Глава 3: Типы тестов ... 81

исрсию программы и снова ищете ошибки. Вы находите старые ошибки, не замеченные на первом этапе, и новые, Появившиеся после доработки. Вот как Мартин и Мак-Клер (Martin & mcClure, 1983) подытожили собранные Боэмом (Boehm) данные об эффективности исправления найденных оши­бок.

• Если для исправления ошибки нужно изменить не более десяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 50%.

• Если для исправления ошибки нужно изменить около пятидесяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 20%.

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

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

Руководители проектов часто рассчитывают ограничиться двумя цикла­ми тестирования: в первом выявить все ошибки, а во втором убедиться, что все они исправлены. Но на самом деле для тестирования может понадо­биться порядка восьми циклов, а если на каждом из них тестировать про­грамму менее тщательно — тогда от 20 до 30.

Стандартная процедура тестирования "черного ящика"

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

82 Часть I: Основы

Планирование

Как и всякая работа, тестирование программного продукта начинается с планирования: определяется стратегия, разрабатываются серии тестов, распределяются между сотрудниками задания. Начинать планирование можно сразу после того, как команда проектировщиков выработает требо­вания к программному продукту. Однако чаще подробное планирование начинается на первом цикле тестирования, когда перед вами готовый про­граммный продукт. О разработке тестов мы с вами поговорим в главе 7, а в главе 12 обсудим составление общего плана тестирования.

Приемочное тестирование

При поступлении каждой новой версии программного продукта тести­ровщики прежде всего проверяют, достаточно ли она стабильна. Если она “обрушивается” при малейшей провокации, возиться с ней не стоит. Такое первое беглое тестирование называют приемочным или квалификационным.

Лучше всего, если приемочные тесты будут стандартизированы. Тогда их копии можно передать программистам, чтобы те проводили их сами и не сдавали вам программы раньше времени. Это позволит избежать возвра­тов тестировщиками неработающих программ — моментов, психологичес­ки неприятных для обеих сторон.

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

Во многих компаниях приемочные тесты частично автоматизированы с помощью специального программного обеспечения, выполняющего тести­рование “черного ящика”.

Проверка стабильности программы

Насколько стабильна полученная вами версия программы? Сколько циклов тестирования она выдержит — четыре или 24? Вас могут попросить оценить стабильность программы для составления календарного плана работ, оценить стоимость услуг по ее тестированию сторонним агентством или оценить качество программного продукта, который компания собира­ется купить и распространять.

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