Часть II. Технологии быстрого тестирования и советы. ние с целью выяснения, не разрушили ли последние изменения какую-либо из функ­ ций, ранее успешно работавших

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

Рис. 7.3. Взаимодействие разработчика и тестировщика: жизненный цикл программной ошибки.

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

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

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

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