Жизненный цикл разработки

Диаграмма шарнирно-каскадной модели, представленная на рис. 7.1, помогает по­ нять, когда следует применять статическое тестирование, а когда — динамическое тестирование. Эта диаграмма шарнирно-каскадной модели не противоречит приве­ денной в конце главы 1, хотя рис. 7.1 и содержит несколько дополнительных аббре­ виатур, которые представляют основные термины, используемые в этой и последую-

• щих главах. Документация, служащая основой для проведения комплексных, систем­ ных и приемосдаточных испытаний, создается, соответственно, на этапах рабочего проектирования, эскизного проектирования и разработки технического задания. Данная взаимозависимость показана двунаправленными стрелками, и именно на этих этапах некоторые проекты испытаний начинают давать сбои. Если код не удовлетво­ ряет требованиям технического задания, причиной программных ошибок могут по­ служить следующие три обстоятельства:

• Технические требования были изменены, но это не было отражено в доку­ ментации

• Один из случаев тестирования, сценариев тестирования или результатов испы­ таний содержал ошибку, которая привела к ложному обнаружению отказа

• Код содержит программную ошибку

Часть II. Технологии быстрого тестирования и советы

Рис. 7.1. Диаграмма шарнирно-каскадной модели.

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

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

Во время разработки некоторых проектов тестировщики не приступают к работе до тех пор, пока не будет завершен этап тестирования кода и модулей (ТКМ) и пока полностью не будет написан исходный код. Фактически, иногда тестировщики начи­ нают свою деятельность лишь после частичного завершения этапа комплексных ис­ пытаний (КИ). Если в вашей организации используется именно такой поход, значит, в ней не исповедуется философия быстрого тестирования. Если специалисты по тес­ тированию не участвуют в разработке планов испытаний, случаев тестирования, сце­ нариев тестирования, не занимаются анализом результатов тестирования и статиче­ ским тестированием документации до и во время этапа ТКМ, стоит задуматься о на­ прасных потерях времени разработки, которые вызваны необходимостью устране­ ния ошибок, допущенных на ранних этапах жизненного цикла разработки программ­ ного обеспечения. Кое-кто полагает, что источником всех ошибок является исходный код. Это совершенно неверно. Например, ошибки, допущенные на этапе разработки

технического задания (ТЗ), могут вылиться в месяцы напряженной работы над архи­ тектурными интерфейсами, низкоуровневого проектирования, создания кода и на-

писания документации. И лишь потом станет ясно, что полученный результат — вовсе " не то, что нам требовалось" или что " это выполняется не так, как нам требовалось". Мы часто упрекаем команду разработки технического задания, но кто из ее персонала способен обнаружить подобные ошибки и избежать их на этапе разработки ТЗ? При­ ходится лишь стыдиться, что никто из тестировщиков не принимал участия в работах этого этапа и, соответственно, попросту не мог обнаружить и устранить такие ошиб­ ки простым зачеркиванием или отправкой листа бумаги в корзину. Сколько денеж­ ных средств расходуется напрасно только потому, что тестировщики не участвуют в ранних этапах жизненного цикла разработки? В главе 8 рассматривается технология статического тестирования, получившая название совместной разработки требова­ ний к приложению (joint application requirements, JAR), которая служит примером следования философии быстрого тестирования, т.е. того, как необходимо сочетать выработку технических требований с их тщательным тестированием.

На ранних этапах жизненного цикла для описания того, что предположительно должно выполнять программное обеспечение (т.е. требования), используются слова обычного языка. Эти словесные описания превращаются в представленные в той или иной графической форме архитектурные диаграммы. Подсистемы и подблоки опре­ деляются соответствующими описательными фрагментами ТЗ. В ходе дальнейшего жизненного цикла разработки потоки операций и данных описываются другими гра­ фическими формами. Это же касается и таблиц, описывающих имена и отношения, которые будут положены в основу баз данных и запросов. После того, как логика про­ граммы полностью определена, для проверки полноты отражения программистами всех возможных ситуаций часто используются диаграммы состояний. Ошибки вно­ сятся во время каждого такого преобразования из одного языка описания задачи в другой. Задачей тестировщиков является обнаружение ошибок подобного рода.

Стратегии разработки тестовых случаев естественным образом делятся на две ка­ тегории, в зависимости от того, с чем тестировщику приходится иметь дело:

1. Тестирование " черного ящика". Если известны конкретные функции, кото­рые должен выполнять данный продукт, можно прогнать тесты, подтвер­

ждающие полную работоспособность каждой из функций. Термин " черный ящик" просто означает, что при разработке тестовых случаев тестировщики

' ничего не знают о внутренней структуре или коде. Применяемые во время тестирования " черного ящика" технологии обычно называют технологиями динамического тестирования, и многие из них рассматриваются в главе 10.

2. Тестирование " белого ящика". Если известны особенности внутренней ра­боты продукта, можно выполнить тесты, подтверждающие, что внутренняя работа продукта происходит в соответствии со спецификацией, а все внут­ ренние компоненты используются правильно. Термин " белый ящик" означа­ ет, что при разработке тестовых случаев тестировщики используют любые доступные сведения о внутренней структуре или коде. Технологии, приме­ няемые во время тестирования " белого ящика", обычно называют техноло­ гиями статического тестирования, и многие из них исследуются в главе 9.

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