Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 2. Анализ требований и тестирование 55 Мы выявили три вида рабочих продуктов, которые создаются на стадии формули рования требований: • Документ определения требований, который представляет собой изложение требований заказчика к программному продукту, сформулированное на естест венном языке. • Спецификация требований, которая еще называется функциональной специ фикацией, представляющая собой технические требования, выраженные в но тации, которая может использоваться для разработки программных продуктов. • Документ, отслеживающий требования, который может применяться для ото бражения теста на требование, послужившее причиной появления этого теста. В результате обеспечивается возможность тестирования всех требований. Мы описали содержимое каждого из этих документов и выдвинули некоторые идеи относительно того, как их проверять. Более подробную информацию о приме нении статического тестирования на стадии формулирования требований, включая описание методики проведения JAR-сеансов, можно найти в главе 8. Наконец, мы обсудили роль прототипирования на стадии формулировки требований и рассмотре ли, как выполняется тестирование в рамках жизненного цикла эволюционного про тотипа. В следующей главе мы более подробно рассмотрим, что происходит после выяв ления всех требований к программному продукту. В центр внимания выдвигаются планирование тестирования и оценка трудозатрат. Планирование испытаний Темы, рассматриваемые в главе: • Стратегия тестирования • Определение стратегии тестирования • Оценка трудозатрат на тестирование Q Подготовка и пересмотр документов, содержащих планы проведения испытаний • Что дальше Как отмечалось с самого начала книги, основной принцип быстрого тестирования предусматривает максимально тесную связь с разработкой на протяжении всего жиз ненного цикла программного продукта. Во время выявления и анализа требований подобное интегрирование достигается за счет использования технологии статиче ского тестирования. Последняя предусматривает пересмотр требований с целью об наружения дефектов, а также участие специалистов по тестированию в процессе формулирования требований с целью более раннего получения спецификаций, что, в свою очередь, позволяет задействовать требования во время планирования испыта ний. Принцип интегрирования разработки и тестовых действий должен соблюдаться и в процессе планирования и определения трудозатрат. Тестирование программного обеспечения представляет собой дорогостоящую, ресурсоемкую работу, на выполне ние которой расходуется до половины сметной стоимости проекта. Высокая эффек тивность планирования испытаний и правильная оценка трудозатрат в значительной мере содействует успеху всего процесса тестирования, в то время как неудачи на этой стадии могут привести к превышению сметной стоимости проекта и нарушению гра фика работ. Диаграмма видов деятельности, связанных с планированием испытаний, показана на рис. 3.1. Входными для процесса планирования будут документы, которые содер жат требования, описанные в главе 2. Как упоминалось в главе 2, если документы с формулировками требований отсутствуют, придется самостоятельно составить, по меньшей мере, сокращенный вариант таких документов. Невозможно провести не обходимое тестирование программного продукта, не имея представлений о функ циональных возможностях продукта и связанных с ними ожиданий заказчика. Глава 3. Планирование испытаний 57 Рис. 3.1. Виды деятельности, осуществляемые при составлении плана испытаний Выходным результатом действий исполнителей, осуществляющих планирование тестирования, является документ или набор документов, который должен быть про верен тестовой группой, группой разработчиков и персоналом, осуществляющим управление разработкой и сопровождением программ. В плане проведения испыта ний указаны ресурсы, необходимые для тестирования программного продукта, опре делено, что подлежит тестированию, как должно проводиться тестирование и какие выходы или выходные результаты будут получены по итогам тестирования. Содер жимое и формат плана испытаний обсуждаются далее в этой главе. Процесс планирования испытаний образуется из следующих основных видов дея тельности: • Определение стратегии тестирования • Определение состава и структуры испытательной системы (аппаратных и про граммных средств) • Оценка трудозатрат (ресурсы и график работ) • Оценка рисков невыполнения графика работ и подготовка плана мероприятий по смягчению последствий от овеществления этих рисков. • Подготовка и пересмотр (утверждение) документов с планом проведения ис пытаний. Каждый из указанных выше видов деятельности подробно обсуждается в данной главе. Технология оценки трудозатрат исследуется в главе 12. Пример плана прове 58 Часть I. Процесс быстрого тестирования дения испытаний приложения ТМТ приводится в третьей части книги. Несмотря на то что на рис. 3.1 показана линейная последовательность основных видов деятельно сти, зачастую они выполняются одновременно или по итерационной схеме. И хотя порядок выполнения видов деятельности может меняться, важно, чтобы все они бы ли частью процесса планирования испытаний. Планирование тестирования можно сравнить с луковицей, т.е. это многоуровне вый процесс. Планирование начинается с определения стратегии тестирования на концептуальном уровне, после чего добавляются уровни дальнейшей детализации, которые описывают архитектуру тестирования, условия испытаний, а также тесто вые случаи до тех пор, пока не будет составлен план проведения испытаний в его окончательном виде. После того, как план проведения испытаний будет оформлен в виде документа и утвержден, процесс планирования не прекращается, поскольку воз можны изменения требований, изменения в графике работ и другие виды изменений, которые влекут за собой коррекцию плана проведения испытаний. План проведения испытаний должен поддерживаться на всем протяжении процесса разработки про граммного продукта как динамически развивающийся документ. Он должен хранить ся в безопасном хранилище и поддаваться управлению версиями. Стратегия тестирования Первое действие в планировании испытаний предусматривает разработку стратегии тестирования на высоком уровне. В общем случае стратегия тестирования должна определять объемы тестовых работ, типы методик тестирования, которые должны применяться для обнаружения дефектов, процедуры, уведомляющие об обнаружении и устраняющие дефекты, критерии входа и выхода из испытаний, которые управля ют различными видами тестирования. Реализуя принцип тесного интегрирования разработки и тестирования с целью оптимизации графика разработки, стратегия тестирования должна отображать различные виды тестовой деятельности на жиз ненный цикл разработки. При формулировании общей стратегии должно быть пре дусмотрено как статическое, так и динамическое тестирование. Если для поддержки различных видов тестовой деятельности используется авто матизация, стратегия автоматизации должна рассматриваться как составная часть общей стратегии тестирования. Автоматизация требует выполнения независимых параллельных работ, которые должны тщательно планироваться и выполняться только в тех случаях, когда это не приводит к снижению эффективности. Мы предлагаем следующий подход к формулированию стратегии тестирования: 1. Определить объемы тестовых работ путем анализа документов, содержащих требования к программному продукту (технические условия), дабы выяснить, что нужно тестировать. Рассмотреть виды тестирования, которые не следуют непосредственно из документов с требованиями, такие как тестирование воз можности установки и наращивания возможностей программного продукта, удобство и простота обслуживания продукта, а также способности к взаимо действию с другими видами аппаратных средств из среды заказчика. 2. Определить подход к тестированию за счет выбора статических и динамиче ских тестов, связанных с каждой стадией разработки. Здесь потребуется Глава 3. Планирование испытаний 59 включить описания всех рабочих продуктов, которые должна подготовить тестовая группа. 3. Определить критерии входа и выхода для каждой стадии тестирования, равно как и все точки контроля качества, для чего потребуется участие специали стов по тестированию. 4. Определить стратегию автоматизации в случае, если планируется использо вание автоматизации какого-либо вида тестовой деятельности. Автоматизация требует проведения независимых параллельных работ, которые должны тща тельно планироваться и выполняться только в тех случаях, когда это не при водит к снижению эффективности. Определение объемов тестовых работ При определении объемов тестовых работ важно рассмотреть вопрос, какая часть программного продукта должна подвергаться тестированию. В области тестирования программного обеспечения давно установлен тот факт, что программу, реализующую большую часть функциональных возможностей, невозможно протестировать полно стью. Этот факт исследуется во врезке 3.1 "Можно ли выполнить исчерпывающее тестирование программы?" Ответом, который мы получаем на основе этой врезки, будет "Нет!". Конечно, можно выполнить достаточно исчерпывающее тестирование старой доброй программы, выдающей фразу "hello, world" (привет, мир!), которая содержит всегo лишь несколько строк, не имеет условных переходов, GUI- интерфейса (Graphical User Interface — графический интерфейс пользователя). Тем не менее, для программ, реализующих реальные задачи, всегда характерна опреде ленная специфика входных данных, какие-то комбинации входных последовательно стей или ветвление кода, до проверки которых просто не доходят руки. М О Ж Н О ЛИ ВЫПОЛНИТЬ ИСЧЕРПЫВАЮЩЕЕ ТЕСТИРОВАНИЕ П Р О Г Р А М М Ы ! п е р в о е , что потребуется предпринять, прежде чем приступить к проектированию тес- тов, — это определить общий объем работ по тестированию. Нужно ли попытаться вы- Выполнить исчерпывающее тестирование программного обеспечения, или же существуют фундаментальные ограничения относительно того, что м о ж н о ожидать от тестовых ра- бот? В данной врезке мы проведем анализ примера компонента программного обеспе ч е н и я , исходя из поставленного выше вопроса. Рассмотрим программный компонент, который вычисляет стоимость перевозки некото р о г о продукта с известным весом по заданному почтовому индексу получателя. В про г р а м м е имеется GUI-интерфейс, через который м о ж н о вводить почтовый индекс (наряду с другими данными, имеющими отношение к обрабатываемой транзакции). В этом слу- чае расходы на перевозку представляются промежуточными результатами вычислений, которые пользователю не отображаются. Для того чтобы увидеть результаты вычисле н и й , потребуется отправить запрос в базу данных. К а з о в а я идея представлена на блок-схеме, изображенной на рис. 3.2. На этой диаграм ме показано лишь отношение, связывающее ввод и вывод, поэтому не придется вникать h подробности, относящиеся к GUI-интерфейсу и базе данных. Для простоты положим, что в качестве стандартного почтового индекса может исполь- |зоваться любое пятизначное положительное целое число. Другими словами, входные величины принимают значения из диапазона от 00000 до 99999. 60 Часть I. Процесс быстрого тестирования Для каждого входного значения программа вычисляет стоимость перевозки, которая ко леблется в пределах от $5 до $20. Отображение входа на выход описывается отношени ем "многие-к-одному", а это означает, что несколько почтовых индексов могут поро дить одну и ту же стоимость перевозки. Теперь, когда получено представление о том, как работает эта часть программного обеспечения, можно вернуться к вопросу о возможности исчерпывающего тестирования рассматриваемой программы. В данном случае мы конкретно хотим знать, можно ли проверить эту программу на всех возможных значениях входных данных. Существуют два класса ввода: допустимый и недопустимый. Пятизначные положитель ные целые числа суть допустимый ввод, в то же время отрицательные целые числа, чис ла с десятичной точкой, буквы алфавита, управляющие коды и пробелы не рассматри ваются как допустимый ввод. Простой подсчет количества допустимых почтовых индексов говорит о том, что числом допустимых вводов будет 100000 (пятизначные числа, не разрешенные почтовой служ бой, игнорируются). Предположим, что автоматизация в данном случае не применяется, т.е. тестирование программы выполняется в неавтоматизированном режиме. Процедура тестирования требует от тестировщика вручную вводить допустимые входные значения, отправлять запросы в базу данных для получения стоимости перевозки, сравнивать вы численные значения стоимости перевозок и фиксировать полученные результаты. М о ж но запросто потратить 3 минуты на один ввод, так что на проверку всех допустимых входных значений будет затрачено 5000 часов, что составляет более 2 лет напряженной работы. Кроме того, подобную проверку, возможно, придется выполнить несколько раз, поскольку каждая новая версия должна тестироваться совершенно аналогично. По сути дела, все возможные входные значения проверить просто невозможно. Картина меняется, если реализовать автоматизацию рассматриваемого вида тестирования, но даже и в этом случае вряд ли захочется тратить время на автоматизацию и тестирование каждого возможного ввода. В главах 4 и 11 будет показано, как сузить диапазон тесто вых входных данных и получить компактный, управляемый набор эквивалентных значений с помощью методики разбиения на классы эквивалентности. Если дополнительно принять во внимание и все недопустимые значения, диапазон еще больше расширится. М о ж н о также запланировать проверку ввода на предмет недопус тимости для отрицательных целых чисел, чисел с десятичной точкой, нечисловых значе ний. Это еще больше увеличит количество возможных вводов, поэтому вероятность вы полнения 'абсолютно всех таких попыток станет ничтожно низкой. На основе проведен ных рассуждений мы приходим к фундаментальному ограничению тестирования: Ограничение тестирования: Исчерпывающее тестирование компьютерной программы невозможно. Занимаясь аналогичными исследованиями, Прессман в [43] привел в качестве примера программу на языке С, состоящую из 100 строк с двумя вложенными циклами, причем каждый цикл выполняется от 1 до 20 раз. Во внутреннем цикле находятся четыре конст рукций- if-end-else. В своей работе Прессман доказал, что на автоматизированное тести рование этой программы при условии, что на проверку каждого из 10 1 4 возможных пу тей будет тратиться одна миллисекунда, потребуется 3170 лет. Приведенный пример с почтовыми кодами показал, что исчерпывающее тестирование вводов невозможно, а пример Прессмана дает право утверждать, что даже в условиях автоматизированного ввода исчерпывающее логическое тестирование оказывается нере альным. Становится ясно, что одним из непременных условий быстрого тестирования яв ляется разумный отбор тестов для выполнения. Врезка 3.1 Глава 3. Планирование испытаний 61 Входные данные Почтовый индекс Вычисление стоимости перевозки Выходные данные Стоимость перевозки Рис. 3.2. Функциональные возможности тестируемой программы Поскольку подвергнуть тестированию абсолютно все невозможно, важность вы бора того, что нужно протестировать, сомнений не вызывает. Если допустить "пере бор" в тестировании, т.е., если тестовое покрытие будет избыточным, то для отладки программного продукта потребуется значительное время, что поставит под угрозу срок сдачи проекта. Если тестирование окажется недостаточным (точнее, недоста точным будет тестовое покрытие), то увеличится риск пропуска того или иного де фекта, устранение которого будет стоить очень дорого, особенно после сдачи про граммного продукта в эксплуатацию. Отыскать нужный баланс между этими двумя крайностями поможет опыт и способ измерения успешности тестирования. Вот несколько предложений по разработке стратегии тестирования, которые по могут в поиске оптимального тестового покрытия. Тестируйте в первую очередь требования с наивысшим приоритетом. Предпо ложим, что в вашем распоряжении имеется документ определения требований, в котором требованиям присвоены приоритеты. Выберите те из них, которые представляют для заказчика наибольшую важность, либо которые причинят за казчику наибольшие неприятности в случае выхода программного продукта из строя. Если запланировано тестирование всех требований, и ресурсы это позво ляют, естественно, придется тщательно проверить выполнение всех требований. В случае нехватки ресурсов, перед отправкой продукта заказчику необходимо тщательно протестировать требования с наивысшими приоритетами. Возможно, стоит получить согласие заказчика на то, что требования, которые проверены частично или не проверены вообще, не будут поддерживаться вплоть до следую щей версии продукта. Тестируйте новые функциональные возможности и программный код, кото рый изменялся с целью исправления или совершенствования старых функ циональных средств. Эвристическое правило гласит: если программный код подвергался исправлениям, его необходимо протестировать. В начальной версии программного продукта новым является все. Однако если версия является оче редным обновлением или эксплуатационной версией, особое внимание следует уделить новому коду. Имейте в виду, что любые изменения, внесенные в про граммный код, могут исказить даже те части программы, которые непосредствен но "не затрагиваются" изменениями. В этом случае лучше всего как можно чаще выполнять регрессионные тесты для всей функциональности программы, какими бы ни были изменения в коде. Используйте разбиение на эквивалентные классы и анализ граничных значе ний для снижения трудозатрат на тестирование. Эти технологии описаны в гла вах 4 и 10; обе технологии могут использоваться для выявления максимального 62 Часть I. Процесс быстрого тестирования тестового покрытия за счет определения поднабора входных значений во время тестирования компонентов ввода/вывода. Тестируйте те участки, в которых наиболее вероятно присутствие проблем. Известная пословица гласит: "ошибки имеют свойство накапливаться". Если об наружен какой-то дефект, очень часто рядом притаились еще несколько дефектов, ждущих своей очереди быть обнаруженными. Если во время анализа требований некоторые участки вызывают особое беспокойство, или есть сведения от разра ботчиков, что часть компонентов породили массу проблем во время модульного тестирования и проверки взаимодействия и функционирования компонентов, упомянутые участи кода необходимо пометить, дабы обратить на них пристальное внимание при системных испытаниях. Сосредоточьте свое внимание на функциях и конфигурациях, с которыми наиболее часто будет иметь дело конечный пользователь. Если в спецификации требований применяется методика случаев использования или же если у вас име ется доступ к функциональному разрезу конечного пользователя (т.е. математиче скому ожиданию использования каждой функции), вы получаете дополнительный источник информации для установки приоритетов тестирования. Большая часть времени, отведенного на тестирование, должна затрачиваться на проверку наибо лее часто используемых конфигураций и операций. Проблемы тестирования множественных конфигураций будут подробно обсуждаться в разделе "Тестовые конфигурации" далее в этой главе. „ Один из дополнительных подходов придать системному тестированию большую эффективность состоит в том, чтобы убедить разработчиков тщательно выполнять модульное тестирование и проверку взаимодействия и функционирования компо нентов, прежде чем передавать программный код тестовой группе. Слишком часто передача тестовой группе той или иной программной конструкции завершается кон статацией о невозможности ее установки, или тем, что после установки конструкция не работает. Значительную часть времени на тестирование можно сэкономить, если ввести в действие некоторые критерии приемки, не допускающие передачу тестовой группе неработающих программных кодов. Объем тестирования должен определяться документами, регламентирующими план проведения испытаний. Пример формата плана проведения испытаний приво дится далее в главе. Пример плана проведения испытаний можно найти в третьей части. Определение подхода к тестированию Второй раздел формулировки стратегии тестирования касается определения похода к тестированию. Построение подхода к тестированию начинается с исследования каждой стадии жизненного цикла разработки с целью отбора тестов статического и динамического тестирования, которые могут быть использованы на соответствую щей стадии. При этом не имеет значения, какая модель жизненного цикла разработ ки используется: каскадная, спиралевидная или модель с итеративными версиями — для отбора эффективных тестов можно исследовать этапы любой перечисленной модели. В качестве примера возьмем каскадную модель и выясним, какие виды тести рования могут для нее использоваться. |