Введение
Создание надежного, проверенного программного обеспечения (ПО) невозможно без полноценной, релевантной системы тестирования, оценок надежности, работоспособности, использования минимально достаточного комплекса качественных тестов.
Эффективность тестирования
Насколько эффективна используемая система тестирования, особенно, в условиях перехода от классических принципов программирования больших комплексов ПО к разработке мобильных приложений и микросервисов, тестирование которых является задачей ничуть не менее сложной, важной и длительной.
Традиционное тестирование с его основным подходом: "ПО тестируется модульно, после его сборки по статистической логической структуре на основе заранее разработанных тестах", меняет парадигму: "ПО тестируется по ходу программирования сборки, иногда - на лету, в реальном режиме".
Устранение ошибок разработки ПО, особенно, на этапе сопровождения («продолжающейся разработки»), является более ресурсоемким (временной ресурс - главный!), чем на предыдущих этапах (проектирование, программирования, верификация и др.). Динамично повышаются риски сбоев ПО, багов, появление уязвимостей, степень их латентности и сложность исправления, избавления от них. Тестирование требует не менее 50% бюджета разработки ПО.
Выход, интуитивно понятный, очевиден - тестировать, верифицировать в течение всего ЖЦ (жизненного цикла) ПО, разработки.
Смена парадигмы тестирования – Тестирование 2.0
Чем раньше и полнее идентифицируются ошибки, тем лучше. Для этого имеются новые технологии тестирования, верифицирования, позволяющие не только эвристически идентифицировать, но и формально описывать, прогнозировать их появление, ущерб от рисков. Развиваются и нейросетевые, нечетно-множественные (логические) подходы, методики валидации и др.
Верификацию понимаем не только в узком понимании – как экспертно-эвристическую проверку внутренней (логической) «реакции» на наличие ошибок, отклонения от спецификации, но и системно - как проверку ПО в качестве системы, как доказательство правильности, работоспособности ПО. Ясно, что смена парадигмы тестирования возможна лишь при наличии определенной культуры тестирования (верификации), управляемости процесса, использовании объективно-ориентированной разработки (object development), базирующейся на объектах, классах, отношениях.
Тестирование - важнейший этап разработки ПО, этап подготавливаемый, планируемый, бюджетируемый, методологически и технологически поддерживаемый. Тестирование должно идентифицировать все ветви дерева решений, эмерджентные свойства системы и осуществлять комплексную проверку всех спецификаций.
Каждая тренируемая ситуация, уязвимость информирует о степени отображения, учета функциональности приложения, поэтому руководитель группы тестировщиков, проекта и системные аналитики должны проводить аудит, мониторинг тестирования, системы тестов. С привлечением заказчика, тестолога, который не должен высказывать критерии тестирования, а лишь участвовать в анализе и оценке факторов, архитектуры тестирования, подсистемы общей системной архитектуры проекта.
Какие основные требования к качеству ПО (на этапе тестирования) являются основными, системными?
Перечислим соответствующие спецификации:
1) сложностные – по архитектуре, структуре, информации, длине, представительности и др.;
2) эволюционируемость - модифицируемость, расширяемость, модульность и др.;
3) тестированность – верифицируемость, минимальная достаточность системы тестов и др.;
4) управляемость - алгоритмизируемость, структурируемость, адаптируемость, безотказность и др.;
Каковы практические методы (алгоритмы) оценки тестирования? Многие параметры ПО определяются метриками Холстеда: длина модулей, время программирования, тестирования, оптимальная производительность (точнее, оптимальное перераспределение времени программирования, реализации проекта) и др. Например, параметры отладки модуля, идентифицированные метрики, определяются как: Е=7.8-0.17Т, Е=2.13+0.0156L, где Е – количество ошибок, Т - уровень подготовки (можно отождествить с компетентностью, стажем работы) программиста, L - длина модуля. Если интенсивность появления новых ошибок известна (т.е. известна функция распределения), то можно определить вероятность безотказной работы в промежутке по формуле Лапласа, а затем и время между двумя последовательными отказами.