Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 9

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 9)

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

Прототипом программы является урезанная реализация, которая имитирует то поведение программы, которое необходимо пользователю [ЯТАК891. Цель этого — дать нечто осязаемое пользователю, чтобы он мог нам сказать, является ли полезным для него то, что мы создаем, будет ли он это впоследствии покупать. Прототип на самом деле не обязан работать и обычно не работает. Мы создаем программное обеспечение для пользователей.

Привлечение их к процессу как можно раньше является эффективным подходом, позволяющим избежать грубых промахов. Анализ требований. Требования задают содержание проектирования [У Е Н В80[. Если требования несовместимы, то проектирование не может быть корректным. Лнализ требований означает проверку требований на логическую непротиворечивость, тестируемость, легкость реализации. Мы пе можем ожидать, что пользователь обеспечит нас адекватными требованиями, так как оп не умеет этого делать. Мы все были бы похожи на машину, которая, не загрязняя окружающую среду, проезжает 100 километров на литре воды, везет 12 взрослых людей и помещается на стоянке 3 к 2 м.

Мы все были бы похожи на «Мерседес» по цене «Запорожца>. Нашей целью как создателей программного обеспечения це является сделать невозможное и удовлетворить все капризы пользователей. Нашей целью является разработка продукта, соответствующего своей цене. Формальный анализ [АХРЕ79, ВАВЕ94, НЛХТ76, ЪЪ'1ХС94[. Мы не можем тестировать все, да и нет в этом необходимости .

Это особенно справедливо в случае поведенческого тестирования. Множество вещей, которые мы не можем на практике протестировать в настоя1цее время (и вряд ли когда-нибудь сможем), включает в себя все возможные способы взаимодействия характеристик друг с 38 Глава ! ° Введение другом. Тестирование поведения программы при каждом возможном варианте инсталляции, является лругой неосуществимой задачей. То же самое относится к взаимодействию между нашим пакетом программ и другими пакетами, проверке защищенности нашей программы, некоторым коммуникационными протоколам и множеству алгоритмов.

Всякий раз, когда по ряду причин сложность тестирования увеличивается быстрее, чем сложность самого тестируемого объекта, формальный анализ, возможно, математический, является предпочтительнее тестирования. Мьь однако, нуждаемся в тестировании, чтобы убедиться, что сам наш анализ в должной мере свободен от ошибок'. Проектирооаггие. Хороший проект имеет мало ошибок и легко тестируется. Намного легче спроектировать что-то, что не может быть протестировано, чем что-то, поддающееся тестированию. Намного легче спроектировать что-то, что совершенно невозможно сопровождать, чем спроектировать что-то, что возможно.

Самые грамотные требования сводятся на нет непродуманными проектами, проверить которые невозможно при помощи конечного числа тестов. Формальное инспектирование [гАСА76, С!1ВВЗ, %ЕПх!90~ является первичным методом предотвращения ошибок, и это неоднократно подтверждалось. Процесс разработки программного обеспечения, который не включает в себя формальное инспектирование, очевидно дефектен, и устранение ошибок в нем намного больше зависит от тестирования. Сомопгестировапие.

Тестирование, выполняемое самими программистами, гораздо более эффективно, чем тестирование, выполняемое кем-то еще. То же самое относится к тестированию группой, производящей данное программное обеспечение. Аналогично тестирование в организации, разрабатывавшей программное обеспечение, эффективнее, чем внешнее тестирование (то есть бета-тестирование) того же самого программного обеспечения. Это не отвергает идеи, что независимое тестирование может быть действенно, так как эффективность — ие единственный критерий, определяюгций, кому и какое тестирование проводить. Если независимый тестировщик повторяет тест, ранее выполненный разработчиком, или просто выполняет тестирование, которое следовало бы выполнить во время разработки, в этом случае независимое тестирование совсем не приносит никакой информации, фактически не имеет смысла.

Такое тестирование (независимое повторение тестов разработчика) может быть полезно, только если разработчик некомпетентен или предумышленно делает не все корректно. А это противоречит нашей гипотезе о компетентности программиста. Цель независимого тестирования — обеспечить различные ракурсы, следовательно, различные тесты; более того, проводить эти тесты в среде с более широкими возможностями (и поэтому более сложной и дорогой), чем это доступно разработчику.

Цель самотестирования — удалить те ошибки, которые могут бьггь найдены ' Бее, что мы лслаеы в яр«шсссе разработки программного обеспечения, подвержено ошибкалс Формальное (то сеть математическое) доказательство коррсктиосги алгоритма точно так же уязвимо лля ошибок, как любой другой процесс, выполияемый человеком. Убедиться в зоом легко: достаточно вспомнить о количестве статей в математических журналах, озаглавленных; «Коитри ример к теорсме...«. 1.ч. Процесс разработки программного обеспечения 39 посредством малых затрат в простейшей детерминированной среде путем тестирования модулей/компонентов илп низкоуровневого системного тестирования.

Ипсглрументы. Мы считаем исходные синтаксические ошибки кода просто помехами, так как у нас есть инструменты (компиляторы), которые находят такие ошибки гораздо лучше, чем мы сами. В наших языках программирования и компиляторах к настоящему времени появились совершенные детекторы ошибок, автоматизировавшие то, что когда-то являлось сложной для человека задачей.

Если ошибка может быть определена (и/или исправлена) автоматически, это должно быть сделано. Не пытайтесь отключать автоматпзапию и инструменты, выявляющие ошибки. Исключить надо как раз подверженную ошибкам ручную обработку кода, тогда, когда доступна автоматизация. Существует все более увеличивающаяся разница между инструментами, которые в действительности используют программисты и тестировщики, и инструментами, которые разрабатывают для ~ их исследователи.

Ликвидируйте этот разрыв! Он стоит того. Это окупится. Мы, как тестировщики, должны всегда стремиться к тому, чтобы можно было вообще обойтись без тестирования. Это наша недостижимая цель. Тестирование является контролем качества. Обеспечение качества означает предотвращение ошибок. Всегда выгоднее предотвратить ошибки, чел1 их потом находить. Но эта цель недостижима, так как история показывает, что автоматизация процесса и предотвращение предыдущих ошибок являются предпосылками к встрече со все более сложными задачами, которые ставят перед нами нужды пользователей.

Наш текущий технологический процесс (каким бы несовершенным он ни был) является более совершенным, чем технологический процесс, использовавшийся всего десятилетие назад. Мы уже не программируем так, как это делали десять лет назад, по мы пишем новые программы, песущис в себе все более сложные ошибки. Наши пользователи повышают свои требования к качеству, а, следовательно, растут требования к нашим возможностям и методал1 тестирования. 1.4.

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

Наличие процесса еще не означает существования детально разработанной для него документации. Ряд наилучших проектов на моей памяти имели крайне ограниченный объем документации. И наоборот, когда меня спрашивают о том, что 40 Глава 1 ° Введение необходимо иметь, я ссылаюсь на подробно задокументированное описание процесса, оставшееся после одного из самых крупных провалов из тех, что мне доводилось видеть. Об ьем формалы < ой< д<псументаци и для коц крет ного проекта напрямую зависит от размера этого проекта. Документы (еслн они читаются) — это наиболее эффективный способ донести детали проекта до человека, не разбирающегося в данном процессе и в предпосылках к проекту.

Контролировать процесс, а значит обеспечить его качество обычно проще, если шаги в процессе задокументированы. Он т<онятен. Если процесс непонятен тому, кто должен его понимать, то этому процессу невозможно следовать. Понимания можно добиться, читая документацию, если только людям дается время на осознание и суммирование того, что они прочли.

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

Характеристики

Список файлов книги