Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 68
Текст из файла (страница 68)
Внутренние термины: все определения, все пути определение-использование, все пути, все использования, утверждение, поведенческое тестирование, ветвь, ошибка, дерево, составной предикат, компонент, поток управления, поток данных, тестирование доменов, рабочая срела, отказ, взаимодействие характеристик, 10.3. Обязательная автоматизация 269 ввод, инструментальное оснаШение, тестирование интеграции, связь, модель, итог, вывод, путь, предикат, структурное тестирование, синтаксическое тестирование, система, ошибка проектирования теста, тестовый сценарий, тестировшик, тестирование модулей, проверка. 10.3. Обязательная автоматизация Моя цель в этой главе состоит не в том, чтобы убедить вас в необходимости автоматизации тестирования, потому что если вы не верите в это, то не станете читать эту книгу. Моей целью является помочь вам четко сформулировать аргументы, используемые для доказательства важности капиталовложений в технологию тестирования гипотетической корпорации Феррингов, которые являются противниками формального тестирования, не говоря уж об инструментах автоматического тестирования.
Некоторые дополнительные подробности об автоматизации тестов можно найти в [ГКЕЕ88, НЕХ!)89, МП Е86, ХОМ!)87, РЕКЕ86, УОСЕ80]. Для меня одной из самых удручаюших картин является образ человека, который вручную делает на клавиатуре то, что может быть сделано автоматически. Это и грустно, и смешно. Мы живем в пятом десятилетии от начала производства компьютеров, а некоторых нз нас все еше нужно убеждать в пользе компьютеров, Автоматизация тестирования — это тот самый случай.
Это забавно, так как всего век назад достиг своего совершенства паровоз. А за пятьдесят лет до этого междугородные почтовые кареты ташились упряжкой лошадей с верховым на первой лошади, который управлял всей упряжкой. По мне, так ручное тестирование — это то же самое, что всадник перед ускоряюшимся локомотивом. Это опасно, унизительно и совершенно нелепо. Если бы человеческое достоинство и оптимизация оплаты труда были бы единственным доводом в пользу автоматизации, как это было в прошлом, то аргументы по автоматизации тестирования проходили бы мимо ушей. Это не те аргументы, которые можно использовать для доказательства важности инвестиций в автоматизацию, так как бухгалтер с творческим подходом всегда сможет найти слабое место в ваших аргументах.
А аргумент очень прост — ручное тестирование уже не работает. Оно никогда не работало очень хорошо, не работает сейчас и не будет работать в будущем. Ручное тестирование является самообманом. В нем понятие результата заменяется просто тяжелым трудом. И, что самое плохое, приводит к ложной уверенности в успехе. Если же вам не хватает самоуверенности, то сушествует гораздо более дешевый (как законный, так и незаконный) фармакологический способ ее получить.
Ручное проведение тестирования не работает. Первый миф, который должен быть рассеян, — это вера в то, что ручное выполнение тестирования работает. У нас есть превосходная статистика ошибок ручного ввода, составленная за многие дни набора на клавиатуре. Профессиональная машинистка совершает в среднем три ошибки на 1000 нажатий. Это было легко определить, так как за первоначальным вводом следовал повторный ввол с клавиатуры, во время которого второй 270 Глава 10 ° Инструментальные средства и автоматизация оператор контролировал первого.
Сравнение первых действий со вторыми происходило полностью автоматически. Обычный тест содержит 250 символов. Тестировшик, который не является оператором печатающего устройства, не обладает высокой точностью специально обученного оператора. Следовательно, нам слелует ожидать, что большинство тестов, исполняемых вручную, имеют по крайней мере одну ошибку, проистекающую из неверного нажатия на клавишу. К тому же, в отличие от оператора печатающего устройства, для которого проверка была автоматизирована (более 60 лет назад), при ручном тестировании проверка выполняется визуально.
А визуальная проверка является процессом даже более подверженным ошибкам, чем собственно набор. Люди даже не знают, как высока частота появления ошибок при ручном тестировании, потому что без автоматического средства выполнения невозможно записать, как много попыток выполнения теста было сделано перед тем, как тест все-таки выполнился корректно, если зто произошло.
По моему собственному опыту, уже 20 лет назад использование примитивных инструментов автоматического исполнения, таких как бумажная лента или телетайп, окуналось, так как ручное выполнение тестов было настолько ненадежно, что практически являлось бесполезным занятием.
Ручное тестирование приводит к ошибочной уверенности в успехе. Выполнение теста руками является делом трудным, скучным, грубым и бесчеловечным. Человеческая природа, будучи именно тем, чем она является, особенно это касается западной культуры, имеет тенденцию уравнивать усилия с результатом: «Мы так тяжело работали, у нас должно получиться хорошее тестированиеЬ Ошибкам не важны человеческие усилия.
При тестировании поощряется обнаружение ошибок, а не усилия сами по себе. Тем не менее, большие усилия необходимо мотивировать. А основная ложная мотивация для ручного тестирования состоит в том, что это должно быть эффективно — иначе для чего бы мы так тяжело работали? Это и есть статистически не подтвержденная ложная уверенность. Ложная уверенность греет душу. Если это то, что нужно, то гораздо лучше не тестировать вовсе. Требование надежности обуславливает использование автоматического тестирования. В течение обычного дня я выполняю более 800 000 операций с различными накопителями на магнитных лисках.
В этом легко убедиться, просто использовав команду зндятвяюз в конце дня. В какой-нибудь из этих операций могут проскальзывать ошибки, но, к счастью, относящиеся к аппаратным средствам или операционной системе, и я их игнорирую. Я не могу вспомнить, когда я в последний раз обнаруживал искажение данных программой. У меня есть причины ожидать, что я буду использовать свою систему в течение следуюгцих 10 лет без потерь и искажений данных. Мне хочется пожелать того же самого для остальных 100 миллионов пользователей РС.
Если бы компания М1сгозой хотела обеспечить гарантию статистической стабильности (с помощью теории надежности программного обеспечения), то есть чтобы никакая из их платформ никогда не допускала потерю или искажение данных в результате действий с диском, потребовалось бы 100 тестирующих машин, работающих 24 часа в сутки, выполняющих 1000 тестов в секунду, и все это примерно в течение 3 миллионов лет.
10.3. Обязательная автоматизация 271 Пользователи требуют от нас очень высокой функциональной надежности, Все статистически обоснованные методы оценки функциональной надежности программного обеспечения основаны на совершенно автоматических методах тестирования; и, как вы можете видеть, даже с такой автоматизацией все, что необходимо для пользовательской надежности, не может быть легко проверено.
Люди не могут следовать шаблонам стохастического тестирования, необходимого для обеспечения всех известных оценок надежности программного обеспечения. Так что, пока вы в своем уме, вы не будете верить случайности. Какой же вывод можно сделать о функциональной надежности программного обеспечения по результатам ручного тестирования? Да никакой! Абсолютно никакой! И еше раз никакой'.
Вы не можете подтвердить качество обьекта на уровне 1О ", если точность тестирования составляет 10-'. Как часто применять тест? Неудачи при попытке обоснования использования ручного тестирования обычно основаны на грубом просчете в количестве применений тестов. Под «грубым просчетом» я подразумеваю просчет на порядок (илн даже больше). Если вы полагаете, что тест должен проводиться только один раз, то использование автоматического тестирования будет трудно аргументировать.
Но почему же люди недооценивают количество проходов теста? Прежде всего они не учитывают ошибки при проектировании теста. Тестировщики точно так же не защищены от ошибок, как и программисты. Если у нас есть хороший тест, т. е. тест, который обнаружил ошибки, то он должен быть запущен дюжину раз. По крайней мере три раза для отладки теста. Три раза для подтверждения того, что появились те же самые ошибки. В этом случае заново продемонстрируйте их программисту, который также захочет убедиться в том, что ошибки повторяются. Таким образом, мы получили уже около 10 запусков теста. Затем еще два или три раза тест запускает программист во время исправления ошибки.
Затем для подтверждения исправленийй тест еще два или три раза запускает тестиро вши к. Двадцать запус ков— это самая низкая оценка, так как мы еще не учитываем всех менеджеров, которых необходимо убедить. Если же, как это часто случается на более поздних стадиях тестирования, ошибка уже не является простой ошибкой, которую можно объяснить одним компонентом, а проистекает из взаимодействия между компонентами, то результат можно смело увеличивать втрое.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
