Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 6. В о п р о с ы объединения п р о ц е с с о в т е с т и р о в а н и я . . . 155 нию. Необходимо отметить три соображения относительно привлечения субподряд чиков. Во-первых, они могут привлекаться к сотрудничеству с целью оценки трудоза трат и планирования испытаний на начальной стадии проекта. Желательно, чтобы они принимали активное участие в работах по оценке и планированию. Во-вторых, все ожидаемые результаты планов должны быть включены в договор, который согла сован и утвержден всеми заинтересованными сторонами. Наконец, задача контроля и отслеживания разработки проекта должна включать работу субподрядчиков. Пятой областью КРА, которая фигурирует в списке для уровня 2 модели СММ, яв ляется обеспечение качества. Основной функцией поддержки качества на уровне 2 яв ляется текущий контроль разработки программного продукта с тем, чтобы обеспе чить строгое соблюдение требований процесса и получить оценку качества про граммного продукта. Группа обеспечения качества служит для руководства своего рода окном, позволяющим получить представление о том, как создается проект. Группа обеспечения качества не должна зависеть от разработки и управления в том смысле, что она должна обеспечить независимый, объективный взгляд на положение вещей. Под "независимым" понимается тот факт, что группа обеспечения качества предоставляет отчеты руководству отдельно от группы разработки. И хотя группу тестирования могут попросить выступать в роли группы обеспечения качества, в рамках данной книги подобная роль не предполагается ни в одном из процессов. Все виды тестовой деятельности, такие как формальные инспекции и неформальные пе репроверки, в данном случае рассматриваются как составные части статического тес тирования. Последней областью КРА в списке для уровня 2 модели СММ является управление конфигурацией. Основное назначение управления конфигурацией состоит в размеще нии избранных рабочих продуктов в безопасном хранилище, которое контролирует ся механизмом управления версиями. Естественно, под управление конфигурациями должны подпадать документы с техническими требованиями, проектные документы и программные коды. В перспективе тестирования план проведения испытаний, тес товые случаи и результаты тестирования (включая сообщения о дефектах) так же передаются под управление конфигурациями. Мы обсуждали это в главах 3, 4 и 5, равно как и напоминали о том, что инструментальное средство управления тестиро ванием является хорошим вкладом для решения конкретных задач управления кон фигурацией силами группы тестирования. Возможности совершенствования процессов Независимо от того, используется ли в качестве базы совершенствования процессов модель СММ, или принят какой-то другой подход, для решения задачи совершенст вования процессов обычно применяется систематизированный и упорядоченный подход, который предусматривает выполнение следующих действий: • Оценка состояния текущего процесса. Первое, что следует предпринять, так это определить, где вы находитесь по отношению к принятой базовой структу ре. Для получения оценки можно привлечь консультантов извне, которые прошли специальную подготовку и способны дать оценку организации в кон тексте модели развития функциональных возможностей, подобной СММ. С другой стороны, внутреннюю оценку можно провести в форме послепроектно- го обзора, который часто предназначен не только для праздничного подведе- 156 Часть I. Процесс быстрого тестирования ния итогов окончания проекта, но и для того, чтобы определить, что сделано хорошо, а что должно совершенствоваться. Обе оценки, внутренняя и внеш няя, требуют полной поддержки со стороны верхнего эшелона руководства ор ганизации и участия специалистов, которым надлежит внедрить предлагаемые изменения и пользоваться ими в дальнейшем. • Определение областей, требующих совершенствования. По результатам оценки текущего процесса должен быть составлен список его областей, в кото рых необходимо провести усовершенствования. П р и этом важно определить их приоритеты и зафиксировать этот порядок в соответствующих планах. По пытки внести изменения сразу во все области этого списка часто приводят к глубоким разочарованиям. • Планирование работ по совершенствованию процессов. Необходимо при влечь к планированию специалистов, занимающихся внедрением усовершенст вований, что позволит учесть их предложения и заручиться их поддержкой. Такой план должен предусматривать внедрение средств измерения степени продвижения по направлению к целям совершенствования процесса. В контек сте модели развития функциональных возможностей, эта мера продвижения к цели по прошествии 12 или 18 месяцев может принять форму другой формаль ной оценки, с промежуточными контрольными точками, позволяющими от слеживать движение вперед. • Внедрение изменений и мониторинг их эффективности. После создания плана, внедрения всех его пунктов, получения отдачи и выяснения корректив следует всячески сохранять движение вперед, установив его в качестве основ ного курса развития. Для совершенствования процесса необходимо время. На переход с уровня 1 на уровень 2 у крупных организаций уходит от двух до трех лет. Продвижение неболь ших организаций может оказаться более быстрым (анализ совершенствования не больших проектов и организаций можно найти в [38]). Что дальше Данная глава завершает первую часть, посвященную подходу к тестированию про граммного обеспечения, на который мы ссылаемся как на быстрое тестирование. Бы строе тестирование есть структура, построенная на основе: • Персонала • Интегрированного процесса тестирования • Статического тестирования • Динамического тестирования. В этой главе мы обсуждали кадровый аспект тестирования и проблемы совершен ствования самого процесса тестирования. Касаемо персонала был представлен спи сок качеств, которыми должен обладать специалист по тестированию, перечислены ошибки, которые часто допускают тестировщики, и даны советы по интервьюирова нию потенциальных работников. Все это является предпосылками создания сбалан сированной группы тестирования. Глава 6. Вопросы объединения процессов тестирования... 157 Выше отмечалось, что какой бы высокой квалификацией ни обладали специали сты, если в их распоряжении не будет систематизированного и упорядоченного про цесса тестирования, они не смогут работать с максимальной отдачей. Мы сформули ровали три базовых принципа, которые следует иметь в виду, реализуя свои стремле ния усовершенствовать процесс тестирования: • Тестирование не может быть независимым процессом. • Эффективный процесс тестирования может быть построен только постепенно, стадия за стадией. • Чтобы совершенствование процесса привело к успеху, необходимо учитывать мнение конечных исполнителей. В качестве примера пошагового подхода к совершенствованию процесса приво дилась модель СММ программного обеспечения, разработанная институтом SEI. П р и этом некоторые ключевые области обработки были отображены на тестирование. В следующей части книги предлагаются хорошо зарекомендовавшие себя на прак тике советы, технологии и примеры, которыми можно воспользоваться для повыше ния эффективности тестирования. Однако, как мы убедились на базе материала этой главы, процесс разработки программного обеспечения не поддается быстрым изме нениям. Практически воплощая идеи, изложенные в первых двух частях книги, на верняка возникнет желание воспользоваться плановым пошаговым подходом к со вершенствованию. При этом изменения в первую очередь будут вноситься в те части процесса, которые обеспечат наибольший эффект. Примеры организации ключевых тестовых работ можно найти в третьей части книги. Технологии быстрого тестирования и советы Введение в технологии тестирования и советы Темы, рассматриваемые в главе: • Область применения технологий тестирования • Жизненный цикл разработки • Преимущества быстрого тестирования а Определение статического тестирования • Определение динамического тестирования • Жизненный цикл дефекта • Формальные этапы тестирования Q Обязанности членов команды тестирования • Что дальше Область применения технологий тестирования Для более наглядного представления области применения технологий тестирования в таблице 7.1 приводится список технологий, которые используются при разработке тестовых задач. Некоторые из них являются статическими, другие — динамическими технологиями тестирования. Но можно ли с первого взгляда определить, к какой ка тегории относится та или иная технология? Хотя этот список явно неполон, он при зван убедить, что при использовании только нескольких из этих технологий в проек те могут быть допущены программные ошибки, которые легко могли бы быть обна ружены в случае применения одной из других технологий. В следующих пяти главах приведены описания этих терминов, цели применения технологий и примеры использования части из них в проектах. Чтобы читателям было легче решить, когда следует применять те или иные технологии, в некоторых главах рассматриваются примеры, взятые из реальной жизни или построенные на основе опыта авторов. Глава 7. Введение в технологии тестирования и советы 161 Таблица 7.1 Технологии тестирования Аппаратное тестирование Нагрузочные испытания Испытания в утяжеленном режиме Испытания на долговечность при хранении Тестирование конфигурации Тестирование совместимости Тестирование возможностей установки Испытания надежности Испытания на пригодность к обслуживанию Тестирование документации Процедурное тестирование Приемочные испытания Климатические испытания Испытания в режиме "черного ящика" Испытания в режиме "белого ящика" Входной контроль Испытания на соответствие стандартам Сравнительные испытания Испытания граничных значений Испытания на наличие побочных эффектов Тестирование ветвей Тестирование сегментов Тестирование функциональных возможностей Тестирование модулей Испытания баз данных Логическое тестирование Аттестационные испытания Проверочные испытания (верификация) Контрольные (проверочные) испытания Сбор претензий и пожеланий Контроль синхронизации Тестирование обращений к подпрограммам Испытания работы в многозадачном режиме Испытания последовательности событий Имитационная проверка Эксплуатационные испытания Проверка точности Испытания устойчивости Тестирование на непротиворечивость Проверка ранее внесенных изменений Жизненный цикл разработки Диаграмма шарнирно-каскадной модели, представленная на рис. 7.1, помогает по нять, когда следует применять статическое тестирование, а когда — динамическое тестирование. Эта диаграмма шарнирно-каскадной модели не противоречит приве денной в конце главы 1, хотя рис. 7.1 и содержит несколько дополнительных аббре виатур, которые представляют основные термины, используемые в этой и последую- • щих главах. Документация, служащая основой для проведения комплексных, систем ных и приемосдаточных испытаний, создается, соответственно, на этапах рабочего проектирования, эскизного проектирования и разработки технического задания. Данная взаимозависимость показана двунаправленными стрелками, и именно на этих этапах некоторые проекты испытаний начинают давать сбои. Если код не удовлетво ряет требованиям технического задания, п р и ч и н о й программных ошибок могут по служить следующие три обстоятельства: • Технические требования были изменены, но это не было отражено в доку ментации • Один из случаев тестирования, сценариев тестирования или результатов испы таний содержал ошибку, которая привела к ложному обнаружению отказа • Код содержит программную ошибку 162 Часть II. Технологии быстрого тестирования и советы Т З Требования (техническое задание) Y ™ / п и Приемочные испытания Э П Эскизный проект \ / С т Системное тестирование РП Рабочий проект ки Проверка взаимодействия и _ функционирования компонентов д системы (комплексные испытания) ТМ Тестирование модулей Рис. 7.1. Диаграмма шарнирно-каскадной модели. Обратите внимание, что в двух первых случаях ошибка должна обнаруживаться средствами статического тестирования. Эти ошибки возникают вследствие несоблю дения жизненного цикла разработки. Персонал, выполняющий быстрое тестирова ние на ранних этапах разработки программного обеспечения (от разработки техни ческого задания до написания кода), обеспечит наилучшую гарантию предотвраще ния подобных неудач в процессе тестирования. В качестве общего правила можно утверждать следующее: технологии динамиче ского тестирования должны применяться разработчиками программного обеспече ния, начиная с проверки вновь созданного кода на этапе тестирования кода и моду лей (ТКМ) или раньше, если предполагалось создание прототипа. Технологии стати ческого тестирования применяются как на этапе разработки, так и на этапе тести рования. Во время разработки некоторых проектов тестировщики не приступают к работе до тех пор, пока не будет завершен этап тестирования кода и модулей (ТКМ) и пока полностью не будет написан исходный код. Фактически, иногда тестировщики начи нают свою деятельность лишь после частичного завершения этапа комплексных ис пытаний (КИ). Если в вашей организации используется именно такой поход, значит, в ней не исповедуется философия быстрого тестирования. Если специалисты по тес тированию не участвуют в разработке планов испытаний, случаев тестирования, сце нариев тестирования, не занимаются анализом результатов тестирования и статиче ским тестированием документации до и во время этапа ТКМ, стоит задуматься о на прасных потерях времени разработки, которые вызваны необходимостью устране ния ошибок, допущенных на ранних этапах жизненного цикла разработки программ ного обеспечения. Кое-кто полагает, что источником всех ошибок является исходный код. Это совершенно неверно. Например, ошибки, допущенные на этапе разработки технического задания (ТЗ), могут вылиться в месяцы напряженной работы над архи тектурными интерфейсами, низкоуровневого проектирования, создания кода и на- Глава 7. Введение в технологии тестирования и советы 163 писания документации. И лишь потом станет ясно, что полученный результат — вовсе "не то, что нам требовалось" или что "это выполняется не так, как нам требовалось". Мы часто упрекаем команду разработки технического задания, но кто из ее персонала способен обнаружить подобные ошибки и избежать их на этапе разработки ТЗ? При ходится лишь стыдиться, что никто из тестировщиков не принимал участия в работах этого этапа и, соответственно, попросту не мог обнаружить и устранить такие ошиб ки простым зачеркиванием или отправкой листа бумаги в корзину. Сколько денеж ных средств расходуется напрасно только потому, что тестировщики не участвуют в ранних этапах жизненного цикла разработки? В главе 8 рассматривается технология статического тестирования, получившая название совместной разработки требова ний к приложению (joint application requirements, JAR), которая служит примером следования ф и л о с о ф и и быстрого тестирования, т.е. того, как необходимо сочетать выработку технических требований с их тщательным тестированием. На ранних этапах жизненного цикла для описания того, что предположительно должно выполнять программное обеспечение (т.е. требования), используются слова обычного языка. Эти словесные описания превращаются в представленные в той или иной графической форме архитектурные диаграммы. Подсистемы и подблоки опре деляются соответствующими описательными фрагментами Т З . В ходе дальнейшего жизненного цикла разработки потоки операций и данных описываются другими гра фическими формами. Это же касается и таблиц, описывающих имена и отношения, которые будут положены в основу баз данных и запросов. После того, как логика про граммы полностью определена, для проверки полноты отражения программистами всех возможных ситуаций часто используются диаграммы состояний. Ошибки вно сятся во время каждого такого преобразования из одного языка описания задачи в другой. Задачей тестировщиков является обнаружение ошибок подобного рода. Стратегии разработки тестовых случаев естественным образом делятся на две ка тегории, в зависимости от того, с чем тестировщику приходится иметь дело: 1. Тестирование "черного ящика". Если известны конкретные функции, кото рые должен выполнять данный продукт, можно прогнать тесты, подтвер ждающие полную работоспособность каждой из функций. Термин "черный ящик" просто означает, что при разработке тестовых случаев тестировщики ' ничего не знают о внутренней структуре или коде. Применяемые во время тестирования "черного ящика" технологии обычно называют технологиями динамического тестирования, и многие из них рассматриваются в главе 10. 2. Тестирование "белого ящика". Если известны особенности внутренней ра боты продукта, можно выполнить тесты, подтверждающие, что внутренняя работа продукта происходит в соответствии со спецификацией, а все внут ренние компоненты используются правильно. Термин "белый ящик" означа ет, что при разработке тестовых случаев тестировщики используют любые доступные сведения о внутренней структуре или коде. Технологии, приме няемые во время тестирования "белого ящика", обычно называют техноло гиями статического тестирования, и многие из них исследуются в главе 9. На поздних этапах жизненного цикла программного обеспечения, которые пред ставлены правой половиной шарнирно-каскадной модели, скомпилированный про граммный код используется для управления компьютерной системой, периферийны- 164 Часть II, Технологии быстрого тестирования и советы ми устройствами и подсистемами обмена данными с целью реализации всех функций, которые задокументированы как требования. При этом должны удовлетворяться все архитектурные и проектные спецификации. Часто именно на этом этапе приложение запускается первый раз и может быть подвергнуто испытаниям по производительно сти, совместимости с несколькими платформами, применимости, пригодности к ус тановке и другим формам и технологиям динамического тестирования из рассмот ренных в главе 10. Теперь все подсистемы и подблоки, описанные в архитектурной и проектной документации, реализованы и скрыты внутри компьютерного кода. Преимущества быстрого тестирования Многие технологии быстрого тестирования могут применяться на ранних этапах жизненного цикла разработки программного обеспечения, как только становятся известны технические требования. В то же время, конкретные варианты этих техно логий статического тестирования часто повторяются на более поздних этапах жиз ненного цикла (глава 8 посвящена технологии быстрого тестирования на этапе опре деления технических требований). Естественно, возникает вопрос: "Не связано ли привлечение специалистов по тестированию на ранних этапах жизненного цикла разработки с увеличением затрат?". На рис. 7.2 показана модель оценки стоимости разработки программного обеспечения (исследованиям этой модели оценки стоимо сти программного обеспечения посвящается глава 12), которая наиболее точно со гласуется с экспериментальными данными по соотношению затрат для случаев обыч ного и быстрого тестирования. Сумма значений трудозатрат (в процентах), приве денных в таблице слева от этого рисунка, превышает 100%. Сумма трудозатрат этапов разработки, а именно — ЭП, РП, ТКМ и КИ, составляет 100%, и на диаграмме эти суммарные трудозатраты представлены областью, расположенной ниже кривой "раз работка — трудозатраты". Традиционно при этом трудозатраты на разработку ТЗ не учитываются, поскольку разработка ТЗ должна быть завершена до того, как можно будет планировать трудозатраты этапов разработки. Значение трудозатрат, плани руемых для этапа разработки Т З , составляет 8% для быстрого тестирования против 7% для обычного тестирования, причем это значение рассчитывается по отношению к трудозатратам, представленным областью под кривой "разработка — трудозатраты". В структуре трудозатрат на разработку программного обеспечения традиционно принято также не учитывать трудозатраты в течение первого года после поступления продукта на рынок (иногда этот этап называют этапом эксплуатации и сопровожде ния (ЭиС)). Планируемые трудозатраты этого этапа составляют 10% для быстрого тестирования и 15% для обычного тестирования (в процентах от общей суммы тру дозатрат на разработку). Обратите внимание, что хотя на диаграмме этапы разработки для случаев быстро го и обычного тестирования совпадают, из секторной диаграммы видно, что общая сумма трудозатрат при использовании технологии быстрого тестирования составля ет 56,25% от общей суммы трудозатрат в случае применения обычного тестирования (36%/64%). Поскольку трудозатраты на разработку проектов с применением быст рого тестирования меньше трудозатрат на разработку проектов с применением обычного тестирования, время поставки программных продуктов на рынок также существенно сокращается. Глава 7. Введение в технологии тестирования и советы 165 тз эп РП ткм ки ЭиС Быстрое тестирование 8 24 32 24 20 10 Обычное тестирование 7 17 24 31 28 15 Распределение трудозатрат (в %) по этапам Преимущества быстрого тестирования - Стоимость - Оптимальный календарный план - Качество продукта - Простота управления процессом разработки - Учет интересов клиентов - Чувство уверенности у разработчиков - Повторное использование продукта Рис. 7.2. Сравнение трудозатрат при быстром и обычном тестировании. Представьте себя в качестве руководителя разработки проекта с использованием технологии быстрого тестирования. Вы ведете беседу с руководителем проекта, в котором применяется обычное тестирование. Вы: "Время разработки и объем трудо затрат моего нового проекта примерно в два раза меньше времени и трудозатрат, требуемых на создание программного продукта примерно такого же объема." Руково дитель другого проекта: "Ха, готов поспорить, что качество вашего продукта никуда не годно." Вы: "На самом деле, как это ни странно, в программе оказалось всего около одной т р е т и скрытых ошибок, из числа допущенных в предыдущем проекте анало гичного объема." Руководитель другого проекта: "Во имя всех святых, но как вы этого добиваетесь?" Вы: "Мы применяем технологию быстрого тестирования с первого до последнего дня разработки, параллельно и в комплексе с самой разработкой. И это действительно окупается. Мы перехватываем контракты у конкурентов, и наши ко нечные пользователи также остаются в выигрыше!" Определение статического тестирования При статическом тестировании для визуальной экспертизы или автоматической об работки документации/кода программы с целью обнаружения ошибок используются только текстуальные и / и л и графические ф о р м ы программного обеспечения. Тек стовые или графические процессоры наподобие компиляторов, программ проверки перекрестных ссылок, эмуляторов дискретных событий, программ вывода на печать, программ статического контроля, программ распечатки ветвей и счетчиков цикло- матической сложности — все они относятся к одной категории и носят название ста тических процессоров. Многие из них представляют собой исключительно важные инструментальные средства тестировщика программного обеспечения. Существует 166 Часть II. Технологии быстрого тестирования и советы ряд выполняемых вручную процессов, применяемых при таких видах статического тестирования, как экспертизы, контрольные списки и оценка проектов. Этим вопро сам посвящена глава 8. Ошибки желательно обнаруживать до или в момент их внесе ния в жизненный цикл разработки программного обеспечения. Хорошим примером своевременного выявления/исправления ошибок может служить программа дина мической проверки орфографии, выполняющаяся внутри текстового процессора. Эта программа активно ищет текстовые строки, отсутствующие в текущем словаре, и после обнаружения такой строки, заменяет ее наиболее близким по написанию сло вом или выделяет ее, чтобы пользователь смог выбрать правильное слово из списка слов с аналогичным написанием. Хотя статическое тестирование может применяться в течение всего жизненного цикла разработки и сопровождения, оно особенно по лезно на этапах, которые предшествуют созданию выполняемого кода. Определение динамического тестирования Динамическое тестирование суть обнаружение ошибок с помощью компьютера или эмулятора компьютера, предназначенного для выполнения программы, которая была создана разработчиками в соответствии с техническими требованиями. Динамиче ское тестирование соответствует естественному стремлению, возникающему при на личии выполняющей программы. А именно — предоставить компьютеру возможность помочь в обнаружении ошибок путем выполнения ряда примеров или сценариев, ор ганизованных в форме тестовых случаев. Ориентированные на пользователя экраны, которые, быть может, высмеивались на этапах разработки ТЗ и проектирования, не ожиданно начинают оказывать влияние на характеристики производительности, ко торые, возможно, были неясны во время проводимого ранее анализа архитектуры. В процессе выполнения динамических тестов тестировщик действительно может по ставить себя на место пользователя и выполнить тест так, как любой пользователь будет использовать программу. Сначала специалисты по тестированию могут обра тить внимание на временную синхронизацию и точность результатов выполнения программы. В случае разработки новой подсистемы, прежде всего, активизируются другие подсистемы, обеспечивающие доступ к базе данных совместного использова ния, обмен данными между подсистемами или выполнение любых других функций, добавленных новой подсистемой. Тестирование на совместимость предполагает выполнение одних и тех же тестов для программы на нескольких компьютерных платформах и/или на нескольких кон фигурациях. Для сравнения, выполнение регрессивных тестов предполагает прогон одних и тех же тестов по отношению к (я+1)-ой версии программы и сравнение полу ченных результатов с результатами тестирования №ной версии. Вводя различные входные данные и наблюдая за изменением выходных данных, поведением и измене нием производительности компьютерной системы, тестировщики могут решить, го това ли программа к началу использования конечными потребителями. Не всегда это столь просто, как кажется, поскольку необходимо учитывать очень много перемен ных, таких, например, как правильность работы оборудования, корректность функ ционирования компиляторов, кода динамической поддержки и операционной сис темы, под управлением которой выполняется приложение, пригодность данных для приложения и множество других факторов. Каждый из них может служить одной из Глава 7. Введение в технологии тестирования и советы 167 основных причин возникновения вероятных ошибок, которые должны быть обнару жены во время динамического тестирования. Некоторые приложения используются широким множеством пользователей, пре следующих различные цели. Например, система ввода заказов может использоваться потребителями, являющимися в то же время сотрудниками отдела продаж, работа которых состоит в получении информации о состоянии нескольких поступивших заказов. Программа обработки заказов задействует различные части системы ввода заказов с целью получения информации о состоянии заказа и изменения части заказа. Программа обработки кредитных карточек обрабатывает исключения, которые ге нерируются модулем автоматизированной обработки кредитных карточек, являю щимся частью системы ввода заказов. Для выполнения всего сценария в среде много пользовательского приложения требуется значительная работа по предварительному планированию, логической организации и установке терминалов, линий связи, на чальной файловой структуры и координированию действий нескольких тестиров- щиков. Жизненный цикл дефекта Чтобы можно было избавиться от блокировок при тестировании, для разработчиков программного обеспечения предельно важно исправлять программные ошибки как можно быстрее на этапах динамического тестирования. Как правило, блокировки при тестировании вызываются логическими ошибками, которые препятствуют обра ботке тестовых данных соответствующими строками кода. На ранних этапах динами ческого тестирования вполне естественно, что тестировщики и разработчики тру дятся в тесном содружестве, обнаруживая и исправляя программные ошибки. Но на последних этапах тестирования или при работе над более крупными проектами роль координатора, контролера и расстановщика приоритетов играет группа контроля за внесением изменений (change control review board — CCRB), что иллюстрируется рис. 7.3. На этом рисунке показан жизненный цикл программной ошибки во время динамического тестирования. Когда программный модуль готов к тестированию, ве дущий разработчик, тесно взаимодействующий с диспетчером конфигурации про граммного обеспечения (ДКПО), выполняет операцию сборки. В результате создает ся выполняемая версия программного продукта, и исходный код обновляется до но вой версии. Персонал группы тестирования отвечает за установку испытательной среды для данной выполняемой программы, включая создание компьютерных систем, опера ционных систем, баз данных, коммуникационных линий и т.п. Кроме того, этот пер сонал выбирает подходящий набор тестовых случаев. П р и выборе тестовых случаев учитывается природа и размещение в коде программных ошибок, обнаруженных мо дулем. В соответствии со сценариями тестирования специалист по тестированию исследует программу и последовательно сравнивает промежуточные результаты с результатами тестирования, которые задокументированы в тестовом случае. Несов падение реальных и ожидаемых результатов свидетельствует либо о необходимости обновления ожидаемых результатов тестового случая реальными результатами, либо об обнаружении еще одной ошибки. После прогона выбранного набора тестовых случаев по отношению к создаваемой версии выполняется регрессивное тестирова- 168 Часть II. Технологии быстрого тестирования и советы ние с целью выяснения, не разрушили ли последние изменения какую-либо из функ ций, ранее успешно работавших. Характеристики любых новых ошибок вносятся в базу данных модели надежности и в отчет об ошибках, после чего цикл процесса от ладки продолжается. Рис. 7.3. Взаимодействие разработчика и тестировщика: жизненный цикл программной ошибки. На рис. 7.3 показан также обходной путь для продолжения тестирования этой же версии. Он пролегает через процесс правки/обхода ошибки. Группе тестирования может потребоваться разделить тестовые случаи, которые все же должны прогонять ся для текущей версии, на те, что столкнутся с этой же ошибкой, и на те, которые не должны быть подвержены ее воздействию. Это позволяет выполнять тестирование до тех пор, пока дефект не будет исправлен в будущих версиях. Иногда для продол жения тестирования требуется использование правки (patch) исполняемого модуля. В случае возникновения блокировки во время тестирования приоритет исправления ошибки повышается до наивысшего уровня. Тем самым задача немедленного исправ ления ошибки становится первоочередной. То, что группа тестирования занята динамическим тестированием, не препятст вует реализации отдельными членами группы дополнительных технологий статиче ского тестирования. Все технологии статического тестирования полностью приме нимы во время выполнения динамического тестирования. Например, результаты ряда динамических тестов могут сравниваться с ожидаемыми результатами. Эта срав нительная оценка может быть автоматизирована или же в ходе ее выполнения может Глава 7. Введение в т е х н о л о г и и т е с т и р о в а н и я и с о в е т ы 169 использоваться процесс статического тестирования, аналогичный экспертной оцен ке. В нескольких компаниях было установлено, что некоторые из членов их групп тестирования не применяют адекватные технологии статического тестирования при анализе результатов. В этих компаниях говорят, что многие из специалистов, заня тых динамическим тестированием, обладают менталитетом, который можно харак теризовать следующим высказыванием: "Что ж, этот тест действительно не привел к отказу этого компьютера!" Подобный менталитет позволяет ошибкам оставаться не замеченными во время выполнения динамического тестирования, несмотря на то, что сами по себе тестовые случаи обеспечивают возможность обнаружения и ранее неизвестных ошибок. Похоже, что менталитет наподобие "... это не привело к отказу компьютера" пре обладает также среди персонала, занимающегося динамическим тестированием про дуктов, в которых используется обмен данными через модемы. Обмен данными по средством модемов имеет долгую историю, и приобрел репутацию сопряженного с такими сбоями, как генерация сигналов занятости, несоответствие скорости переда чи данных отвечающего и запрашивающего модемов или даже ошибки из категории "прочие", которыми тестировщики склонны объяснять любое беспричинное зависа ние отвечающего модема. Не сообщая о подобных ошибках, тестировщики подвер гают свою компанию риску продолжать поставлять тестируемый продукт с неустра- ненными коммуникационными ошибками. Предположим, что подобный продукт был продан и установлен в нескольких помещениях больницы. Эти загадочные сбои типа "отвечающий модем просто зависает без видимой причины" будут как раз такими сбоями, которые становятся основной причиной нареканий со стороны сотрудников больницы, совершенно справедливо полагающих, что модемы должны немедленно обеспечивать соответствующую скорость обмена данными и соединение (при отсут ствии сигнала занятости). Такие сбои не только становятся причиной обращения в службы технической поддержки больницы, телефонной компании и фирмы- изготовителя модема, но зачастую служат причиной претензий в адрес компании, которая выпустила или продала программный продукт. Формальные этапы тестирования Динамическое тестирование может начинаться с этапа тестирования модулей и за вершаться приемочными испытаниями. Стратегии динамического тестирования де лятся на две категории: а именно на тестирование "черного ящика" и тестирование "белого ящика". Как правило, стратегия тестирования "белого ящика" применяется на этапах тестирования модулей и комплексных испытаний, в то время как стратегия тестирования "черного ящика" — на этапах системного тестирования и приемочных испытаний. Цель тестирования модулей состоит в том, чтобы убедиться в реализации в коде всех запроектированных функций и в устойчивости воспроизведения общих воз можностей и непротиворечивости выполнения программного модуля. П р и тестиро вании модулей для управления тестом во время выполнения часто применяются драйверы и заглушки, в то время как при комплексных испытаниях для управления комплексными функциями, образованными несколькими модулями или подсистема ми, как правило, используется GUI-интерфейс. 170 Часть II. Технологии быстрого тестирования и советы Цель, комплексных испытаний является необходимость убедиться в соответствии по входным и выходным параметрам всех интерфейсов между модулями или подсис темами, а также в правильности других совместно используемых или передаваемых данных, таких как, например, записи и поля баз данных, совместно используемые экраны GUI-интерфейсов или разделяемые коммуникационные магистрали. Системное тестирование может начинаться непосредственно после завершения комплексных испытаний всех модулей или, по крайней мере, тех из них, которые образуют основную подсистему. Системное тестирование должно фокусироваться на глобальных вопросах производительности, масштабируемости, пригодности к уста новке, устойчивости к воздействиям окружающей среды и общей применимости ко нечными пользователями. В ходе приемочных испытаний версии программных продуктов, являющиеся кан дидатами для поставки на рынок, исследуются с целью определения их приемлемости для конечных пользователей. В случае применения методологии быстрого тестиро вания для выполнения всех этих этапов жизненного цикла тестирования требуется все меньше и меньше времени, поскольку большая часть ошибок обнаруживается и устраняется на ранних этапах разработки. Обязанности членов команды тестирования Специалисты по тестированию выполняют подготовку к тестированию, прогоняют тесты и докладывают о результатах тестирования. Существует много должностей, необходимых для обеспечения полноценной работы команды тестирования. Эти должности, особенно в небольших проектах, могут занимать лица, обладающие подготовкой в нескольких областях. Краткий перечень должностей приведен в таблице 7.2. Таблица 7.2 Обязанности членов команды тестирования Выполняемая работа/должность Обязанности Обеспечение качества Предоставляет перечень и подробные определения всех действий по тестированию, включая шаблоны и примеры. Обеспечивает инструктаж и тренировку по созданию планов тести рования и тестовых случаев. Обеспечивает текущий мониторинг и поддержку во время проведе ния тестирования с учетом точного распределения ролей в каждом из планов тестирования. Аудит и управление Обеспечивает ввод дополнительных условий, которые должны ока зывать влияние на управление тестированием, и выполняет другие функции, связанные с аудитом. Предоставляет обзоры, касающиеся соответствия стандартам по аудиту. Глава 7. Введение в технологии тестирования и советы 171 Окончание табл. 7.2 Выполняемая работа/должность Обязанности Разработчик программного обеспечения Бизнес-аналитик Разработчик тестов Тестировщик Отладчик Менеджер- тестирования Администратор тестирования Предоставляет документацию по тестированию модулей. Оказывает тестировщикам помощь в создании тестовых случаев для проведения испытаний основных компонентов, комплексных, системных и приемочных испытаний. Осуществляет руководство разрешением проблем во время выполнения тестирования. Выполняет тестирование модулей. Создает план приемочных испытаний. Создает тестовые случаи для проведения приемочных испытаний. В содружестве с тестировщиком создает тестовые случаи для про ведения тестирования основных компонентов. Проводит приемочные испытания. Просматривает и утверждает критерии приемки. Создает тестовые случаи для проведения тестирования основных компонентов, комплексных и системных испытаний. Проводит комплексные и системные испытания. Во время проведения приемочных испытаний предоставляет техническую поддержку с целью разрешения возникающих проблем и вопросов. Прогоняет тестовые случаи. Записывает реальные результаты. Заполняет отчеты о возникших во время тестирования проблемах. Проверяет устранение обнаруженных проблем. Обеспечивает устранение обнаруженных проблем. Проверяет действительное наличие обнаруженных проблем. Обеспечивает устранение всех аспектов обнаруженной проблемы, в том числе исправление документации для пользователя. Обеспечивает создание инфраструктуры тестирования, в том числе управление тестированием и обеспечение инструментальными средствами для его проведения. Осуществляет координирование/управление всеми действиями по тестированию. По мере необходимости определяет приоритетность устранения проблем. Докладывает о ходе тестирования руководству проекта и руково дству службы по работе с клиентами/пользователями. Отслеживает соответствие между реальными и плановыми сроками выполняемых работ. Регистрирует отчеты о возникающих в ходе тестирования проблемах. Подготавливает ежедневные сводки о состоянии выполнения работ, сравнивая их выполнение с планом и с общим объемом работ по тестированию. 172 Часть II, Технологии быстрого тестирования и советы Что дальше В главах 8 и 9 подробно рассматриваются технологии статического тестирования. Глава 10 посвящена технологиям динамического тестирования. В главах 11 и 12 ос вещены показатели тестирования и модели оценки затрат на тестирование. Вот на звания этих глав: 8. Совместная разработка требований к приложению (JAR): метод выработки требований с применением быстрого тестирования 9. Технологии статического тестирования и советы 10. Технологии и советы по динамическому тестированию 11. Разработка и использование показателей тестирования: моделирование и прогнозирование ошибок 12. Технологии оценки трудозатрат на тестирование и советы Совместная разработка требований к приложению (JAR): метод выработки требований с применением быстрого тестирования Темы, рассматриваемые в главе: • М е т о д о л о г и я JAR Q Р о л ь с п е ц и а л и с т о в по т е с т и р о в а н и ю в п р о ц е с с е JAR • Р е з ю м е Одно из основных условий успешной разработки программного обеспечения — дос тижение понимания требований клиентов. Как было показано в главе 2, четкое опре деление технических требований служит отправной точкой эффективного процесса разработки программного обеспечения. Существуют различные методы, призванные улучшить обмен информацией между клиентом и командой разработчиков. Один класс методов, используемых для выра ботки технических требований, называется технологией ускоренной разработки спецификации приложения (fast application specification techniques, FAST), которая кратко описывалась в главе 2. Совместная разработка требований к приложению (Joint Application Requirements, JAR) — это технология FAST, которая предназначена для обеспечения полной интеграции статического тестирования с процессом выра ботки требований. Интеграция статического тестирования в процесс JAR в виде его составной части достигается за счет выполнения действий, известных под названием совершенной поддержки. Совершенная поддержка — это организованный способ ин терактивного анализа и пересмотра выработанных требований. Действия, связанные с совершенной поддержкой, описаны далее в этой главе. Результатом JAR-сеанса является набор тщательно проанализированных требова ний, которые согласованы с пользователями конечного продукта или их представи- 174 Часть II. Технологии быстрого тестирования и советы телями. Требования, выбранные в JAR-сеансе, включают в себя как функциональные, так и подходящие нефункциональные требования. Например, сюда может входить календарный план поставки продукта по этапам. Методология JAR Участвующие в JAR-сеансе образуют комиссию, составленную из представителей ко манды разработчиков, нескольких пользователей, знакомых с различными функцио нальными возможностями, которые должны присутствовать в конечном продукте, представителя клиента/покупателя и председателя комиссии JAR. Как правило, для проведения заседаний комиссии JAR на одну-две недели выделяется просторный конференц-зал. Одна из возможных схем расположения мест в конференц-зале с уче том ролей приглашенных для участия в JAR людей показана на рис. 8.1. Рис. 8.1. Размещение основных участников в помещении для проведения JAR. Обратите внимание, что в состав комиссии не входят ни менеджеры, ни вице- президенты, ни представители отдела обеспечения качества, ни представители отде ла снабжения, ни представители отдела поставки. Если кто-то из представителей этих подразделений появляется на одном из заседаний комиссии, председатель должен попросить их покинуть зал на период обсуждения вопросов совершенной поддержки, которые будут описаны позже. Члены комиссии не должны пропускать заседания и их не должны отвлекать сообщениями или телефонными звонками. Роль председателя состоит в постоянно удерживать в центре внимания команды три следующих задачи: выработка требований, четкая формулировка требований и уточнение требований. Накануне заседания комиссии JAR председатель должен про вести установочное совещание для ознакомления членов комиссии со стоящими пе ред ней целями и правилами работы. В ходе этого установочного совещания члены Глава 8. Совместная разработка требований к приложению (JAR) 175 комиссии должны дать свое согласие действовать в соответствии со следующими правилами: • Не допускать личных нападок. Например, не пренебрегать и не дискредитиро вать идеи, высказанные другими участниками. • Помнить, что одновременно может высказываться только один человек. • Прежде чем предлагать какую-то идею, подумать о том, какова ее ценность, и окажет ли она влияние на конечный продукт. • Тщательно формулировать свои предложения, и после их анализа документи ровать их в заключительном документе. • Задавать вопросы только председателю. • Подавать председателю сигнал о необходимости перерыва в заседании (напри мер, скрестив руки), принятый в комиссии на случай возникновения непредви денных ситуаций/перерывов (например, при необходимости перерыва для от дыха или если был замечен какой-либо личный выпад). • Во время заседания комиссии JAR не допускать проявления никаких внешних отвлекающих факторов (сообщений электронной почты, вызовов по пейджеру или телефону). • Присутствовать на заседаниях, быть внимательным, творческим и полезным. Председатель знакомит членов комиссии с целями и ограничениями проекта по созданию программного обеспечения, а также определяет цели работы комиссии JAR, в числе которых: • Сбор сведений о потребностях и ожиданиях пользователей, а также определе ние показателей эффективности. • Анализ потребностей и ожиданий пользователей для выработки словесного описания функционирования системы и отдельных функций, которые должны выполняться продуктом. • Выработка требований по поставке и модернизации продуктов, которые долж- .ны устанавливаться и модернизироваться на рабочих местах пользователей. • Разработка формулировок всех разделов требований, которые должны быть освещены в итоговом документе. • Получение от клиента и пользователей подтверждений того, что формулиров ки требований удовлетворяют их потребности и ожидания. • Составление поэтапного графика поставки продукта с расширяющимся набо ром возможностей с целью удовлетворения текущих и долговременных по требностей и ожиданий пользователей, а также определение показателей эф фективности этих поэтапных поставок. В состав комиссии должны входить опытные эксперты по исходным материалам (source matter expert, SME), обладающие глубокими познаниями в области бизнес- правил, областей применения и потоков данных, которые должны учитываться во время разработки новой системы. Приходящие эксперты по исходным материалам приглашаются на интервью, посвященные выработке требований, каждое из кото рых длится около 1,5 часов. На эти интервью могут приглашаться до двадцати экс- 176 Часть II. Технологии быстрого тестирования и советы пертов, по двое одновременно. По окончания каждого интервью комиссии выделяет ся время на документирование требований, которые были выработаны на основе доклада эксперта, и для отражения мероприятий по совершенной поддержке на пла катах, которые применяются для фиксации требований. Типовой календарный график работы комиссии JAR типа "когда, кто и почему" показан в табл. 8.1. В этом примере представлены семь отдельных заседаний: устано вочное, три дня интервью с экспертами по исходным материалам, два рабочих дня и один день подготовки материалов для формальной документации. Поскольку в ходе каждого заседания, посвященного интервью с экспертами, беседа проводится с двумя из них, в этом примере в заседаниях комиссии JAR всего принимают участие 24 экс перта. Прежде чем начнутся рабочие заседания, комиссии может потребоваться пол дня для реорганизации настенных плакатов. С целью минимизации ощущения избы точности может потребоваться объединение аналогичных плакатов. Кроме того, мо жет возникнуть необходимость определить приоритеты требований в двух наборах, например, разделение требований на те, что могут быть реализованы на первом эта пе представления проекта, и те, которые должны быть реализованы на втором этапе. Поскольку каждое рабочее заседание проходит в среде, подобной библиотечной, на каждое из 6 рабочих заседаний приглашаются только по 4 эксперта по исходным ма териалам. Кроме экспертов по исходным материалам, на рабочие заседания в качест ве наблюдателей могут быть приглашены несколько лиц, чье служебное положение не позволяет им входить в состав комиссии. Между рабочими заседаниями члены ко миссии выполняют процедуры совершенной поддержки для включения комментари ев экспертов по исходным материалам в основной набор плакатов. Таблица 8.1. Когда ,Типовой Кто календарный график заседаний комиссии JAR |