Здравствуйте!
Это первый пост из серии про автоматизацию проверок ПО. Мы поговорим о том, зачем это нужно и как сделать автоматизированные проверки с минимальными затратами.
Предназначение проверок ПО (любых) заключается в обнаружении дефектов. Поэтому для начала неплохо разобраться в том,
- Сколько дефектов есть в Вашем ПО
- Насколько они критичны
- Когда они будут обнаружены
Естественно, что я не могу знать точные ответы на эти вопросы для Вашего конкретного ПО. Но можно дать некоторые прикидки.
Количество дефектов
Для начала немного теории.
В 2008-м году, компания Software Productivity Research LLC провела исследование на тему разработки ПО в крупных компаниях (Capers Jones, Software Quality in 2008: A survey of the state of the Art). Они исследовали качество ПО, которое разрабатывалось с 1984 по 2008 гг., в 650 компаниях (из них 150 входят в 500 крупнейших корпораций США) и 35 государственных учрежденях (в том числе военных) в 24 странах мира. В общей сложности они исследовали около 12500 проектов.
Согласно их данным, в начале эксплуатации ПО содержит следующее количество дефектов:
- При высоком качестве управления разработкой: 0,13 на балл функциональной оценки
- При среднем качестве управления разработкой: 0,75 на балл функциональной оценки
- При низком качестве управления разработкой: 3,05 на балл функциональной оценки
Баллы функциональной оценки (function points) являются средством измерения объёма и сложности ПО. Для наших целей можно воспользоваться таблицей пересчёта баллов функциональной оценки в строки кода. Это тоже усреднённые данные, но тем не менее. Такую таблицу для разных языков программирования можно найти здесь.
Пример
Допустим, у меня есть программа на Яве размером в 70.000 строк кода. Один балл функциональной оценки соответствует (в среднем) 55 строкам кода на Яве. Получаем 1273 баллов функциональной оценки (70 000 / 55).
Предположим далее, что качество управления разработкой было средним.
На основании этих данных мы можем сказать, что в начале этой эксплуатации этой программы в ней содержится 1273 * 0,75 = 955 дефектов.
Степень тяжести дефектов
Наши американские друзья посчитали, однако не только количество ошибок в ПО, но и их распределение по степени тяжести. Согласно их данным, дефекты распределяются так:
- Тотальный сбой: 1 % всех дефектов
- Серьёзные проблемы: 20 %
- Мелкие проблемы: 35 %
- Косметические: 44 %
Пример
Теперь мы можем определить количество дефектов разного типа в нашей программе из прошлого примера:
- Тотальный сбой: 955 * 1 % = 10 штук
- Серьёзные проблемы: 955 * 20 % = 191 штука
- Мелкие проблемы: 955 * 35 % = 334 штуки
- Косметические: 955 * 44 % = 420 штук
То есть, на момент ввода в эксплуатацию в программе имеется 201 дефект, из них 10, приводящие к тотальному сбою. Тотальный сбой – это такие ситуации, в которых останавливается работа программы и разработчики в авральном порядке делают исправленную версию ПО.
Выявление дефектов
В момент ввода ПО в эксплуатацию в нём есть дефекты, но они не выявлены. Согласно указанной выше статистике, в среднем за первый год эксплуатации выявлятся 60 % дефектов (конкретные цифры зависят от сложности ПО).
Проблема в том, что за этот год критические дефекты могут привести к катастрофе.
Автоматизация проверок ПО позволяет ускорить процесс выявления дефектов.
Успехов
Дмитрий Писаренко
