Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 12. Технологии оценки трудозатрат на тестирование и советы 287 С. гЬинзнсовон точки з п вния по п ход с использованием спи п эл €5. и п ной модели жизненно- -го цикла обладает определенными преимуществами перед подходом с применением каскадной модели. В таблицу 12.3 сведены самые важные статистические данные каж- дой из частей рассматриваемого примера. Наиболее эффективной моделью для анализируемого примера является многоярусный ! - спиралевидный жизненный цикл, поскольку он обеспечивает более раннюю передачу . результирующего приложения конечным пользователям, определяет необходимый ра- * бочий персонал для каждой стадии приблизительно на год {причем количество сотрудни- .; ков в течение года не изменяется), характеризуется меньшими расходами по сравнению С каскадной моделью и дает возможность воспользоваться преимуществами от совер- • шенствования процесса в каждой стадии по мере продвижения через все пять сборок. TDEV 49 15 17 Часть 1 2 3 Описание 5 сборок, 15KLOC, попарная интеграция 1 сборка, 75 KLOC 5 сборок, 15KLOC, Затраты в миллионах долларов 1,593 1,699 1,593 Максимальное количество персонала 5 14 18 накопительная интеграция Технология функциональных баллов В [1] предложена методология классификации программного обеспечения по разме рам, которая построена на предположении, что производительность разработки программного обеспечения каким-то образом связана с функциональными возмож ностями. Области функциональных возможностей, которые при этом учитываются, называются значениями информационного домена, часть из которых перечислена ниже: • Количество вводов пользователя — подсчет числа вводов пользователя. Учиты вается каждый ввод пользователя, который представляет пользователю отли чающуюся информацию, связанную с приложением. Вводы должны отделяться от запросов, которые учитываются отдельно. 288 Часть II. Технологии быстрого тестирования и советы • Количество выводов для пользователя — подсчет числа выводов для пользова теля. Учитывается каждый вывод для пользователя, предоставляющий отли чающуюся информацию из приложения. В этом контексте под выводами пони маются отчеты, экраны, сообщения об ошибках и тому подобное. Индивиду альные элементы данных внутри отчетов отдельно не подсчитываются. • Количество запросов пользователя — запрос определяется как интерактивный ввод, вызывающий ту или иную немедленную реакцию программного обеспе чения в форме интерактивного вывода. • Количество файлов — учитывается каждый логический главный файл (т.е. ло гически сгруппированные данные, которые могут быть частью крупной базы данных, состоящей из отдельных файлов). • Количество внешних интерфейсов — учитываются все машиночитаемые ин терфейсы (например, файлы данных на некоторых носителях, используемых для передачи в другие системы). Введите полученные числовые значения в столбец "Количество" таблицы, изо браженной на рис. 12.24. На рис. 12.23 представлен первый этап двухэтапного процесса подсчета функцио нальных баллов (function points, FP). Этап 1 начинает исполнитель, имеющий опыт оценки методом функциональных баллов. Исполнитель должен ответить на вопросы специальной анкеты, используя при этом числа, указанные в заголовке анкеты. После получения ответов на все 14 вопросов анкеты, необходимо сложить все числа, пред ставляющие ответы, и передать полученную сумму на следующий шаг. На шаге 2 потребуется перемножить эти числа на соответствующие веса, которые указаны в столбцах, помеченных как "Простой", "Средний" и "Сложный", просумми ровать полученные произведения и поместить сумму в поле "Общая сумма" в соответ ствии с инструкциями, приведенными в начале раздела. И, наконец, воспользуйтесь формулой, показанной в нижней части рис. 12.24. В качестве сомножителя SUM(F i ) необходимо подставить сумму коэффициентов уточнения сложности, полученных на шаге 1. Функциональный балл представляет собой взвешенную метрику индексного типа. предназначенную для изменения объема функциональности программного пакета, каким его видит конечный пользователь. В начале семидесятых, работая в компании IBM, Аллан Альбрехт (Allan Albrecht) ввел понятие функционального балла. Он пола гал, что функциональные возможности программного приложения представляет со бой более важную характеристику размера программного обеспечения, нежели число LOC (Lines Of Code — строк программного кода), которое было тогда традиционной единицей измерения объема программного продукта. Функциональные баллы ставят ся в один ряд с функциями обработки информации, которые поставляются пользова телям. Функциональные баллы представляют собой средство измерения размеров программного продукта, которые не зависят от методов разработки, технологий и языков программирования. Как метрика размеров программного обеспечения, зна чения в функциональных баллах обладают большей надежностью и могут опреде ляться на ранних стадиях жизненного цикла разработки программного продукта. Глава 12. Т е х н о л о г и и о ц е н к и т р у д о з а т р а т на т е с т и р о в а н и е и с о в е т ы 289 FP = общая сумма х [0,65 + 0,01 х SUM(Fj)] Рис.24. Шаг 2 вычисления функциональных баллов Шаг 1 • С каждым вопросом связан коэффициент уточнения сложности Fi, где i = 1 , . . . , 14. Дайте оценку каждого коэффициента по шкале от 0 до 5. (0 = влияние отсутствует; 1 = эпизодическое влияние; 2 = умеренное влияние; 3 = среднее влияние, 4 = значительное влияние; 5 = существенное влияние) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12 13. 14. Требуются ли в системе механизмы резервирования и восстановления? Требуется ли обеспечить обмен данными? Являются ли рассматриваемые функции функциями распределенной обработки данных? Являются ли производительность критическим фактором? Будет ли система работать в условиях существующей, интенсивно используемой операционной системы? Требуется ли в системе интерактивный ввод данных? Требует ли интерактивный ввод данных заполнения транзакции на нескольких рабочих экранах? Производится ли обновление главных файлов в интерактивном режиме? Относятся ли вводы, выводы, файлы или запросы к категории сложных? Относится ли внутренняя обработка к категории сложной? Относится ли разрабатываемый код к категории используемого многократно? Включены ли в проект преобразование и установка? Предназначена ли система для многократной установки в различных организациях? Разрабатывалось ли приложение с целью упростить изменения и облегчить работу пользователя? Рис. 12.23. Коэффициенты уточнения сложности в функциональных баллах Шаг 2 290 Часть II. Технологии быстрого тестирования и советы Метрика в функциональных баллах, равно как и число строк программных кодов (LOC), в определенной степени противоречива. Убежденные противники функцио нальных баллов утверждают, что в этом случае имеет место некоторая подмена поня тий, поскольку рассматриваемые вычисления основаны скорее на субъективных, не жели на объективных данных. Они же утверждают и то, что эти данные с трудом со гласуются с фактическими показателями, полученными по завершении проекта. Кроме того, функциональные баллы не имеют физического содержания, каким обла дает LOC. Сторонники этого метода приводят аргумент в их пользу, что функцио нальные баллы обладают преимуществом независимости от языков программирова ния. Это делает их более ценными по сравнению с числом LOC в отношении языков программирования четвертого поколения, которые являются непроцедурными и не связаны с понятием строки кода. Функциональные баллы можно получить непосред ственно из технических требований, в то время как число LOC может быть получено на момент определения концепций только по аналогии с ранее разработанными про ектами. В настоящее время существует группа IFPUG (International Function Point Users Group— Международная группа пользователей функциональных баллов), которая была создана около десяти лет тому назад с целью стандартизации определений и использования рассматриваемой технологии. Есть и другие организации, занимаю щиеся разработкой программного обеспечения, которые применяют технологию функциональных баллов. В подавляющем большинстве проектов, которые выполняла наша организация, размеры программных продуктов оценивались числом строк про граммного кода, хотя для оценки размеров двух проектов были успешно применены функциональные баллы. При помощи таблицы перевода Кейперса Джонса (Capers Jones), представленной на рис. 12.1, можно перевести функциональные баллы в числа LOC для широкого спектра применяемых в настоящее время языков программи рования. Резюме В процессе планирования работ по выполнению проекта программного продукта необходимо решить следующие задачи: • Выбрать жизненный цикл разработки программного обеспечения. • Достичь глубокого понимания предварительных требований и основных огра ничений. • Спрогнозировать трудозатраты и календарный график работ, а также дать оценку размеров и затрат средств на разработку, взяв за основу статистические данные по существующим программным продуктам. • Воспользоваться подходом "разделяй и властвуй" с целью распределения задач среди предполагаемых исполнителей в соответствии с их квалификацией. Соответствующий процесс получения оценки предусматривает следующие дей ствия: • Сбор входной информации, в том числе построение матрицы оценки размера программного обеспечения, и принятие решений относительно жизненного цикла разработки. Глава 12. Технологии оценки трудозатрат на т е с т и р о в а н и е и советы 291 • Получение оценки общих трудозатрат (в часах) на основе статистических дан ных по существующим программным продуктам. • Распространение оценки общих трудозатрат на каждую задачу и каждый рабо чий график, соблюдая при этом границы основных стадий. Если возможно, оценку трудозатрат необходимо распространить и на различные сборки спи ральной модели жизненного цикла. • Документирование в ф о р м е электронной таблицы каждой задачи, трудозатрат на ее выполнение, графиков работ, включая информацию о базисе оценок и списки реальных условий, в которых реализуется жизненный цикл. • Пересмотр оценок для передачи их руководству и выполнение предложенных коррективов в соответствии с действующими требованиями. Примеры выполнения быстрого тестирования Пример формулирования требований Глава 2 была посвящена процессу определения требований. В ней же приводилась диаграмма процесса формулирования требований, которая для удобства показывает ся еще раз на рис. 13.1. В документе определения требований все системные требования излагаются на обычном разговорном языке. В результате упрощается работа с документом со сторо ны заказчиков, что позволяет их привлекать к процессу разработки продукта. Вход ными данными для документа определения требований является набор требований, сформированный в течения взятия неформальных интервью у заказчиков. Кроме того, проводятся более строгие совещания и целенаправленные сеансы, посвящен ные совместной разработке требований к приложению (JAR); организация JAR- сеансов подробно рассматривалась в главе 8. Опрос заказчика с целью выявления требований, которые он предъявляет к программному продукту • Интервью • Технология FAST Подготовка документа, содержащего определения требований • Документ, содержащий определения требований, составлен на естественном языке, вполне понятном заказчикам, пользователям, коллективам разработчиков и специалистам по тестированию Подготовка спецификаций требований • Спецификация требований (функциональная спецификация) изложена на языке, который дает возможность использовать его для проектирования и реализации системы Подготовка матрицы прослеживаемое™ требований • Матрица прослеживаемое™ требований ставит в соответствие каждому требованию тесты, проектные компоненты и программные коды •) Пересмотр требований • Воспользуйтесь статическим тестированием для проверки полноты, непротиворечивое™, осуществимости и контролепригодности требований и подтвердите, что требования удовлетворяют потребностям пользователя -• На стадию проектирования Рис. 13.1. Процесс формулирования требований Глава 13. Пример формулирования требований 295 В главе 2 упоминалось о том, что определениям требований присущи следующие характеристики: • Каждое требование должно быть снабжено уникальным идентификатором, чтобы можно было однозначно ссылаться на него при планировании тестового покрытия, при проектировании тестовых случаев и в отчетах по результатам тестирования. • Требования должны быть представлены с точки зрения пользователя системы. Системные и приемочные испытания должны быть.спроектированы на основе определений требований, следовательно, эти определения должны быть сфор мулированы в перспективе системного уровня. Этот принцип препятствует по явлению требований, затрагивающих внутренние свойства системы и требую щих детальных знаний программного кода для успешного тестирования. Такие требования должны возникать на поздних стадиях разработки и охватываться модульным тестированием и проверкой взаимодействия и функционирования компонентов системы. • Должны быть включены как функциональные (functional), так и нефункциональные (nonfunctional) требования. Функциональные требования суть требования, опи сывающие услуги и функции, которые должна выполнять разрабатываемая сис тема. Нефункциональные требования описывают ограничения, накладываемые на работу системы, например, количество одновременно работающих пользо вателей, и стандарты, которым должна соответствовать система. • Документ определения требований должен находится под управлением конфи гурациями. Это, по меньшей мере, означает, что данный документ подпадает под управление версиями и что все версии документа должны быть помещены в безопасное хранилище, подобное, например, каталогу, содержимое которого обычно дублируется. Если требования подвергаются изменениям, мы должны иметь возможность проследить, чтобы соответствующие изменения были вне сены в тестовые случаи системных и приемочных испытаний. Структура документа определения требований может основываться на специфи кациях, определенных в стандарте IEEE Standard 830: The IEEE Guide to Software Require ments Specifications (дополнительные сведения по применению этого стандарта можно найти в главе 2). Сейчас мы предлагаем приступим к изучить пример документа определения тре бований, который был подготовлен для вымышленного набора инструментальных средств управления тестированием (Test Management Toolkit, ТМТ). Это приложение позволяет менеджерам и инженерам, специалистам в области тестирования управ лять планами тестирования, отчетами о дефектах, результатами тестирования, а так же другой информацией, связанной с тестированием программного обеспечения. ТМТ представляет собой Web-приложение, благодаря чему несколько географически удаленных пользователей могут одновременно участвовать в нескольких проектах по тестированию. Проект разработки приложения Т М Т приводится в качестве приме ра, который рассматривается на протяжении всей третьей части книги. В следующей главе содержится пример плана тестирования, который основан на требованиях к приложению ТМТ, определенных в данной главе. Определение требований ТМТ TMT-RD-10 Идентификатор документа: TMT-RD-10 Версия: 0.8 Автор: Крис Браун (Chris Brown) Набор инструментальных средств управления тестированием Версия 1.0 Определение требований Хронология версий Версия Дата Автор Описание 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 08/31/2001 09/02/2001 09/02/2001 09/03/2001 09/03/2001 09/03/2001 09/07/2001 09/07/2001 Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Эскиз документа определения требований для ТМТ Добавлена возможность управления проектами, выполнена доводка Расширена структура данных, выполнена доводка Добавлена возможность создания матрицы прослеживаемости требований Добавлены экраны справки В структуру данных добавлено поле Project Name (Название проекта) Добавлено требование многопользовательской поддержки Добавлена многопользовательская поддержка в индексный раздел 3 Утверждено Дата утверждения Маркетинга Программирования Тестирования Чак Д. Клут (Chuck D. Klout), директор отдела маркетинга Сюзанна Перл (Suzanna Perl), менеджер отдела программирования Брит Гейтер (Bret Gater), менеджер отдела тестирования 09/07/2001 09/09/2001 09/09/2001 296 Определение требований ТМТ TMT-RD-10 Содержание 1. Введение 298 1.1. Назначение 298 1.2. Область применения 299 1.3. Обзор 299 2. Общее описание 299 2.1. Перспективы применения продукта 299 2.2. Функции продукта 299 2.2.1. Тестовые планы 299 2.2.2. Список прогона 299 2.2.3. Тесты 299 2.2.4. Выполнение тестов 299 2.2.5. Отчеты об ошибках 300 2.2.6. Итоговые отчеты 300 2.2.7. Резервное копирование и восстановление 300 2.2.8. Безопасность 300 2.2.9. Удаленное администрирование 300 2.2.10. Матрица прослеживаемое™ требований 300 2.3. Пользовательские характеристики 300 2.4. Общие ограничения 300 2.5. Допущения и зависимости 300 2.5.1. Операционные системы 301 2.5.2. Браузеры 301 2.5.3. Реляционные базы данных 301 2.5.4. Сервер Web-страниц 301 2.5.5. Зависимость от процессора 301 |