Стратегия тестирования

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

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

Мы предлагаем следующий подход к формулированию стратегии тестирования:

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

2. Определить подход к тестированию за счет выбора статических и динамиче­ ских тестов, связанных с каждой стадией разработки. Здесь потребуется


Глава 3. Планирование испытаний

включить описания всех рабочих продуктов, которые должна подготовить тестовая группа.

3. Определить критерии входа и выхода для каждой стадии тестирования, равно как и все точки контроля качества, для чего потребуется участие специали­ стов по тестированию.

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

Определение объемов тестовых работ



При определении объемов тестовых работ важно рассмотреть вопрос, какая часть программного продукта должна подвергаться тестированию. В области тестирования программного обеспечения давно установлен тот факт, что программу, реализующую большую часть функциональных возможностей, невозможно протестировать полно­ стью. Этот факт исследуется во врезке 3.1 "Можно ли выполнить исчерпывающее тестирование программы?" Ответом, который мы получаем на основе этой врезки, будет "Нет!". Конечно, можно выполнить достаточно исчерпывающее тестирование старой доброй программы, выдающей фразу "hello, world" (привет, мир!), которая содержит всегo лишь несколько строк, не имеет условных переходов, GUI-интерфейса (Graphical User Interface — графический интерфейс пользователя). Тем не менее, для программ, реализующих реальные задачи, всегда характерна опреде­ ленная специфика входных данных, какие-то комбинации входных последовательно­ стей или ветвление кода, до проверки которых просто не доходят руки.

М О Ж Н ОЛИ ВЫПОЛНИТЬ ИСЧЕРПЫВАЮЩЕЕ ТЕСТИРОВАНИЕ П Р О Г Р А М М Ы !

п е р в о е , что потребуется предпринять, прежде чем приступить к проектированию тес-тов, — это определить общий объем работ по тестированию. Нужно ли попытаться вы-Выполнить исчерпывающее тестирование программного обеспечения, или же существуют фундаментальные ограничения относительно того, что можно ожидать от тестовых ра-бот? В данной врезке мы проведем анализ примера компонента программного обеспе­

ч е н и я , исходя из поставленного выше вопроса.

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



Казовая идея представлена на блок-схеме, изображенной на рис. 3.2. На этой диаграм­ ме показано лишь отношение, связывающее ввод и вывод, поэтому не придется вникать h подробности, относящиеся к GUI-интерфейсу и базе данных.

Для простоты положим, что в качестве стандартного почтового индекса может исполь-|зоваться любое пятизначное положительное целое число. Другими словами, входные величины принимают значения из диапазона от 00000 до 99999.


60 Часть I. Процесс быстрого тестирования

Для каждого входного значения программа вычисляет стоимость перевозки, которая ко­ леблется в пределах от $5 до $20. Отображение входа на выход описывается отношени­ ем "многие-к-одному", а это означает, что несколько почтовых индексов могут поро­ дить одну и ту же стоимость перевозки.

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

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

Простой подсчет количества допустимых почтовых индексов говорит о том, что числом допустимых вводов будет 100000 (пятизначные числа, не разрешенные почтовой служ­ бой, игнорируются). Предположим, что автоматизация в данном случае не применяется, т.е. тестирование программы выполняется в неавтоматизированном режиме. Процедура тестирования требует от тестировщика вручную вводить допустимые входные значения, отправлять запросы в базу данных для получения стоимости перевозки, сравнивать вы­ численные значения стоимости перевозок и фиксировать полученные результаты. М о ж ­ но запросто потратить 3 минуты на один ввод, так что на проверку всех допустимых входных значений будет затрачено 5000 часов, что составляет более 2 лет напряженной работы. Кроме того, подобную проверку, возможно, придется выполнить несколько раз, поскольку каждая новая версия должна тестироваться совершенно аналогично.

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

Если дополнительно принять во внимание и все недопустимые значения, диапазон еще больше расширится. Можно также запланировать проверку ввода на предмет недопус­ тимости для отрицательных целых чисел, чисел с десятичной точкой, нечисловых значе­ ний. Это еще больше увеличит количество возможных вводов, поэтому вероятность вы­ полнения 'абсолютно всех таких попыток станет ничтожно низкой. На основе проведен­ ных рассуждений мы приходим к фундаментальному ограничению тестирования:

Ограничение тестирования: Исчерпывающее тестирование компьютерной программы невозможно.

Занимаясь аналогичными исследованиями, Прессман в [43] привел в качестве примера программу на языке С, состоящую из 100 строк с двумя вложенными циклами, причем каждый цикл выполняется от 1 до 20 раз. Во внутреннем цикле находятся четыре конст­ рукций- if-end-else. В своей работе Прессман доказал, что на автоматизированное тести­ рование этой программы при условии, что на проверку каждого из 1014 возможных пу­ тей будет тратиться одна миллисекунда, потребуется 3170 лет.

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

Врезка 3.1


Глава 3. Планирование испытаний

Входные данные Вычисление Выходные данные
стоимости
Почтовый индекс перевозки Стоимость перевозки

Рис. 3.2. Функциональные возможности тестируемой программы

Поскольку подвергнуть тестированию абсолютно все невозможно, важность вы­ бора того, что нужно протестировать, сомнений не вызывает. Если допустить "пере­ бор" в тестировании, т.е., если тестовое покрытие будет избыточным, то для отладки программного продукта потребуется значительное время, что поставит под угрозу срок сдачи проекта. Если тестирование окажется недостаточным (точнее, недоста­ точным будет тестовое покрытие), то увеличится риск пропуска того или иного де­ фекта, устранение которого будет стоить очень дорого, особенно после сдачи про­ граммного продукта в эксплуатацию. Отыскать нужный баланс между этими двумя крайностями поможет опыт и способ измерения успешности тестирования.

Вот несколько предложений по разработке стратегии тестирования, которые по­ могут в поиске оптимального тестового покрытия.

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

Тестируйте новые функциональные возможности и программный код, кото­ рый изменялся с целью исправления или совершенствования старых функ­ циональных средств.Эвристическое правило гласит: если программный кодподвергался исправлениям, его необходимо протестировать. В начальной версии программного продукта новым является все. Однако если версия является оче­ редным обновлением или эксплуатационной версией, особое внимание следует уделить новому коду. Имейте в виду, что любые изменения, внесенные в про­ граммный код, могут исказить даже те части программы, которые непосредствен­ но "не затрагиваются" изменениями. В этом случае лучше всего как можно чаще выполнять регрессионные тесты для всей функциональности программы, какими бы ни были изменения в коде.

Используйте разбиение на эквивалентные классы и анализ граничных значе­ ний для снижения трудозатрат на тестирование.Эти технологии описаны в гла­вах 4 и 10; обе технологии могут использоваться для выявления максимального



0402771922138355.html
0402830109642506.html
    PR.RU™