Глава 9. Технологии статического тестирования и советы 201
Средства автоматизации тестирования
Существует множество средств автоматизированного статического тестирования.
Большинство из них являются специализированными средствами, а не одним уни
версальным инструментом, которое могло бы применяться во всех случаях. Еще одна отличительная особенность этих средств статического тестирования — их зависи
мость от языка. Обнаружение ошибок в исходном языке или в языке документации предполагает выделение ошибок, в том числе орфографических, синтаксических, ошибок, связанных с неопределенными переменными и указателями, незакрытыми программными конструкциями, неопределенными ссылками, включая Internet- адреса, и т.д.
Прослеживаемость требований
Прослеживаемость требований означает сохранение формулировки требования от момента его указания до момента выполнения. Из главы 8 уже должно быть известно, что результатом совместной разработки требований к приложению (Joint Application
Requirement, JAR) является набор требований к программному обеспечению. После
дующие требования разбивают исходные на набор производных требований, кото
рые, как правило, документируются в спецификации проекта программного обеспе
чения (Software Design Specification, SDS). Мы уже рассмотрели существующие воз
можности статического тестирования этой переформулированной версии требова
ний, которые позволяют обнаружить пропущенные, неверно сформулированные, двусмысленные и попарно конфликтующие требования, приводящие к ошибкам в спецификации проекта программного обеспечения. Обнаружение ошибок в требова
ниях — наибольший выигрыш, даваемый всеми формами тестирования. В рамках па
радигмы быстрого тестирования определяется матрица прослеживаемости требова
ний (Requirements Traceability Matrix, RTM), за счет использования которой группа разработки, включая тестировщиков, демонстрирует свою заинтересованность в со
блюдении и полноте тестирования требований. При этом на протяжении всего жиз
ненного цикла разработки применяются как статические, так и динамические сред
ства тестирования.
С другой стороны, если применяется методика, отличная от быстрого тестирова
ния, и тестирование начинается лишь тогда, когда разработка программного обеспе
чения подходит к концу, то для получения RTM, которая будет использоваться для планирования тестирования в ходе оставшейся части жизненного цикла разработки, придется выполнить реконструирование требований.
Программа контроля единиц измерения
физических величин
Огромную помощь в разработке научных программ оказывает программа контроля единиц измерения физических величин. Эта программа представляет собой статиче
ский препроцессор исходного кода, который проверяет, что результат каждого ма
тематического выражения выражается в соответствующих единицах измерения фи
зических величин. Рассмотрим выражение для определения частоты (R) или скоро-
202 Часть II. Технологии быстрого тестирования и советы сти:
Rl =
D1/T1, где
D1 — пройденное расстояние, а 77 — время передвижения. Это выражение справедливо только в том случае, если единицы измерения физических величин совместимы. Иначе оно будет неверным. Например, если расстояние выражается в километрах, а время — в минутах, то скорость, вычисляемая в соответствии с этим выражением, должна выражаться в км/мин. Если это значение скорости необходимо вставить в другое выражение, в котором скорость должна выражаться в милях в час (миль/ч), вначале потребуется выполнить преобразование
R1 (км/мин) в
R2(миль/ч).
При реализации в качестве статического средства контроля программа контроля единиц измерения физических величин содержит дополнительные спецификации ввода всех переменных, хранящих физические величины, которые определены в специально сформатированных строках исходного кода. При каждом использовании или определении этих переменных формулы проверяются на предмет того, что пе
ременные в левой части выражения (результаты) получают единицы измерения на основе вычислений и на базе объявленных единиц измерения, которые связаны с переменными из правой части (входные переменные).
Символьное выполнение Символьное выполнение — это
технология подстановки символов в формулы, зако
дированные внутри языка программирования с выполнением алгебраического объе
динения символов в соответствии с алгоритмом. Рассмотрим код функции вычисле
ния синуса SINE, приведенный на рис. 9.6. Этот алгоритм содержит минимальное количество произведений, как показано в следующем выражении: sin(x) =x*(l -х
2
*(1/3! -х
2
*(1/5! -х
2
*(1/7! -х
2
*(...))))).
30
REAL FUNCTION SINE (P,EPS)
ERROR = P
SUM = P
DO J = 3,1000,2
ERROR = ERROR * (P**2) / (J* (J+l))
SUM = SUM - ((J+l)/2) * ERROR
IF (ABS(ERROR) .LT. EPS)
THEN
GO TO 30
ENDIF
ENDDO
SINE = SUM
RETURN
END
Рис. 9.6. Функция SINE, реализованная с использованием разложения вряд Тейлора
Глава 9. Технологии статического тестирования и советы
203
Программа символьного выполнения осуществляет математические упрощения для реализации приведенных в таблице 9.3 шагов алгоритма, который представляет собой известный метод разложения в ряд Тейлора.
Полученные результаты можно сравнить со значением функции sin(x), получен
ным из большинства математических справочников, а именно: sin(x) = х- x3/З! +x5/5! + х
7
/7!...
Повторимся еще раз: из этого описания понятно, почему символьное выполнение является средством статического тестирования. Это связано с тем, что для выполне
ния алгоритма не требуется ввод числовых данных.
Таблица 9.3. Символьное выполнение алгоритма, приведенного на рис. 9.6
J Ошибка Сумма
3 Р*(Р
2
/12) = Р
3
/12 Р - ( 4 / 2 ) * ( Р
3
/ 1 2 ) = Р - Р
3
/6 5 ( Р
3
/ 1 2 ) * Р
2
/ 3 0 - Р
5
/ 3 6 0 P - P
3
/ 6 + (6/2)*P
5
/360 =
P - P
3
/ 3 ! + P
5
/120 7 Р
5
/ 3 6 0 * Р
2
/ 5 6 = Р
7
/20160 P - P
s
/ 6 + P
5
/120-4*(P
7
/20160) =
Р - Р
3
/З! + Р
5
/ 5 ! - Р
7
/ 7 !
J P
J
/ ( J ! * ( J + l ) / 2 ) д л я j = 3,n,2 P - S U M ( p j / J ! ) д л я J = 3 , n , 2
Листинги перекрестных ссылок
Листинги перекрестных ссылок — это зависящее от языка средство тестирования и отладки, которое индексирует использование переменных внутри каждого модуля.
Некоторые перекрестные ссылки включают в себя список строк исходного кода, в которых переменные используются или определяются. Это позволяет тестировщику выявлять неправильно введенные имена переменных, приводящие к возникновению программных ошибок. Неправильно введенная переменная будет либо неопределен
ной, либо использоваться в вычислении, в котором присутствовать не должна. В большинстве компиляторов такая функция реализована.
Программы улучшенной печати
Программы улучшенной печати — это зависимое от структурированного языка сред
ство тестирования, обеспечивающее корректное завершение каждой структурной конструкции. Например, если в конструкции IF-THEN-ELSE-ENDIF отсутствует клю
чевое слово ENDIF, при улучшенной печати структура будет выглядеть неправильно выровненной. Это часто приводит к ошибке, поскольку часть ELSE может содержать выражение, которое не должно выполняться. Во многих компиляторах структуриро
ванных языков такая функция реализована.
204 Часть II. Технологии быстрого тестирования и советы Средства сравнения версий Средства управления конфигурациями обеспечивают
выбор в качестве последней версии такой, которую можно проверить на предмет изменений. Эти средства служат для упрощения работы создателей программного обеспечения. Например, если два разработчика проверяют одну и ту же версию исходного кода и начинают вносить в нее изменения, то когда они одновременно делают попытку вернуться обратно к проверке, возникает дилемма. Определить, какая версия должна проверяться пер
вой, может помочь только какой-нибудь механизм блокировки, предоставляемый средством управления конфигурациями. После этого оба автора могут прийти к со
глашению о способе объединения конфликтующих изменений. Еще одно применение средства сравнения версий связано с проверкой на полное совпадение файла и одной из версий, поддерживаемых системой управления конфигурациями.
Ряд дополнительных функций средства управления конфигурациями помогают испытателям определить, вносились ли изменения в исполняемый код или в файлы данных между двумя последовательными версиями. Эти функции называются
средствами сравнения версий. Средство сравнения версий осуществляет сравнение одной ячейки за другой, выделяя различия между двумя ячейками. При этом термин "ячей
ка" может означать строку исходного кода или поле данных внутри записи. Специа
листы по тестированию и разработчики должны обмениваться информацией об об
ластях изменений в новых версиях. Как правило, это делается при помощи записей.
Это же средство может использоваться и в качестве инструмента предотвращения ошибок во время проверки измененных областей. Естественно, неизменные области могут потребовать регрессивного тестирования для обнаружения возможных побоч
ных эффектов, но тестовые случаи, предназначенные для проверки неизмененных областей кода, наверняка не потребуют повторного выполнения. Таким образом, ис
пользование средства сравнения версий может привести к повышению эффективно
сти работы персонала, занятого быстрым тестированием.
Тестирование алгоритмов Если перед тестировщиком поставлена задача тестирования модуля, который реали
зует преобразование данных по определенному алгоритму, наиболее строгий подход предполагает разработку входных и ожидаемых результирующих данных, которые позволят испытать возможности, варианты выполнения и условия возникновения ошибок алгоритма. Например, если перед специалистом по тестированию стоит за
дача проверки алгоритма быстрого преобразования Фурье, проверке должны под
вергаться несколько свойств этого преобразования. Поскольку быстрое преобразо
вание
Фурье является линейным, тестировщик создает тестовый случай для проверки равенства
T(a*f, +
b*f2) =
a*T(f,) +
b*T(f2). Поскольку быстрое преобразование Фурье является обратимым, тестировщик может выполнить прямое преобразование от
дельных частот в спектральную функцию, а затем подвергнуть эту спектральную функцию обратному преобразованию и убедиться в совпадении результата с исход
ными отдельными частотами, т.е. в том, что
T'[T\f)]=f. На этом этапе тестировщик может прийти к выводу, что код реализует обратимое линейное преобразование, но вопрос о том, является ли алгоритм действительно преобразованием Фурье, остается
Глава 9. Технологии статического тестирования и советы 205 открытым. Специалисту по тестированию наверняка придется создать данные для фиксированной частоты, для которой спектральная функция имеет только одну не
нулевую составляющую на выбранной частоте, и убедиться, что ее амплитуда имеет правильное значение. За этим тестовым случаем могут прогоняться случаи для сле
дующей "чистой" частоты и так далее, пока не будут протестированы все частоты и амплитуды.
Однако этот строгий подход относится к категории динамического тестирования, которое представляет собой тему главы 10. Значительно больший объем тестирова
ния этого алгоритма можно предпринять во время его разработки с одновременным использованием статического тестирования. При разработке требований упомяну
тый алгоритм формулируется, например, так: "Пользователь должен располагать утилитой, которая будет выполнять быстрое преобразование Фурье для комплексных данных,
длина которых составляет степень двух, вплоть до 2 10
включительно". Эта формулировка понятна персоналу инженерной или физической лаборатории, но разработчик программного обеспечения может не обладать достаточной математи
ческой подготовкой. Во время эскизного проектирования это требование должно быть разбито на более понятные части. Прежде всего, входные и выходные данные помещаются в два двумерных массива длиной я, имеющие тип COMPLEX и макси
мальную длину 210 во флаг ошибки типа INTEGER и в переменную Nтипа INTEGER, значение которой лежит в интервале [2,10]. Приведенная информация эскизного проекта определяет пользовательский интерфейс, который дает возможность подго
товить прототип, или заглушку, для помещения ее в графический интерфейс пользо
вателя на этапе эскизного проектирования до того, как будут получены необходимые разъяснения от персонала инженерной или физической лаборатории.
На этапе рабочего проектирования алгоритм быстрого преобразования Фурье должен быть тщательно проанализирован. Здесь же понадобиться выбрать либо его оригинальную версию, разработанную Кули (Cooley) и Туки (Tukey) в 1965 году [12], либо какую-нибудь другую модификацию из более новых. Потребуется принять ряд решений относительно порядка обработки. Например, нужно ли применять обрат
ный порядок следования разрядов выходных данных перед завершением преобразо
вания, или предварительно сортировать таблицу данных синусов и косинусов с ис
пользованием алгоритма с обратным порядком следования разрядов, после чего со
хранять данные в фиксированной области памяти с тем же обратным порядком сле
дования разрядов. Необходимо также принять решения относительно требования к точности алгоритма. Это решение должно подкрепляться задокументированными ссылками на техническую литературу, которая обосновывает требования по тестиро
ванию точности результирующего алгоритма преобразования. Кроме того, нужно определить и требования ко времени выполнения преобразования, чтобы можно было проанализировать, достаточно ли будет скалярного процессора, или же потре
буется процессор, в архитектуре которого реализованы векторные инструкции и дру
гие функции обработки массивов.
Этапы проектирования программного обеспечения служат фундаментом для раз
работки требований, и все тестирование, выполняемое во время проектирования, за исключением динамического тестирования прототипов, является статическим. Мно
гие решения, которые должны быть приняты во время рабочего проектирования, могут оказаться ошибочными и вести к значительным перерасходам средств или к
206 Часть II. Технологии быстрого тестирования и советы формулированию требований, которые не могут быть выполнены. Подход к этому вопросу с использованием быстрого тестирования заключается в сосредоточении усилий на поиске компромиссных решений на этапе рабочего проектирования. Затем компромиссные решения могут использоваться в качестве средства предотвращения изменчивости требований - одной из основных причин повышения затрат в ходе разработки с традиционным каскадным жизненным циклом. Компромиссные реше
ния - это форма оптимизации перед утверждением окончательного варианта проек
та, которая предотвращает многократное выполнение дорогостоящих разработок и динамического тестирования для отброшенных проектов/реализаций. В большинст
ве финансовых оценок Института технологий программного обеспечения (Software
Engineering Institute, SEI) финансовые инспектора фиксируют многочисленные на
рушения в области проектирования программного обеспечения. Мы называем это явление "выбоинами" процесса разработки - "ямами" на дороге, которые иногда мо
гут повредить движущийся по ней проект. Быстрое тестирование - это искусство расстановки по всему жизненному циклу разработки специалистов по тестированию,
которые обнаруживают и сообщают о недостатках, как только они появляются.
ПРИМЕР: АНАЛИЗ ОБЩЕЙ ОШИБКИ ОКРУГЛЕНИЯ (ГЭРИ КОББ) Еще одна область применения статического тестирования, которая особенно характерна для сферы научного программирования, — это анализ общей ошибки округления. Для того чтобы убедить в необходимости выполнения этой формы тестирования, стоит лишь' сослаться на один реальный случай из личной практики. В начале семидесятых компания, в которой я работал, заключила с одним из клиентов контракт на перенос их программ
ного обеспеч з скалярного компьютера в векторный. В части контракта, касающей ся приемки конечных продуктов, было оговорено следующее условие: на векторном. компьютере преобразованные программы будут выполняться в 256 раз быстрее и вьщавать те же шестнадцатеричные результаты, что и при выполнении на скалярном компьютере.
К моменту назначения меня на должность руководителя группы преобразования про
граммного обеспечения, я выполнил оценку основных характеристик каждой из основе ных преобразуемых систем, как с точки зрения времени выполнения, так и в плане по-' лучения распечаток входных и выходных переменных при прогоне программ для данных, которые владельцы приложений считали типовыми. Мне казалось, что это должно было помочь выполнить условия получения приемлемой производительности для выбранного, метода преобразования. Вскоре после начала преобразования программного обеспече
ния один из моих сотрудников пришел к шутливому выводу: одно из выходных шестна- дцатеричных значении было названо W W M , что означало "worldwide mass" ("масса земного шара ). Это значение было результатом суммирования масс всех ячеек с е т к и ' наброшенной на весь земной шар. После совместной работы мы установили, что такое вычисление приводило к переполнению значения с плавающей точкой при обходе пои- мерно половины земного шара, поскольку накапливаемая сумма становилась настолько: большой, что добавление массы остальных ячеек сети не
вело к изменению суммы Бо- лее того, скалярный компьютер выполнял 36-разрядные операции с плавающей точкой то время как векторный компьютер мог выполнять 32- или 64-разрядные векторные операции с плавающей точкой. Мы явно оказались в проигрышной позиции. Если выпоп- нять сложение с одинарной точностью, переполнение возникло бы прежде, чем удалось добраться даже до середины сетки (т.е. шестнадцатеричный результат отличается от получаемого на скалярном компьютере). Если же выполнять суммирование с двойной' точностью, вычисление выполнялось бы медленнее (невозможно было получить 256- кратное увеличение производительности), и переполнение начинало бы возникать при обходе примерно 3 / 4 сетки (шестнадцатеричный результат отличается от первоначаль-
Скачать 4.53 Mb.