Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Отчет_Роман_Уваров.docx
Скачиваний:
6
Добавлен:
28.09.2019
Размер:
58.66 Кб
Скачать

По субъекту тестирования

  • альфа-тестировщик (alpha tester);

  • бета-тестировщик (beta tester).

Альфа-тестеры, это сотрудники компании или сотрудники компании подрядчика, тестирующие разрабатываемое приложение. Тестирование проводится с помощью профессиональных методов.

Бета-тестеры – люди не являющиеся сотрудниками компании или же подрядчиками. В большинстве случаев, бета-тестеры относятся к будущим пользователям разрабатываемого ПО. Тестируют приложение просто работая с ним как целевые пользователи.

По времени проведения тестирования

  • тест приемки (smoke test, sanity test или confidence test);

  • тестирования новых функциональностей (new feature testing);

  • регрессивное тестирование (regression testing);

  • тест сдачи (acceptance или certification test).

Тест приемки осуществляется в при передачи приложения от разработчиков к инженерам по тестированию на очередной итерации разработки. Тест приемки состоит из проверки самых базовых функциональностей, при неработоспособности которых более детальное невозможно и/или не имеет смысла.

Тестирование новых функциональностей направлено на проверку возможностей системы, появившихся в разрабатываемом приложении после очередной итерации.

При регрессивном тестировании, выполняются все ранее написанные тесты или же тесты проверяющие область в которой были совершены изменения. Регрессивное тестирование необходимо для обнаружения дефектов вызванных изменениями сделанными разработчикам в уже существующих областях программы, а так же для проверки влияния новых функциональностей на уже существующие.

Тест сдачи, это финальное тестирование приложения перед релизом версии. Включает в себя полную регрессию, тестирование на совместимость, производительность и т.п.

По критерию "позитивности" сценариев

  • позитивное тестирование (positive testing);

  • негативное тестирование (negative testing).

При позитивном тестировании проверяются результаты работы приложения при получении им «правильных» входных данных. Позитивное тестирование предполагает «правильное» использование системы и тестовые сценарии строятся на этом основании.

Негативное» тестирование показывает как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того что бы обнаружить ошибки вызванные некорректными данными или неверным обращением пользователем с системой. Как правило негативное тестирование находит больше ошибок, но более приоритетным является позитивное тестирование, т.к. способность приложения работать в правильных условиях, важнее чем его способность справляться с ошибками исключениями.

По степени изолированности тестируемых компонентов

  • компонентное тестирование (component testing);

  • интеграционное тестирование (integration testing);

  • системное тестирование (system or end-to-end testing).

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится по средствам вызовов функций и методов кода, который необходимо проверить при поддержке сред разработки, таких как фреймворки для модульного тестирования.

Интеграционное тестирование (Integration testing) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию. Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группы модулей — выполняется через их интерфейс, с использованием тестирования «чёрного ящика».

Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.