Тестирование и отладка программного обеспечения (ПО)

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

Основные термины

Тестирование (testing) – процесс выполнения программы с целью найти ошибки. Может выполняться как с компьютером, так и без него (общий термин).
Доказательство (proof) – попытка найти в программе ошибки путем доказательств на основе математических теорем о правильности программы безотносительно к внешней программной среде (вид тестирования).
Контроль (verification) – попытка найти ошибки, выполняя программу в тестовой или моделируемой среде (вид тестирования).
Испытание (validation) – попытка найти ошибки, выполняя программу в заданной программной среде (вид тестирования).
Аттестация (certification) – авторитетное подтверждение правильности программы (итоговое тестирование, для критичного ПО).

Отладка (debugging) – средство установления точной природы ошибок, процесс, противоположный тестированию, ведет к устранению ошибок.

Виды тестирования

Автономное тестирование, тестирование модуля  (module testing) –  контроль отдельного модуля в изолированной среде (например, с помощью ведущей программы), инспекция текста модуля на сессии программистов, которая иногда дополняется математическим доказательством правильности модуля.
Тестирование сопряжений (integration testing) – контроль сопряжений между частями системы, как между компонентами в комплексе, так и между модулями отдельного компонента (например, у заглушки).
Комплексное тестирование (system testing) – контроль  и/или испытание системы по отношению к исходным целям. Является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания в реальной среде.

ПРИНЦИПЫ (аксиомы) тестирования

  1. Хорош тот тест, для которого высока вероятность обнаружения ошибки.
  2. Главная проблема тестирования – решить, когда закончить (кончаются деньги и время).
  3. Невозможно тестировать собственную программу.
  4. Необходимая часть тестов – описание выходных документов.
  5. Избегайте не воспроизводимых тестов.
  6. Готовьте тесты как для правильных, так и для неправильных данных.
  7. Не тестируйте «с лету».
  8. Детально изучайте результаты каждого теста.
  9. По мере обнаружения все большего числа ошибок в некотором модуле или программе, растет вероятность обнаружения в ней еще большего числа ошибок.
  10. Тестируют программу — лучшие умы.
  11. Считают тестируемость главной задачей разработчиков программы.
  12. Не изменяй программу, чтобы облегчить тестирование.
  13. Тестирование должно начинаться с постановки целей.

Мои примечания к аксиомам тестирования:

  1. Не гордитесь тестом, который не обнаружил ни одной ошибки.
  2. При планировании разработки выделяйте не менее 50% времени на тестирование и отладку, тогда у вас появится шанс закончить работу в срок.
  3. Другой человек не будет испытывать уважения к вашим способностям писать правильный код. Поэтому, когда нет возможности передать тестирование другому разработчику, следует отстраниться от своей разработки и отнестись к ней как чужой (такой психологический настрой).
  4. Если вы не описали заранее ожидаемые результаты, то даже неумышленно можно истолковать фактические результаты как верные.
  5. Не воспроизводимые тесты – тесты, которые нельзя повторить нужное количество раз.
  6. Обязательно в наборе тестов должны быть входные данные, которые могут не соответствовать смыслу задачи (смотри пример с формулой Герона), либо формату вводимых данных.
  7. Тестирование «с лету» подразумевает, что тесты не следует придумывать после написания кода, это следует делать заранее.
  8. Группируйте ошибки тестирования, постарайтесь понять их природу.
  9. Рекомендация относится к коллективной разработке, когда менее опытный программист делает много ошибок в своем коде программы.
  10. Тестирование – творческий процесс, автор тестов должен понимать технологию тестирования и иметь собственный опыт программирования.
  11. Например, методология структурного программирования обеспечивает обозримость ПО за счет деления его на модули и стандартизации их взаимодействия. Полезными свойствами программного кода является осмысленный выбор идентификаторов объектов наличие комментариев.
  12. Вы можете изменить программу в процессе отладки. Важно – не забыть восстановить полезный код.
  13. Для каждого процесса тестирования начинайте с определения цели.

Связь процесса тестирования с процессом проектирования ПО

 В процессе проектирования ПО обычно принимаются следующие решения:

  1. Требования к ПО (область применения, назначение, условия эксплуатации);
  2. Цели создания ПО (решение определенных задач);
  3. Внешние спецификации «что должно делать ПО» (функции и требования к ним)
  4. Архитектура системы;
  5. Структура программы (разбиение на программные модули);
  6. Внешние  спецификации модуля (функции модуля);
  7. Логика модуля (алгоритмы);

Как вы видите, процесс непосредственного кодирования не включен в проектирование.

Процессы тестирования (в скобках указаны номера связанных с ними процессов проектирования):

1. Автономный тест (6, 7)
2. Тест сопряжений (4, 5)
3. Тест функций (3)
4. Комплексный тест (2)
5. Тест приемлемости (1)

Тестирование ПО включает:

1) постановку задачи;
2) проектирование тестов;
3) написание тестов;
4) тестирование тестов;
5) выполнение тестов;
6) изучение результатов тестирования.

Два крайних подхода к проектированию тестов:

«Черный ящик» — недостижимый идеал: проверить все возможные комбинации и значения входных данных.
«Белый ящик» — связывание теста только с логикой программы:

  • Каждая команда – хотя бы один раз;
    Каждый условный переход – в каждом направлении хотя бы раз;
    Цикл – ни разу, один раз, максимальное число раз.

Две стратегии тестирования: восходящее и нисходящее

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

Критерии выбора стратегии тестирования

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

Отладка

После цикла тестирования начинается цикл отладки программы.

Самое сложное – понять по результатам тестирования причину ошибки. Ошибка в модуле (например, в методе обработки некоторого события) может быть связана как с логикой обработки данных, так и с ошибкой сопряжений (при передаче параметров). Ошибки вызова форм приложения могут быть связаны с неверно выбранным способом их взаимодействия.

Далее выдвигается гипотеза, которая проверяется после изменения программного кода.

Важно, что после этого следует снова выполнить (полное или частичное) тестирование, так как любое изменение кода может внести новые ошибки.


NEW: Наш Чат, в котором вы можете обсудить любые вопросы, идеи, поделиться опытом или связаться с администраторами.


Помощь проекту:

Понравилась статья? Поделиться с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x
()
x