Часть I. Процесс быстрого тестирования. Вход в системное тестирование должно означать начало совместных работ при уча­ стии групп разработчиков и тестировщиков

Циклы тестирования

Вход в системное тестирование должно означать начало совместных работ при уча­ стии групп разработчиков и тестировщиков. Тестировщики выполняют прогон за­ планированных тестов, выявляют дефекты и пишут сообщения о дефектах. Разра­ ботчики читают сообщения о дефектах, воспроизводят проблемы и исправляют про­ граммный код. Вопрос заключается вот в чем: как исправления передаются в группу тестирования?

Ответ на этот вопрос зависит от цикла создания программного обеспечения. Раз­ работчики регистрируют проделанные исправления в системе управления конфигу­ рациями в рамках подготовки к периодическим построениям сборок. Построение сборки обычно выполняется на базе ежедневного или еженедельного цикла, после чего блок передается группе тестирования в соответствии с их потребностями.

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

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

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

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

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

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

Один из способов отслеживания тестов, прогон которых выполнен на заданной сборке, предусматривает ведение списка прогона тестов на сборке для каждой сборки тестируемого программного обеспечения. Пример списка прогона тестов на сборке показан на рис. 5.5. В этом списке в качестве заголовка указан идентификатор сборки и дата прогона теста; список прогона тестов, по существу, представляет собой список того, " что нужно сделать" каждому специалисту по тестированию. Если планируется применение испытательных комплексов или рабочих станций коллективного поль­ зования, этот список позволит избежать конфликтов, если в нем для каждого специа­ листа по тестированию будет указываться испытательный комплекс, на котором должны запускаться тесты. Если же возникнут конфликты требований на использо­ вание испытательного комплекса, то в таких случаях может потребоваться разработ­ ка рабочего графика для комплексов. В списке прогона тестов на сборке один стол­ бец резервируется под краткое изложение результатов тестирования.