1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

выдерживает критики, т.к. полный

перебор

всех

возможных вариантов

У

выполнения программы находится за пределами вычислительных

возможностей даже

для

очень небольших

программ. Поэтому никакое

тестирование не может гарантировать отсутствия ошибок.

Т

Поэтому со временем понимание целей тестирования изменилось.

Сегодня общепринятым определением тестирования считаетсяНследующее,

данное Гленфордом Майерсом [1]: "Тестирование – это процесс выполнения

программ с целью обнаружения ошибок".

Б

До начала 80-х годов процесс тест рования программного обеспечения

(ПО) был разделен

с

процессом

разработки:

вначале программисты

й

реализовывали заданную функц ональность, а затем тестировщики

приступали к проверке качества созданных программ. Однако такой подход

и

создает множество пр блем. Нап имер, разработка программ может

оказаться достаточно дли ельнрй (скажем, несколько месяцев) – чем в это

время должны занима ься

ес ир вщики?

о

Другая, более серьезная проблема заключается в плохой

предсказуемости результатовтакого процесса разработки. Ключевой вопрос

таков:

потребуется

на завершение продукта, в котором

существует 500 и вестных ошибок? На самом деле, предугадать это

времени

совершенно нев зможно, так как разные ошибки будут требовать разного

з

времени на исправление, а исправление известных ошибок будет неизбежно

связано

внесением новых. Существует следующая мрачная статистика:

сколько

однострочное изменение в программе с вероятностью 55 % либо не

исправляет

старую ошибку, либо вносит новую. Если же учитывать

изм н ния любого объема, то в среднем менее 20 % изменений корректны с

даже

первого раза.

В связи с этим в 90-х годах появилась другая методика разработки,

Ркоторую вслед за Microsoft'ом называют zero-defect mindset. Основная идея

При такой постановке вопроса тестирование становится центральной

частью любого процесса разработки программ. С другой стороны, zero-defect

mindset предъявляет существенно более высокие требования к квалификации

инженера тестирования: теперь в сферу его ответственности попадает не

только функциональное тестирование, но и организация процесса разработки

(процесс ежедневной сборки, участие в инспекциях, сквозных просмотрах и

У

обычное чтение исходных текстов тестируемых программ). Поэтому

идеальной

кандидатурой на

позицию тестировщика

становится

наиболее

Т

опытный программист в команде. Такой специалист мог бы не просто

существенно улучшить качество создаваемого продукта, но и передать свой

опыт младшим товарищам.

Н

Б

1.1. Различные подходы к тестированию (черный ящик, белый ящик)

й

Долгое время основным способом тестирования было тестирование

методом "черного ящика" – программе подавались некоторые данные на

и

При этом,

вход и проверялись результаты в надежде на ти несоответствия.

как именно работает

программа, сч тается несущественным. Следует

отметить,

р

что даже при таком подходе необходимо иметь спецификацию

было

программы для того, чтобы

с чем с авн вать результаты.

Этот

подход до

сих

п

является

самым

распространенным в

т

повседневной практике, но у него есть целый ряд недостатков. Во-первых,

таким способом невозм жно найти взаимоуничтожающихся ошибок, во-

поведение

вторых, некоторые ош бки возникают достаточно редко (ошибки работы с

з

х рудно найти и воспроизвести и т.д.

памятью) и потому

В свя и с эт м появ лись методы тестирования, которые изучают не

о

программы, но

и ее внутреннее устройство

только внешнее

(исх дные тексты). Такие методики обобщенно называют тестированием

п

"бел го ящика". К ним относятся: обзоры кода, инспекции, аудит,

критический анализ и т.д. Основной трудностью подобных методов является

Р

сложность отслеживания вычислений времени выполнения.

Внимательное изучение этих методов тестирования показывает, что

они дополняют друг друга, то есть различные методы находят разные

еошибки.

Поэтому

наиболее

эффективные

процессы разработки ПО

Таблица 1.1

Показатели эффективности различных методов тестирования

Название методики

Минимальная

Средняя

Максимальная

эффективность

эффективность

эффективность

Персональные просмотры проектных

15 %

35 %

70 %

документов

Неформальные групповые просмотры

30 %

40 %

60 %

Формальные просмотры проектных

35 %

55 %

75 %

документов

Формальные инспекции кода

30 %

60 %

70 %

У

Моделирование и прототипирование

35 %

65 %

80 %

Т

Проверка за партой

20 %

40 %

60 %

Тестирование модулей

10 %

25 %

50 %

Н

Функциональное тестирование

20 %

35 %

55 %

Комплексное тестирование

25 %

45 %

60 %

Б

Тестирование в реальных условиях

35 %

50 %

65 %

Применение всех

93 %

99 %

99 %

перечисленных методик тестирован я

й

Из таблицы видно, что тести

максимально эффективно в тех

ование

случаях,

когда программа п ве яется не только путем запуска,

но и путем

р

чтения, статических пр вер к и т.п. Поэтому классическое определение

Майерса, приведенное выше,

казывается слишком узким и не

охватывающим всех аспековсовременного тестирования. В связи с этим

т

будем поль оваться друг м определением тестирования:

Определен е: Тест рование – это любая деятельность, направленная

на

шибокв программном продукте.

з

обнаружение

1.2. Смежные вопросы тестирования

Об экономической стороне тестирования. Тестирование само по себе

п

явля тся затратной деятельностью, отнимающей время и деньги. Поэтому в

большинстве случаев разработчики программного обеспечения заранее

е

Р

формулируют какой-либо критерий качества создаваемых программ

выпуском

продукта,

но

плохое

качество

выпущенного продукта

запоминается на всю жизнь.

У

На самом деле, Good Enough Quality –

это просто поиск разумного

Т

компромисса между затратами на тестирование, длительностью разработки

продукта и его качеством. Ничего умнее пока не придумали.

Психологические

аспекты

тестирования.

естирование

принципиально отличается от программирования по своим психологическим

характеристикам. Дело в том, что программирование носит конструктивный

характер, а тестирование ПО деструктивно по своей природе. Можно сказать,

что программист создает, строит, а тестировщик отыскиваетНнедостатки этих

построений. Поэтому программисты так часто не замечают очевидных

ошибок в своих программах: к своему творчествуБтрудно относиться

критично.

Все это не значит, что тест рован е "хуже", чем программирование,

й

или что в процессе тестирования нет места творчеству – просто эти виды

деятельности отличаются ко енным об азом,

и для тестирования требуется

и

иной склад характера, чем для п ограммирования. Следовательно,

программист не должен

ес

вать свои собственные программы – для

ир

этого необходим друг й чел век. Более того, программист не должен

тестировать даже чуж е

программы! Дело в том, что программист потратит

какое-то время, перенастраиваясьт

на новую задачу. Даже переключение с

одной

стской задачи на другую требует обычно от 10 минут до

получаса. П нятнои, что переключение с одного образа мышления на другой

отнимет существенно больше времени – возможно, даже день или два.

з

Таким

бразом, принято считать, что команда разработчиков не должна

сов адать с командой инженеров тестирования,

но при этом разработчики и

программ

т стировщики должны постоянно взаимодействовать друг с другом для

достижпния приемлемого качества окончательного продукта.

е

Р