Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 8
Текст из файла (страница 8)
Эта книга только поверхностно затрагивает методы структурного тестирования. Стратегия гибридного теста является комбинацией поведенческой и структурной стратегий [С1АГ«76, г«1СН81]. Поведенческая, структурная и г»гбридная стратегии не противоречат друг другу, и ни про одну из них нельзя сказать, что она лучше других. Модули и низкоуровневые компоненты часто тестируются с помощью структурной стратегии.
Большие компоненты и системы в основном тестируются с помощью поведенческой стратегии. Гибридная стратегия полезна на всех уровнях. Не существует лучшей стратегии, так как полезность стратегии зависит от природы тестируемого объекта, природы ошибок объекта и уровня вагцих знаний. 1.3.4. Парадокс пестицида' Большинство из нас предпочитают доделать дело до конца.
Знать, что работа выполнена, выполнена правильно, и в подходящее время взять следующее задание, Тестирование программного обеспечения на это не похоже. Если вы хорошо сделали работу по выявлению ошибок и если люди из отдела обеспечения качества хорошо выполнили работу по передаче ваших исследований обратно программистам, то они, скорее всего, не повторят прошлых ошибок. Хороший программист, если у него есть время и необходимые ресурсы, обычно изучает проблемы, ныявленные тестировщиками (или им самим), обобщает идеи и затем исследует свое программное обеспечение на предмет выявления и исправления в нем таких же или подобных ошибок. Все методы тестирования имеют встроенные допущения о природе ошибок.
Каткдый метод тестирования нацелен на определенный набор ошибок. Если программист реагирует на результаты тестирования и информацию об ошибках сокращением и удалением этих ошибок, из этого следует, что его программа улучшается, а эффективность предыдущих тестов постепенно уменьшается. То есть ваш тест устаревает и вам приходится изучать, создавать и использовать новые тесты, основанные на новых методах отслеживания новых ошибок. 1.3.5.
Природа и причины ошибок Обратитесь к 1ВЕ1790] и 1А)л)8194] для подробного обсуждения ошибок и категорий ошибок. Главная причина, почему я использую термин «ошибка», а пе официальный термин «дефект», это то, что «дефект» подразумевает, что кто-то должен нести за него ответственность. Предполагается недостаток добросовестности программиста, леность или некомпетентность. Ошибки, сделанные компетентным программистом, работакнцим на современном программном обеспечении, в соот- ' Это называется «наралокс нестнннла» но аналогии с явление»< в сельском хозяйстве, когда лнчннкн лолгоноснка, нрнснособнвшнсь к нлу, вынуждалн нас созлавать все более мошный яд, которьш прнводнл к возня<оювенню нсе более устойчнвых к атому яду лнчшюк, нлн искать принципиально на<к рею«вне.
1.3. О тестировании 35 ветс твующей среде разработки программного обеспечения, не являются дефектами (надеюсзн вы не будете обвинять нас в излшпней мягкости). В хорошем, продуманном программном обеспечении источником ошибок являются слозкность и ограниченная способность людей к борьбе со сложностью, а не тупость. Чем лучше программный процесс, тем менее вероятно, что ошибки, которые сохраняются в течение поведенческого тестирования, являются ошибками конкретных программистов. Большинство ошибок, которые мы находим при помощи поведенческого тестирования в хорошо разработанном, качественном программном обеспечении, являются следствием непредсказуемого взаимодействия между компонентами пли между объектами, нли результатом непредсказуемых побочных эффектов, вызываемых совершенно невинными, на первый взгляд, процессами, Если ошибки, найденные в результате поведенческого тестирования, — простые и их легко распределить по категориям, это говорит о том, что неудовлетворитслен технологический процесс, а не программист.
Мы принимаем на веру, что программист хорбшо обучен, обладает надлежащими инструментами и компетентен'. Это называется «гипотезой компетентного программиста». Так как человек, который проводит поведенческое тестирование, не обязательно является тем тке самым человеком, который пишет программное обеспечение, важно иметь в виду эту гипотезу, считая, что человеческие недостатки и неприязнь не вторгаются в процесс программирования. Полезны три широкие категории ошибок: ошибки модулей/компонентов, ошибки интеграции и системные ошибки, названные так в соответствии с той фазой разработки, в которой, вероятнее всего, могут быть найдены ошибки.
Ошибки модулей/компонентоо найти и избежать легче всего. Когда мы тестируем систему и тест выявляет ошибку, мы не можем сказать, что явилось этому причиной, — ошибка модуля, ошибка интеграции или системная ошибка. Это мы узнаем только после того, как ошибка будет устранена. Так как системное тестирование требует гораздо больших ресурсов, чем тестирование модулей/компонентов, выявление ошибок модулей, оставшихся к моменту начала системного тестирования, представляет собой напрасную трату спл. Таким образом, задачей тестирования модулей/компонентов является сокращение числа ошибок, которые перехолят в последующие стадии процесса.
Ошибки иптегрипии более трудны для выявления и предотвращения, так как онн возникают при взаимодействии между компонентами, которые являются корректными сами по себе, Взаимодействие компонентов подчиняется законам комбинаторики, что означает, что их число растет как и' (как квадрат числа задействованных компонентов) или даже хуже (например, как п! — факториал числа компонентов). Цель тестирования интеграции — убедиться в том, что когда мы переходим к системному тестированию, некорректных взаимодействий между компонентами совсем не осталось или осталось мало. Системное тестирование — это качественно новый уровень тестирования.
Даже если все особенности были проверены при тестировании модулей/компо- ' Если некомнетентныв про грохни нет ис ыожст ствть комн««ситным, нзбввьтесь от него. Если нронесс содержит ошибки, нснржиьтс сто. Нн о1 кого нсльзл ожндюь иродуктнвности без нвдлежвщих инструментов.
36 Глава 1 ° Введение нентов или при тестировании интеграции, нам следует вклк>чита поведенческое тестирование как составную часть системного тестирования. При тестировании модулей/компонентов нлн интеграции то, что мы тестируем, имеет детерминированное поведение. При системном тестировании у цас, однако, возникают дополнительные трудности, связанныс с многозадачностью. Следовательно, порядок, в котором будут возникать тс или иные ситуации, узко не может быть с уверенностью предсказан. Такая неопределенность и проблема синхронизации являются богатой почвой для более сложных ошибок.
Основная цель системного тестирования — убедиться в том, что в недетерминированном мире программное обеспечение ведет себя так же предсказуемо, как и в детерминированном мире. 1.3.6. Когда надо остановиться Процесс тестирования потснцнально бесконечен, как с теоретической, так и с практнчсской точки зрения. Тем це менее, даже зная, что ошибки остались, мы должны завершить тсстирование, так как если мы этого не сделаем, все усилия будут напрасны.
Если у нас есть большос количество опытных данных, то можно создать статистическую модель, которая даст нам понимание того, насколько рискованно прекратить тестирование и предложить программу для коммерческого использования [НАМЕ94, МБЯА901.Если вы почувствовали некоторую осторожность моей формулировки, запомните это, так как обоснованность таких моделей не очевидна и нс бесспорна. Тем не менее, прогресс не стоит на месте, и большинство полезных моделей нуждаются в информации, которую мы собираем при тестировании, особенно в ходе системного тестирования, и которая является частью данных, используемых для определения момента завершения тестирования.
1.3.7. Тестирование черного ящика — это еще не все Тестирование поведения, это егце лалеко не все, что мы должны сделать. Одного тсстировання мало. Если мы рассматриваем все тес.гнрованис, которое мы можем и должны провести с программой, от начала и до конца, поведенческое тестирование занимает 35-65Уо от общего времени'. Относительная полезность поведенческого тестирования зависит от проекта. Если в проекте все характеристики жестко запрограммированы с использованием специальной логики, то структурные моголы превалируют. Когда проект основан на использовании общих алгоритмов, чье специфическое поведение определяется при помощи таблиц данных или параметров вызова, то преоблаласг поведенческое тестирование. Важность поведенческого тестирования подобна вазкности различных методов навигации.
Что именно является наиболее важным, зависит от погоды, от близости берега, от того, какими приборами вы располагастс, и так далее. Нам следует прислушаться к мо- ' В объектно ор~житнргжаииом ирограммироиаиии увеличивается важность иоведеичсского тсстироааиия Ясно, что метолы иовелеичсского тестирования булуг более важны лля созлаиия ирограммиого г~бссиечеиия ири иоыоиеи иадсжиоп библиозсчеи миогокрагио исиользусмык объскзов, чья виугрсиияя работа и гз рука ура сози атея ьио от иас скры ~ ьь веси иаьь иозможво, и рилсо си ироиолить гораздо больше тестов, дяя того чтобы бып, увсрсш жом и и и ысл иос п~ обьсктов ~ ВЕКАВ4, ГчОйт94~.
1.3. О тестировании ЗУ ему любимому автору Натаннелю Боудичу [В0%Р77]: «Мудрый штурман ни- когда не полагается только на один метод>. 1.3.8. Тестирование — это еще не все Ошибки, обнаруженные в процессе тестирования, должны нас, с одной сгороны, радовать, с другой стороны — огорчать. Радовать, так как это означает, что на одну проблему стало меньше; огорчать, поскольку это указывает на несовершенство нашего процесса разработки программного обеспечения. Радовать, так как мы узнали, как усовершенствовать процесс и предотвратить подобные проблемы в будущем, Мы создаем программы около 40 лет, и наиболес важный урок, который мы усвоили, звучит следующим образом: «Делайте зто как можно раньше! > Чем раньше ошибки найдены и исправлены, тем дешевле обходится их исправление.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
