![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Жизненный цикл разработки
Диаграмма шарнирно-каскадной модели, представленная на рис. 7.1, помогает по нять, когда следует применять статическое тестирование, а когда — динамическое тестирование. Эта диаграмма шарнирно-каскадной модели не противоречит приве денной в конце главы 1, хотя рис. 7.1 и содержит несколько дополнительных аббре виатур, которые представляют основные термины, используемые в этой и последую-
• щих главах. Документация, служащая основой для проведения комплексных, систем ных и приемосдаточных испытаний, создается, соответственно, на этапах рабочего проектирования, эскизного проектирования и разработки технического задания. Данная взаимозависимость показана двунаправленными стрелками, и именно на этих этапах некоторые проекты испытаний начинают давать сбои. Если код не удовлетво ряет требованиям технического задания, причиной программных ошибок могут по служить следующие три обстоятельства:
• Технические требования были изменены, но это не было отражено в доку ментации
• Один из случаев тестирования, сценариев тестирования или результатов испы таний содержал ошибку, которая привела к ложному обнаружению отказа
• Код содержит программную ошибку Часть II. Технологии быстрого тестирования и советы
Рис. 7.1. Диаграмма шарнирно-каскадной модели.
Обратите внимание, что в двух первых случаях ошибка должна обнаруживаться средствами статического тестирования. Эти ошибки возникают вследствие несоблю дения жизненного цикла разработки. Персонал, выполняющий быстрое тестирова ние на ранних этапах разработки программного обеспечения (от разработки техни ческого задания до написания кода), обеспечит наилучшую гарантию предотвраще ния подобных неудач в процессе тестирования.
В качестве общего правила можно утверждать следующее: технологии динамиче ского тестирования должны применяться разработчиками программного обеспече ния, начиная с проверки вновь созданного кода на этапе тестирования кода и моду лей (ТКМ) или раньше, если предполагалось создание прототипа. Технологии стати ческого тестирования применяются как на этапе разработки, так и на этапе тести рования.
Во время разработки некоторых проектов тестировщики не приступают к работе до тех пор, пока не будет завершен этап тестирования кода и модулей (ТКМ) и пока полностью не будет написан исходный код. Фактически, иногда тестировщики начи нают свою деятельность лишь после частичного завершения этапа комплексных ис пытаний (КИ). Если в вашей организации используется именно такой поход, значит, в ней не исповедуется философия быстрого тестирования. Если специалисты по тес тированию не участвуют в разработке планов испытаний, случаев тестирования, сце нариев тестирования, не занимаются анализом результатов тестирования и статиче ским тестированием документации до и во время этапа ТКМ, стоит задуматься о на прасных потерях времени разработки, которые вызваны необходимостью устране ния ошибок, допущенных на ранних этапах жизненного цикла разработки программ ного обеспечения. Кое-кто полагает, что источником всех ошибок является исходный код. Это совершенно неверно. Например, ошибки, допущенные на этапе разработки
технического задания (ТЗ), могут вылиться в месяцы напряженной работы над архи тектурными интерфейсами, низкоуровневого проектирования, создания кода и на-
писания документации. И лишь потом станет ясно, что полученный результат — вовсе " не то, что нам требовалось" или что " это выполняется не так, как нам требовалось". Мы часто упрекаем команду разработки технического задания, но кто из ее персонала способен обнаружить подобные ошибки и избежать их на этапе разработки ТЗ? При ходится лишь стыдиться, что никто из тестировщиков не принимал участия в работах этого этапа и, соответственно, попросту не мог обнаружить и устранить такие ошиб ки простым зачеркиванием или отправкой листа бумаги в корзину. Сколько денеж ных средств расходуется напрасно только потому, что тестировщики не участвуют в ранних этапах жизненного цикла разработки? В главе 8 рассматривается технология статического тестирования, получившая название совместной разработки требова ний к приложению (joint application requirements, JAR), которая служит примером следования философии быстрого тестирования, т.е. того, как необходимо сочетать выработку технических требований с их тщательным тестированием.
На ранних этапах жизненного цикла для описания того, что предположительно должно выполнять программное обеспечение (т.е. требования), используются слова обычного языка. Эти словесные описания превращаются в представленные в той или иной графической форме архитектурные диаграммы. Подсистемы и подблоки опре деляются соответствующими описательными фрагментами ТЗ. В ходе дальнейшего жизненного цикла разработки потоки операций и данных описываются другими гра фическими формами. Это же касается и таблиц, описывающих имена и отношения, которые будут положены в основу баз данных и запросов. После того, как логика про граммы полностью определена, для проверки полноты отражения программистами всех возможных ситуаций часто используются диаграммы состояний. Ошибки вно сятся во время каждого такого преобразования из одного языка описания задачи в другой. Задачей тестировщиков является обнаружение ошибок подобного рода.
Стратегии разработки тестовых случаев естественным образом делятся на две ка тегории, в зависимости от того, с чем тестировщику приходится иметь дело:
1. Тестирование " черного ящика". Если известны конкретные функции, которые должен выполнять данный продукт, можно прогнать тесты, подтвер
ждающие полную работоспособность каждой из функций. Термин " черный ящик" просто означает, что при разработке тестовых случаев тестировщики
' ничего не знают о внутренней структуре или коде. Применяемые во время тестирования " черного ящика" технологии обычно называют технологиями динамического тестирования, и многие из них рассматриваются в главе 10.
2. Тестирование " белого ящика". Если известны особенности внутренней работы продукта, можно выполнить тесты, подтверждающие, что внутренняя работа продукта происходит в соответствии со спецификацией, а все внут ренние компоненты используются правильно. Термин " белый ящик" означа ет, что при разработке тестовых случаев тестировщики используют любые доступные сведения о внутренней структуре или коде. Технологии, приме няемые во время тестирования " белого ящика", обычно называют техноло гиями статического тестирования, и многие из них исследуются в главе 9.
На поздних этапах жизненного цикла программного обеспечения, которые пред ставлены правой половиной шарнирно-каскадной модели, скомпилированный про граммный код используется для управления компьютерной системой, периферийны-
|