Под конец, я решил
рассмотреть отдельные виды тестирования, не входящие в общие классификации, в качестве набора информации по существующим видам тестирования. Я расскажу о каждом из используемых терминов.
Здесь я выделил регрессионное тестирование, конфигурационное тестирование, приемочное, usability, нагрузочное и тестирование производительности.
Регрессионное тестирование – повторное. С его помощью проверяют исправления в программе. Например,
есть дефект. Его фиксят, исправляют, после чего проводят регрессионный тест, т.е. проверяют, исправлена ли ошибка на самом деле или нет. Данный набор действий необходимо выполнять регулярно. Причина -если ошибка возникла, то она вполне может появляться еще не один раз. При выходе каждой новой версии программы, желательно проверять, какие ошибки были до этого, т.к. они могут появляться заново в дальнейшем.
После того, как мы получили новую версию программы, с исправленной ошибкой, провели регрессионный тест, возникает главная проблема – в каком объеме тестировать. Естественно для начала мы проверим ту же самую ошибку, ту же самую ситуацию. Допустим, что эта ошибка исправлена. Но при исправлении кода могли быть внесены изменения и в соседние участки кода, в соседние
функции программы. Поэтому обычно проверяют саму ошибку и функцию, которая находится рядом по логике, либо рядом – в соседнем участке кода, если его просмотр разрешен.
Поэтому здесь проблема понять, в каком масштабе провести регрессионное тестирование.
Часто ошибки появляются там, где тестирование уже успешно пройдено. Это и есть регрессионные ошибки. Поэтому предыдущие тесты прогоняются вновь и вновь. Либо вручную, либо автоматизировано, что довольно удобно в данном случае. Прогонять тесты в автоматическом режиме занимает немного времени. Кроме того, как побочный эффект, при регрессионном тестировании можно смотреть скорость выполнения кода, а также анализировать его размер.
По статистике, от 50 до 80 процентов от общего числа ошибок приходится на изменения в программе: при исправлении багов, при добавлении новых функций, новых опций.
Поэтому регрессионное тестирование необходимо. Надо убедиться, что новая версия программы не содержит ошибок, которых не было и раньше, что в программе ничего не сломано из функционала, который уже успешно работал, плюс надо проверить, что исправленные ошибки действительно исправлены.
Шаги выполнения регрессионного тестирования:
1)получают новую версию программы,
2)проверяют основную функциональность с помощью smoke - тестов,
3)проверяют, исправлены ли ошибки,
4)затем проверяют соседние участки кода,
5)затем проверяют ошибки по этой теме, которые ранее были зарегистрированы, исправлены, и уже успели успешно пройти тестирование.
6)На последнем этапе проверяют те ошибки, которые часто повторялись, т.е. те участки кода, где часто программу ломали заново. Например, ошибка была зарегистрирована, исправлена, не прошла тестирование, после чего опять была исправлена и опять же не прошла тестирование. Такой цикл может повторяться несколько раз. Проверяют часто
повторяемые ошибки, которые исправлялись более 2х раз, затем более одного, затем уже все остальные ошибки. Именно в таком приоритете.
Конфигурационное тестирование – проверка работоспособности системы в различных конфигурациях: операционная система, аппаратное обеспечение (оперативная память, процессор, видео-карта и т.п.). В документации к программе часто указывают требования компьютера для запуска программы, например, оперативная память - 64 Мб, видео – 16 Мб, установленная операционная система – WindowsXPи т.д. На всех заявленных конфигурациях программа должна работать!
На каждой конфигурации должен быть протестирован хотя бы основной функционал. Здесь очень сильно может помочь автоматизация.
Если мы провели тестирование на одной конфигурации, всё это записали и автоматически воспроизвели на других конфигурациях
– это сэкономит массу времени и усилий.
При автоматизации тестов обычно делают привязку к интерфейсу, а так как он не меняется на разных конфигурациях системы, то тест успешно выполняется и на других конфигурациях. Здесь есть подводный камень – в различных браузерах Web – приложения могут отображаться по-разному, поэтому привязка к интерфейсу в данном случае не работает. Поэтому тестирование необходимо провести хотя бы на основных браузерах.
Usability – тестирование – удобство и простота пользования программой.
Мы проверям, насколько быстро пользователь осваивается с программой, насколько ему удобно работать с программой.
Причем тестируется не только программа, но и,например, документация к программе, т.е. всё рассматривается в комплексе.
Например, 60% сайтов сделаны таким образом, что человек не может быстро сориентироваться на сайте. Поэтому необходимо проводить usability – тестирование.
Обычно набирают фокус-группы, в которые включают несколько человек из целевой аудитории, после чего наблюдают за их действиями. Пользователи заходят на сайт, выполняют действия, которые им необходимы. Тестировщики анализируют, насколько быстро пользователи
ориентируются на сайте, сколько времени у них займет понять, как добиться того, что они хотят. После этого надо понять, как сделать так, чтобы пользователям было проще и удобнее пользоваться сайтом. Мнения пользователей также учитывают и принимают в рассмотрение.
