Данная статья раскрывает понятие тестирования программного обеспечения, объясняет, для чего нужно тестирование, а также описывает наиболее интересные и эффективные способы тестирования программного обеспечения.
Одним из этапов создания программного обеспечения является его тестирование. Наверняка каждый разработчик в начале своего пути пытался выяснить, когда же процесс тестирования и отладки может быть завершен? В какой момент можно анализировать результаты и передавать проект в эксплуатацию?
Большинство разработчиков понимает, что программ без ошибок не бывает, но на определенном этапе тестирования возникает вопрос: «Стоит ли дальше искать ошибки, или можно оставить некоторые из них до следующего этапа разработки?".
На сегодняшний день не существует такого метода тестирования, который бы позволил полностью обнаружить все дефекты и установить корректность функционирования исследуемого программного обеспечения.
Как говорил Эдгар Дейкстра (1970): «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие».
Ошибки бывают разные, и на поиск каждой ошибки уходит разное время. Зачастую, на полное тестирование программы просто не хватает времени, поэтому во всех режимах и со всеми параметрами оно трудно реализуемо.
Тестирование программного обеспечения — это процесс исследования, испытания программного продукта, для демонстрации разработчикам и заказчикам, что программа соответствует требованиям и (или) для выявления ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
За всю историю своего развития, процедура тестирования претерпела множество изменений, начиная от строго формализованного тестирования, которое использовалось для тестирования программ для нужд министерства обороны. В 1960-х внимание в основном уделялось полному тестированию, предполагающему полный проход всех алгоритмов с различными входными данными. Позднее такое тестирование было признано невозможным. В 1970-х понятие тестирования определялось двойственно. С одной стороны, тестирование считалось успешным, когда программа демонстрировала корректную работу, но, с другой стороны, успешным считалось то тестирование, в результате которого были найдены некоторые ошибки в работе программы. В 1980-е годы тестирование вышло на новый уровень. Тестированию подвергался не уже готовый продукт, а продукт в процессе всего цикла разработки. В это время появлялись первые инструменты для автоматизированного тестирования. В 1990-х начали появляться различные программные инструменты для поддержки процесса тестирования. В 2000-х появилось еще более широкая методология тестирования, которая предполагала максимизацию значимости всех этапов жизненного цикла программы.
Существует несколько подходов к тестированию, которые предлагают различные алгоритмы. Но в основном, это процесс творческий, который не всегда придерживается определенных правил.
Конечно, тестирование наиболее полезно на ранних этапах разработки проекта, так как это более экономично. Программа считается готовой к выпуску, когда устранены абсолютно все критические ошибки и ~85 % не критических ошибок. Считается, что дальнейшее тестирование экономически не целесообразно.
Так как у программного обеспечения (ПО) отсутствует эталон, к которому необходимо стремится, чтобы оно считалось полностью протестированным, то следует стремиться к некоторым уровням качества.
К таким уровням относятся:
- отсутствие остановок работы ПО;
- отсутствие синтаксических ошибок;
- выполнение функций ПО, описанных в техническом задании без ошибок;
- соответствие расчетных значений эталонным.
В тот момент, когда программное обеспечение соответствует всем вышесказанным уровням, оно считается протестированным и его можно передавать в эксплуатацию. Далее ПО будет передано на тестирование пользователям, которое будет продолжаться в течение всего времени пользования.
За все время существования программирования определилось несколько признаков, по которым принято производить тестирование программы: по объекту тестирования, по знанию системы, по степени автоматизации, по степени изолированности компонентов, по времени проведения тестирования, по признаку позитивности сценариев, по степени подготовленности к тестированию.
По уровням тестирования можно выделить несколько основных типов:
- модульное тестирование — тестируется минимальный компонент программы (класс, функция);
- интеграционное тестирование — тестируются межкомпонентные элементы;
- системное тестирование — тестирование всей системы на соответствие установленным требованиям;
- альфа-тестирование — штатные разработчики или потенциальные пользователи имитируют реальную работу с системой;
- бета-тестирование — распространение пробной версии программного обеспечения для большей группы лиц, с целью удостоверится в отсутствии ошибок.
Все технологии тестирования можно разделить на две большие группы: статическое и динамическое тестирование. В динамическом тестировании код исполняется, а в статическом — не выполняется. Здесь анализ программы происходит на основе исходного кода.
К наиболее интересным и эффективным техникам можно отнести тестирование белого ящика и тестирование черного ящика. Обе эти техники предполагают, что код исполняется, и разница состоит лишь в том, какой информацией владеет тестировщик.
При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения.
При тестировании чёрного ящика, тестировщик имеет доступ к программе только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования.
Так же эффективным во многих случаях может быть регрессионное тестирование. Эта технология тестирования позволяет подтвердить, что изменения, внесенные в программу при выпуске новой версии, не повлияли на работоспособность программы.
В некоторых случаях, тестировщики прибегают к тестовым скриптам. Тестовые скрипты пишутся для проверки компонентов, в которых высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.
Помимо технологий тестирования были разработаны несколько эвристик, которые предлагают ситуации для остановки тестирования. Эвристики — это быстрые, недорогие способы решения проблемы или принятия решения. Эвристики подвержены ошибкам, то есть они могут, как сработать, так и не сработать. Таких эвристик на данный момент существует 11 штук. Каждая из них работает в определенном контексте, поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Рассмотрим их.
1. Эвристика «Время вышло!". Самая распространенная эвристика. Тестирование заканчивается, как только вышло отведенное на него время.
2. Эвристика «Мертвой лошади». Тестирование заканчивается, когда обнаруживается слишком много ошибок, и дальнейшее тестирование не имеет смысла.
3. Эвристика «Освежающей паузы» предполагает приостановку тестирования, когда стало скучно или пропало вдохновение. Так же пауза может возникнуть из-за появления ошибки большего приоритета.
4. Эвристика «Отсутствие продвижения». Любые тесты приводят к одним и тем же результатам.
5. Эвристика «Больше нет интересных вопросов». Все важные основные вопросы получили свои ответы. Используется обычно в дополнение с другими эвристиками.
6. Эвристика «Пиньяты». Тестирование прекращается в тот момент, когда возникает достаточно явная серьезная проблема.
7. Эвристика «Задание выполнено». Тестирование прекращается тогда, когда получены ответы на поставленные вопросы.
8. Эвристика «Отмена задания». К этой категории относится прекращение тестирование по требованию заказчика.
9. Эвристика «Зашел в тупик». Остановка тестирование происходит по причине того, что имеется блокирующая ошибка, которая не препятствует тестированию области программы. Проблема может исходить от недостатка оборудования или же от недостатка квалификации тестировщиков.
10. Эвристика «Привычного завершения». Тестирование завершается в соответствие с протоколом, задающим некоторое количество идей для тестирования или циклов тестирования.
11. Эвристика «Уклонения/безразличия». Такой вариант возможен в том случае, если тестировщикам не интересно как работает программа, или тестируемое ПО является первой версией, которую вскоре заменят.
Подводя итоги вышесказанному, тестирование программного обеспечения — это трудоемкий процесс, который не подвергается определенным правилам и не всегда следует по определенному алгоритму. Нельзя сказать, что для определенного типа программ больше подходит определенная технология тестирования. Для каждого определенного случая подбирается своя методика тестирования и свои эвристики остановки. Этот выбор зависит от многих критериев, таких как тип программного обеспечения, цели создания программного обеспечения, задачи, для выполнения которых создавалось данное программное обеспечение. Человек, занимающийся тестированием программного обеспечения должен обладать большим багажом знаний для эффективного и своевременного поиска ошибок.
Литература:
1. Гленфорд Майерс, Том Баджетт, Кори Сандлер. Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. — М.: «Диалектика», 2012.
2. Канер Кем, Фолк Джек, Нгуен Енг Кек. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001.
3. Калбертсон Роберт, Браун Крис, Кобб Гэри. Быстрое тестирование. — М.: «Вильямс», 2002.
