Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 9. Технологии статического тестирования и советы 193 Окончание табл. 9.1 № п/п Основные действия Советы Управление ходом встречи со стороны аудиторов Выводы и подготовка отчета Ознакомление с заключительными выводами Отчет с заключительны ми выводами и заметки, сделанные в ходе бесед В ходе каждой беседы аудиторы должны поддерживать нуж ный ритм, профессиональный и производительный настрой и следить за тем, чтобы она проводилась в соответствии с графиком. Во время беседы недопустимы никакие персо нальные обвинения. Каждого участника следует призывать высказывать собственное мнение по каждой затронутой в ходе беседы теме. По завершении каждых трех бесед оба аудитора должны работать вместе в течение 2-3 часов, чтобы "по горячим сле дам" систематизировать выполненные заметки в поисках улучшений, вытекающих, по меньшей мере, из двух бесед. Один из аудиторов должен составить черновик выводов и передать его для комментариев второму аудитору. Процесс должен продолжаться до тех пор, пока между аудиторами не будет достигнуто соглашение по формулировке и тону каждо го вывода. В некоторых случаях может планироваться ознакомление руководителей проекта с заключительными выводами с це лью прояснения каждого вывода. Но доведение выводов до сведения членов группы разработки и вспомогательного пер сонала — задача руководителей данного проекта. Аудиторы должны уничтожить все заметки, сделанные в ходе бесед. Они должны поместить отчет с заключительными выводами в архив аудиторских проверок и сделать запись о завершении аудита в журнале регистрации аудиторских проверок. В 1999 году нам довелось провести аудиторские проверки более 25 команд разра ботчиков, дабы удостовериться, что эти команды, занимавшиеся внесением измене ний, решающих проблему 2000-го года, полностью выполнили соответствующее тес тирование и аттестацию, и эта проблема должна быть решена к первому кварталу 2000 г. Результаты, полученные в ходе аудита проектов программного обеспечения, свидетельствовали о высоком профессионализме аудиторов во время проведения бесед и о точности сделанных выводов, которые указывали на любые возможные проблемы в ходе производственных процессов. Ценность проведения этой проверки для компании заключалась в том, что аудиторская проверка 10% команд разработчи ков позволила в ходе выполнения проекта по решению проблемы 2000-ного года прийти к правильному заключению: изменения, внесенные в программное обеспече ние производственного процесса в период между тестированием и аттестацией, не привели к созданию несовместимого программного обеспечения. 194 Часть II. Технологии быстрого тестирования и советы Инспекции/критический анализ/ экспертные оценки Экспертные оценки в той или иной форме используются в большинстве проектов по разработке программного обеспечения. Одна из задач персонала подразделений обеспечения качества состоит в выполнении статистических выборок, чтении и по метках пользовательской или клиентской документации. Эти действия квалифици руют как экспертную оценку. Иногда программист направляет листинги исходного кода только что созданного модуля и его проектную документацию другому програм мисту с просьбой прочесть код и снабдить его пометками. Это также называется экс пертной оценкой. Программисты также делятся друг с другом отладочной информа цией с целью устранения особо трудно обнаружимых ошибок. Участие в таком свое образном клубе обмена информацией об ошибках тоже считается экспертной оцен кой. Хотя эти неформальные действия позволяют исправить множество ошибок, су ществует множество ошибок, которые остаются незамеченными, в основном из-за недостаточной полноты и тщательности при проведении экспертной оценки. Спе циалисты по тестированию могут использовать экспертные оценки во время разра ботки сценариев тестирования, получения данных тестов и оценки результатов тес тирования. С целью совершенствования методов экспертной оценки в качестве более полных и тщательных средств поиска, документирования и исправления ошибок были разра ботаны методы формализованного критического анализа и инспекций. Критический анализ предполагает, что автор документа или исходного кода программы представ ляет коллегам свой подход к использованию данного компонента программного про дукта. Группа коллег обсуждает предложенные автором подходы/алгоритмы, интер претации требований или метод документирования, задавая автору вопросы или прося пояснений, пока вся группа не будет удовлетворена предложенными решения ми. Тестировщики могут также использовать критический анализ во время планиро вания тестов, подготовки тестовых случаев, получения данных и оценки результатов тестирования. Майкл Фаган впервые определил понятие инспекции во время работы в компании IBM [34]. Инспекции определяется в качестве одной из форм экспертной оценки и обладают рядом общих черт с неформальным просмотром кода и критической оцен кой. Инспекции начинаются с представления автором листинга исходного кода и проектной документации модуля координатору инспекций. Распределение ролей и обязанностей в группе выполнения инспекций Координатор инспекций выбирает четыре-пять инспекторов, один из которых на значается председателем комиссии по инспекциям. Координатор выбирает также время и место проведения инспекций. Он подготавливает для команды проведения' инспекций четыре или пять пакетов документации, включающих в себя копии лис тингов модуля и соответствующей проектной документации, несколько форм ин спекций и соответствующих данному этапу контрольных перечней, составленных на Глава 9. Технологии статического тестирования и советы 195 базе опыта предыдущих инспекций. Эти пакеты документации передаются членам комиссии не позже, чем за два дня до проведения заседания комиссии. Каждый член комиссии по инспекциям должен быть тщательно подготовлен. Председатель комис сии и ее члены должны знать, что они должны потратить от одного до двух часов на ознакомление с представленными на инспекцию материалами до начала заседания комиссии. Каждый из инспекторов может делать пометки на листингах исходного кода, а остальные комментарии вносятся в формы инспекций, входящие в состав па кета документации. Формы инспекций частично заполняются каждым членом комис сии до прихода на заседание. В том числе это относится к перечню возможных оши бок, областей, в которых возможны усовершенствования, замечаниям о несоблюде нии соответствующих стандартов и т.п. Накануне заседания председатель комиссии должен предложить каждому члену комиссии еще раз убедиться в том, что они завер шили просмотр материалов, и сообщить уточненное время и место проведения засе дания. Календарный план типичной инспекции приведен в таблице 9.2, но при необ ходимости сроки выполнения отдельных этапов можно сократить до одного дня. Таблица 9.2. Календарный план проведения типичной инспекции В ходе заседания председатель комиссии рассаживает участников заседания в со ответствии с рис. 9.5. Решение о количестве разработчиков и специалистов по тести рованию в составе комиссии принимается координатором инспекций и зависит от характера пакета представляемой на инспекцию документации. Например, если это план тестирования, в комиссии должны участвовать один-два специалиста по тести рованию и ни одного или один разработчик программного обеспечения. В то же вре мя, если представленный на инспекцию пакет содержит исходный код на языке C++, 196 Часть II. Технологии быстрого тестирования и советы диаграмму потоков данных и диаграмму отношений объекта, за столом комиссии мо гут присутствовать два разработчика программного обеспечения и ни одного или один тестировщик. И, наконец, если пакет содержит список всех компонентов дан ной версии продукта, то более подходящим может быть состав комиссии, представ ленный в правой части рис. 9.5, когда место разработчика программного обеспече ния или специалиста по тестированию занимает руководитель разработки версии или лицо, отвечающее за управление конфигурацией программного обеспечения. Рис. 9.5. Различные расположения мест за столом комиссии по инспекции. Задача председателя комиссии по инспекции состоит в выполнении функций, способствующих проведению заседания комиссии. В этом качестве председатель ко миссии обеспечивает, чтобы снабженный документацией и развернутый в соответст вии с ранее упоминавшейся подготовкой процесс инспекций был выполнен в полном объеме. Задача регистратора недостатков заключается в фиксации всех обнаружен ных комиссией дефектов, удаление любых дублированных замечаний, руководство процессом уточнения формулировок каждого из обнаруженных просчетов, класси фицирование ошибок по уровню серьезности и присвоение им номера SEV перед тем, как они будут внесены в формы инспекции и представлены координатору. Зада чи регистратора показателей сводятся к обеспечению учета дефектов (ошибок) и возможных основных причин их возникновения или этапов жизненного цикла, на которых они, скорее всего, были допущены. Кроме того, в задачи входит и фиксация любых других текущих показателей инспекции проекта, таких как: общее время, за траченное членами комиссии на подготовку к инспекции, количество инспекторов в комиссии, общее время, затраченное на инспекции, общее количество ошибок, све дения о которых были введены в базу данных недостатков, и т.п. Эти данные вводят ся в формы инспекций. Председатель собирает формы у всех комиссии, после чего Глава 9. Технологии статического тестирования и советы 197 обновляет базы данных дефектов, показателей и контрольных перечней и представ ляет печатную копию сводного пакета документации координатору инспекций. Отчетность о процессе выполнения инспекций Координатор инспекций обеспечивает максимально быстрый ввод сведений об ошибках, зафиксированных в пакете документации по инспекции, в общую базу дан ных дефектов проекта. Еще одна отличительная черта быстрого тестирования за ключается в том, что некоторые из этих недостатков помечаются как "блокирующие", т.е. данная ошибка непосредственно препятствует дальнейшему тестированию кон кретной функции. О выявлении блокирующих ошибок и ошибок уровня SEV 1 (ката строфических) следует немедленно сообщать команде разработки, чтобы она смогла выполнить отладку. Основная цель быстрого тестирования состоит в обнаружении и исправлении ошибок в кратчайшие строки. Сохранение данных о каждой ошибке может сущест венно повысить точность и значимость процесса инспекции. Контрольный пере чень, составленный на основе полученного опыта, должен создаваться для каждого этапа жизненного цикла. Эти сгруппированные по этапам контрольные перечни должны стать действующими документами, отражающими данные о новых ошибках, которые получаются в результате какой-либо инспекции. Комиссия по инспекции может выполнить общий анализ каждой ошибки с целью выяснения этапа, на кото ром она была допущена. Эта комиссия должна добавить полученные сведения в кон трольный перечень данного этапа, чтобы следующая комиссия, выполняющая ин спекцию материалов в рамках этапа, наверняка обнаружила ошибку, аналогичную обнаруженной ранее. Такая обратная связь, реализуемая для каждой ошибки, делает контрольный перечень инспекций постоянно совершенствующимся документом. А это, в свою очередь, является отличительной чертой организации, которая обучается на собственных ошибках. Показатели процесса инспекции Показатели, полученные в результате проведения инспекций, непосредственно за гружаются в модель ошибок проекта. Количество дефектов на тысячу исходных строк кода объединяется с другими показателями инспекций, получаемыми в течение оп ределенного периода времени, например, ежедневно, еженедельно или в течение этапа разработки, и добавляется к входным данным программы оценки погрешности программного обеспечения (Software Error Estimation Program, SWEEP). Программа SWEEP подробно описывается в главе 11. Использование электронной почты или другого электронного приложения для ускорения процесса инспекции Для обеспечения быстрого тестирования на протяжении всего жизненного цикла проекта разработки программного обеспечения должны интенсивно использоваться разнообразные способы повышения эффективности. Существует несколько техноло- 198 Часть II. Технологии быстрого тестирования и советы гий, которые применяются не только к процессу инспекции, как описано в этом раз деле, но и к другим процессам в рамках цикла разработки. Предполагается, что ко манда разработки программного обеспечения создает исходный код на компьютерах, которые связаны между собой локальными сетями (local area networks — LANs). За счет использования серверов локальной сети или архитектуры типа сервер- хранилище данных (storage area network, SAN) любой участник проекта должен иметь возможность доступа к общим хранилищам данных проекта. В таких сетях поддержи ваются структуры каталогов, которые должным образом организуют данные по раз работке и тестированию. При этом предусматривается их регулярное резервное ко пирование в соответствии с установленным календарным планом. В качестве альтер нативы технологии LAN/SAN управление хранилищем данных проекта может осу ществляться также с помощью некоторого электронного приложения, действующего на Web-сайте проекта в рамках корпоративной сети организации. Это приложение должно заботиться о сохранении документации по разработке в системе управления конфигурациями, которая реализует строгий контроль версий и регулярно, в соот ветствии с календарным планом, выполняет резервное копирование. Используя встроенный календарь и обмен сообщениями по электронной почте локальной сети организации, персонал, занятый проектированием, может резерви ровать конференц-залы и приглашать участников каждой инспекции. Во время раз работки проекта, при которой задействованы методы быстрого тестирования, по добное повышение эффективности ведет к уменьшению временных затрат коорди натора инспекций на резервирование конференц-зала и приглашение всех инспекто ров на время, не связанное с какими-либо накладками. Соблюдение этого условия обеспечивается координатором, который при выборе подходящего времени и места заседания может просматривать календарные планы всех кандидатов в инспекторы. Корпоративная инфраструктура, образующая корпоративную сеть организации, пре доставляет также доступ к пакету документации по инспекциям, который может быть оформлен в виде набора гиперссылок в сообщениях электронной почты на доступ ные только для чтения версии форм и документов в общих хранилищах данных. Кро ме того, копии одних и тех же общих файлов могут добавляться в виде присоедине ний к календарным назначениям, рассылаемым всем инспекторам. Инспекция — это инструмент статического тестирования, который может приме няться для всех программных документов, начиная с этапа разработки требований и заканчивая этапом приемочных испытаний. Быстрое тестирование предполагает постоянный контроль на предмет возникновения ошибок, которые должны быть об наружены и исправлены как можно скорее после их возникновения. Поскольку ин спекции должны выполняться применительно к документу, который разрабатывается на данном этапе жизненного цикла, все обнаруженные в ходе инспекций дефекты должны отслеживаться вплоть до основной причины их возникновения. Затем ко миссия по инспекциям должна обновить контрольные перечни данного этапа, чтобы будущие комиссии не пропустили эти же или аналогичные ошибки. Ниже приведены характеристики инспекций, которые соответствуют требованиям быстрого тестиро вания: • В результате инспекций создаются списки ошибок, каждой из которых присво ен номер уровня серьезности, характеризующий приоритет процесса ее устра- Глава 9. Технологии статического тестирования и советы 199 нения. Список ошибок вносится в базу данных дефектов и используется при внесении изменений в систему, положенную в основу будущих версий. • В результате инспекций создаются версии контрольных перечней для одного или более этапов, на основе которых инспекторы выполняют анализ основных причин возникновения дефектов. Эти контрольные перечни полностью гото вы к использованию во время следующего выполнения данного этапа в рамках текущего или другого проекта. • В результате инспекций определяются показатели, которые управляют харак теристической моделью ошибок проекта и служат входными данными для про граммы оценки погрешности программного обеспечения (SWEEP), используе мой для прогнозирования скрытых дефектов, остающихся в самом программ ном продукте. Эти показатели служат также основой для постоянного совер шенствования процесса выполнения инспекций. Программа SWEEP подробно описывается в главе 11. • Инспекции способствуют повышению квалификации инспекторов, которые, возвращаясь к выполнению своих обязанностей разработчика, имеют более глубокие знания о продукте или требованиях, архитектуре, проекте и запро граммированных алгоритмах, а также о типах ошибок, которые следует отсле живать во время работы над их собственными рабочими продуктами. Из этого определения процесса инспекции, которое было разработано специаль но для быстрого тестирования, должно быть понятно, как именно объединять эту форму статического тестирования с реальным процессом разработки, и какое значе ние придается быстрому повышению качества результирующего продукта. Процесс инспекции, выполняемый в ходе быстрого тестирования, сокращает календарные сроки за счет исправления ошибок в ходе разработки, а не ближе к ее завершению. Формальная верификация Верификация — это действия по проверке выполнения на и-ом этапе разработки того, что было запланировано на (п -1)-ом этапе. Во время создания архитектуры системы и при определении требований производительности специалист по тестированию должен сравнивать обусловленные архитектурой ресурсы производительности с об щими требованиями. Во время тестирования рабочей проектной документации тес- тировщик будет сверять эту документацию с документацией по архитектуре, которая была разработана на этапе высокоуровневого проектирования. На этапе создания кодов тестировщик будет проверять код, сравнивая его с рабочей проектной доку ментацией. Например, в соответствии с рабочей проектной документацией для реа лизации некоторой функции должны быть созданы пять модулей, причем одним из них является комплекснозначный алгоритм быстрого преобразования Фурье (БПФ). В такой ситуации среди множества тестовых случаев должен существовать случай, ориентированный на проверку кода БПФ во время выполнения и обеспечивающий оценку точности, эффективности и всех встроенных функций, которые могут при сутствовать. 200 Часть П. Технологии быстрого тестирования и советы Языки на основе спецификаций Одно из средств в инструментальном наборе специалиста по тестированию носит название программного доказательства. Данное средство относится к категории формальной верификации, поскольку при этом подтверждается соответствие кода его рабочему проекту. Программное доказательство начинается с формулировки на специальном языке теоремы или леммы (называемой спецификациями) непосредст венно в основном коде, а именно — в заголовках каждого главного блока кода. Затем пользователь интерактивно взаимодействует с автоматизированным средством дока зательства теоремы с целью определения соответствия кода приведенной теореме или лемме. Такого рода языки называют языками на основе спецификаций или язы ками утверждений, а на инструментальное средство ссылаются как на средство фор мальной верификации. Хотя в настоящее время подобные средства редко применя ются при промышленной разработке программного обеспечения, тем не менее, они заслуживают того, чтобы включить их в арсенал инструментов тестирования. Автоматизированное доказательство теорем У нас имеется определенный опыт выполнения программных доказательств с ис пользованием компьютеризованной утилиты доказательства теорем Gypsy [18] для проверки приблизительно тысячи строк кода. Принцип работы утилиты Gypsy за ключается в следующем. Сначала тестировщик помещает формулировки теорем и лемм вместе с блоками кода, написанного на языке Gypsy (один из вариантов языка Pascal). Затем встроенный в Gypsy модуль доказательства теорем проверяет правиль ность реализации блоком кода всех утверждений, сформулированных в теоремах и леммах. Алгоритм, корректность работы которого довелось доказывать с помощью этого средства формальной проверки, носил название Collision Avoidance (исключе ние столкновений). В настоящее время упомянутый алгоритм реализован в компью терных системах Федерального авиационного агентства США для предупреждения самолетов о грозящих столкновениях. Для достижения этой цели на самолетах, а также на высоких зданиях и горах устанавливаются радиомаяки-ответчики. Эти мая ки-ответчики передают цифровые пакеты, содержащие данные о таких динамиче ских характеристиках полета, как высота, скорость и направление полета. На базе математических моделей динамики полета выполняется имитационное моделирова ние для данных из полученных цифровых пакетов, цель которого заключается в оп ределении вероятности столкновения, а также в выработке необходимой тактики предотвращения столкновения. Эти данные автоматически и заблаговременно пере даются на борт самолетов с пересекающимися траекториями полета и позволяют предотвратить столкновение. Таким образом, очевидно, что код алгоритма исключе ния столкновений должен быть корректным, причем доказуемо корректным. Вначале программа исключения столкновений была переведена на язык Gypsy, и для каждого блока кода были сформулированы теоремы. Затем при помощи возмож ностей Gypsy по доказательству теорем было установлено, что все теоремы в коде реализованы. В ходе процесса была обнаружена одна программная ошибка, после чего в исходный код были внесены соответствующие исправления. Процесс оказался безболезненным и действительно эффективным. |