Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 4. Проектирование и разработка тестов 109 • Допустимыми вводами являются все пятизначные наборы цифровых символов, образующих рабочий почтовый код • Недопустимыми вводами являются: • Наборы цифровых символов, содержащие менее пяти символов • Н а б о р ы цифровых символов, содержащие более пяти символов • Наборы из пяти символов, не являющиеся рабочим почтовым кодом • Наборы из нецифровых символов. Аналогичное разбиение может быть построено и для массы брутто отправляемого груза. Например, требуется программа, работающая только с грузами, масса которых находится в диапазоне от 1 до 100 унций. В этом случае числовые значения, попа дающие в диапазон от 1 до 100, включая и конечные точки, являются допустимыми. Все значения меньше 1 и больше 100, отрицательные значения и нецифровые значе ния образуют недопустимые классы ввода. Нужно спроектировать такие тесты, которые выполняют проверку, по меньшей мере, одного представителя каждого допустимого класса ввода и, по меньшей мере, одного представителя недопустимого класса ввода. В результате тестирования с при менением допустимых вводов должны быть получены однозначно определенные и ожидаемые результаты. Для почтового кода 78723 и массы в 20 унций ожидается по лучить конкретное значение стоимости, и это значение должно быть определено в функциональных требованиях. В случае ввода недопустимых данных должно быть получено соответствующее сообщение об ошибке, если оно определено в техниче ских требованиях и спецификациях. П р и вводе недопустимых данных программа, по меньшей мере, не должна завершаться аварийно, вызывать искажение данных или вести себя непредсказуемым образом. Более подробное обсуждение разбиения на классы эквивалентности можно найти в главе 10, а также в [36], [27], [43], [28] и [17]. Анализ граничных значений. Анализ граничных значений представляет собой тех нологию проектирования тестов, которая является дополнением разбиения на клас сы -эквивалентности. Вместо того чтобы выбирать некоторый конкретный элемент класса эквивалентности, анализ граничных значений предлагает проектировщику теста выбрать элементы, которые находятся "на границе" класса. Экспериментально было доказано, что дефекты имеют тенденцию концентрироваться на границе облас ти ввода, а не в ее центре. Не особенно ясно, почему так получается, это всего лишь установленный факт. Например, в случае программы, которая для почтового индекса и веса отправляе мого груза вычисляет стоимость доставки, анализ граничных значений позволяет применять в качестве тестовых значений минимальное и максимальное значение ве са (1 унция и 100 унций), а также ближайшее значение, меньшее минимально допус тимого (0 унций), и ближайшее значение, большее максимально допустимого (101 унция). Эти значения позволяют проверить границы диапазона допустимых значе ний, а также значения, выходящие за пределы этого диапазона. Более подробную информацию по анализу граничных значений можно найти в главе 10, а также в [36], [27], [43] и [17]. 110 Часть I. Процесс быстрого тестирования Определение ожидаемых результатов Основу динамического тестирования составляет прогон управляемого набора опера ций на конкретной сборке программного продукта и сравнение полученных резуль татов с ожидаемыми результатами. Если получены ожидаемые результаты, то тест считается прошедшим на этой сборке; если зафиксировано аномальное поведение, то считается, что тест на этой сборке не прошел, в то же время этот тест, возможно, позволил обнаружить очередную неисправность. Непременным условием для опре деления, прошел или не прошел конкретный тест, является однозначное определе ние ожидаемых результатов этого теста. Таблица 4.2. Примеры ожидаемых результатов Шаг Действие Ожидаемый результат Отметка (V) 1. Щелкнуть на элементе "Стоимость На экран выводится меню доставки" в главном меню. Стоимость доставки. 2. Ввести значение "101" в поле Сообщение об ошибке "Неправильно веса доставляемого груза. указан вес доставляемого груза". 3. Ввести значение "0" в поле Сообщение об ошибке "Неправильно веса доставляемого груза. указан вес доставляемого груза". 4. Ввести значение "100" в поле На экран выводится "100 унций" веса доставляемого груза. как вес доставляемого груза Фрагмент тестового случая для программы, которую рассматривается в качестве примера и вычисляет стоимость доставки по почтовому индексу груз с заданным ве сом, приводится в таблице 4.2. Шаги методики тестирования пронумерованы в пер вом столбце. Краткие описания действий, выполняемых тестировщиком, даны во втором столбце, а исчерпывающие описания ожидаемых результатов находятся в третьем столбце. Предполагается, что в этом примере при проведении испытаний будет использоваться твердая (или интерактивная) копия этой таблицы, в связи с чем в ней предусмотрен четвертый столбец, в котором тестировщик может отмечать ка ждый выполненный шаг. В дальнейшем мы покажем, что следует предпринимать в случае, если какой-то тест не проходит. Особое внимание следует обратить на то, чтобы на каждом шаге методики тестирования предоставлялись четкие описания ожидаемых результатов. Установка и очистка — тестирование из известного состояния Один из основных принципов тестирования заключается в том, что всегда необхо димо знать, в каком состоянии находится тестируемая система. Если обнаружен де фект, но тестировщик не знает, какие действия привели к сбою, в таком случае воз никают трудности при воспроизведении этого сбоя. Необходимость проводить тес тирование из известного состояния означает, что каждый тестовый случай должен привести аппаратные и программные средства в известное состояние. Это отнюдь не означает, что тестировщик обязан обесточить систему, перезагрузить ее и запускать программу с самого начала — как и в любых других ситуациях при тестировании, все имеет свои пределы. Глава 4. Проектирование и разработка тестов 111 Во избежание перехода испытываемой системы в состояния, которые невозмож но воспроизвести, существует ряд практических мер. Одной из них является выпол нение энергетического цикла системы перед началом тестирования — это, по- видимому, следует делать в начале каждого рабочего дня. Другая мера предусматри вает периодическое обновление баз данных и удаление тестовых каталогов. Если применяется автоматизация тестирования, то очистку баз данных и каталогов дан ных можно проводить часто и не тратить на это много времени. Возможно, что тес тируемая система производит изменения во встроенных программных средствах. Если это так, то встроенные программы потребуется перезагрузить либо до запуска логически связанных тестов, либо в начале каждого рабочего дня, что обеспечит тес тирование неискаженной версии встроенных программных средств. В идеальном случае для сохранения текущего состояния тестируемой системы в специальном хра нилище, для регистрации различного рода отклонений и для перевода тестировщи- ком системы в нужное состояние используются автоматизированные инструменталь ные средства. Существуют два подхода к инициализации теста. Один из них предусматривает применение специальной программы настройки, которая перед началом тестирова ния приводит систему в известное состояние, и использование стандартных про грамм очистки, которые "аннулируют" изменения, внесенные в процессе тестирова ния. Другой подход предусматривает только настройку и никакой очистки. Если пе ред прогоном каждого теста выполняется соответствующая операция настройки, то не имеет значения, что произойдет в конце теста — все равно до прогона следующего теста известные условия будут восстанавливаться, при этом усилия, затраченные на очистку, могут оказаться напрасными. Разумеется, могут возникнуть проблемы в си туациях, когда добавляется новый тест, не рассчитанный на настройку, а выполнен ные ранее тесты перевели систему в непредусмотренное состояние. Рекомендуемый в таких случаях практический метод предусматривает выполне ние очисток после прогона теста, который внутренне переводит систему в непреду смотренное состояние. Например, если вы переполняете каталог данных, искажаете базу данных или переводите систему в состояние сбоя, то наилучшим решением будет восстановление системы в ее нормальном состоянии по окончании теста. Аналогич но, .если осуществляется прогон теста, о котором известно, что он зависит от началь ного состояния системы, то лучше всего будет воспользоваться установочной проце дурой для инициализации тестируемой системы. Шаблон тестового случая Все предложения, касающиеся проектирования тестового случая, обсуждавшиеся до сих пор, могут быть сведены в единый шаблон тестового случая. Возможно, возник нет желание создать собственный шаблон, тем не менее, стоит обратить внимание на один из вариантов такого шаблона, показанный на рис. 4.2. Тестовые случаи, осно ванные на этом шаблоне, можно распечатать для целей неавтоматизированного тес тирования, либо за счет организации отображения в браузере их HTML-версий поя вится возможность прогона тестов в интерактивном режиме. 112 Часть I. Процесс быстрого тестирования Информация Идентификатор тестового случая Владелец теста Местонахождение теста (путь) Дата последнего пересмотра Тестируемое требование Конфигурация средств тестирования Взаимозависимость тестовых случаев Цель теста о тестовом случае SC03 ver3.0 Джин Дуглас (Jean Douglas) TestServer:D:\TestProject\TestSuite\SC03.doc Месяц/день/год SC101 ST02 Выполнить прогон теста SC01 и его перед прогоном данного теста. настройку Проверить, что допустимые входные значения веса отправляемого груза дают правильные значения стоимости доставки, и что недопустимые входные значения приводят к выдаче сообщений об ошибке. Методика тестирования Настройка на прогон теста Не проводится Шаг Действие 1. Щелкнуть на элементе "Стоимость доставки" в главном меню. 2. Ввести "101" в поле веса доставляемого груза 3. Ввести "0" в поле веса доставляемого груза 4. Ввести "100" в поле веса доставляемого груза 5. Ввести "1" в поле веса доставляемого груза Ожидаемый результат Отображается меню "Стоимость доставки" Сообщение об ошибке "Неправильно указан вес доставляемого груза" Сообщение об ошибке "Неправильно указан вес доставляемого груза" Указан вес доставляемого груза "100 унций" Указан вес доставляемого груза "1 унция" Очистка после прогона теста Не производится Результаты теста Тестировщик: JD Дата прогона теста: N/A Отметка (V) (V) (V) X (V) (V) N/A месяц/день/год Результат теста (P/F/B): F Примечания: - Тест потерпел неудачу на шаге 3. - При возникновении неисправности выдается код ошибки BR1011. Рис. 4.2. Пример тестового случая Глава 4. Проектирование и разработка тестов 113 Основными элементами шаблона тестового случая являются: • Идентификатор тестового случая — включает номер версии теста. • Владелец теста — имя или инициалы лица, эксплуатирующего тест (оно может не совпадать с именем автора теста). • Дата последнего пересмотра — эта информация позволит определить, является ли тест актуальным. • Наименование теста — описательное имя теста, которое позволяет легко оты скать тест и понять его назначение. Применение имен, не несущих смысловой нагрузки, например, "xxxLLL0123.tst", не рекомендуется. • Местонахождение теста — это полное имя пути, включая сервер. • Тестируемое техническое требование — это должен быть уникальный иденти фикатор, который отображается на документы с техническими требованиями. • Цель тестирования — краткая и четкая формулировка того, чего должен дос тичь данный тест. Более подробная информация изложена выше, в разделе "Определение целей теста". • Конфигурация средств тестирования — спецификация ввода, спецификация вывода, условия испытаний. • Настройка на прогон теста— эта процедура подобна методике тестирования. Она предусматривает описание действий, выполняемых тестировщиком, и ожидаемых результатов. Если настройки автоматизированы, это может выгля деть как run setupSC03.pl. • Методика тестирования — описание действий, выполняемых тестировщиком, и ожидаемых результатов. • Взаимозависимость тестовых случаев — идентификация любого тестового слу чая, прогон которого должен предшествовать прогону данного теста, дабы вы полнение данного теста начиналось при заданных условиях. • Очистка теста — если системы была переведена в неустойчивое состояние или данные оказались разрушенными, очистка предоставит шанс устранить подоб ные ситуации. Управление конфигурацией тестового случая Во время прогона теста необходимо выполнить заданный набор операций на задан ной конфигурации системы. Это обстоятельство гарантирует, что тест можно вос произвести и что он осуществляет проверку заданных функциональных возможно стей. По мере того, как меняется программный продукт в результате исправления обнаруженных дефектов или по причине изменений, внесенных в технические тре бования, тесты также требуют изменений. Функциональные возможности программ ного продукта и тесты должны синхронно реагировать на такие изменения, в про тивном случае тесты приведут к неверным результатам. Управление направлением изменения программного продукта осуществляется благодаря использованию инструментальных средств CM (Configuration Manage ment— управление конфигурациями), таких как инструментальные средства CVS (Control Version System — система управления версиями) или ClearCase. С помощью 114 Часть I. Процесс быстрого тестирования упомянутых средств файлы, содержащие программные коды, проверяются при со хранении и при модификации. Эти средства обеспечивают управление версиями, при этом предыдущие версии файла архивируются и, в случае необходимости, легко могут быть найдены. Такой тип СМ-систем очень хорошо работает как в условиях неавтоматизирован ных, так и автоматизированных тестовых случаев. Он позволяет идентифицировать некоторый набор тестов так, что с некоторой группой тестов ассоциируется номер версии. Например, версия 3.0 набора тестов по вводу данных может использоваться для испытаний версии 3.0 тестируемого программного продукта. Пересмотр и отладка тестов После написания или автоматизации тест необходимо проверить на наличие дефек тов с целью их немедленного устранения, и затем испытать на некоторой сборке про граммного продукта. Статическое тестирование тестовых случаев можно проводить с применением той же технологии, которая используется для проверки выполнения технических требований, т.е. обследования, сквозного контроля или экспертных оценок (см. раздел "Методы статического тестирования" в главе 2). Эти методы могут применяться в различных сочетаниях, если сложность тестов такова, что необходи мо тщательное статическое тестирование. Например, экспертные оценки можно ис пользовать в методиках, а формальное обследование — в автоматизированных сцена риях, реализующих методики тестирования. При проверке тестовых случаев необходимо обратить внимание на ряд следую щих моментов: • В какой мере соответствует тест или тестовый набор функциональным воз можностям, заявленным в технических требованиях? • Покрывает ли тестовый набор все технические требования? • Организованы ли тесты достаточно эффективно, чтобы можно было обходить ся минимальными конфигурациями средств тестирования? • Включены ли тесты в систему управления конфигурациями? • Есть ли среди тестов избыточные? Можно ли устранить эту избыточность? • Достаточно ли подробно разработана методика тестирования, чтобы стала воз можной ее автоматизация? • Снабжен ли каждый шаг тестирования четко определенными ожидаемыми ре зультатами (критерий удачного/неудачного исхода испытаний)? • Правильно ли воспроизводят автоматизированные тесты неавтоматизирован ные шаги тестирования? Если вы провели статическое тестирование плана проведения испытаний, то пе ресмотр тестовых случаев пойдет намного проще, поскольку вопросы, касающиеся покрытий технических требований тестами, должны решаться во время пересмотра плана проведения испытаний. Вопросы, касающиеся избыточности тестов и эффек тивного использования конфигурации средств тестирования, также должны быть затронуты в процессе пересмотра плана проведения испытаний, во всяком случае, на уровне предварительных решений. Тщательные пересмотры планов проведения ис- Глава 4. Проектирование и разработка тестов 115 пытаний и тестовых случаев, равно как и статическое тестирование программного продукта, содействуют раннему обнаружению дефектов в тестах и позволяют сокра тить затраты времени на отладку тестовых случаев. В рамках такого пересмотра каждый новый тест нужно прогнать на некоторой сборке программного продукта, дабы удостовериться, что методика тестирования позволяет получить ожидаемые результаты. Поскольку этот тест, по-видимому, будет прогоняться на программном коде, в изобилии содержащем дефекты, необходимо соблюдать определенную осторожность при анализе неудачных исходов прогона тес та в плане, что является источником проблемы — программный код или сам тест. От ладка тестового случая часто требует от исполнителей такого же инженерного искус ства и аналитических способностей, которые так необходимы разработчикам про граммного обеспечения во время отладки кода программного продукта. Автоматизация тестовых случаев В главе 3 отмечалось, что при правильном планировании и разумных ожиданиях ис пользование автоматизированных инструментальных средств и автоматизированных тестовых случаев представляет собой хороший способ снижения затрат времени на тестирование программного продукта. В этой главе мы кратко обсудим некоторые руководящие принципы, регламентирующие автоматизацию тестовых случаев. Авто матизация тестов — это вид деятельности по разработке программного обеспечения, для выполнения которого нужно обладать таким же опытом и квалификацией, как и при создании любого другого программного продукта. Если вы планируете потратить средства и усилия на автоматизацию тестовых случаев, рекомендуем ознакомиться с материалами [15] и [17]. Ниже перечисляются некоторые руководящие принципы автоматизации тесто вых случаев. Разумеется, приводимые ниже принципы следует привязать к конкрет ным условиям. • Выполняйте автоматизацию только тех тестовых случаев, которые будут по вторяться достаточно большое количество раз, чтобы такая автоматизация бы ла рентабельной с точки зрения стоимости. Если вы намерены автоматизиро вать тесты, которые должны выполняться всего несколько раз, стоимость ав томатизации в смысле времени и финансов может превзойти ожидаемую выгоду. • Разрабатывайте сначала неавтоматизированную версию тестового случая и только после этого переходите к его автоматизации. Контрольные примеры должны быть отлажены с тем, чтобы убедиться, что неавтоматизированная ме тодика испытаний определена верно, а конфигурация тестового случая работа ет правильно. Попытки одновременной отладки методики тестирования и про граммного кода, который автоматизирует эту методику, могут оказаться неэф фективными, более того, в худшем случае они могут стать причиной появления ошибок в тестовом случае. Если неавтоматизированный тестовый пример под вергается отладке первым, он становится базисом, с которым можно сверять автоматизированный тестовый случай. • Предназначенная для автоматизации неавтоматизированная методика тести рования должна быть четко сформулирована и должна допускать однозначное толкование с тем, чтобы инженер по автоматизации мог сосредоточиться на 116 Часть I. П р о ц е с с быстрого тестирования разработке программного кода, а не задумываться над тем, как должен выпол няться тот или иной тестовый шаг. • Определите стандартную практику кодирования и придерживайтесь ее требо ваний. Автоматизация представляет собой программное обеспечение, которое должно разрабатываться столь же аккуратно, как и тестируемый программный продукт. Если планируется использование автоматизированных сценариев в качестве регрессивных тестов, то вполне возможно, что они будут нужны в течение продолжительного времени. В конечном итоге может случиться так, что исполнитель, эксплуатирующий тестовый сценарий, и его разработчик — разные лица. В подобных ситуациях четко написанный и правильно задокументированный программный код есть непременным условием его э ф ф е к т и в н о й эксплуатации. • Автоматизированные тесты должны проверяться на соответствие неавто матизированным тестам, от которых они произрастают. Пересмотры про граммных кодов сценариев приносят большую пользу при выявлении ошибок в автоматизации и при контроле соблюдения требований стандартов. Полная проверка автоматизированного сценария должна подтвердить, что он предос тавляет те же функциональные свойства, что и его неавтоматизированный прототип, и эта проверка должна проводиться в лабораторных условиях. П р и этом выполняется параллельный прогон неавтоматизированной и автоматизи рованной версий теста на всех запланированных конфигурациях тестовых средств и в запланированных условиях. • Автоматизированные тестовые сценарии должны находиться под управлением системы поддержки множества конфигураций в т о й же структуре каталогов, что и неавтоматизированные тесты. Система управления версиями или конфи гурациями должна следить за тем, чтобы в каждый конкретный момент време ни была активной только одна санкционированная версия сценария. Управле ние версиями обеспечивает воспроизводимость и повторяемость каждого тес та. П р и воспроизведении дефектов, при проверке исправлений дефектов, а также при выполнении регрессивного тестирования очень важным условием является наличие единственного известного теста, ориентированного на вы явление заданного дефекта. Что дальше В этой главе обсуждались проектирование и разработка тестов. Ключевыми пунктами в процессе проектирования и разработки тестов являются: • Определение целей теста (совершенствование подхода к тестированию и уточ нение объема тестирования). • Определение спецификаций ввода для каждого теста. • Определение тестовой конфигурации для каждого теста. • Проверка проектных решений тестов на предмет обеспечения необходимого уровня покрытия и технической точности. |