|
|
@@ -16,6 +16,9 @@
|
|
|
- [Интеграционное тестирование](#интеграционное-тестирование)
|
|
|
- [Пользовательское тестирование](#пользовательское-тестирование)
|
|
|
- [Сбор информации в ходе эксплуатации](#сбор-информации-в-ходе-эксплуатации)
|
|
|
+ - [Оценка зрелости процессов](#оценка-зрелости-процессов)
|
|
|
+ - [Оценка степени контроля качества разработки](#оценка-степени-контроля-качества-разработки)
|
|
|
+ - [Абстрагирование тестирования](#абстрагирование-тестирования)
|
|
|
|
|
|
## Анализ ситуации
|
|
|
|
|
|
@@ -89,3 +92,49 @@
|
|
|
Отсутствие этих этапов приведт к тому, что потребители проголосуют рублём в сторону аналогичных продуктов от других производителей.
|
|
|
|
|
|
Отсутствие эксплуатационно-диспетчерской службы является признаком наплевательского отношения к потребителям.
|
|
|
+
|
|
|
+### Оценка зрелости процессов
|
|
|
+
|
|
|
+Оценку зрелости процессов следует производить по таблице, как указано по [ссылке](https://ru.wikipedia.org/wiki/Уровни_зрелости_управления).
|
|
|
+
|
|
|
+Каждый следующий уровень в каждой конретной ситуации может иметь свой вес. Но обще принятой практикой вляется увеличение количества баллов `*2` от предыдущего уровня.
|
|
|
+
|
|
|
+Таким образом уровни зрелости процессов имеют веслвые коэффициенты: 1, 2, 4, 8, 16, 32.
|
|
|
+
|
|
|
+Диапазон оценок по такой шкале примерно 27 дБ.
|
|
|
+
|
|
|
+### Оценка степени контроля качества разработки
|
|
|
+
|
|
|
+В соответствии с вышеизложенным, можно предложить методику оценки контроля качества цифрового продукта.
|
|
|
+
|
|
|
+По юнит-тестированию следует оценивать покрытие функций:
|
|
|
+
|
|
|
+1) Функция покрыта тестами на 0%: -2 балла
|
|
|
+2) Функция покрыта тестами до 60%: -1 балл
|
|
|
+3) Функция покрыта тестами 60-84%: +1 балла
|
|
|
+4) Функция покрыта тестами более 85%: +4 балла
|
|
|
+
|
|
|
+В качестве итоговой оценки берётся отношение полученных быллов к маскимальному количеству.
|
|
|
+
|
|
|
+- более 85%: хорошо;
|
|
|
+- 60-85%: удовлетворительно;
|
|
|
+- если есть хотя бы одна функция с покрытием менее 50% -- неудовлетворительно.
|
|
|
+
|
|
|
+При интеграционном тестировании следует контролировать количетво тестов по функционалу.
|
|
|
+
|
|
|
+В ходе текущей разработки покрытие тестами менее 85% следует считать неудовлетворительным.
|
|
|
+Если в ходе интеграционного тестирования из общег очисла тестов проходит менее 90% следует считать результаты неудовлетворительными.
|
|
|
+
|
|
|
+В ходе приёмочного тестирования любой критический сбой должен расцениваться как неудовлетворительная оценка. Продукт не выполняющий свои критические функции не может быт ьпринят в эксплуатацию. Если в ходе приймки до двух некритических сбоев на 100 функций -- можно принять оценку удовлетворительно.
|
|
|
+
|
|
|
+При оценке качества управления надо ориентироваться на уровень сложности разрбатываемого продукта. В любом случае, формальные признаки описаны, должны быть оценены экспертным способом, качество продукта не может быть оценено выше чем на одну ступень, чем оценено качество процессов управления.
|
|
|
+
|
|
|
+## Абстрагирование тестирования
|
|
|
+
|
|
|
+В реальной эксплуатации некоторый набор условий может не наступить никогда. В части логики из-за того, что это будет означат ьаварию ,в части случаев из-за того, чт особытие самопо себе крайне редкое.
|
|
|
+
|
|
|
+Но такие ситуации должны быть отработаны ещё в ходе разработки. И это требование является основанием для постоянного поддержания и использования стенда для постоянной проверки того, что такие редкие ситуации отрабатываются правильно.
|
|
|
+
|
|
|
+Также нельзя опираться на внешние входящие данные и события по той причине, что их источники могут в своей логике содержать ошибки. И значит, что там возможны такие комбинации входных данных и событий, которые не предполагались самими же разработчиками.
|
|
|
+
|
|
|
+В связи с этим для разрабатываемого продукта *должен* быть определён механизм поступления всех вариантов возможных данных и событий, и обязательно в том числе -- невозможные их комбинации.
|
SVI