Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 10. Технологии динамического тестирования и советы 215 му использованию конечной программы, он всегда учитывает широту и степень по крытия тестирования. Чтобы гарантировать тестирование как удачных, так и не удачных ветвей внутри каждой функции, тестировщик должен уделять пристальное внимание классам эквивалентности входных данных функций. Анализ граничных значений Весьма перспективной областью для поиска ошибок являются границы классов экви валентности функции. Как правило, анализ, который ведет к определению классов эквивалентности, определяет и эти границы. Включение нескольких пограничных значений в тестовые случаи для данной функции поможет проверить удовлетворение ожиданий (требований) пользователя. Кратко рассмотрим причины ошибок разра ботчиков при кодировании граничных значений. Причины появления в программ ных продуктах ошибок, связанных с граничными значениями, достаточно легко по нять, анализируя количество преобразований, которые выполняются с момента раз работки требований до момента начала динамического тестирования. Прежде всего, все требования создаются на высоком уровне. Они содержат не слишком много под робностей. Как правило, на этапе рабочего проектирования (РП) проектировщики программного обеспечения добавляют в RTM так называемые производные требова ния, преобразуя исходные требования в подробные и точные с точки зрения вы числений. В организациях, занимающихся быстрым тестированием, уже осознали важность этапа РП для команды тестирования. Если производные требования отсутствуют или разработаны неправильно, то персоналу, занятому кодированием или тестировани ем, в ходе планирования, соответственно, придется дополнять высокоуровневый проект архитектуры и исходные требования этими документально оформленными подробностями рабочего проекта, в том числе и определяющими поведение про граммы на границах классов эквивалентности. В качестве примера рассмотрим кон струкции IF. По прошествии ряда лет многие исследователи в области компьютерных наук отметили, что утверждения в конструкции IF — это те программные элементы, в которых ошибки встречаются наиболее часто. Решение об использовании условия "меньше чем" или "меньше или равно" в утвердительной части конструкции IF часто принимается на этапе РП. В противном случае отсутствие этих спецификаций долж но быть выявлено во время инспекций, выполняемых на этапе РП. Отрицательное тестирование Отрицательное тестирование означает всего лишь подход, при котором тестиров щик, рассматривая программный продукт в качестве "черного ящика", определяет способы, как заставить продукт выдавать неверные ответы или вообще прервать вы полнение. Выяснив у проектировщиков, какие требования должны быть выполнены перед запуском программы, хороший специалист по тестированию может опреде лить набор тестовых случаев для выяснения реакции программного продукта на не соблюдение одного из этих предварительных условий. Рассматривая программу под этим непривычным углом зрения, тестировщик предпринимает попытки ее вы полнения: 216 Часть II. Технологии быстрого тестирования и советы • на платформах, на которых ее выполнение не планировалось; • при отсутствии коммуникационных линий или при вводе неправильных вход ных данных; • при отсутствии файлов данных, при отсутствии записей в базах данных или при произвольно переставленных данных в файлах данных; • при неверно введенных именах ссылок или при неопределенных, неправиль ных или отсутствующих конфигурационных параметрах; • при выключенных периферийных устройствах типа принтеров, сканеров, внешних дисководов компакт-дисков или CD-RW, внешних жестких дисков, внешних динамиков и т.п. Как уже упоминалось в разделе "Разделение по классам эквивалентности", к отри цательному тестированию относится также и ввод неправильных данных. Эти непра вильные данные могут поступать в форме недопустимых данных, введенных пользова телем, случайно заполненных данными коммуникационных буферов, недопустимых значений в индексных файлах, переполненных журнальных файлов, в которых указа тель находится в конце файла, и т.д. Устойчивость программы — это ее способность выдержать без сбоя отрицатель ное тестирование. Естественно, существует определенный предел устойчивости, тем не менее, разработчики программного обеспечения должны критично относится к коду и тестировать его как с правильными, так и с неправильными данными. Они должны предусмотреть самопроверку на предмет присутствия минимально допусти мой системной конфигурации и ее готовности выполнить приложение. Это самотес тирование должно предприниматься в начале выполнения программы, поскольку с момента установки продукта конфигурация могла измениться. Недостаточно выпол нять самотестирование конфигурации только во время установки приложения. Персонал, занимающийся тестированием, располагает широким спектром конфи гураций оборудования, на котором может выполнять тестирование системы. С пер соналом разработки, который использует типовые компьютеры, дела обстоят иначе. Важно, чтобы все члены команды тестирования осознали свою ответственность за проверку того, что продукт работает и дает одинаковые результаты во всех конфигу рациях, которые указаны в документе требований. Помимо обязательных конфигу раций, персонал, ответственный за тестирование, должен выполнить проверку обя зательных конфигураций, поддержка которых была отключена или которые были как-то расширены. Если во время тестирования эти конфигурации приводят к гене рации исключений, то, как минимум, документация по продукту должна содержать предупреждение о недопустимых конфигурациях. Стратегия отрицательного тестирования никогда не должна напоминать стрельбу наудачу. Напротив, планы тестирования должны быть тщательно продуманными, непротиворечивыми, завершенными и эффективно обеспечивать обнаружение оши бок. Штат, занятый разработкой методов тестирования, должен быть полностью укомплектован для разработки тестовых случаев, обеспечивающих соблюдение стра тегии тестирования, которая задокументирована в плане тестирования. При соблю дении этих условий тестирование системы будет эффективно в плане обнаружения и устранения в продукте множества ошибок. Глава 10. Технологии динамического тестирования и советы 217 Тестирование на основе определения степени риска Еще одна технология быстрого тестирования заключается в определении меры сте пени риска и введении соответствующих политик и процедур для ее использования. В ходе всей разработки проекта мера степени риска должна применяться абсолютно единообразно в соответствии с положениями, задокументированными в политиках и процедурах. Мера степени риска может определяться в какой-либо строгой форме, как показано в таблице 10.1. Таблица 10.1. Мера степени риска Уровень Стандарт для риска выбора этого уровня 1 Ошибка приводит к прерыванию всех приложений и сеансов коммуникации; требуется перезапуск, поэтому данные сеанса могут быть утеряны или оказаться неполными. 2 Ошибка приводит к неправильным ответам, которые могут влиять на последующие результаты, если пользователь продолжает работать с приложением. 3 Ошибка позволяет получить правильные результаты, но требования пользователя удовлетворяются не полностью. 4 Информация, представляемая пользователю, или эффективность приложения не отвечает требованиями по применимости. 5 Данное свойство может быть улучшено, но оно не оказывает отрицательное влия ние на работу пользователя. Для каждой подсистемы конечного программного продукта организуется группа контроля за внесением изменений, занимающаяся сопровождением, отслеживанием состояния и утверждением версий, в которых устранены отдельные поднаборы за фиксированных ошибок. В организациях часто ведется база данных ошибок, которая существует под эгидой группы контроля за внесением изменений, но используется совместно (с предоставлением доступа только по чтению) командами разработки и тестирования. Персонал этих команд исправляет и повторно тестирует ошибки, за планированные для устранения в будущих версиях конечного продукта. Эта инфра структура поддерживает подход к быстрому тестированию на основе определения степени риска, который может обеспечить поэтапную передачу конечного продукта заказчику. Инфраструктура подходит также для двух партнеров по разработке про граммного обеспечения, географически расположенных в различных точках земного шара. Стандарт IEEE Standard 1044 института инженеров по электротехнике и электро нике (Institute of Electrical and Electronics Engineers — IEEE) [24] устанавливает до полнительные определения, действия и процессы во время отслеживания ошибок. Этот стандарт возлагает на тестировщиков ответственность за классификацию ошибки во время ее обнаружения (распознавание). Ошибка, о которой сообщается в документации по тестированию, анализируется на предмет оказываемого ею влия ния, и для нее предлагается значение меры степени риска (влияние распознавания). 218 Часть II. Технологии быстрого тестирования и советы Команда разработки или сопровождения предпринимает шаги (исследование), чтобы удостовериться в повторяемости ошибки, и пытается определить ее основную при чину. Затем делаются уточнения предложенного значения меры степени риска и пла на, в том числе выделенных ресурсов, первой версии, в которой данная ошибка будет устранена, и оцениваются затраты (влияние исследования). В ходе выполнения этого плана предпринимаются действия по корректировке, и команда тестирования снова обращается к тестовому случаю, во время прогона которого ошибка была обнаружена впервые. Кроме того, команда выполняет набор регрессивных тестов, чтобы удосто вериться в том, что исправление ошибки не привело к появлению других ошибок. На основе результатов повторного тестирования заключительные выводы документи руются в примечании по реализации той версии, которая вначале содержала ошибку. Краткое описание этого процесса приведено в таблице 10.2 Диаграмма информационных потоков, приведенная на рис. 10.1, помогает упоря дочить подпроцессы на каждом из этапов и увязать их со всем процессом. Типовые группы контроля за конфигурацией и технологическим циклом, которые в настоящее время используются во многих организациях, могут обеспечить удобное сопровож дение этого процесса отслеживания ошибок. Для того чтобы закрыть проблему, свя занную с ошибкой, потребуется согласовать и программу, и ее документацию, в том числе требования, эскизную и рабочую документацию по проекту, а также руково дство пользователя. Глава 10. Технологии динамического тестирования и советы 219 Таблица 10.2. Терминология процесса отслеживания ошибок в соответствии со стандартом IEEE Standard 1044. Распознавание Влияние распознавания Исследование Влияние исследования Действие Заключительные выводы Выполняемые действия Предполагаемая причина Повторяемость Симптомы Состояние продукта Значение для клиента Степень серьезности Влияние на выполнение функций/ безопасность Действительная причина Источник Тип Влияние на ка лендарный план Влияние на стоимость Степень риска проекта Влияние на качество Социальные последствия Приоритет Решение про блемы Корректирующее действие Заключительные выводы Какие действия выполнялись во время проявления ошибки? На каком этапе жизненного цикла продукта она была обнаружена? Какова может быть причина ее появления? Удалось ли повторно добиться появления ошибки? Каким образом проявляется ошибка? Какова возможность использования продукта? Насколько устранение ошибки важно для клиента? Насколько серьезной была ошибка? Насколько серьезной была ошибка с точки зрения вы полнения стоящих перед проектом целей или угрозы для безопасности людей? Что привело к возникновению ошибки? Что было источником ошибки? Каким был тип ошибки? Сравнительное влияние на календарный план разработ ки продукта. Сравнительное влияние на бюджет. Риск, связанный с устранением ошибки. Влияние на качество продукта или надежность устране ния ошибки. Социальные последствия устранения ошибки. Степень важности устранения ошибки. Какие действия были предприняты перед закрытием отчета? Какие действия следует предпринять для предотвраще ния появления этой ошибки в будущем? Какова судьба ошибки, исходя из заключительного ана лиза? 220 Часть II. Технологии быстрого тестирования и советы Определение полноты охвата ветвей при тестировании В области проектировании программного обеспечения существует несколько опре делений тестирования ветвей. Наиболее традиционное определение гласит, что ветвь — это последовательность выполнения операторов исходного кода, начинаю щаяся с точки входа или условного разветвления и заканчивающаяся следующим ус ловным разветвлением или точкой выхода. Такие ветви были названы DD-ветвями (от decision-to-decision path — ветвь типа "решение-решение"). Теоретики подхода быстрого тестирования признают бесперспективность попыток обеспечить при тестировании полный охват всех DD-ветвей и рекомендуют вместо этого использовать программное средство автоматизации документирования всех DD- ветвей в исходном коде. Кроме того, на этапе тестирования блоков или комплексных испытаний необходимо определить приоритеты тестирования, чтобы испытания обязательно охватывали поднабор DD-ветвей, в которых вероятность наличия ошибки наиболее высока. Листинг программы, приведенный на рис. 10.2, был создан в период 1979-1981г.г., когда авторы разрабатывали систему тестирования программного обеспечения (Soft ware Testing System, STS). Эта система предназначалась для внутреннего использова ния в корпорации Texas Instruments, Inc., основанной организацией Advanced Soft ware Technology (AST). STS была программным инструментом, который позволял программистам на языке Fortran выполнять перечисление ветвей исходного кода. Для тестировщика STS служила удобным средством определения нужных значений переменных программы для перемещения программного счетчика по конкретной DD-ветви. STS могла устанавливать зонды в каждой DD-ветви. Во время выполнения эти зонды регистрировали номера DD-ветвей по мере их выполнения. После не скольких запусков программы анализ журнальных файлов позволял выяснить, какие DD-ветви не выполнялись. В случае аварийного прерывания выполнения программы журнальный файл, содержащий трассировку ветвей, объединялся с файлом с прону мерованными строками исходного кода, что позволяло генерировать отчеты, содер жащие строки исходного кода в порядке, обратном выполнению. Этот файл был очень полезен во время отладки, поскольку его можно было загрузить в текстовый редактор и выполнять поиск имен переменных, которые были связаны с прерывани ем программы. ADVANCED SOFTWARE TECHNOLOGY — FORTRAN SOFTWARE TESTING SYSTEM — (STS) DATE: 12/08/80 TIME: 12:40:34 PAGE: 1 THE OPTIONS IN EFFECT FOR THIS RUN OF STS STATIC ANALYZER ARE: LIST = INPUT SCANONLY = NO APPEND = NO TYPE = BOTH TIMEFIO = NO DOPTION = NO COPY = YES Глава 10. Технологии динамического тестирования и советы 221 1* С THIS PROGRAM WILL SPLIT A FILE WITH 3* С 4* С UNIT5 — INPUT (PARM1) 5* С UNIT6 — OUTPUT DIRECTORY (PARM2) 6* С UNIT7 — LIST (PARM3) 7* С 8* IMPLICIT INTEGER*2 (A-Z) 9* LOGICAL HEQ,HNE,FIRST,NEWMEM,GETYNO,ASCII 10* DIMENSION CARD(80),PATH80(80),PATH40(40) , CHARS(4),OLDMEM(4) 11* DATA CBB,FIRST,ASCII/2H ,.TRUE.,.FALSE./ 12* DATA LESSTH,R,E,P/2H< ,2HR ,2HE ,2HP / 13* 1000 FORMAT(80A1) 14* CALL SCIINT(IERR) 15* С 16* С OPENFH LUNO,PARM, ACCESS, BKSZ ) 17* С 18* CALL OPENFL(5,1,1,80) 19* CALL OPENFL(7,3,3,80) 20* ASCII=GETYNO(4,IERR) 21* CALL BANNER(ASCII) 22* CALL GETDIR(PATH80,NDEX,2) 23* NDEXM2=NDEX-2 24* WRITE(7,5000) (PATH80(I),1=1,NDEXM2) 25* WRITE(7,6000) 26* 5000 FORMAT(' THE OUTPUT DIRECTORY',/,IX,79A1) 27* 6000 FORMAT!//,' FILE WITHIN OUTPUT DIRECTORY NUMBER RECORDS') 28* NRECS=0 29* RECCNT=0 30* 31* 32* 33* 34* 1 CONTINUE 35* DO INDEX 1=1,80 36* CARD(I)=CBB 37* END DO 38* READ(5,1000,END=100) CARD 39* IF(ASCII) CALL EBCDIC(2,CARD,0) 40* С WRITE(10,1000) CARD 41* NEWMEM=(CARD(l).EQ.LESSTH.AND.CARD(2).EQ.R.AND.CARD(3).EQ.E. MODULE NAME — MAIN ADVANCED SOFTWARE TECHNOLOGY — FORTRAN SOFTWARE TESTING SYSTEM —(STS) DATE: 12/08/80 TIME: 12:40:44 PAGE: 42* &AND.CARDH) .EQ.P) 43* С WRITE(10,111) CHARS,NDX,LEN 44* 111 FORMATC AT 111 '4A2,2X,2110) 45* IF(FIRST.AND.(.NOT.NEWMEM)) 4 6* THEN 4 7 * WRITE(7,1500) 222 Часть II. Технологии быстрого тестирования и советы 4 8 * 1500 FORMAT(' ERROR: FIRST RECORD IS NOT A 5 0 * STOP 5 1 * END IF 5 2 * IF(NEWMEM) 5 3 * THEN 5 4 * NDX=5 55* CALL HFIELD(CARD,NDX,CHARS,80,LEN,CODE) 5 6 * IF (.NOT.FIRST) 5 7 * THEN 5 8 * CALL ENDFIL(6) 5 9* NRECS=NRECS+RECCNT 6 0 * WRITE(7,7000)OLDMEM,RECCNT 61* 7000 FORMAT(10X,4A2,26X,15) 62* RECCNT=0 6 3 * END IF 64* DO INDEX 1=1,4 65* OLDMEM(I)=CHARS(I) 6 6 * END DO 67* CALL SETMEM(CHARS,PATH80,NDEX,PATH40,3,6) 68* FIRST=.FALSE. 69* DO INDEX 1=1,80 7 0 * CARD(I)=CBB 7 1 * END DO 7 2 * READ(5,1000,END=100) CARD 7 3 * IF(ASCII) CALL EBCDIC(2,CARD,0) 7 4 * С WRITE(10,1000) CARD 7 5 * END IF 7 6 * WRITE(6,1000) (CARD (I) ,1 = 1,80) 7 7 * RECCNT=RECCNT+1 7 8 * GO TO 1 7 9 * 100 CALL CLOSEW(5,IERR) 8 0 * CALL ENDFIL(6) 8 1 * NRECS=NRECS+RECCNT 8 2 * WRITE(7,7000)OLDMEM,RECCNT 83* WRITE(7,3000) NRECS 8 4 * 3000 FORMAT(//,'THE TOTAL NUMBER OF RECORDS SPLIT WAS:',15) 85* CALL ENDFIL(7) 8 6 * STOP 8 7 * END (STS) -- STATIC ANALYSIS FOR MODULE "MAIN ", BEGINNING AT LINE 14 PATH 1: 14 THRU37 EOP PATH 2: 37 JUMP35 THRU37 EOP MODULE NAME — MAIN ADVANCED SOFTWARE TECHNOLOGY — FORTRAN SOFTWARE TESTING SYSTEM — (STS) DATE: 12/08/80 TIME: 12:40:56 PAGE: EXIT EOP PATH PATH PATH PATH PATH 3 4 5 6 7 37 38 38 39 39 A A THRU38 JUMP7 9 THRU39 THRU39 THRU4 5 EOP THRU8 6 EOP В THRU45 EOP |