Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 69
Текст из файла (страница 69)
Если тестирование эффективно (то есть находит большинство ошибок), тогда средняя оценка количества повторных прогонов тестов для всех тестов (тех, которые обнаруживают ошибки, и тех, которые не обнаруживают) очень высока. На этот счет нет надежных статистических данных, так как это не принято записыватгь здесь изложен мой собственный опыт. Помимо автоматического выполнения на обычной бумажной ленте, мы использовали также майларовую перфоленту (зта лента, в 10 раз дороже обычной бумажной ленты, изнашивала ленточный перфоратор значительно быстрее), так как обыкновенная бумажная лента не могла выдержать многократные повторные прогоны.
Я точно не знаю, но, вероятно, через 40 или 50 прогонов через устройство считывания с ленты обычная бумаж- ' Однако можно сделать много выводов относительно несовершенства ручного тестирования и его подверженности ошибкам. 272 Глава 10 ° Инструментальные средства и автоматизация ная лента начинает изнашиваться. Так спросите сами себя; были ли мои тестировщики попросту некомпетентны, или же из этого можно извлечь урок? Мир технического обслуживания [Р!0094].
Современный процесс разработки программного обеспечения состоит не только из создания и тестирования нового кода, но также из поддержки существующего кода. Для большинства продуктов программного обеспечения около 80 процентов усилий тратится на техническую поддержку, как на корректирующее сопровождение, которое исправляет обнаруженные ошибки, так и на прогрессивное сопровождение, которое модернизирует и добавляет новые возможности. В течение типичного цикла сопровождения модифицируется менее 5 процентов кода. Однако это обычно приводит к необходимости комплексного регрессионного тестирования (то есть повторения наиболее важного подмножества из набора первоначальных тестов) [В(1КК88[. Общепризнанный опыт при проведении ручного регрессионного тестирования заключается в отказе от его использования.
Одно из двух приносится в жертву— или прогрессивное тестирование (тестирование новых характеристик), или эквивалентное тестирование (тестирование неизменных характеристик), или даже оба вместе. Это опасная ситуация, так как в развивающемся продукте его сопровождение может являться причиной ошибок, количество которых сравнимо с количеством всех остальных ошибок. Программисты сопровождения защищены от ошибок не более, чем тестировщики и программисты исходного кода. Попытки провести ручное регрессионное тестирование (в действительности его не применяют) приводит к возрастанию число ошибок сопровождения до недопустимо высокого уровня. Сколько в действительности стоит ручное тестирование? Стоимость ручного тестирования практически невозможно оценить, так как информационная инфраструктура, необходимая для проведения точных исследований, возникает только после выполнения автоматизации тестирования.
Но мы можем определить общую стоимость труда, если посмотрим, сколько людей занимается тестированием. Это должно быть выполнено корректно, что практически невозможно. Вам необходимы общие данные о трудозатратах, в первую очередь включающие в себя стоимость сервиса, стоимость горячей линии и тому подобное. Если стоимость программного обеспечения определена корректно и должным образом связана с различными видами деятельности, в таком случае большинство организаций, которые проводят такую оценку впервые, будут просто потрясены реальной стоимостью ручного тестирования. 10.4.
Базовый пакет инструментов 10.4.1. Основы В этой главе я не ставил перед собой цель дать всеобьемлющий обзор инструментов тестирования. Это заняло бы всю книгу. Для обзора текущих инструментов я рекомендую [ЕВТС83, СКАН91, СКАН93, РА!С93, МАКС94 и ЯОЕТ94[. Коммерческие инструменты эволюционируют так быстро, что создание хорошего 10. $. Базовый пакет инструментов 273 и всеобъемлющего руководства невозможно, за исключением разве что периодических публикаций. Цель этой главы — рассмотреть инструменты тестирования в перспективе и обсудить важные технические особенности, на которые вам следует обращать внимание при выборе коммерческих инструментов или при их разработке. Нет инструмента, который бы точно соответствовал обсуждаемым характеристикам; любой инструмент представляет собой смесь таких характеристик.
10.42. Инструменты для покрытия Эта книга посвящена поведенческому тестированию. Но в конце концов то, что мы тестируем, — это просто кусочки программы. Программы, обладающей некоей структурой. Как мы можем узнать, что наше тестирование выполнено хорошо? Здравгяй смысл говорит о том, что по меньшей мере каждую команду на уровне объекта следует выполнять в процессе тестирования. Поведенческое тестирование основано на модели программы, но не на самой программе, а модели могут быть ошибочными. Поэтому модель тоже необходимо проверить. Ключевой частью проверки является то, что модель должна надлежащим образом отражать поведение, заложенное в реально существующее программное обеспечение.
Если мы протестировали все части нашей модели, но не протестировали весь код, значит наша модель нельзя назвать качественно разработанной. Цель инструментов для структурного покрытия — дать нам техническое задание и количественную оценку того, какую часть программы мы фактически выполним при тестировании. Необходимо обеспечивать охват в 100 процентов. Если мы используем методы поведенческого тестирования, нам по-прежнему следует контролировать покрытие структуры, чтобы знать реальное положение дел. Каждый метод тестирования содержит в себе метрику покрытия, которая измеряет степень применимости метода.
В тех случаях, когда метод имеет структурный прототип, для подтверждения реальности покрытия следует использовать соответствующий инструмент структурного покрытия. В тех случаях, когда нет очевидного структурного прототипа, вам следует записать или же определить пределы, в которых ваши тесты обеспечивают покрытие. На данный момент существует достаточно много источников информации об инструментах для структурного покрытия различных типов.
Для получения дополнительной информации по коммерческим инструментам я советую обратиться к руководствам 1СКАН93, ОА1С93, МАКС94, БОЕТ941. Ниже представлены основные категории инструментов структурного покрытия. 1. Покрытие потока управления. Наименее эффективный способ — это покрытие операторов исходного кода, что является простым покрытием узлов и поэтому практически бесполезно. Однако инструменты, предлагаемые рынком, обеспечивают измерение степени покрытия операторов — источников потока управления.
Этого явно недостаточно. По крайней мере, должно быть обеспечено покрытие ветвления. На практике, особенно для таких языков как С, которые поддерживают составные предикаты, давно известно, что простого покрытия ветвления (звена потока управления) 274 Глава 10 ° Инструментальные средства и автоматизация недостаточно и что каждый предикат составного предиката должен тестироваться (по крайней мере) для значения истиид или ПОхь. Большинство коммерческих инструментов обеспечивают все три метрики покрытия — операторов исходного кода, ветвлений в исходном коде и покрытие условий в исходном коде предиката. Инструменты для покрытия потока управления действуют (как правило) посредством автоматической модификации исходного кода, добавляя технологические операторы, которые будут регистрировать пути и сегменты программы, реально работающие при проходе тестов.
Все зти инструменты обладают некоторыми потенциально важными ограничениями, о которых вам следует знать. ° Различные компиляторы. Все инструменты покрытия содержат в себе компиляторы или их эквиваленты. Так как компилятор инструмента тестирования и рабочий компилятор часто сделаны разными производителями, то их объектные коды могут различаться. Для надежности тесты, произведенные при помощи инструментов, следует повторить с реальными компиляторами для подтверждения того, что итоги полностью совпадают.
° Верхний предел объема кода. На сегодняшний день инструменты покрытия фактически ограничены объемами сегментов исходного кода в пределах от 30 000 до 50 000 строк. При возрастании размера не только время выполнения тестов становится слишком большим, но и возрастает вероятность неверно отследить выполнение каждого сегмента. ° Обработка условного ветвления.
Компиляторы используют отложенное вычисление, в котором оценка предиката заканчивается при определении значения истинности предиката. Это значит, что можно попытаться покрыть все предикативные условия (истинюлохь), но обычно так не делают. При современной оптимизации компиляторов, при продолжающейся оптимизации аппаратных средств и при наличии средств упреждающего исполнения команд и кэш-памяти нет гарантии, что инструмент покрытия покажет то, что происходит на самом деле.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
