 |
Общая стратегия тестирования
|
|
|
|
Задачи, которые возникают в процессе тестирования модулей:
· Планирование тестирования.
· Разработка тестов.
· Формирование отладочных заданий.
· Собственно тестирование.
· Обработка результатов тестирования.
Методы тестирования можно различать по следующим признакам:
· Степень автоматизации: ручные, автоматизированные методы.
· Форма представления модуля: символьная (на языке программирования), машинный код.
· Компоненты программы, на которые направлено тестирование: структура программы или преобразование переменных.
· Статические или динамические методы.
В книге [12] отмечается, что в первую очередь следует тестировать структуру программы, так как операторы анализа условий составляют в среднем 10-15% от общего числа операторов программы.
Искажение логики работы программы приводит к серьезным ошибкам. К тому же данный вид тестирования имеет наилучшие показатели эффективность/стоимость.
Существует два вида тестирования потоков данных:
· Анализ решений.
· Проверка по аналитическим формулам.
В [12] предлагается следующая методика тестирования модулей. Нужно последовательно проводить различные виды тестирования, начиная с самых простых:
1. Ручное тестирование (работа за столом).
2. Символическое тестирование (инспекции, сквозные просмотры).
3. Тестирование структуры.
4. Тестирование обработки данных.
5. Функциональное тестирование (сравнение со спецификацией, взаимодействие с другими модулями).
Способы тестирования взаимодействия модулей
Существуют два способа проверки взаимодействия модулей[1,с.107]:
· Монолитное тестирование.
· Пошаговое тестирование.
Пусть имеется программа, состоящая из нескольких модулей
|
|
|
Рисунок 1
Обозначения:
Прямоугольники – модули, тонкие линии представляют иерархию управления (связи по управлению между модулями), жирные стрелки – ввод и вывод данных в программу.
Монолитное тестирование заключается в том, что каждый модуль тестируется отдельно. Для каждого модуля пишется один модуль драйвер, который передает тестируемому модулю управление, и один или несколько модулей-заглушек.
Например, для модуля B нужны 2 заглушки, имитирующие работу модулей Е и F.
Когда все модули протестированы, они собираются вместе и тестируется вся программа в целом.
Пошаговое тестирование предполагает, что модули тестируются не изолированно, а подключаются поочередно к набору уже оттестированных модулей.
Недостатки монолитного тестирования (перед пошаговым):
1. Нужно много дополнительных действий (написание драйверов и заглушек).
2. Поздно обнаруживаются ошибки в межмодульных взаимодействий.
3. Следствие из 2 – труднее отлаживать программу.
Преимущества:
1. Экономия машинного времени (в настоящее время существенной экономии не наблюдается)
2. Возможность параллельной организации работ на начальной фазе тестирования.
Стратегии выполнения пошагового тестирования
Существую две принципиально различных стратегии выполнения пошагового тестирования[1, с.111]:
· Нисходящее тестирование.
· Восходящее тестирование.
Нисходящее тестирование
Начинается с головного модуля, в нашем случае с модуля А.
Возникают проблема: как передать тестовые данные в А, ведь ввод и вывод осуществляется в других модулях? Как передать в А несколько тестов?
Решение:
а) Написать несколько вариантов заглушек B, для каждого теста
б) Написать заглушку B так, чтобы она читала тестовые данные из внешнего файла.
Стратегии подключения модулей:
|
|
|
а) подключаются наиболее важные с точки зрения тестирования модули
б) подключаются модули, осуществляющие операции ввода/вывода (для того, чтобы обеспечивать тестовыми данными «внутренние» модули
Однако нисходящее тестирование имеет ряд недостатков:
Предположим, что модули I и J уже подключены, и на следующем шаге тестирования заглушка H меняется на реальный модуль H.
Как передать тестовые данные в Н?
Это нетривиальная задача, потому что между J и Н имеются промежуточные модули и может оказаться невозможным передать тестовые данные, соответствующие разработанным тестам.
К тому же достаточно сложно интерпретировать результаты тестирования Н, так как между Н и I также существуют промежуточные модули.
Восходящее тестирование
Практически противоположно нисходящему тестированию.
Начинается с терминальных (не вызывающих другие модули) модулей.
Стратегия подключение новых модулей также должна основываться на степени критичности данного модуля в программе.
Лишено недостатков нисходящего тестирования, однако имеет свой, главный недостаток:
Рабочая программа не существует до тех пор, пока не добавлен последний (в нашем случае А) модуль.
Выбор одной их двух представленных стратегий определяется тем, на какие модули (верхнеуровневые или модули нижнего уровня) следует обратить внимание при тестировании в первую очередь.
|
|
|
