Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 464
Скачиваний: 1
СОДЕРЖАНИЕ
Роль тестирования в процессе разработки
Фазы жизненного цикла тестирования программного обеспечения
Измерения в процессе тестирования. Польза измерений
Польза измерений при тестировании программного обеспечения
Показатели, характеризующие стоимость тестирования
Показатели, характеризующие стратегию тестирования
Метрики для этапа планирования тестирования
Метрики для показателей этапа тест-дизайна
Метрики для оценки качества тестирования
Метрики для оценки стоимости тестирования
Метрики для оценки объема тестирования
Метрики для оценки стратегии тестирования
Измерение комбинаций техник тестирования
Оценка адекватности тестовых данных
Польза и правила применения метрик в процессе тестирования
-
Метод соотношения персонала на проекте
Метод соотношения персонала на проекте вычисляет процент, который должна составлять по численности команда тестирования, от общего числа персонала на проекте. В таблице 8 представлены расчеты размера тестовой команды, используя метод соотношения персонала на проекте на уровне тестирования интеграции и системы [7]78.
Таблица 6. Численность команды тестирования. Метод соотношения
Тип разработки | Число сотрудников на проекте | Процент команды тестирования | Число тестировщиков |
Коммерческий продукт для крупного рынка | 50 | 27% | 13 |
Коммерческий продукт для небольшого рынка | 50 | 16% | 8 |
Коробочный программный продукт | 50 | 14% | 7 |
Государственное (внутреннее) приложение | 50 | 11% | 5 |
Корпоративное (внутреннее) приложение | 50 | 14% | 7 |
Приложение для индивидуального клиента | 50 | 10% | 5 |
-
Метод расчета оценки трудозатрат с помощью тестовых процедур
Метод расчета оценки трудозатрат с помощью тестовых процедур использует для расчета такие артефакты тестирования как число запланированных тестовых процедур, чтобы оценить количество человеко-часов и число необходимых тестировщиков. Этот метод сравнительно менее эффективен, поскольку он полностью зависит от количества тестовых процедур, запланированных и выполненных. Применение метода требует предварительной подготовки. Она включает в себя разработку списка прошлых проектов, включая данные, относящиеся к размеру (например, число функциональных точек, количество тестовых процедур) и трудозатраты, измеренные с точки зрения человеко-часов. Количество тестовых процедур, необходимых для нового проекта оценивается на основании прошлых проектов. Команда смотрит на взаимосвязи между количеством тестовых процедур и затраченными часами на предыдущих проектах, чтобы оценить примерное количество часов тестирования для текущего проекта. Этот метод зависит от различных факторов, в том числе от того, что проекты, которые будут сравниваться, должны быть схожими с точки зрения технологий, необходимых экспертных знаний и решаемых задач.
Таблица 9 иллюстрирует пример использования Метода расчета оценки трудозатрат с помощью тестовых процедур [7]79.
Таблица 7. Метод расчета оценки трудозатрат с помощью тестовых процедур
| Число тестовых процедур | Коэффи-циент | Количест-во человеко-часов | Времен-ной период | Число тестировщи-ков |
Предыдущие проекты(сред-нее от 2х или более схожих проектов) | 860 | 6.16 | 5300 | 9 месяцев (1560 часов) | 3.4 |
Оценка нового проекта | 1120 | 6.16 | 6900 | 12 месяцев (2080 часов) | 3.3 |
-
Метод планирования задач
В этом методе данные о численности человеко-часов, затраченных для выполнения задач тестирования на предыдущих проектах, используются для оценки трудозатрат. Данные включают в себя данные о времени, связанные с разбиением задач на более мелкие подзадачи, чтобы можно было сопоставлять разные виды этих задач.
Таблица 10 показывает использование метода планирования задач [7].
Таблица 8. Метод планирования задач
| Число тестовых процедур | Коэффициент | Количество человеко-часов |
Предыдущие проекты(среднее от 2х или более схожих проектов) | 860 | 6.16 | 5300 |
Оценка нового проекта | 1120 | 6.16 | 6900 |
В таблице 11 (см. Приложение 3) приведен пример оценки часов, необходимых на выполнение различных тестовых заданий в рамках этапов тестирования нового проекта. Столбец «Скорректированная оценка» показывает, как изменяется предварительная оценка по мере изменения условий.
Используя скорректированную оценку, можно рассчитать, что число тестировщиков равно 3.1 для проекта продолжительность 12 месяцев, как показано в таблице 12.
Таблица 9. Пример расчета числа тестировщиков
| Число тестовых процедур | Коэффициент | Количест-во человеко-часов | Временной период | Число тестировщи-ков |
Оценка нового проекта | 1120 | 5.71 | 6403 | 12 месяцев (2080часов) | 3.1 |
В книге L. M. Laird, M. C. Brennan. Practical Software Measurement and Estimation: A Practical Approach. [33]80 методологии оценки разделяют на 6 типов:
-
экспертная оценка; -
использование исходных данных; -
аналогия; -
функциональные точки; -
индивидуальные модели; -
алгоритмические модели.
Есть два основных подхода к применению методологий оценки: «снизу-вверх», «сверху-вниз».
В подходе «снизу-вверх» оценки нижних уровней продукта группируются в высокоуровневые. В подходе «сверху-вниз» начинают с общей оценки всего проекта и постепенно разбивают на более мелкие процессы.
Экспертная оценка:
Метод экспертной оценки предполагает оценку проекта, осуществленную несколькими экспертами. Есть два подхода к методу экспертной оценки: первый – декомпозиция работ и деятельности, второй - декомпозиция системы [33]81. В декомпозиции работ и деятельности в большей степени используется субъективное мнение, а не количественные показатели и предыдущие проекты. Эксперт думает о работе, которую предстоит сделать, квалификации людей, которые будут делать это, чтобы создать план необходимых мероприятий, их продолжительности и количестве людей, необходимых для выполнения этих действий за определенный период времени [33]. В методе декомпозиции системы система разбивается на модули нижнего уровня или компоненты, и общие трудозатраты рассчитывается путем суммирования трудозатрат на каждый модуль. В случае возникновения конфликтов между оценками экспертов, из [33] рекомендует использовать метод Delphi, более конкретно Wideband Delphi метод, который опирается на использование частого взаимодействия, чтобы прийти к консенсусу.
Использование исходных данных:
Этот подход основан на предположении, что производительность является функцией от размера и прикладной области. Если доступны оценки размеров тестовых процедур и можно предсказать коэффициент выхода, то оценка трудозатрат - это просто соотношение размера и коэффициента выхода. Размер тестовых процедур и быстроту выхода можно оценить, используя данные предыдущих проектов.
Аналогия:
Метод оценки по аналогии предлагает использовать опыт и данные завершенных проектов, чтобы оценить новый проект.
Метод оценки с использованием прокси-точек:
Данный метод оценки использует внешние характеристики системы для определения ее размера. Первичный метод использует функциональные точки, точки объекта (используется в COCOMO II), а также варианты использования. Оценка происходит в три этапа. Во-первых, размер оценивается с использованием любой прокси метрики, далее оценки корректируются с учетом факторов сложности и, наконец, оценки корректируются на коэффициент производительности, как функции на одного сотрудника в месяц.
Индивидуальная модель:
Использование индивидуальной модели подразумевает изменение или корректировку стандартной модели оценки с учетом особенностей конкретного проекта.
Алгоритмическая модель:
Алгоритмические модели – это эмпирические модели, которые получаются при регрессионном анализе. Большинство алгоритмических моделей сперва оценивают размер, потом используют его, чтобы оценить трудозатраты, которые с свою очередь будут использованы для оценки стоимости и построения графика. Алгоритмические модели формируют базис как для ручных моделей оценки, так и для инструментальных.
Использование метрик Холстеда для оценки трудозатрат:
Метрики Холстеда могут быть использованы для оценки трудозатрат. Предложенные измерения:
-
n1 – число отдельных операторов в программе; -
n2 – число отдельных операндов в программе; -
N1 – общее число операторов; -
N2 – общее число операндов.
Холстед разработал выражения для объема программы V (volume) и уровня программы PL (program level), которые могут быть использованы для оценки трудозатрат. Объем программы определяет объем информации в битах, необходимый для программы. Уровень программы – это мера сложности приложения. Используя эти определения, трудозатраты могут быть вычислены как:
e = V/PL, где V – объем программы, PL – уровень программы.
V = N*log2(n), где N = N1+N2 - длина программы, n = n1+ n2 – словарь программы.
PL = 1/[(n1/2)*(N2/n2)]
Процент трудозатрат на тестирование от общих трудозатрат можно выразить как:
k = e(k)/∑e(i),
где e(k) – это трудозатраты на модуль k, а ∑e(i) – сумма трудозатрат по Холстеду на все модули системы.
Оценки бюджета для следования задокументированным процедурам:
Наиболее значительные затраты в большинстве проектов приходятся на человеческие ресурсы. После того, как продолжительность тестирования установлена и известно, сколько времени каждый тестировщик потратит на проект, бюджет на тестирование может быть определен путем расчета коэффициента ресурсов [34]82. Важно документировать предположения, которые сделаны при оценке стоимости для оценки рисков и улучшения оценок для будущих проектов.
Ограничения подходов для оценки трудозатрат:
1. На трудозатраты с предыдущих завершенных проектов нельзя полагаться полностью. Профессиональные тестировщики обязаны использовать свой опыт, когда имеют дело с необычными обстоятельствами;
2. При оценке необходимо учитывать опыт организации в проведении тестирования;
3. Требования к тестированию должны быть четкими;
4. Внедрение автоматизированного инструмента привносит сложность в проект. Это должно рассматриваться соответствующим образом;
5. Знание тестировщиком предметной области является важным атрибутом, который влияет на временные рамки;
6. Организация команды тестирования должна быть принята во внимание;
7. Имеет значение время, в которое началась деятельность по тестированию, потому что раннее начало деятельности по планированию позволяет лучше понять требования и обнаружить ошибки на ранних этапах;
8. Наличие или отсутствие задокументированных процессов для тестирования составляет еще один важный фактор для планирования времени тестирования;
9. Программное обеспечение с повышенной сложностью требует более тщательного тестирование, и это должно быть принято во внимания при построении графика тестирования;
10. Существует вероятность изменения требований и дизайна в процессе разработки [11]83;
11. Программное обеспечение должно быть вовремя поставлено для тестирования [35]84.
Краткое изложение результатов оценки показателей ожидаемых затрат на тестирование, продолжительности тестирования и требований к ресурсам приведены в таблице 13.
Таблица 10. Показатели "Ожидаемые затраты на тестирование", "Продолжительность тестирования", "Требования к ресурсам"
Свойство показателя | Показатель |
Цель | Оценить трудозатраты на тестирование |
Польза показателя | Помогает при доработке общего графика разработки программного обеспечения |
Прогнозирование сроков помогает отслеживать ход тестирования | |
Прогнозирование требуемых ресурсов и времени помогает оценить трудозатраты на весь процесс тестирования | |
Изученные техники | Метод соотношения разработки и тестирования. |
Метод соотношения персонала на проекте | |
Метод расчета оценки трудозатрат с помощью тестовых процедур | |
Метод планирования задач | |
Экспертная оценка | |
Использование исходных данных | |
Аналогия | |
Метод оценки с использованием прокси-точек | |
Индивидуальная модель | |
Алгоритмическая модель | |
Использование метрик Холстеда для оценки трудозатрат | |
Ограничения показателя | На трудозатраты с предыдущих завершенных проектов нельзя полагаться на полностью |
При оценке необходимо учитывать опыт организации в проведении тестирования | |
Требования к тестированию должны быть четкими | |
Внедрение автоматизированного инструмента привносит сложность в проект | |
Знание тестировщиком предметной области является важным атрибутом |