Когда я купил дом, забор вокруг заднего двора был в довольно плохом состоянии. Однажды летом я решил построить новый забор. Через пару дней тяжелого труда забор выглядел превосходно. На следующий день мой сосед вернулся из какой-то поездки и спросил: "У вас телефон работает?" Я тут же понял, что произошло: копая последнюю яму для опоры моего нового забора, я повредил телефонный кабель соседа. Пытаясь исправить одну проблему (старый забор), я создал новую, даже не заметив ее (мой сосед лишился телефона).
Я рассказал эту историю для того, чтобы проиллюстрировать понятие регрессии. Иногда при разработке и обслуживании программного обеспечения могут иметь место аналогичные ситуации. Когда разработчик добавляет новую функцию или исправляет дефект в системе, существует вероятность того, что изменяемый код используется какой-нибудь функцией, которая вроде бы не имеет к нему никакого отношения. Откуда мне было знать, что тот же клочок земли, который я хотел использовать под свой забор, уже использовался под телефонный кабель моего соседа? Если при каждом изменении кода мы тестируем только саму новую функцию, то нельзя быть уверенным, что все используемые функции продолжают работать. В моем случае готовый забор выглядел замечательно, но мой сосед больше не мог звонить по телефону (чего я совершенно не заметил).
Есть только один способ убедиться в том, что мы не нарушили существующую функциональность - это повторно протестировать все функции при каждой ревизии или итерации системы. Именно это мы называем функциональным регрессионным тестированием.
Функциональное регрессионное тестирование можно выполнять вручную. Проблема заключается в том, что с развитием проекта набор функциональных тестов выполняется все медленнее. В какой-то момент времени на выполнение набора тестов вручную может потребоваться больше времени, чем на создание новой сборки!
Когда это случится, рабочей группе придется сделать непростой выбор. Необходимо будет найти способ, позволяющий определить, какие тесты являются менее важными и могут быть опущены для некоторых или всех тестов сборки. Дверь для регрессий, кроющихся в таких непротестированных функциях приложения, будет открыта.
Что такое IBM Rational Functional Tester ?
IBM Rational Functional Tester представляет собой инструмент для автоматизации функционального регрессионного тестирования. Другими словами, он использует компьютер для того, чтобы выполнить тесты гораздо быстрее, чем это можно сделать вручную. Ключ к этому - запись взаимодействий пользователя с приложением и обеспечение возможности повторить эти взаимодействия впоследствии. Именно этим мы и займемся чуть позже.
Обратите внимание на то, что IBM Rational Functional Tester - инструмент для функционального регрессионного тестирования. Rational Functional Tester не предназначен для создания нагрузки при стрессовом тестировании. Для этого необходим инструмент Rational Performance Tester. В предлагаемом учебном руководстве мы продемонстрируем использование модуля расширения для тестирования функций приложения, а не его масштабируемости.