Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 10. Технологии динамического тестирования и советы 223 PATH PATH PATH PATH PATH PATH PATH PATH PATH PATH PATH PATH PATH PATH 8 9 10 11 12 13 14 15 16 17 18 19 20 21 45 45 52 52 56 56 66 66 71 71 72 72 73 73 JUMP52 THRU50 JUMP7 6 EOP THRU56 JUMP64 THRU66 JUMP64 THRU71 JUMP69 THRU72 JUMP79 THRU73 A THRU73 EOP A THRU7 8 EOP EXIT THRU78 EOP THRU66 EOP THRU66 EOP THRU71 EOP THRU8 6 EOP В THRU78 JUMP34 JUMP34 EOP EOP EOP EXIT JUMP34 THRU37 THRU37 THRU37 EOP STS CYCLOMATIC COMPLEXITY INTERVAL ( 11 , MODULE NAME - MAIN ADVANCED SOFTWARE TECHNOLOGY DATE: 12/08/80 -- FORTRAN SOFTWARE TESTING SYSTEM TIME: 12:40:59 . •- (STS) PAGE: 88* SUBROUTINE BANNER(ASCII) 89* IMPLICIT INTEGER*2 (A-Z) 90* LOGICAL ASCII 91* DIMENSION DATI(8),NDX(1),VAL(2,2) 92* DATA NOPTS,VAL/l,2H Y,2H N,2HES,2HO / 93* DO INDEX I=l,NOPTS 94* NDX(I)=2 95* END DO 96* IF (ASCII) NDX(1)=1 97* CALL DT(DATI) 98* WRITE(7,1000)DATI 99* WRITE(7,2000) ((VAL(NDX(I),J),J=l,2),1=1,NOPTS) 100* RETURN 101* 1000 FORMAT(' SPLIT UTILITY',/, 102* & • DATE: ' , 4A2 , ' , TIME : ' 4A2 , 103* & //,' OPTIONS SELECTED') 104* 2000 FORMAT(' CONVERT EBCDIC->ASCII=',2A2,/) 105* END (STS) — STATIC ANALYSIS FOR MODULE "BANNER ", BEGINNING AT LINE 93 PATH 22 PATH 23 PATH 24 PATH 25 PATH 2 6 93 95 95 96 96 THRU95 JUMP93 THRU96 A THRU96 A THRU100 EOP THRU95 EOP В THRU100 EXIT EOP EXIT STS CYCLOMATIC COMPLEXITY INTERVAL = ( 3 , 3 ) THIS IS A NORMAL COMPLETION OF STS -- STATIC ANALYZER RELEASE 3.1 Puc. 10.2. Автоматизированный вывод листинга ветвей и значений показателей циклома- тической сложности, выполняемый системой STS. 224 Часть II. Технологии быстрого тестирования и советы Для того чтобы можно было прочесть листинг ветвей, потребуется ввести сле дующие определения: • <номер строки> — номер, помещаемый программой в каждую строку кода • J U M P <номер строки> означает какую-либо форму конструкции GO T O , ENDDO или IF • T H R U <номер строки> включает все строки вплоть до строки <номер строки> • <номер строки> А означает часть T H E N конструкции IF • <номер строки> В означает часть ELSE конструкции IF • ЕОР указывает конец ветви Кроме того, при чтении этого листинга необходимо обратить внимание на пару вычисленных и отображенных значений показателя цикломатической сложности. Число слева определено Томасом Дж. Маккейбом (Thomas J. McCabe) в [31]. Значе ние справа — это показатель цикломатической сложности, определенный Гленфор- дом Дж. Майерсом (Glenford J. Myers) [37] в ответ на первоначальную публикацию Маккейба. Вспомните, что показатель цикломатической сложности — это минималь ное количество отдельных запусков модуля, которое потребуется для хотя бы одно кратного выполнения каждой строки кода. Данная информация может оказаться по лезной при прогнозировании затрат на тестирование. Можно попытаться найти все ветви в одном из таких модулей и прочувствовать ценность описываемого программ ного средства с точки зрения обеспечиваемой им экономии времени. Большинство теоретиков программирования сходятся во мнении, что свыше по ловины ошибок в новом коде являются результатом ошибок в логике построения ко да. Тестирование ветвей выявляет логическую структуру кода и позволяет тестиров- щику сосредоточить внимание на ее правильности. Однако арсенал специалиста по тестированию не должен ограничиваться только одним этим средством, поскольку строки кода в части THEN конструкции IF всё же могут содержать ошибки, которые приводят к получению неправильных результатов или аварийному прерыванию про граммы. Кроме того, следует учитывать, что многие ветви в программе являются тупико выми. Это понимают очень немногие тестировщики. Как правило, разработчики, создающие отладочный код, управляют его выполнением при помощи переменной, значение которой по умолчанию устанавливается таким, что отключает отладку. С момента поставки кода и в течение всего времени его использования клиентом это значение по умолчанию остается в состоянии отключенной отладки. В следующем разделе приведена схема снижения трудоемкости выполнения полного тестирования DD-ветвей, основанная на использовании приоритетов. Тестирование случаев использования В наше время в объектно-ориентированном программировании часто используется технология проектирования, называемая проектированием случаев использования (см. рис. 10.3). В случаях использования отражается взаимодействие отдельных эле ментов друг с другом на основе конкретного сценария. Популярные сценарии случаев использования находят свое отражение в большинстве проектов. Строгое отображе ние сценариев на случаи использования позволяет сделать вывод о существовании Г л а в а 10. Т е х н о л о г и и д и н а м и ч е с к о г о т е с т и р о в а н и я и с о в е т ы 225 набора популярных случаев использования в рамках различных проектов. В [35] бы ла отмечена такая взаимосвязь и предпринята попытка связать данные частоты использования с диаграммами случаев использования. Данные частоты исполь зования могут быть выражены в процентах от общего количества случаев использования. Имея такую информацию о проекте продукта, специалисты по быстрому тестированию могут выделять более 50% времени, в течение которого создаются тестовые случаи, на менее чем 50% кода, характеризующегося самым частым применением, т.е. на популярные случаи использования. Покупатель ПК Поставщик услуг Internet Пользователь ПК Рис. 10.3. Пример диаграммы случаев использования - регистрация у поставщика услуг Internet во время приобретения ПК. Другой аналогичный подход заключается в зондировании DD-ветвей, как описы валось в предыдущем разделе. После того как зонды вставлены в код, необходимо выполнить большой объем тестовых случаев и отсортировать полученные журналь ные ф а й л ы выполнения ветвей по номерам зондов. Количество тестов должно опре деляться исходя из требований, информационных потоков и возможного опыта ис пользования в технологическом цикле существующих систем. DD-ветви, номера зон дов которых встречаются наиболее часто, образуют эмпирический прогноз частот основного использования. Описанный процесс относится к технологии быстрого тестирования, поскольку его назначение состоит в экономии времени и повышении эффективности обнаружения ошибок. Ч т о может быть хуже, чем когда несколько специалистов по тестированию тратят массу времени на разработку тестовых случаев для нескольких ветвей нового фрагмента кода, лишь только для того, чтобы выяс- 226 Часть II. Технологии быстрого тестирования и советы нить, что код является невыполняемым и поэтому не может быть протестирован. Или, скажем, в принципе новый код является выполняемым, но выполняется только при удовлетворении какого-то маловразумительного условия. Какое бессмысленное рас ходование времени и ресурсов с нулевой эффективностью, поскольку ни одна ошибка не обнаруживается! Проектирование случаев использования и прогнозирование частоты использова ния каждого из них позволяет определить приоритеты тестовых случаев. Чтобы можно было оптимизировать ресурсы и эффективность тестирования, эти приори теты должны быть положены в основу разработки тестовых случаев и порядка их прогона. Прежде чем применить к тестированию подход, основанный на случаях использо вания, тестировщики и разработчики должны обеспечить гарантированное соответ ствие случаев использования списку требований и коду. Несоответствие документа ции по требованиям и кода — это недостаток, который часто отмечается во время аудита многих проектов по созданию программного обеспечения. В некоторых орга низациях документации по программе уделяется не такое пристальное внимание, как документации для пользователя. Иногда случаи использования, разработанные на основе исходных требований, передаются группе тестирования без проверки на со ответствие текущим требованиям. Однако за это время исходные требования могли претерпеть изменения. В таких ситуациях тестировщики, используя информацию о случаях использования, могут получить ложное обнаружение ошибок. В ходе даль нейших исследований выяснится, что код удовлетворяет списку требований, но не случаям использования. Вероятность наличия ошибок в тестовом случае и результа тах будет высокой, а усилия, потраченные на разработку тестового случая, окажутся напрасными. Псевдоотладка/видоизменение Псевдоотладка (bebugging), являющаяся одной из форм видоизменения программы, — это способ определения эффективности стратегий тестирования, применяемых в проекте. Прежде чем приступать к псевдоотладке, необходимо заручиться поддерж кой и тестировщиков, и разработчиков. Как бы вы ответили на вопрос, часто зада ваемый руководителем разработки: "Когда можно ожидать выявления большинства ошибок в этой версии?". Обычно руководитель тестирования задает встречный во прос: "А сколько мелких ошибок нам нужно найти?" Основным показателем прогрес са тестирования должно быть процентное отношение числа найденных ошибок к числу скрытых ошибок, которые нужно найти. Проблема, связанная с вычислением упомянутого показателя, состоит в том, что и числитель, и знаменатель этого отно шения неизвестны. Псевдоотладка заключается в преднамеренном внесении ошибок в программу. Да лее полученная версия тестируется, и после этого определяется эффективность тес тирования путем сравнения обнаруженных и искусственно созданных ошибок. От ношение числа обнаруженных искусственно созданных ошибок к числу созданных ошибок должно быть равно отношению числа найденных ошибок к числу скрытых ошибок в продукте. Этот метод позволяет оценить показатель прогресса тестирова ния, определенный чуть выше. Глава 10. Технологии динамического тестирования и советы 227 Организации, в которых применяется быстрое тестирование, находят, что псев доотладка может ускорить проведение тестирования благодаря определению условий его прекращения. Фактически, процесс преднамеренного внесения ошибок требует творческого подхода. Если искусственно созданные ошибки распределяются по ти пам в соответствии с исторически сложившейся моделью ошибок аналогичных раз работок, с использованием того же языка программирования, и если обнаруженные ошибки таким же образом распределены по типам, то анализ прогресса тестирования можно выполнить по типам. В этом случае можно не только со всей определенностью ответить на вопрос: "Когда можно ожидать выявления большинства ошибок в этой версии?", но и сказать: "Мы нашли большинство логических ошибок в программе, а теперь заняты разработкой дополнительных тестовых случаев для проверки надеж ности модулей обработки ошибок". Аналогично, все искусственно созданные ошибки могут быть распределены по уровням серьезности. И тогда, если обнаруженные ошибки также распределить по уровням серьезности, можно не только ответить на заданный вопрос, но и сказать: "Мы нашли большинство ошибок с уровнями серьез ности 1 и 3, а сейчас разрабатываем дополнительные тестовые случаи для обнаруже ния ошибок с уровнями серьезности 2 и 4". Аналогичные подходы к видоизменению программы могут использоваться в от ношении ошибок, которые не связаны с исходным кодом, в том числе неправильных данных в базе данных, некачественных коммуникационных линий, поврежденных данных, неправильных данных, вводимых пользователем, ненадежных интерфейсов между процессами и т.п. Видоизменение программы представляет собой эффектив ное средство, которое может использоваться разрабатывающей организацией, кото рая повторно использует код из другого проекта. Частью процесса повторного ис пользования исходного кода является его сопровождение. Псевдоотладка может применяться для проверки хода этого сопровождения, определяя конечные цели тес тирования, которые будут использоваться при разработке новых тестовых случаев. Трассировка/трассировка снизу вверх/ мгновенные дампы/постпечать Специалисты по тестированию могут воспользоваться рядом инструментальных средств, которые существуют и применяются в современных разработках. Четырьмя из этих средств являются трассировка, трассировка снизу вверх, мгновенные дампы и постпечать. Опытные программисты, помнящие времена больших компьютеров, мо гут решить, что этот раздел посвящен выводу на печать или чтению системной диаг ностической информации, в том числе шестнадцатеричных системных дампов и со общений редактора связей, для определения природы, места и исходного уровня причины системной ошибки. На самом деле это не так. Несмотря на сходные терми ны, мы определяем технологии, исходя из современных спецификаций и средств. Например, в программу, основанную на применении транзакций, проектировщики часто включают функцию трассировки транзакций, которая может избирательно включаться любым пользователем, выбирающим эту опцию в своей конфигурации. Эта опция создает файл трассировки с отображением входных и выходных данных транзакции и форматированные мгновенные дампы данных запроса. Естественно, испытатель должен тестировать систему без включения этой опции, поскольку для 228 Часть II. Технологии быстрого тестирования и советы пользователя по умолчанию выбирается именно этот режим. Но если кажется, что в приложении выполнения транзакций что-либо не в порядке, тестировщик должен проверить наличие опции трассировки транзакций, включить ее и сохранить жур нальный файл, чтобы ошибку можно было повторить. Результаты трассировки долж ны быть приобщены к отчету об ошибке, что упростит воспроизведение условий ее возникновения. П р и обнаружении ошибки недостаточно черкнуть в блокноте: "Не удалось загру зить файл", или включить подобную заметку в сообщение электронной почты, на правленное автору кода. Большинство теоретиков тестирования призывают разде лять задачи тестирования и разработки, чтобы тестировщик был независимым и отве чал только за обнаружение ошибок. Основной принцип быстрого тестирования за ключается в объединении этих ролей в той мере, пока это способствует ускорению процессов обнаружения и устранения ошибок. Тестировщики могут поместить эк ранные снимки, например, в документ Microsoft Word, и снабдить их рабочими по метками или указателями на сценарии тестирования (см. рис. 10.4). Отчет об ошибке Время/дата: 9:40 пополудни 6 / 1 3 / 2 0 0 1 Дата отчета: 9:50 пополудни 6 / 1 3 / 2 0 0 1 по электронной почте в support groove.com Суть отказа: В окне Groove Maintenance Update (Обновление программы Groove) я выбрал ссылку "Update Groove" ("Обновить Groove") и получил сообщение об ошибке, в ко тором говорилось, что не удалось найти URL-адрес. Это сообщение повторялось трижды, после чего, при четвертой попытке, я сделал следующую копию экрана. В примере, приведенном на рис. 10.4, представлена неповторяющаяся ошибка. Через несколько дней после отправки отчета по этой ошибке тестировщик повторил этот тест. URL-адрес был найден, и загрузка выполнилась успешно. П р и этом исполь зовалось то же клиентское программное обеспечение. Свидетельствует ли это о том, что никакой ошибки не было? Нет, в момент получения экранного снимка ошибка имела место. Отсутствие ошибки в клиентской программе означает лишь то, что ошибка была исправлена на сервере, после чего все стало работать правильно. В сис темах с архитектурой к л и е н т / с е р в е р ошибки распределяются по двум программным базам, и обслуживание таких систем отличается от обслуживания автономных про грамм. Эти различия будут темой одного из последующих разделов. Создание точек прерывания/правки Точка прерывания (breakpoint) определяется как способ останова программного счетчи ка в какой-либо точке исходного кода. Отладчики, в случае их применения к про граммам на языке ассемблера, позволяют устанавливать точки прерываний для полу чения информации о состоянии памяти и регистров. Это дает возможность изменить данные в памяти или собрать информацию о распределении памяти, которая помо жет отыскать способ исправления ошибки. Глава 10. Технологии динамического тестирования и советы 229 Создание правок (patching) — еще одна технология программирования на языке ассемблера, при которой определенная инструкция перехода переписывается, или правится, для перехода в область "заплаты" внутри адресного пространства програм мы. В этой области выполняется какой-то вспомогательный код, после чего осущест вляется переход на инструкцию, следующую за исправленной. Обычно такой способ исправления ошибок применяется в больших программах, реализованных на языке ассемблера, например, Lotus 1-2-3. Как механизм точек прерываний и правок можно применить в современном тес тировании программ? Привлекательность этих технологий состоит в высокой скоро- 230 Часть II. Технологии быстрого тестирования и советы сти диагностирования и исправления ошибок, особенно тех, которые задерживают реализацию тестирования. Иногда тестировщик обнаруживает ошибку, которая пре пятствует выполнению дальнейшего тестирования в области данной ошибки. Такие ошибки, как определено в главе 5, называются блокирующими. Если подобную ошиб ку не исправить в кратчайшие сроки, это приведет к остановке всего процесса тести рования. Более чем для 95% ошибок, о которых сообщается команде разработки для их исправления, вполне приемлемо дождаться, пока группа контроля за внесением изменений определит приоритет и запланирует ресурсы для устранения каждой ошибки. Однако менее 5% блокирующих ошибок требуют немедленных действий, целью которых будет определение быстрого способа обхода заблокированных вет вей. Разработчик может предоставить временный способ исправления дефектного объекта с последующим частичным изменением связей, чтобы вернуть эту промежу точную/измененную версию персоналу тестирования. Это временное исправление будет повторно реализовано и протестировано в будущей полной версии, но пока группа тестирования может сохранить высокую эффективность обнаружения других ошибок в остальной части программы, начиная с точки блокирующей ошибки. Тестирование потока данных Один из способов создания тестовых случаев для ошибок, связанных с потоками дан ных, которые проходят через невзаимодействующую с пользователем часть програм мы — это создание базовой копии файлов данных первоначального запуска програм мы. Затем выполняется сравнение результатов всех последующих запусков програм мы, при условии, что программа прогоняется с той же самой копией файлов данных. Наконец, в исходный код программы вставляются зонды, которые вносят в журнал уникальный номер зонда после выполнения каждого оператора ввода/вывода про граммы. Сравнивая номера зондов, записанные в журнал при каждом запуске про граммы, можно определить, остается ли поток данных через зонды неизменным для каждого теста, который выполняется при использовании одной и той же базовой ко пии файлов данных первоначального запуска. Затем этот тестовый случай может применяться для проверки неизменности потока данных и в новой версии. Более распространенным способом тестирования потоков данных является под ход, который используется для тестирования приложений, ориентированных на транзакции, например, систем ввода заказов, систем обработки заказов, технологи ческих систем, систем выписки счетов, поставки и возврата продукции. Данные, по лученные в результате каждой тестовой транзакции, могут отслеживаться в каждом из этих процессов и подтверждаться промежуточными результатами тестирования, выполняемого между процессами. В случае тестирования изменений существующих систем планирование и выпол нение тестирования потоков данных не связано с особыми сложностями, поскольку снимки системы можно сделать до и после того, как каждый процесс впервые исполь зуется существующей системой. Впоследствии, после внесения изменений в новую версию и ввода в нее тех же самых данных, новые результаты можно сравнить (ино гда автоматически) с предыдущими результатами тестирования существующей сис темы. |