Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 9. Технологии статического тестирования и советы 185 довольны, когда представитель отдела тестирования заявляет: "Да, мы, по крайней мере, один раз протестировали каждую строку кода". Томас Маккейб (Thomas McCabe) и Чарльз Батлер (Charles Butler) [32] в качестве показателя определили чи словое значение цикломатической сложности V e Это значение может быть вычисле но по одному из трех способов: 1. Путем подсчета количества областей планарного графа, который представля ет процесс структурированной программы. 2. Цикломатическая сложность (V g ) графа процесса g определяется выражением V=E- N + 2, где Е— количество ребер графа процесса, a N— количество узлов графа процесса. 3. Цикломатическая сложность (V g ) графа процесса g определяется также выра жением V g =P + 1, где Р — количество предикатов (логических утверждений) в графе процесса. Пример представления проекта модуля в виде графа Показанный на рис. 9.1 планарный граф делит плоскость на пять областей, пронуме рованных цифрами от 1 до 5, поэтому его цикломатическая сложность V=5. Попы тайтесь найти четыре предиката в коде и в соответствующем ему графе процесса. В заключение определите количество тестовых случаев, которые потребовались бы, по меньшей мере, для однократного тестирования каждой строки кода. Тестирование ветвей PDL Процедура сортировки Выполнение до тех пор, пока остается хотя бы одна запись Считывание записи; Если поле записи 1 = О, то выполнить обработку записи; Сохранение в буфере; Увеличение значения счетчика; Иначе, если поле записи 2 = 0, то сбросить значение счетчика; Иначе обработать запись; Сохранение в файле; endif enddo end Примечание: каждая структурированная программа имеет направленный планарный граф. Рис. 9.1. Планарный граф программы, иллюстрирующий определение показателя циклома тической сложности. 186 Часть II. Технологии быстрого тестирования и советы Значение цикломатической сложности для тестирования программ состоит в том, что V представляет собой минимальное количество независимых ветвей, которые должны быть проверены для тестирования всей программы. Испытатель должен быть в состоянии применить это свойство к графу "а", представленному в левой части рис. 9.2, и разработать минимальное количество тестовых случаев, которые должны быть выполнены для полного охвата всего приложения, соответствующего данному графу. При этом возникает ряд вопросов. Обеспечивают ли два приведенных тесто вых случая полное тестирование всех ветвей? Нет ли какой-либо ветви, которая оста лась неохваченной тестовыми случаями 1 и 2? И если да, то каким должен быть до полнительный тестовый случай? Рис. 9.2. Определение минимального набора тестовых случаев на основе значения показателя цикломатической сложности. В [18] Питер Чейз Белфорд (Peter Chase Belford) описал, как в рамках одного из выполненных им проектов в корпорации Computer Science Corporation при помощи показателя цикломатической сложности удалось снизить стоимость проекта и одно временно повысить качество программного продукта за счет снижения сложности кода. ПРИМЕР: ПРОЕКТ CENTRAL FLOW CONTROL Эти учебные примеры заимствованы из [18]. В проекте Central Flow Control (CFC) для документирования алгоритмов использовался псевдокод. Для языка разработки псевдо кода (pseudocode design language, PDL) была создана программа синтаксического ана лиза, в которой был реализован счетчик цикломатической сложности. Глава 9. Технологии статического тестирования и советы 187 Стоимость разработки каждой модели и соответствующее ей значение показателя цик ломатической сложности наносились на фафик, и для полученных данных определялась наиболее подходящая S-образная кривая. S-образная кривая Белфорда показана на рис. 9.З. Из приведенного рисунка видно, что существовал диапазон цикломатических значе ний модулей — например, вблизи линейного участка кривой, — которые отражали при емлемую стоимость разработки, выраженную в часах. В то же время другая область представляла неприемлемое возрастание стоимости. В ходе разработки проекта CFC постоянно выполнялось повторное проектирование модулей, для которых показатель цикломатической сложности PDL превышал 30. На основе анализа процесса разработки этой профаммы Белфорд пришел к следую щим выводам: • Лучше использовать меньшие модули. Сложность системы разработки программного обеспечения лучше измерять количест- вом ветвей принятия решений, чем количеством выполняемых операторов в исходном коде. Использование современных методов программирования способствует повышению степени понятности и надежности системы, а также делает процесс разработки более управляемым. Надежность программного обеспечения повышается с увеличением времени, которое тратится на проектирование. В некоторых проектах применяются стандарты, в которых предпринимается попытка ог- раничить размер каждого из модулей до некоторого приемлемого объема кода. На рис. 9.4 показано, как определить набор эвристических правил и представить его в форме дерева принятия решений, подтверждающего выводы Белфорда и других иссле дователей. Эти стандарты могут использоваться персоналом службы тестирования при разработке автоматизированных средств оценки всего проекта или отдельных про граммных модулей. Время разработки (в часах) 0 5 1 0 1 5 2 0 2 5 3 0 3 5 4 0 4 5 Количество DD-ветвей Рис. 9.3. S-образная кривая Белфорда: с увеличением показателя цикломатической сложно сти более 30 затраты начинают возрастать по экспоненциальному закону. 188 Часть II. Технологии быстрого тестирования и советы Эвристическое правило: весьма вероятно, что модуль содержит много ошибок, если он имеет от 100 до 300 LOC, а его сложность составляет 15 или более Эвристическое правило: скорее всего, модуль содержит много ошибок, если он: • имеет более 300 LOC • оценка его проекта не проводилась • изменялся более 5 раз Рис. 9.4. Определение стандартов, ограничивающих размер и сложность исходных модулей. Формальная оценка Имеет смысл периодически проводить формальную оценку каждого аспекта проекта разработки программного обеспечения. Может возникнуть вопрос, какое отношение периодические формальные оценки имеют к быстрому тестированию. Быстрое тес тирование — это метод, в основе которого лежит выполнение каждой задачи на как можно более раннем этапе жизненного цикла и одновременное обнаружение и уст ранение любых недостатков, могущих возникать в процессе решения каждой задачи. Как правило, формальная оценка проводится накануне завершения какого-либо эта па, и объектами таких оценок становятся результаты, базы данных показателей про екта, календарные планы, перечни недостатков и тому подобные документы, полу ченные на каждом этапе жизненного цикла разработки. Цель формальной оценки состоит в ознакомлении отдельных членов команды разработки с оценкой всех аспектов достигнутых результатов разработки с точки зрения руководства. Каждый разработчик должен увидеть и понять взаимозависимо сти между всеми полученными результатами, в особенности между теми, за получе ние которых он несет ответственность. Каждый разработчик должен увидеть и по нять, какие показатели содержат информацию, имеющую отношение к выполняемой им работе. Специалисты по тестированию должны обратить особое внимание на элементы, которые должны оцениваться. Например, на состояние выполнения зака за на поставку испытательного оборудования или даты готовности новой документа- Глава 9. Технологии статического тестирования и советы 189 ции, поскольку эта информация может влиять на план выполнения тестирования или разработку тестового случая. Иначе говоря, каждый участник выполнения формаль ной оценки оценивает результаты этапа с точки зрения их готовности к использова нию. Хотя кое-кто может заявить, что эти обзоры служат для осуществления контро ля над ходом разработки программного обеспечения со стороны руководства, мы смотрим на этот вопрос несколько иначе. Данные, полученные от членов команды, наряду со списками недостатков/нерешенных вопросов должны компилироваться и упорядочиваться руководителями различных уровней. Это позволит передать эти данные команде разработчиков, чтобы члены команды могли увеличить свою произ водительность или улучшить качество получаемых результатов. Для программного обеспечения, разрабатываемого по контракту, в ходе каждой формальной оценки с участием клиента оценивается соблюдение сроков и условий контракта. Резюме этих оценок могут представляться клиент)', который должен быть уверен в корректности ведения разработки в рамках выделенного бюджета и огово ренных сроков. Н и ж е приведен перечень вопросов, который может подготовить и отслеживать руководитель разработки программного обеспечения или специалист по вопросам обеспечения качества, и который может быть представлен в ходе фор мальной оценки: • Данные о размере программных продуктов или объеме изменений в программ ных продуктах отслеживаются, и в случае необходимости предпринимаются корректирующие действия. • Размер программных продуктов или объем изменений в программных продук тах регулируются в соответствии с задокументированной процедурой. • Данные по трудоемкости и затратам на разработку программы отслеживаются, и в случае необходимости предпринимаются корректирующие действия. • Трудоемкость и затраты на разработку программы регулируются в соответст вии с задокументированной процедурой. • Критичные для выполнения проекта компьютерные ресурсы отслеживаются, и в случае необходимости предпринимаются корректирующие действия. • Критичные для выполнения проекта компьютерные ресурсы управляются в соответствии с задокументированной процедурой. • Календарный план разработки программного обеспечения проекта отслежива ется, и в случае необходимости предпринимаются корректирующие действия. • Календарное планирование и управление разработкой критичных связей и критичных ветвей программы выполняется в соответствии с задокументиро ванной процедурой. • Технические действия по разработке программного обеспечения отлеживают ся, и в случае необходимости предпринимаются корректирующие действия. • Отслеживаются вероятные просчеты в программном обеспечении, которые могут сказаться на затратах, ресурсах, календарном плане и технических аспектах. 190 Часть II. Технологии быстрого тестирования и советы • Вероятные просчеты в программном обеспечении, которые могут сказаться на затратах, ресурсах, календарном плане и технических аспектах, идентифици руются, оцениваются и документируются. • Критичные взаимозависимости между разработками программного обеспече ния идентифицируются, согласуются и отслеживаются в соответствии с задо кументированной процедурой. • Вероятные просчеты в программном обеспечении проекта идентифицируют ся, оцениваются, документируются и контролируются в соответствии с задоку ментированной процедурой. В число присутствующих на формальной оценке могут входить представители компании/организации, выполняющей основную разработку, представители коман ды субподрядчика/партнера, команды организации-покупателя и команды потенци альных пользователей. Проведение формальной оценки позволяет руководству орга низации/проекта контролировать процесс разработки, в том числе просматривая отчеты и предпринимая корректирующие действия в отношении затрат, человече ских ресурсов, компьютерных ресурсов, технических проблем, критичных взаимоза висимостей и вероятных просчетов. Секретарь должен записать действия, по кото рым достигнуты соглашения во время встречи, и по ее окончании перечень выбран ных действий должен быть распространен среди исполнителей и отслеживаться вплоть до момента реализации всех действий. По окончании встречи перечень дей ствий будет проработан руководителями нижнего уровня, способными устранить лю бые конфликты, которые могут возникнуть между группами. Независимо от того, яв ляется ли организация главным подрядчиком или субподрядчиком (в наше время в деловом языке чаще употребляется термин "партнеры"), важно проводить хорошо организованные совместные формальные оценки. Главное достоинство проведения хорошо организованных формальных оценок — это возможность согласовывать уси лия и делиться приобретенным опытом. Для команды тестирования формальные оценки ценны в первую очередь тем, что позволяют гарантировать применение всеми партнерами одних и тех же критериев прохождения/непрохождения тестов, создание во всех организациях-партнерах со вместимых тестовых сред, разработку средств для немедленного распространения информации обо всех обнаруженных ошибках и просчетах, поддержание календар ных планов последовательной поставки версий продукта с устраненными ошибками и достижение соглашений по условиям прекращения тестирования. Применение контрольных перечней Поскольку управление разработкой программного обеспечения может оказаться очень сложным, большое распространение получила практика применения сборни ков извлеченных уроков и наиболее эффективных методик, оформленных в виде контрольных перечней. Контрольные перечни служат удобным напоминанием о дей ствиях, которые должны выполняться в процессе жизненного цикла разработки. Обычно они документируются в форме утвердительно-вопросительных предложений типа "если... то... ?". Контрольные перечни не следует искать в Internet, выбирая те, которые кажутся подходящими. Более того, контрольные перечни не должны ис пользоваться в качестве стандартов организации. Если контрольный перечень не Глава 9. Технологии статического тестирования и советы 191 разработан на основе уроков, извлеченных в рамках данного проекта, польза от него будет невелика. В то же время, правильно составленные контрольные перечни слу жат мощным средством снижения вероятности просчетов в ходе разработки проекта. П р и выполнении быстрого тестирования, в зависимости от выбранного жизнен ного цикла разработки, языка и средств, используемых для разработки, и множества других факторов, контрольные перечни, созданные для данного проекта, могут иметь различное назначение. Н и ж е приведены примеры пунктов контрольного перечня: • Если требования включают в себя требования по доступности, то должен ли используемый в проекте текст подвергаться проверке на предмет соответствия стандарту компании, предусматривающему манипуляции доступностью? • Если требования включают в себя требования по доступности, то отражен ли в плане тестирования факт применения средств тестирования доступности про екта на предмет соответствия стандарту? • Если требуется применение процесса инспектирования на предмет соответст вия стандартам компании, то прошли ли все участвующие в инспектировании 4- часовый курс обучения и сдали ли выпускной экзамен? • Если температура является обязательным параметром, то обеспечивается ли возможность выбора пользователем отображения температуры по шкале Цель сия или Фаренгейта? • Если "abc" — выбранное средство управления конфигурацией, которое будет использоваться в проекте, то заблокированы ли все версии исходных модулей, которые в настоящее время проверяются на предмет обновления? Авторам доводилось встречать базы данных пунктов контрольных перечней, в ко торых утверждение отделялось от вопроса и которые содержали дополнительные поля, используемые в качестве ключей сортировки. Тем самым достигалась возмож ность изменения ф о р м ы печати контрольных перечней в зависимости от текущего этапа и назначения перечней. Повторим еще раз: главное, чтобы при возникновении проблемы все члены команды сделали все возможное для создания пункта контроль ного перечня, в котором было бы указано, что должно быть сделано данной командой для устранения данной проблемы, если она возникнет снова. Как создаются пункты контрольного перечня? Процедура состоит в следующем: если причина жалобы клиента отражена в верхней части диаграммы Парето, то су ществует ли пункт контрольного перечня, в утвердительной части которого описана причина жалобы клиента, а в вопросительной — правило устранения основной при чины неполадки? Да, для создания такого перечня требуется терпение и методич ность, но выгода от его применения огромна. Аудит Для того чтобы убедиться в соблюдении инструкций, процедур и стандартов органи зации, необходимо выполнить аудит в рамках организации. П р и отсутствии утвер жденных инструкций, процедур и стандартов аудит лишен смысла и лишь создавал бы значительные неудобства. Уведомление, планирование, беседы и составление отче тов по результатам аудита — все это действия, имеющие решающее значение для ус пешного проведения аудита. Беседы должны планироваться так, чтобы изолировать 192 Часть II. Технологии быстрого тестирования и советы друг от друга следующие производственные уровни: руководство и функции поддерж ки (например, управление конфигурированием), обеспечение качества, клиен ты/спонсоры/бизнес-аналитик, управление производством, администратор баз дан ных и другие непосредственные исполнители разработки/тестирования. В каждой беседе должны участвовать ведущий аудитор и второй аудитор. Ведущий аудитор ве дет беседу, и оба аудитора фиксируют все сказанное в ходе нее. Между беседами ауди торы могут меняться ролями. Советы по выполнению каждого из основных действий приведены в таблице 9.1. Таблица 9.1. Советы по выполнению каждого из основных действий в ходе аудита № п/п Основные действия Советы 1 Уведомление руководителей проекта Уведомление сотрудни ков, выполняющих вспомогательные функции Уведомление других непосредственных участников разработки/ тестирования Порядок проведения бесед в ходе аудита Гарантия конфиденциальности Необходимо по телефону согласовать удобное время прове дения аудита и список кандидатов для участия в беседах в ходе аудита. Затем потребуется разослать сообщения элек тронной почты с уведомлением о сроках бесед с руководите лями проекта, каждая из которых должна длиться около 1,5 часа. Составьте сообщение электронной почты, адресованное 6-10 участникам, с приглашением принять участие в беседе дли тельностью 1,5 часа, прихватив с собой соответствующие материалы, в том числе переписку между ними и разработчи ками, свои отчеты разработчикам и переписку с руково дством. Составьте сообщение электронной почты, адресованное 6-10 участникам, с приглашением принять участие в беседе дли тельностью 1,5 часа, прихватив с собой соответствующие материалы, в том числе календарные планы, итоговую доку ментацию и образцы отчетов руководителей проекта, со трудников, выполняющих вспомогательные функции и собст венные экспертные оценки. Следует запланировать не менее трех бесед, причем внача ле должны проводиться беседы с сотрудниками, выполняю щими вспомогательные функции, а конце — беседы с руко водителями проекта. Остальные беседы должны проводить ся в соответствии с графиком. В ходе каждой беседы, после краткого вступления следует сделать следующее заявление: "Информация, предостав ленная вами во время этой беседы, будет использована ис ключительно для улучшения процесса и качества продукта, но не для того, чтобы проверить вашу квалификацию или причинить какие-либо неприятности. Аудиторы будут делать пометки, которые будут использованы при составлении отче та, после чего они будут уничтожены. Наши отчеты будут представлены руководителям вашего проекта, но в них никак не будет отражено, кто и что сказал во время бесед. И безус ловно, нигде не будет никаких ссылок на эти беседы в ходе аудита. Вся информация, задокументированная в итоговых отчетах, будет предназначена исключительно для постоянно го совершенствования производственных процессов и каче ства продуктов. |