Как вы будете классифицировать различные методы тестирования программного обеспечения?
Будет ли это правильно?
Черный ящик
1.1 Функциональный
1.1.1 Equivalence 1.1.2 BVA 1.1.3 Use case 1.1.4 Regression 1.1.5 UAT
1.2 Нефункциональный
1.2.1 Testing the System Design
белая коробка
2.1. функциональная
2.1.1 Unit 2.1.2 Integration 2.1.3 System
Подпадают ли вышеперечисленные под правильные категории?
Причина, по которой я спрашиваю об этом, заключается в том, что в качестве части отчета я пытался найти хорошую справку, которая хорошо классифицировала методы испытаний. Это то, что мне дали мой анализ и исследование из разных источников. И я надеюсь, что это полезно для кого-то еще, кто может делать то же самое исследование, но если оно неверно, оно должно быть обновлено.
3 ответа
Вы также можете рассмотреть случай, когда несколько программ, зависящих друг от друга, разрабатываются одновременно. Затем вы должны принять во внимание аппликативную архитектуру, которая группирует все эти приложения в несколько функциональных областей.
Так, например, финансовое приложение, обрабатывающее большое количество данных, будет одной функциональной областью, в которой вам необходимо будет разработать:
- диспетчерский модуль для обработки этих данных на нескольких компьютерах
- GUI для того, чтобы увидеть, что происходит
- средство запуска, чтобы инициировать правильные соединения, получить правильные данные и отформатировать их
- и так далее
Но это был бы только один функциональный домен, так как другие должны были бы быть разработаны для использования результатов ваших программ (например, был бы "ссылочный домен", чтобы хранить эти результаты в различных базах данных и предлагать коммуникационную шину). для других программ, чтобы получить к ним доступ: это будет второй функциональный домен).
Поэтому я бы добавил к вашим тестам следующие категории:
- Тестирование сборки: при тестировании в вашем собственном функциональном домене (на сервере сборки при развертывании различных приложений вашего домена с набором данных тестирования)
- Интеграционное тестирование: когда вы тестируете все приложения из всех функциональных областей, что также называется фронтальным тестированием.
Примечание. "Интеграционное тестирование" - это не то же самое, что "непрерывное интеграционное тестирование", которое в основном может обрабатывать черно-белые тесты, которые вы описываете для одной программы, на очень регулярной основе.
Тесты, на которые я ссылаюсь, выполняются несколько раз в неделю:
- Команда "Project Operational Architecture" вашего домена для тестов сборки: обычно некоторые разработчики вашей команды, которые устанавливают сервер сборки, проверяют актуальность данных и внедряют различные программы, которые вы ответственны за разработку.
- Команда "Production Operational Architectural", отвечающая за настройку "производственной" среды и единственная, кто действительно может протестировать всю цепочку приложений от шрифта до задней части.
Примечание: команда "Операционная архитектура" играет роль "сделать операционную среду выполнения", то есть иметь:
- правильные контакты команды логистики, чтобы иметь правильные серверы и сети,
- Нужные контактные группы прикладных программ, чтобы узнать о различных процессах запуска / остановки приложений и процедурах развертывания всего приложения вашей системы!
Вкратце: ваши категории относятся к одной программе, но когда вы разрабатываете IS (информационную систему), вы вынуждены признать тот факт, что вы не говорите об "одном exe-файле, разработанном одной командой, развернутой на одной рабочей машине".. а затем добро пожаловать в новый мир тестирования;)
Ниже приведены методики тестирования, широко определенные в разделе "Тестирование программного обеспечения":
1. Black Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура / дизайн / реализация тестируемого элемента не известны тестировщику. Эти тесты могут быть функциональными или нефункциональными, хотя обычно они функциональные. Методы разработки теста включают в себя: Эквивалентное разделение, Анализ граничных значений, Графики причинно-следственных связей.
2. White Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура / дизайн / реализация тестируемого элемента известны тестировщику. Методы проектирования тестов включают в себя: тестирование потока управления, тестирование потока данных, тестирование филиала и тестирование пути.
3. Тестирование серого ящика - это метод тестирования программного обеспечения, представляющий собой комбинацию метода тестирования черного ящика и метода тестирования белого ящика.
Я думаю, что ваша категоризация - это хороший первый шаг.
Разделение между черным ящиком и белым ящиком (некоторые предпочитают стеклянный ящик) фокусируется на том, есть ли у вас доступ только к спецификации или более (дизайн, исходный код).
Я бы добавил второе разделение между функциональным и структурным тестированием, которое фокусируется на том, хотите ли вы рассмотреть, что делает программное обеспечение (функциональное) или как оно делает (структурное).
Третье разделение касается того, как вы генерируете входные данные теста, детерминистически или статистически (с преднамеренным распределением, а не случайным образом). В любом случае, вы сосредоточены на том, какое покрытие вы нацеливаете.
Наконец, хорошо известно разделение между различными уровнями программного цикла: модульное тестирование, интеграция, система, приемка,...