Принципы тестирования

ПРИНЦИПЫ ТЕСТИРОВАНИЯ


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

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

Не нужно тестировать свою собственную программу. Ни один программист не должен пытаться тестировать свою собственную программу. Это относится ко всем формам тестирования — как к тестированию системы, так и к тестированию внешних функ­ций и даже отдельных модулей. Тестирование должно быть в высшей степени разрушительным процессом, но имеются глубо­кие психологические причины, по которым программист не мо­жет относиться к своей собственной программе как разрушитель. Дополнительное давление (например, жесткий график) на отдель­ного программиста или весь коллектив разработчиков проекта часто мешает программисту или всему коллективу выполнить адекватное тестирование. Если модуль содержит дефекты вслед­ствие каких-то ошибок перевода, довольно высока вероятность того, что программист допустит ту же ошибку перевода (напри­мер, неправильно интерпретирует спецификации) и при подго­товке тестов.

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

Отсюда вовсе не следует, что программист не может тестиро­вать свою программу. Многие программисты с этим вполне ус­пешно справляются. Здесь лишь делается вывод о том, что тести­рование является более эффективным, если оно выполняется кем-либо другим. Заметим, что все наши рассуждения не относятся к отладке, т. е. к исправлению уже известных ошибок. Эта работа эффективнее выполняется самим автором программы.Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Одна из самых распростра­ненных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидае­мые результаты нужно определять заранее, чтобы не возникла ситуация, когда «глаз видит то, что хочет увидеть».

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

Поэтому во многих случаях оказывается важной не абсолютная точность, а корреляция ошибок. Например, когда математичес­кая программа возвращает массив чисел, может оказаться важ­ным, чтобы вычисленное решение было точным решением для набора входных данных, аппроксимирующего реальные выход­ные данные. Поэтому при тестировании математического про­граммного обеспечения прогнозирование точных выходных дан­ных затруднительно.Избегайте невоспроизводимых тестов, не тестируйте «слету». Использование диалоговых систем иногда мешает хорошему тес­тированию. Для того чтобы тестировать программу в пакетной системе, программист обычно должен оформить тест в виде спе­циальной ведущей программы или в виде файла тестовых дан­ных.

В условиях диалога программист слишком часто выполняет тестирование «с лету», т. е. сидя за терминалом, задает конкрет­ные значения и выполняет программу, чтобы «посмотреть, что получится». Это неряшливая и по многим причинам нежелатель­ная форма тестирования. Основной ее недостаток в том, что та­кие тесты мимолетны; они исчезают по окончании их выполне­ния. Всякий раз, когда программу понадобится тестировать по­вторно (например, после исправления ошибок или после модификации), придется придумывать тесты заново.Тестирование обходится слишком дорого и без этих допол­нительных расходов. Никогда не используйте тестов, которые тут же выбрасываются. Тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно.

Готовьте тесты как для правильных, так и для неправильных входных данных. Многие программисты ориентируются в своих тестах на «разумные» условия на входе, забывая о последствиях появления непредусмотренных или ошибочных входных данных. Однако многие ошибки, которые потом неожиданно обнаружи­ваются в работающих программах, проявляются вследствие ни­как не предусмотренных действий пользователя программы. Тес­ты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем правильные тесты.

Детально изучите результаты каждого теста. По всей веро­ятности, это наиболее очевидный принцип, но и ему часто не уде­ляется должного внимания. Самые изощренные тесты ничего не стоят, если их результаты удостаиваются лишь беглого взгляда. Тестирование программы означает большее, нежели выполнение достаточного количества тестов; оно также предполагает изуче­ние результатов каждого теста. «Да, я уже проверял такую ситу­ацию, но такого как-то не заметил в выдаче», — довольно рас­пространенная реакция программиста на обнаруженную новую ошибку.

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

Считайте тестируемость ключевой задачей вашей разработки.Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз. Множество проблем во многих больших программных системах возникает из-за наруше­ния этой аксиомы. Ситуация, когда во время цикла тестирования большой системы некоторые модули приходится подключать больше десяти раз, — не редкость. Каждая версия такого модуля содержит еще одну маленькую дополнительную функцию, необ­ходимую для текущего уровня системы. Если следовать правилам и проектировать небольшие модули, каждый из которых выпол­няет отдельную функцию, бороться с этой проблемой станет легче.Никогда не изменяйте программу, чтобы облегчить ее тести­рование. Часто возникает соблазн изменить программу, чтобы было легче ее тестировать. Например, программист, тестируя модуль, содержащий цикл, который должен повторяться 100 раз, меняет его так, чтобы цикл повторялся только 10 раз. Может быть, этот программист и занимается тестированием, но только другой программы.

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

Приведем еще раз три наиболее важных принципа тестирования.

1. Тестирование — это процесс выполнения программ с целью обнаружения ошибок.2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.

 

Популярные статьи

 

БАНКИ ДАННЫХ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ УПРАВЛЕНИЯ
ДОСТОИНСТВА И НЕДОСТАТКИ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ДАННЫХ
ВИДЫ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ 
ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ АЛГОРИТМОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ОФИСА
КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ
КОМПОНЕНТЫ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ АВТОМАТИЗАЦИИ ОФИСА
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО СПЕЦИАЛИСТА
ЭТАПЫ РАЗВИТИЯ ИНФОРМАТИЗАЦИИ
ПОНЯТИЕ МУНИЦИПАЛЬНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ 
РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ
ФУНКЦИИ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ
МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ
ПРАВИЛА ЗАЩИТЫ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ
ДОКУМЕНТАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ
ПРОТОКОЛЫ ТЕСТИРОВАНИЯ
ДЕСТРУКТИВНЫЕ ВОЗМОЖНОСТИ ВИРУСОВ
КЛАССИФИКАЦИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
КОНЦЕПТУАЛЬНАЯ, ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ МОДЕЛИ
КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ ПОДГОТОВКИ ТЕКСТОВЫХ ДОКУМЕНТОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ЭКСПЕРТНЫХ СИСТЕМ
ДИАЛОГОВЫЙ РЕЖИМ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ
ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ