Lesson 52

Ах, да.
Благодаря конторе и начальству еду на sqa days 10. Еще едут 2 тестировщицы.
Хорошо.

Екб, кто-нибудь еще будет там?
Не екб: Феликс? Редфокс? Думтест? Кто там еще-то... Вас увижу?

4-го буду в мск. Там есть что-нибудь интересное?

Слово Канеру:

Техники тестирования основанные на том, как вы тестируете.


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

Тестирование по плану Ручное тестирование, обычно выполняемое новичками, которые шаг за шагом следуют плану тестирования, написанному старшим тестировщиком.

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


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

Партизанское тестирование Быстрая и грязная атака продукта. Форма исследовательского тестирования, ограниченная во времени, выполняемая опытным тестировщиком-исследователем. Например старший тестировщик может потратить один день на область, которая в противном случае игнорировалась бы. Он пробует на продукте самые мощные свои атаки. И если находит серьезную проблему, то область будет перетестирована и может быть изменен весь план тестирования. Если он не находит проблем, то и в дальнейшем область будет игнорироваться или походить лишь небольшие испытания.

Тестирование по сценарию Обычно обладает четырьмя атрибутами. 1) Тесты должны быть реалистичны. Они должны повторять то, что обычно делают с продуктом заказчики. 2) Тесты должны быть сложными, включать в себя использование нескольких функций. 3) По ним должно быть просто определить, прошла программа тест или нет. 4) Заинтересованные лица должны согласиться, что программа должна быть исправлена если не выдержит этой проверки. Тест, обладающий всеми четырьмя атрибутами будет убедительным, и давать на выходе реальные баги. Однако вам придется долго создавать и поддерживать качественные сценарии.

Тестирование по сценарию (прим. w_bf: это не я ошибся, это у Канера повтор) Тесты, основанные на кейсах использования продукта обычно называют тестами по сценарию (Jacobson 1992, Collard 1999) или юзкейс-тестами. (Многие люди классифицировали бы их как тесты основанные на покрытии важных сценариев использования)

Тестирование установки Установка ПО различными путями на различных системах. Проверка того, какие файлы добавлены и изменены на диске. Работает ли установленная программа? Что случится при удалении программы?

Стресс тестирование Тестирование системы, находящейся под атакой\нагрузкой и требующей для работы большого количества ресурсов. Под высокой нарузкой система имеет высокую вероятность падения, но картина событий, предшествующих падению может указывать на уязвимость в ПО, которая может быть использована. Asbock (2000) - отличная инструкция по нагрузочному тестированию.

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

Тестирование производительности Такие тесты проводят для определения того, как быстро работает программа, чтоб решить, нуждается ли ПО в оптимизации. Но такие тесты могут найти и многие другие баги. Значительные изменения в производительности по сравнению с предыдущим релизом могут идентифицировать эффект от ошибки в программе. Например, если проверите, как долго работает некая функция сегодня, а затем проверите то же самое завтра, вы вероятно, сможете проверить это вместе с программистом и написать отчет об ошибке, в случае если тест прошел значительно быстрее или медленнее. Либо считать эти изменения подозрительными, так как произошли фундаментальные изменения в программе.
Sam Guckenheimer заметил: "Разница в производительности также может означать изменения в сторонних компонентах ПО или изменения в конфигурации. Например изменения в JVM с различными релизами JDK. Так тестирование производительности может даль удивительные результаты, даже если ваш код не менялся вообще."