Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 9. Технологии статического тестирования и советы 207 Для того чтобы отстоять примененный нами метод достижения оговоренной в контракте производительности в данном случае, пришлось доказать, что базовая программа полу- чает неверное значение массы земного шара и поэтому преобразованная программа не должна получать такой же ошибочный результат. Приложение анализа общей ошибки округления суть технология статического тестирова- ния, берущая свое начало из области численного анализа, который подробно преподает- ся на университетских курсах по теории вычислительных машин и систем. 8 этой теории каждая переменная входных данных имеет связанный с ней вектор ошибок. Если Х,=С,+с„ a y,—D,+d„ то ошибка E определяется следующим выражением: ' где E(N)=SUM(c,+ d,) для i=1 N Далее, поскольку при считывании входных значений компьютер всегда усекает действи- тельные значения X, и У„ значения с, и d, всегда будут неотрицательными усеченными значениями. Следовательно, функция ошибок E(N) монотонно возрастает и является не- ограниченной сверху. Этот численный анализ может быть выполнен применительно к бо- лее сложным алгоритмам для проверки их ограничений по стабильности. Подводя итог этому реальному примеру, отметим следующее: тестировщики, имеющие дело с научными приложениями, должны уметь выполнять численный анализ сложных алгоритмов, чтобы определить граничные условия компьютерных имитаций, в которых задействованы эти сложные алгоритмы. Хотя упомянутые требования могут казаться не- померно высокими для тестировщиком, они помогают показать ценность специалистов, обладающих подготовкой в области численного анализа или общей математической под- готовкой. Такие специалисты по тестированию смогут обнаружить нестабильные алго- ритмы и отыскать для них стабильные альтернативы, которые окажутся гораздо более предпочтительными для компьютерных имитаций, особенно в сфере научного программирования. Диспетчер тестирования Роль диспетчера тестирования заключается в организации и направлении повсе дневного продвижения и отслеживании состояния тестирования с использованием подхода быстрого тестирования. В небольших проектах эту роль может выполнять руководитель проекта. В средних проектах эта должность может называться "руково дитель тестирования". В случае очень больших проектов, во время динамического тестирования эти обязанности могут выполняться отдельным, полностью занятым только этой работой лицом, работающим с командой тестирования, специалистами по сетям, администраторами баз данных, техниками лаборатории тестирования и бизнес-аналитиками, которые представляют интересы сообщества пользователей. При выполнении тестирования применимости эта должность может называться за ведующим лабораторией применимости. Такой заведующий призывает посетителей из сторонних организаций испытать новый набор продуктов и технологий на пред мет удобства его использования в реальных сценариях. Роль диспетчера тестирования заключается в изучении планов тестирования про екта и реализации следующих координационных действий: • Определение и управление календарными графиками загрузки персонала, ко торые потребуются для прогона полного набора тестовых случаев. • Обеспечение соответствия порядка выполнения тестов потоку данных в про граммном обеспечении. • Документирование сценариев тестирования. 208 Часть II. Технологии быстрого тестирования и советы • Проектирование форм отчетности по тестированию, которые будут запол няться, анализироваться и сравниваться с данными результатов прогона тес тов. • Сбор данных о состоянии тестов, выполняемых в реальном времени, и состав ление соответствующих отчетов. Как видите, роль диспетчера тестирования в чем-то аналогична роли режиссера кинофильма или мультимедиа-продукта. Без диспетчера тестирования отдельные тестировщики, каждый из которых работает с собственным поднабором тестов, соз давали бы хаос из-за недостаточной согласованности календарного графика выпол нения тестирования, тестовых платформ, недостаточно полного совместного ис пользования файлов, отсутствия "снимков" результатов тестирования и резервных копий, которые потребуются для генерирования среды каждого тестового случая. Параллельное выполнение тестирования несколькими специалистами с использова нием независимых и разделяемых сетевых ресурсов требует наличия организованно го плана, согласованного выполнения и обобщения результатов. Защита интересов конечных пользователей, выполняется ли она бизнес-аналитиками, сопровождаю щими большие действующие информационные системы, или псевдо-конечными пользователями коммерческого продукта, требует присутствия специально назна ченного лица, а именно диспетчера тестирования. Диспетчер должен обеспечивать готовность календарных графиков, ресурсов и данных к моменту начала тестирова ния, а по завершении тестирования тот же диспетчер должен составлять списки про блем с их приоритетами и передавать все материалы в команду разработки. Часто планы тестирования требуют тестирования совместимости для нескольких конфигураций, например, Wintel PC, MAC, Linux и PDA, каждая из которых имеет множество периферийных устройств типа сканеров, принтеров, модемов, дисково дов CD-RW, видеокамер, джойстиков и удаленных клавиатур или игровых устройств ввода/вывода. Кроме того, тестовое оборудование может потребоваться для тести рования нескольких проектов, поэтому между сеансами тестирования возникает не обходимость в сборке или разборке конфигураций. С целью оптимизации и эффек тивного управления лабораторией тестирования создается должность диспетчера тестирования, которому часто помогают несколько техников этой лаборатории. Диспетчер дает указания техникам по установке тех или иных аппаратных и про граммных платформ и сетевых ресурсов, задействованных в нескольких проектах. Он же планирует время работы лаборатории и обслуживающего персонала. В подразде лениях информационных технологий эта задача может оказаться очень сложной и должна выполняться несколькими диспетчерами тестирования. При этом должны использоваться компьютерные системы на базе мейнфреймов и множества термина лов или ПК для бизнес-аналитиков, которые соединяются между собой через гло бальную корпоративную сеть. Кроме того, для имитации реальной производственно^ среды корпоративная сеть должна иметь соединения электронного обмена данными (electronic data interchange, EDI) со множеством серверов бизнес-партнеров; подоб ные соединения получили название телекоммуникаций типа "бизнес-бизнес" (busi ness-to-business, В2В). Глава 9. Технологии статического тестирования и советы 209 Базы данных материалов совместного использования Когда команда тестирования обнаруживает проблему в программном обеспечении, последняя должна быть зарегистрирована, должен быть определен ее приоритет, установлен календарный график ее устранения командой разработки, определен график подготовки версии к тестированию, выполнено повторное тестирование на предмет устранения первоначальной проблемы и возникновения побочных эффек тов. Простейший способ решения этих проблем заключается в использовании базы данных материалов совместного использования. Каждая запись в этой базе данных представляет одну проблему и имеет поля, заполняемые каждым сотрудником, кото рый сталкивался с данной проблемой. Для обеспечения эффективного поиска нуж ных материалов база данных материалов совместного использования может быть отсортирована и разбита на отдельные базы данных по каждой программной подсис теме, по штату разработки каждой программы, по используемому программному обеспечению других организаций и по каждому типу проблем. Кроме того, админи страторы базы данных должны часто выполнять вставку обновленных записей в базу материалов совместного использования. Для проверки того, что проблемы отслеживаются, а сведения о них сообщаются всеми организациями-участниками разработки, необходимо выполнять периодиче ские просмотры и оценки состояния базы данных. Как правило, команды разработки сопровождают несколько версий результирующего продукта. В некоторых случаях сопровождение или создание версии может выполняться отдельным лицом, назы ваемым создателем версии. Для этих версий должны составляться календарные пла ны и предусматриваться повторное тестирование, при этом база данных материалов совместного использования будет обновляться текущими данными таких сеансов по вторного тестирования. Современной реализацией базы данных материалов совместного использования должен быть защищенный Web-сайт, управляемый базой данных, который находится в экстрасети, принадлежащей генеральному подрядчику. Для обеспечения возможно сти обновления и внесения изменений в соответствующие записи базы данных со стороны персонала каждого проекта потребуется создать программы обслуживания приложений (application service program, ASP) с механизмом транзакций. Подобная реализация обеспечивает полностью авторизованное сотрудничество партнеров по разработке, поддерживая отсортированные по приоритетам списки проблем. Имен но поэтому описанная система рассматривается как успешная реализация концепции быстрого тестирования. Резюме В этой главе был исследован набор реальных технологий, которые тестирующая ор ганизация должна немедленно взять на вооружение, если она желает ступить на путь быстрого тестирования. На основании главы 7 можно сделать вывод, что сильным аргументом в пользу применения технологий быстрого тестирования служит воз можность завершения разработок вдвое быстрее при использовании вдвое меньшего количества людей и при допуске вчетверо меньшего количества скрытых дефектов в 210 Часть II. Технологии быстрого тестирования и советы конечном продукте. Основная идея этой главы, посвященной статическому тестиро ванию, состоит в том, что в рамках жизненного цикла разработки необходимо как можно раньше приступать к поиску ошибок и вводу отчетов об ошибках в базы дан ных совместного использования. Точно так же быстро следует исправлять ошибки и извлекать соответствующие уроки, помещая сведения об ошибках в контрольные пе речни и модели надежности. В конце концов, эффективность проделанной работы должна оцениваться, прежде всего, на основе количества обнаруженных ошибок. По стоянное совершенствование процесса разработки приводит к снижению числа до пускаемых просчетов, уменьшает количество персонала, необходимого для этапов динамического тестирования и снижает количество рекламаций со стороны клиентов. Технологии динамического тестирования и советы Темы, рассматриваемые в главе: • Функциональное тестирование и анализ • Разделение по классам эквивалентности • Анализ граничных значений • Отрицательное тестирование • Тестирование на основе определения степени риска • Определение полноты охвата ветвей при тестировании • Тестирование случаев использования • Псевдоотладка/видоизменение • Трассировка/трассировка снизу вверх/ мгновенные дампы/постпечать • Создание точек прерывания/правки • Тестирование потока данных • Тестирование на предмет утечек памяти • Тестирование интерфейса "человек-компьютер" • Тестирование нагрузочной эффективности • Тестирование конфигурации платформы • Резюме 212 Часть II. Технологии быстрого тестирования и советы У читателей может возникнуть вопрос: "Какие ошибки могут остаться незамечен ными после интенсивного применения технологий статического тестирования, ти пичных для методики быстрого тестирования?" Ответ очень прост: скрытые ошибки. Скрытые ошибки — это ошибки, которые существуют, но не обнаружены. В среднем программы, попадающие к конечным пользователям, содержат от 0,2 до 20 скрытых ошибок на тысячу инструкций исходного кода (К delivered source instructions, KSDI). В случае интенсивного применения технологий статического тестирования при раз работке проекта, к началу динамического тестирования количество скрытых ошибок должно снизиться на 65—80%. Остальные 20—35% скрытых ошибок должны быть об наружены на этапах тестирования модулей (ТМ), комплексных испытаний (КИ), сис темных испытаний (СИ), приемочных испытаний (ПИ) и сопровождения. В течение динамического тестирования обнаруживаются ошибки, которые были допущены во время процессов определения требования технического задания (ТЗ), эскизного проектирования (ЭП), рабочего проектирования (РП) и кодирования. Еще? одним, иногда упускаемым из виду, источником скрытых ошибок является повторно используемое программное обеспечение. К возможными типам ошибок относятся: логические ошибки, простые опечатки, ошибки организации данных, ошибки, влияющие на эффективность, ошибки применимости, ошибки запросов баз данных, ошибки доступа к файлам, дефекты интерфейсов, ошибки управления загрузкой, от сутствующие функции, ошибочные алгоритмы, проблемы обмена данными, дефекты сценариев тестирования, неверное вычисление результатов тестов и множество дру гих. Короче говоря, последовательное накопление ошибок, которые все еще остают ся скрытыми на момент начала динамического тестирования, происходит на всех предыдущих этапах проектирования. За счет применения методики быстрого тести рования, которая позволяет максимально быстро выявить и исправить большинство скрытых ошибок, можно сэкономить время и существенно снизить трудозатраты. На этапах ТЗ и ЭП жизненного цикла разработки функциональные требования объединяются с нефункциональными. Примерами нефункциональных требований могут служить календарный план поставки продукта, состав установочного комплек та, требования по заполнению базы данных, временные характеристики алгоритма, человеческий фактор, требования к поддерживаемым конфигурациям, коммуника ционная инфраструктура, требования к обеспечению безопасности, надежность и т.п. Большинство из этих требований разрабатывается на основе стандартов про граммирования или руководств по стилю, действующих в конкретной организации. Как правило, стандарты программирования создаются на базе опыта работы органи зации. Извлеченные в процессе деятельности уроки, наряду с результатами марке тинговых исследований программной продукции конкурирующих организаций, оформляются в виде стандартов программирования, иногда называемых руково дствами по стилю. Если ваша организация готова инвестировать определенные сред ства в тестирование, имеет смысл вкладывать их в автоматизацию тестирования стандартов программирования или руководств по стилю. После такого инвестирова ния персонал, занимающийся быстрым тестированием, может повысить скорость работы за счет многократного использования существующих планов тестирования, тестовых случаев, сценариев и средств тестирования, которые разработаны для про верки выполнения нефункциональных требований. Однако специалистам по тести рованию все еще придется разрабатывать тестовые случаи, сценарии тестирования, Глава 10. Технологии динамического тестирования и советы 213 методы обработки результатов тестов и средства тестирования при подготовке к ис пытаниям новых функций продукта, т.е. выполнения функциональных требований. В этой главе исследуется множество технологий динамического тестирования. Тем не менее, представленный в ней набор технологий не является исчерпывающим. Цель применения этих технологий заключается в планомерном и эффективном уменьшении количества скрытых ошибок в программном продукте. Во время плани рования своей работы члены команды тестирования должны самостоятельно опре делять подходящий количественный и качественный состав применяемых техноло гий. Результатами выполнения задач по разработке тестов, которые имеют исключи тельно большое значение для достижения цели планомерного выявления скрытых ошибок, являются планы тестирования, тестовые случаи, сценарии тестирования и методы обработки результатов тестирования. Функциональное тестирование и анализ Функции, на которые иногда ссылаются как на функциональные возможности, — это именно то, разработку чего оплачивают пользователи. Часто в литературе, посвя щенной торговле и маркетингу, эти функции представляют в виде маркированных перечней, которые сравниваются с аналогичными перечнями конкурирующих про дуктов. Эти перечни функций продукта определяются на этапе разработки требова ний и тщательно отслеживаются в ходе выполнения этапов проектирования и коди рования, например, в матрице прослеживаемости требований (Requirements Trace- ability Matrix, RTM). Эти функции являются побочным результатом так называемого пошагового уточнения, и они представляют собой фрагменты исходного кода, обра зующие модули или объекты. Функциональный анализ представляет собой действия по описанию характери стик функции, влияющих на процесс ее проектирования и тестирования. Предполо жим, что имеется разложение в ряд Тейлора для функции y(x;)=sin(x) (см. раздел "Символьное выполнение" в главе 9). На этапах проектирования следовало бы вы полнить функциональный анализ для определения точности вычисления разложения как в плане указания размера слова, требуемого для хранения используемых пере менных с плавающей точкой, так и в плане любых промежуточных результатов. На пример, для некоторых функций можно показать, что точность частичного разложе ния для переменной у(х) будет повышаться с увеличением количества членов ряда Тейлора. Важно отметить, что если на этапах проектирования функциональный ана лиз не выполнялся, его придется выполнить во время подготовки к динамическому тестированию. Организации, откладывающие оценку точности алгоритма до момен та начала динамического тестирования, не могут быть отнесены к тем, которые ис поведуют стратегию быстрого тестирования. В организациях, взявших на вооруже ние методику быстрого тестирования, во время разработки тестовых случаев, подго товки тестовых данных, сценариев тестирования и технологий обработки результа тов тестов специалисты, ответственные за подготовку к динамическому тестирова нию, просто ссылаются на документацию по функциональному анализу. 214 Часть П. Технологии быстрого тестирования и советы ПРИМЕР: НЕОБНАРУЖЕННОЕ ПЕРЕПОЛНЕНИЕ ПРИ ВЫПОЛНЕНИИ ОПЕРАЦИЙ С ПЛАВАЮЩЕЙ ТОЧКОЙ (ГЭРИ КОББ) Автор вспоминает ситуацию, когда ему довелось столкнуться с реализацией метода ко- нечных разностей для решения системы дифференциальных уравнений в частных произj водных, причем пришлось вплотную заняться функциональным анализом влияния округ- ления и усечения на промежуточные результаты. В ходе этого исследования выяснилось что исходный код вычисляет интеграл по сетке значений переменной с именем mass (масса). По мере добавления отдельных масс, промежуточный результат становился на столько большим, что при достижении приблизительно середины сетки добавление, ос- тальных масс переставало влиять на значение суммы, которое.представлялось значени ем с плавающей точкой. Это было связано с быстрым увеличением показателя степени промежуточной суммы, что приводило к тому, что инструкция выравнивания |показателя степени (используемая при работе со значениями с плавающей точкой) компьютера пренебрегала массами, показатели степени которых были малы по сравнению с показа- телем степени промежуточной суммы. К упомянутому функциональному анализупри ШЛось прибегнуть, когда тестирование позволило сделать вывод что программа будет| выдавать различные результаты при вылолнении ее с использованием инструкции работы со значениями с плавающей точкой одинарной и двойной точности либо при Запуске на компьютерах, в среде которых длины слов отличаются. Разделение по классам эквивалентности Принадлежность двух элементов данных к одному и тому же классу эквивалентности просто означает, что с каждым из них функция выполняет одни и те же операции. Принадлежность двух элементов данных к различным классам эквивалентности оз начает, что существует, по меньшей мере, одна строка кода, требуемая для обработки одного элемента данных, которая не будет использоваться при обработке другого элемента данных. Часто данные, принадлежащие к одному из двух классов эквива лентности, называют правильными данными, а данные второго класса эквивалентно сти — неправильными данными для данной функции. Ветви кода, которые используются для обработки правильных данных, называются удачными ветвями, в то время как вет ви, выполняемые функцией при обработке неправильных данных, называются не удачными ветвями. В проектной документации для большинства функций определены правильные и неправильные входные данные. Для определения классов эквивалентно сти данных для каждой функции тестировщики должны прочесть проектную доку ментацию. Если эта информация отсутствует в проектной документации, тестиров- щику придется применить функциональный анализ и восстановить информацию о классах эквивалентности снизу-вверх. В некоторых случаях в проектной документа ции может использоваться также термин допустимых и недопустимых данных для дай ной функции. Операции тестирования во время ввода неправильных данных доста точно точно называются отрицательным тестированием. Неправильные данные вы бираются с тем, чтобы убедиться в наличии в каждой функции обработчиков исклю чений, выполняющих обработку неправильных данных. Отрицательное тестирова ние не ограничивается одним лишь выполнением операций тестирования для случая неправильных данных (обратитесь к разделу, посвященному отрицательному тести рованию, далее в этой главе). Одна из принципиальных отличительных черт специалиста по тестированию, применяющего технологии быстрого тестирования, состоит в том, что при оценке вероятности наличия скрытых ошибок, которые могут препятствовать эффективно- |