Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 10. Технологии динамического тестирования и советы 231 Еще одним примером блокирующей ошибки, которая также влияет на поток дан ных, может послужить оператор: IF (I > J) THEN B ( I ) = A ( J ) ELSE B ( I ) = 0 ENDIF. Если символ операции "больше чем" (>) указан по ошибке и вместо него должен присутствовать символ операции "меньше или равно" (< = ), обнулится неверная часть массива В. Все вычисления, следующие за этим оператором IF будут иметь дело с эти ми обнуленными значениями В, в то время как они должны выполняться с ненулевы ми значениями, скопированными из массива А. Это означает, что все результаты тес та, зависящие от В, окажутся неверными. Поэтому тестировщик не сможет опреде лить, содержит ли ошибки остальная часть программы (та, что следует за показанным оператором IF). Тестировщик мог бы проследить поток данных для всех значений I и J или их некоторого поднабора. Имея информацию о потоке данных через несколько процессов, специалист по тестированию может извлекать промежуточные результа ты, тем самым ускоряя процесс выявления и последующего воссоздания ошибок. Тестирование на предмет утечек памяти Утечка памяти — это тип ошибки, которая приводит к тому, что приложение посте пенно заполняет всю виртуальную память, управляемую операционной системой. Множество современных языков организуют в виртуальной памяти стек и кучу, обес печивая более эффективное и удобное управление временной областью памяти. Утечки памяти имеют несколько других названий, в числе которых паразитное рас пределение памяти, разрушение стека, разрушение памяти, квазипереполнение. Ос новная причина возникновения ошибки утечки памяти — невозможность освобожде ния виртуальной памяти, которая динамически запрашивается приложением. Не су ществует никаких внешних средств устранения утечки памяти, за исключением избе жания рабочей области приложения, вызывающей утечку памяти. Большинство со трудников служб технической поддержки просто рекомендуют прервать выполнение приложения или перезагрузить операционную систему. На рис. 10.5 показан пример сообщения группы технической поддержки компании Microsoft относительно утечки памяти в поступившей в продажу версии операционной системы Windows 95. Компания Microsoft поместила средства обхода и исправления этих ошибок утеч ки памяти на соответствующие Web-сайты. Как правило, утечка памяти происходит в небольшой функции, которая правиль но написана для своей удачной ветви, но неправильно — для неудачной ветви. Если вы деление виртуальной памяти выполняется во время запуска функции, но ввод данных пользователем приводит к прерыванию программы, обработчик ошибок для данного прерывания может быть не запрограммирован для освобождения виртуальной памя ти. Независимо от того, велик или мал объем выделяемой памяти, повторяющийся характер функции, в конечном счете, обусловит уменьшение объема доступной вир туальной памяти, и программа больше не сможет функционировать. Особенно уяз вимы в этом отношении приложения, которые выполняются круглосуточно в тече ние всех семи дней недели. Даже самые малые утечки памяти со временем приведут к разрушению программы или системы. 232 Часть П. Технологии быстрого тестирования и советы УТЕЧКА ПАМЯТИ В ЯДРЕ WINDOWS 95 ПРИ ИСПОЛЬЗОВАНИИ СОКЕТОВ WINDOWS СИМПТОМЫ При запуске программы, которая использует сокеты Windows, в среде Windows 95 со временем может происходить увеличение объема памяти, используемой операционной системой, особенно если программа открывает и закрывает множество каналов. ПРИЧИНА Ядро Windows 95 (Kernel32.dll) содержит ошибку, которая препятствует корректному освобожде нию определенных небольших структур данных, связанных с процессами сокетов Windows и вы деленными каналами. Со временем эти небольшие утечки памяти могут приводить к существен ному уменьшению объема доступной памяти. Имейте в виду, что ресурсы, связанные с программой, можно освободить, закрыв программу. По сле выхода из программы и перезапуска Windows 95 память освобождается. Рис. 10.5. Поступившая в продажу версия Windows 95 с утечками памяти операционной системы. Утечки памяти особенно трудно выявить в объектно-ориентированных исходных кодах. Тем не менее, при помощи трассировки и отслеживания гистограммы объектов (Object Histogram), разработчик может выяснить, какой объект выделяет и освобождает память и какие вызовы присутствуют между этими вызовами диспетчера памяти. Пе ред загрузкой и запуском сомнительной Java-программы саму среду следует запустить с параметром -tracepopulation. Как только объект, вызывающий утечку памяти, локали зован, не забудьте воспользоваться технологией статического тестирования для ус корения выяснения основной причины. Еще важнее разобраться в коде и любых воз можных прерываниях в удачной ветви, которые могут помешать объекту освобождать память. В C++ существует объект debug_malloc, который может оказаться очень полез ным для трассировки утечки памяти. Хотя утечки памяти не носят перемежающийся характер, о н и быстрее проявляются в бездисковых системах с небольшим объемом памяти, нежели в конфигурациях с большим объемом оперативной памяти и диско вого пространства, перезагрузка которых выполняется редко (например, в с е р в е р ных приложениях). Исходя из концепции быстрого тестирования, можно дать следующий совет. Как только разработчик обнаружил и устранил утечку памяти, он должен проверить но вый код на предмет наличия в этой области других ошибок, могущих привести к утечкам памяти. Достаточно часто, столкнувшись с первым проявлением ошибки, разработчик считает ее единственной, упуская из виду другие ситуации, когда этот же код может не освобождать динамически распределяемую память. Этот совет проти воречит также призывам большинства инструкторов по тестированию и менеджеров конфигурации заниматься устранением только той проблемы, которая указана в от чете об ошибке. Если вы хотите следовать советам по быстрому тестированию, ино гда приходится отказываться от трафаретного подхода и просто заниматься п о в т о р ным проектированием и реализацией приложения. Глава 10, Технологии динамического тестирования и советы 233 Тестирование интерфейса "человек-компьютер" Интерфейс "человек-компьютер" (human-computer interface, HCI) в современных компьютерах может охватывать широкое множество различных периферийных уст ройств, таких как клавиатура, клавишная панель, мышь, световое перо, монитор с сенсорным экраном, речевой интерфейс, сканер и многие другие. Кроме того, в слу чае использования больших систем управления производством, работающих на осно ве больших вычислительных машин, для работы с программой может требоваться большое количество операторов, каждый из которых имеет собственный персональ ный компьютер, действующий как терминал большой вычислительной машины. Планирование тестирования исключительно важно для координации тестирования интерфейса "человек-компьютер", поскольку, возможно, это — единственное тести рование, при котором продукт рассматривается полностью с точки зрения пользова теля. Через этот интерфейс доступны для тестирования многие функциональные тре бования пользователя, а именно это и есть основная цель системных испытаний. П р и использовании интерфейса "человек-компьютер" для выполнения тестиро вания с точки зрения пользователя следует учитывать одно важное обстоятельство. Если команда тестирования начинает тестирование с этапа системных испытаний и при этом интенсивно использует интерфейс "человек-компьютер", диапазон тести рования будет очень ограничен. Тестирование интерфейса "человек-компьютер" — лишь один из множества способов выполнения быстрого тестирования с целью об наружения ошибок. Фактически, как правило, процесс тестирования интерфейса "человек-компьютер" оказывается не слишком эффективным при поиске даже наибо лее общих ошибок, поскольку этот процесс больше ориентирован на проверку мар шрута прохождения потока данных по продукту, а этот маршрут уже подвергался ин тенсивному поблочному тестированию, выполняемому по тщательно разработанным сценариям. П р и организации тестирования интерфейса "человек-компьютер" всегда полезно, чтобы с членами команды тестирования сотрудничал администратор баз данных и несколько конечных пользователей. О н и могут разрабатывать тестовые случаи, сце нарии тестирования и методику обработки результатов тестирования для проверки правильности отображения входных данных на экране. Далее такая информация со храняется в соответствующих записях базы данных, обрабатывается и участвует при составлении отчетов. Администратор баз данных и пользователи могут также созда вать тестовые случаи, сценарии тестирования и методику обработки результатов тес тирования для проверки правильности форматирования выходных данных и их пе редачи на соответствующий носитель или в коммуникационные буферы. Конечные пользователи могут оказать существенную помощь, сотрудничая с груп пой тестирования при разработке объективного приемочного теста. В больших ор ганизациях существует должность бизнес-аналитика. Как правило, бизнес-аналитик выполняет роль своего рода конечного пользователя, который оплачивает работы из фонда проекта и организует тестирование интерфейса "человек-компьютер", при званное определить приемлемость данной версии программного обеспечения. Приемочные тесты, выполняемые конечными пользователями, как правило, будут выполняться в соответствии с определенным сценарием и будут исследовать только 234 Часть II. Технологии быстрого тестирования и советы удачные ветви программы. Тестовые случаи, сценарии тестов и методики обработки результатов тестирования, разработанные конечными пользователями, могут быть не такими строгими, как применяемые в ходе выполнения проекта. Но, несмотря на это, найденные ими ошибки документируются, исправляются и повторно тестируют ся командой тестирования. Затем внесенные изменения, ориентированные на ис правление ошибок, снова тестируются конечными пользователями в ходе дополни тельных приемочных испытаний. С другой стороны, для обеспечения высокой на дежности версии программы и того, чтобы тестовые случаи, сценарии тестов и мето дики обработки результатов тестирования отражали основные случаи использова ния, тестирование, предпринимаемое бизнес-аналитиком, должно охватывать как удачные, так и неудачные ветви. Тестирование нагрузочной эффективности Эффективный с точки зрения затрат способ расширения приложений заключается в использовании распределенных вычислений. Существует два основных компонента сетевой архитектуры: сервер и клиент. Сеть может иметь тысячи серверов и десятки тысяч настольных персональных компьютеров, переносных компьютеров, беспро водных и карманных клиентов, каждый из которых подключается к серверам по сети. Системы клиент/сервер являются одними из наиболее широко распространенных, и огромная доля выполняемого в наши дни тестирования связана со средами типа кли ент/сервер/сеть. Тестирование требований безопасности и доступа относится ско рее к тестированию системы, чем к тестированию приложения. Для баз данных могут потребоваться процессы создания экземпляров, поскольку приложение, выполняю щееся в одном городе/стране, при запросе базы данных должно получать те же ре зультаты, что и это же приложение, одновременно выполняющееся в другом горо де/стране. Тестирование приложений типа клиент/сервер требует глубокого понимания ар хитектуры программного обеспечения, в том числе серверов хранилищ данных, ха рактеристик путей передачи информации и серверов балансирования нагрузки. Час то для успешности тестирования первостепенную важность имеет определение тес товых данных. В этом разделе приведены лишь несколько примеров, но соответст вующие аналогии можно найти и в других приложениях. При тестировании приложений, в которых интенсивно используется обмен дан ными, должны применяться два подхода: использование тестовых шаблонов и ран домизированных потоков данных. Если основной целью тестирования является про верка надежности коммуникационного пути, то можно задействовать тестирование с использованием шаблонов. Выявить искажение в повторяющемся графическом шаб лоне значительно легче, чем просматривать распечатку со значениями данных для выяснения того, присутствует ли в них какая-то ошибка. Инженеры по электронике аналогичным образом используют осциллографы, просматривая осциллограммы сигналов тестовых частот для проверки правильности функционирования соедине ния или процесса. Специалисты по тестированию должны использовать эту техноло гию в ходе процесса самотестирования коммуникационного пути во время начально го запуска системы. Как только коммуникационный путь проходит процесс самотес тирования при начальном запуске, по нему можно передать заранее известный набор Глава 10. Технологии динамического тестирования и советы 235 данных транзакции, что позволит проверить правильность выполнения транзакции и производительность процессора транзакций. Выходные данные, сохраненные в выходных записях или журнальных файлах, можно автоматически сравнить с ожи даемыми результатами. Как правило, такие тесты разрабатываются в форме регрессивных тестов для систем выполнения транзакций, которые постоянно обновляются из-за добавления в производственную среду новых транзакций. Приложения клиент/сервер поддерживают возможность применения тестовой конфигурации, в которой программируются и загружаются сервер эмуляции высоко го темпа передачи данных и тестовый эмулятор хранилища данных. При такой кон фигурации можно проводить испытания банка производственных серверов, которые подключаются к системе через сервер балансирования нагрузки, как показано на рис. 10.6. Сервер имитации высокого темпа прогоняет данные транзакций по альтерна тивному пути к серверу балансирования нагрузки, который, в свою очередь, прогоня ет эти данные через банк производственных серверов со скоростью, превышающей обычные рабочие скорости передачи данных. Этот тест может выявить узкие места с точки зрения производительности. При наличии ветви обратной связи от тестового эмулятора хранилища данных к серверу имитации высокого темпа передачи, воз можно автоматическое сравнение выходных данных транзакций производственного сервера с ожидаемыми выходными данными тестов. Эта замкнутая система может использоваться для проведения лабораторных испытаний новых версий перед их погружением в производственный процесс. Данная технология непосредственно применима и к большинству Web-приложений. Эмулятор высокого темпа передачи данных Рис. 10.6. Сервер имитации высокого темпа передачи данных и тестовый эмулятор храни лища данных испытывают производственное приложение с архитектурой клиент/сервер. 236 Часть П. Технологии быстрого тестирования и советы та-| юп-4 тес-4 • ПРИМЕР: СОЗДАНИЕ ТЕСТОВЫХ ДАННЫХ (ГЭРИ КОББ) Когда я работал в составе группы разработки программного обеспечения (Software En- gineering Process Group, SEPG), ко мне подошел один из инженеров по тестированию и спросил, что мне известно о силах Кориолиса. Я сообщил ему, что, насколько мне из- вестно, это сила, возникающая в результате вращения Земли, которая оказывает влия- ние на любое движущееся тело на ее поверхности или в толще земной к о р ы , вызывая отклонение от курса. Мы говорили о том, что силы Кориолиса вызывают отклонение су- дов и самолетов вправо от курса в северном полушарии и влево — в ю ж н о м . Эта сила оказывает также влияние на морские и воздушные течения. Инженер по тестированию спросил меня, не согласился бы я помочь в создании входных данных для тестовых случаев, которые будут использоваться во время тестирования не- давно разработанной бортовой системы прогнозирования погоды. Я согласился и решил при разработке данных воспользоваться электронными таблицами. Одной из причин та- кого выбора послужило то, что в электронных таблицах все числовые вычисления выпол няются в 64-разрядном модуле арифметических операций с плавающей точкой. Все тес товые данные, которые были нужны инженеру по тестированию, показаны на рис. 10. G E O S T R O P I C W I N D C O M P U T A T I O N D U E T O C O R I O L I S CONSTANTS: EARTH RADIUS (3437.911nm*1852.44m/nm) 6368523.85284 m EARTH'S GRAVITY 9.8 m/sec**2 EARTH'S ANGULAR VEL. ("Omega") 7.2920E-05 per second DEFINE AREA OF INTEREST (AOI): CENTER OF AOI С. LA С.LO CENTER (DEGREES) 30.199998 -97.800000 CORIOLIS FORCE AT CENTER OF AOI 7.33 60E-05 per second AOI WIDTH (3200nm*1852.44m/nm) 5927808 m M=MESH=l/64 5788.875 m resolution GRID SIZE 1024 X 1024 DL = DELTA LONGITUDE (DEGREES) = (AOI WIDTH)/((PI/180)*(EARTH RADIUS)) DL 53.330785596795 degrees AOI POINTS: CENTER(C) (AUSTIN) EAST(R.C.X) NORTH(U.C.X) WEST(L.C.X) SOUTH (L.C.X) CENTER(C) (AUSTIN) EAST(R.C.X) NORTH(U.С X) WEST(L.C.X) SOUTH (L.C.X) x.LA x.LO 30.199998 30.199998 56.865391 30.199998 3.534605 MX 0 -0.46539890067 0 0.4653989006696 0 -97.800000 -124.465392 -97.800000 -71.134607 -97.800000 MY 0.553340844437 0.553340844437 1.212368963348 0.553340844437 0.061729665232 ANGLE SUBTENDED BY ARC 100 NM LONG ON THE EARTH SURFACE: Глава 10. Т е х н о л о г и и д и н а м и ч е с к о г о т е с т и р о в а н и я и с о в е т ы 237 Ю О п т * (1852. 44m/nm) / (earth radius (m) ) * (180/PI) Angle(deg) 1.6665870498998 degrees SCALE FACTOR(SF)= MD/SD = ABS(U.С.MY-L.С.МУ)/SY.MAX SF = 0.00112477 (earth radii) AOI CORNERS: U.LE.X U.RI.X L.LE . X L.RI.X x.LA 29.36670447505 31.03329152495 9.36670447505 28.5334109501 x.LO -96.9667059751 -98.6332930249 -96.9667059751 -98.6332930249 U.LE.X U.RI.X L.LE.X L.RI.X MX -0.575319649058 0.5753196490579 -0.575319649058 0.5753196490579 MY 1.212368963348 1.212368963348 0.061729665232 0.061729665232 BOX CENTERS (DEGREES) ENTER BOX EAST BOX NORTH BOX WEST BOX SOUTH BOX x.LA 33.3166666667 33.3166666667 35.0833333333 33.3166666667 31.5833333333 x.LO 113.7500000000 111.6166666667 113.7500000000 115.8166666667 113.7500000000 MX CENTER BOX EAST BOX NORTH BOX WEST BOX SOUTH BOX -0.037233690709 MY 0.617329479414 0.617329479414 0.654613029744 0.0360701378745 0.581477015532 dX=ABS(DELTA LON.)*(EARTH RADIUS IN m)*COS(LAT.IN RAD.)*(PI/180) East-West dX 390111.37991131 m dY=ABS(DELTA LAT.)*((EARTH RADIUS IN m)*PI/180) North-South dY 389030.98403348 m Test Case 1. Assume following heights of the 300 Mb constant pressure field: CENTER BOX 9000 EAST BOX 9100 NORTH BOX 9100 WEST BOX 8900 SOUTH BOX 8900 GEOSTROPHIC WIND VECTOR COMPONENTS (Ug directed East, Vg directed North) Ug = -(GRAVITY/(2*OMEGA*SIN(LAT.(RAD)))*(PARTIAL OF H WRT Y) = Ug (in m/sec) -62.72030217113 -51.39 Vg = (GRAVITY/(2*OMEGA*SIN(LAT.(RAD)))*(PARTIAL OF H WRT X) Vg (in m/sec) 62.89448561333 51.69 Рис. 10.7. Тестовые данные для учета влияния сил Кориолиса. 238 Часть II. Технологии быстрого тестирования и советы Использование таких электронных таблиц при разработке данных для тестовых случаев дает явные преимущества. Как только подтверждается достоверность этих вычислений, они могут повторно использоваться для вычисления тестовых результа тов в других интересующих областях. Тестирование конфигурации платформы Вариации в конфигурации существенно осложняют тестирование. Одним из таких осложняющих факторов могут рассматриваться п е р и ф е р и й н ы е устройства. Каждое периферийное устройство поставляется с драйвером фирмы-изготовителя, который выбирается из набора драйверов для различных операционных систем. Именно по этому персональные компьютеры являются персональными. Из-за сложности и высо кой стоимости операционных систем и п е р и ф е р и й н ы х устройств тестирование при ложения для всех возможных конфигураций персональных компьютеров оказывает ся слишком дорогостоящим. Тестировщик, занимающийся быстрым тестированием, должен относится к нему, как к тестированию ветвей, где полный охват не возможен, и применять тестовые случаи только к преобладающим комбинациям операционных систем и периферийных устройств. Для того чтобы упростить управление набором тестовых платформ, можно вос пользоваться технологией разработки матрицы тестовых конфигураций, которая ускоряет планирование и реализацию процесса тестирования и способствует органи зации процесса составления отчета по результатам. Предлагаемый формат матрицы тестовых конфигураций показан в таблице 10.3. Элементы, приведенные в столбцах HI и Н2, должны иметь подробные спецификации файла, описывающего номера версий программно-аппаратного обеспечения и положений переключателей для лю бого реконфигурируемого оборудования. Если матрица платформ большая и сложная, она может быть базой данных, обес печивающей датирование транзакций и регистрацию в журналах для реализации управления конфигурациями. Для отражения изменений в аппаратном обеспечении можно с заданной периодичностью выполнять проверки этой матрицы, призванные дать ответ на вопрос: выполняется ли тестирование оборудования на самых совре менных платформах, занимающих такое же место на рынке, как и тестируемый про граммный продукт? Эта матрица или база данных тестовых конфигураций должна совместно использоваться всеми партнерами, несущими ответственность за тестиро вание конечного программного продукта. Обычно при поставке программного продукта на общий потребительский рынок принято перечислять основные требования к платформе. Пример требований к платформе, указываемых при поставке на потребительский рынок, приведен в таб лице 10.4. И н ф о р м а ц и я из этой таблицы не совпадает с данными, приведенными в матрице тестовых конфигураций. Например, при указании операционной системы для тестовой конфигурации необходимо упоминать номер версии и уровень сервис ного пакета. Кроме того, жесткие диски должны указываться вместе с названием фирмы-изготовителя, версии программно-аппаратного обеспечения, версии драйве ра и любых других параметров. Тестировщикам придется разработать отрицатель ные тесты для нескольких конфигураций с отсутствующими или неподходящими компонентами. Это даст возможность задокументировать то, как приложение обра батывает каждую из неподдерживаемых конфигураций. Глава 10. Технологии динамического тестирования и советы 239 Таблица 10.3. Матрица тестовых конфигураций Прочее (дополнительные ID Компоненты Н1 Н2 столбцы) 1 Аппаратное РС-100, Pentium III PC-100, Pentium III обеспечение 2 Операционная Linux 7.0 Windows Win98SE, SP-2 система 3 Клавиатура Happy Hacking Lite Standard Querty 4 Клавишная панель 5 Мышь IntelliPoint Трехкнопочная мышь 6 Перо 7 Сенсорный экран HP 8 Речевой интерфейс Via 9 Сканер Plustek 10 Модем Psion V.90 Xircom 56 бод 11 База данных MS Access Oracle 7.0 12 Объект Build 2.4.3 Build 2.4.4 тестирования 13 Добавьте дополни тельные элементы, вставив дополни тельные строки Таблица 10.4. Основные требования к платформе ID Системные требования 1 Рекомендуется использовать ПК с процессором Pentium 166 (или более производительным) 2 Microsoft Windows 95, 98 или NT 3 30 Мб свободного дискового пространства 4 Не менее 32 Мб свободного пространства в ОЗУ 5 Клавиатура и устройство указания 6 Дисковод CD-ROM (рекомендуется использование 4-скоростного или более производительного дисковода) 7 Видеоплата, обеспечивающая цветовое разрешение 16 бит или TrueColor 8 Звуковая плата, совместимая с Microsoft Windows 9 Драйверы MCI и видеодрайверы 10 Принтер (не обязательно) 11 Доступ к Internet (не обязательно) I 240 Часть II. Технологии быстрого тестирования и советы Резюме В дополнение к технологиям и советам по статическому тестированию, упомянутым в главе 9, в главе 10 освещены дополняющие их технологии и советы по динамическо му тестированию. Каждый специалист по тестированию должен поэкспериментиро вать с этими технологиями и оценить, насколько каждая из них применима для кон кретных целей тестирования. Неплохо описать собственный опыт по использованию новой технологии и добавить этот материал к рассмотренному в данной главе. В этой главе было показано, что несмотря на то, что много участников тратят массу времени на тестирование продукта с точки зрения пользователя и с помощью графического интерфейса, существует ряд очень важных тестовых случаев, которые должны быть разработаны с целью оценки аспектов продукта, отличных от графического интер фейса. Расширяемость, устойчивость к ошибкам, пригодность к высокому темпу пе редачи данных, возможность использования в средах поврежденных платформ и точность результатов считаются наиболее важными областями выявления ошибок в конечном продукте. Параллельное выполнение тестовых случаев требует координи рования и, в ряде случаев, участия назначенного координатора тестирования. При менение технологий статического тестирования к результатам тестирования для тща тельной их проверки на предмет возможных ошибок представляется разумной тратой времени на последнем этапе разработки. Памятуя об этом, приходится лишь удивляться, когда известие в какой-то органи зации о том, что продукт прошел приемочные испытания, вызывает восторг, а зачас тую и удивление. Так не должно быть. Каждый член команды разработки должен не сти достаточную ответственность за выполнение тестирования, чтобы иметь уверен ность в том, что конечный продукт полностью соответствует требованиям пользова телей, и в будущем будет способствовать процветанию организации. Разработка и использование показателей тестирования: моделирование и прогнозирование ошибок Темы, рассматриваемые в главе: О Определение показателей и данных измерений • Использование стандартных показателей для внесения усовершенствований Q Показатели тестирования • Проектно-ориентированная модель ошибок • Программа оценки ошибок программного обеспечения (SWEEP) • Резюме При планировании нового проекта кто-то обязательно задает вопрос: "А где какие- либо фактические данные наших предшествующих проектов?" Может возникать и вопрос: "Какая связь между планом и данными измерений?" План полезен только в том случае, если он расходится с действительностью не более чем на +/-20%. Данные измерений полезны, только если они применимы к проекту, условия которого анало гичны условиям предыдущего проекта, когда эти данные были получены. Представьте себе, что вы являетесь владельцем небольшой океанской яхты и со бираетесь плыть из Атлантик-Сити, Нью-Джерси, на Багамы. Вам пришлось бы по добрать карты атлантического побережья с отображением морских путей, глубин, портов и маяков. Вам потребовалось бы выбрать маршрут и подсчитать время путе шествия с учетом быстроходности яхты и любых ограничений скорости, указанных в навигационных картах. При планировании необходимо выполнить ряд вычислений с учетом скорости расходования различных припасов. Вам следовало бы решить, сколько человек планируется взять с собой в путешествие. Промежуточные результа ты, подобные количеству дней путешествия, определяют количество порций завтра ков, обедов или ужинов, которые потребуются, чтобы прокормить присутствующих 242 Часть II. Технологии быстрого тестирования и советы на борту яхты людей. В соответствии с этим планом вы запасетесь соответствующим количеством топлива, питьевой воды, пищи и других припасов. Эта информация на ходит свое отражение в навигационном и продовольственном планах, в судовой дек ларации и карте маршрута. В море капитан яхты будет сверяться с навигационным планом, записывая такие данные измерений, как скорость и текущий курс. На основе этих данных он вычисля ет время, когда следует начинать высматривать конкретный порт или маяк. Назначе ние этого набора фактических данных измерений состоит в привязке навигационно го плана к известным пунктам маршрута. Отслеживая эти данные измерений и срав нивая их с контрольными пунктами, капитан может ответить на такие наиболее ти пичные вопросы, как "Мы еще не сбились с курса?" или " Н е выбились ли мы из графика?". Применительно к проектам разработки программного обеспечения процесс пла нирования заключается в объединении выбранного жизненного цикла разработки и его этапов (навигационные карты и маршрут), набора функциональных требований (протяженность путешествия в милях), нормативов по количеству строк кода, кото рые должны быть созданы за час работы (предварительно определенная скорость яхты, выраженная в м и л я х / ч ) , графика загрузки персонала по месяцам (маршрут) и промежуточных сроков выполнения проекта (маяки и порты). В ходе разработки руководитель проекта фиксирует фактические данные, напри мер, полученные в течение текущей недели данные по количеству вариантов исполь зования, количеству строк кода, количеству обнаруженных и устраненных ошибок и процентному отношению выполненных тестовых случаев к общему их количеству. Кроме того, руководитель разработки программного обеспечения просматривает план проекта и его календарный график, чтобы иметь возможность ответить на ти пичный вопрос: "Не срываются ли сроки выполнения проекта?" В главе 11 приведены определения показателей и описаны способы сбора и ана лиза данных измерений. Глава 12 посвящена вопросам определения необходимого штата и календарного графика выполнения работ для стандартного жизненного цик ла с использованием стандартной модели оценки затрат. Концепция быстрого тести рования предполагает применение программных показателей, разработанных на ос нове сбора и использования данных измерений, полученных в ходе выполнения пре дыдущих проектов быстрого тестирования. В результате достигается постоянное со вершенствование процессов, повышение качества, снижение затрат и сокращение плановых сроков поставки продукта. Определение показателей и данных измерений Программный показатель — это стандартный способ измерения какой-либо характе ристики процесса разработки программного обеспечения. Данные измерений — это числовые данные, собранные и зафиксированные в единицах измерения, определен ных для показателя. Например, если показателем является количество скрытых оши бок на тысячу строк кода (К lines of code, KLOC), то набор данных измерений мог бы выглядеть следующим образом: {Программа А: 2,6 ошибок/KLOC; программа В: 12,1 ошибок/KLOC; программа С: 5,8 ошибок/KLOC}. |