Принципы поиска ошибок при тестировании

↑

▷ Содержание

⇐ ПредыдущаяСтр 8 из 78Следующая ⇒

Другая количественная мера – плотность ошибок. Количество обнаруженных ошибок на килостроку программного текста (KSLOC – kilo source lines of code) является традиционным показателем. В "здоровых" проектах плотность ошибок имеет тенденцию достигать стабильного значения примерно 10 KSLOC. Проверяя код далее, мы не должны наблюдать увеличения этого показателя.

В объектно-ориентированных системах полезно также измерять число ошибок на класс. При этом правило 80/20 считается приемлемым: 80% выявленных ошибок в программе сосредоточено в 20% классов системы. Важно, чтобы структура классов системы была организована таким образом, при котором разработчики "имеют право" сказать, что с помощью анализа этой структуры, просмотра текста программы и тестирования, ошибки могут быть ликвидированы или сведены к минимуму.

Принципы поиска ошибок при тестировании

"Аксиомы тестирования" (см. Г. Мейерс, Надежность программного обеспечения. –М.: Мир, 1980.):

1. Хорош тот тест, для которого велики шансы обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

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

Один полезный практический принцип сводится к тому, чтобы продолжать испытания до тех пор, пока каждая команда не будет использована хотя бы раз. Тестовые данные должны обеспечить проверку всех возможных условий возникновения ошибок. Должна быть использована каждая ветвь алгоритма. Это значит, что если в логическом блоке имеются два или три исхода, то каждый из возможных путей дальнейшей работы программы необходимо проверить хотя бы по одному разу. Такие проверки называются испытаниями ветвей – они являются необходимыми, но не достаточными.

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

4. Необходимая часть всякого теста – описание ожидаемых выходных данных и результатов.Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда "глаз видит то, что хочет увидеть". Кроме того, хорошо, если по каждому тесту определен набор свойств тестируемого модуля, которые можно считать проверенными при успешном его прохождении. Лучше разрабатывать самопроверяющиеся тесты, либо пользоваться инструментами тестирования, способными автоматически сверять ожидаемые и фактические результаты.

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

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

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

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

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

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

10. Считайте тестируемость одной из ключевых задач вашей разработки. Сложность тестирования программы зависит от ее структуры и качества проектирования. Где это возможно при создании программы, стремитесь обеспечивать облегчение тестирования в будущем. Для этих целей вполне уместно внедрение дополнительных проверок целостности данных – при необходимости ускорить или сократить объем программы, избыточность кода может быть впоследствии ликвидирована.

11. Никогда не изменяйте программу, чтобы облегчить ее тестирование. Часто возникает соблазн изменить программу, чтобы было легче ее тестировать. Например, программист, тестируя модуль, содержащий цикл, который должен повторяться 300 раз, меняет его так, чтобы цикл повторялся только 10 раз. Может быть, этот программист и занимается тестированием, но только другой программы (в частности, в этой новой программе никакой ошибки в данном цикле не возникнет, даже если в качестве счетчика числа итераций цикла используется однобайтовое число).

12. Тестирование должно начинаться с постановки целей. Например, для каждого конкретного типа тестирования должны быть определены ориентиры (набор пройденных путей выполнения программы, проверенные условные переходы и т.п.).

Познавательные статьи:



Организация работы процедурного кабинета

Статус республик в составе РФ

Понятие финансов, их функции и особенности

Сущность демографической политии