Предсказание количества дефектов в тестировании

Несмотря на то, что мы мы используем ручное тестирование для Parallels Cloud Server, 90% функционала покрывается автоматическими тестами. И одной из главных задач для нас является оценка времени автоматического тестирования.

И эта оценка на самом деле является сложной задачей, ввиду того, что процесс имеет большое количество зависимостей и ограничений. Например:

• тесты используют разное количество и конфигурации компьютеров
• тесты имеют разную длительность исполнения
• тесты имеют разную вероятность прохождения, которая зависит от множества других факторов
• количество разработчиков и тестировщиков, вовлечённых в процесс

Мы можем оценить время, необходимое для тестирования небольших изменений, на основании своего опыта и при условии, что большинство параметров тестирования такое же как и в предыдущих обновлениях: такое же количество тестировщиков и разработчиков, такое же количество серверов, похожий набор тестов и т.д. Как только что-то меняется, время тестирования становится труднопредсказуемым на этапе планирования тестирования.

Если обратиться к теории «computer science», то мы узнаем, что «software reliability» это ключевая часть «software quality». И изучение надежности программного обеспечения («software reliability») можно разделить на три части: моделирование, измерение и улучшение надежности. (см. например Software Reliability)

Моделирование надежности программного обеспечения является достаточно зрелым для того, чтобы получать полезные результаты путем применения подходящих моделей к проблеме. Существует много моделей, но ни одна модель не может захватить необходимое количество характеристик программного обеспечения. Должны быть сделаны предположения и абстракции, чтобы упростить задачу. Так же не существует единой модели, которая была бы универсальной для всех ситуаций.

Измерение надежности программного обеспечения является наивным, так как измерения не являются обыденностью в программном обеспечении, как и в других инженерно-технических областях. «Насколько хорошим является это программное обеспечение количественно?» Вопрос простой, но на него нет хорошего ответа. Надежность программного обеспечения не может быть непосредственно измерены, как другие факторы измеряются оценить надежность программного обеспечения и сравнить его среди продуктов. Процесс разработки, ошибки и неудачи найдено все факторы, связанные с надежностью программного обеспечения.

Повышение надежности программного обеспечения трудоёмко из-за недостаточного понимания надежности программного обеспечения в целом и из-за характеристик программного обеспечения. Никогда нельзя гарантировать отсутствие дефектов в программном обеспечении. К тому же ограничения времени и бюджета, ресурсов ограничивает усилия, направленные на улучшение надежности программного обеспечения.

В свою очередь модели надёжности программного обеспечения бывают двух видов:

• Software reliability prediction model

  • модель использует исторические данные
  • обычно модель делается до начала разработки или тестовых итераций
  • предсказывает надежность в будущем времени

• Software reliability estimation model

  • модель использует данные на текущий момент разработки
  • обычно модель делается после того, когда накопится часть данных
  • оценивает надёжность в настоящем или будущем времени

После чтения пары десятков научных статей по этой тематике я сделал для себя несколько выводов:

• первые модели были разработаны ещё в 1971(!) году и с тех пор были опубликованы статьи, описывающие более 200 моделей
• ни одна модель не может охватить все различия в процессах разработки и методологиях. Для упрощения задачи построения модели должны быть сделаны предположения и введены абстракции.
• каждая модель имеет свои предположения, лимитирующие факторы и ни одна из них не универсальна.
• все модели имеют разную точность и стабильность результатов - в литературе рекомендуют попробовать разные модели и остановиться на той, которая дает наиболее приближенные к реальности.

Таким образом выбор модели является непростой задачей. В книге Fault-Tolerant Systems приводится совет от Американского Института Аэронавтики и Астронавтики (The American Institute of Aeronautics and Astronautics (AIAA)) использовать одну из четырёх моделей: Jelinski–Moranda, Littlewood–Verrall, Musa–Okumoto, Schneidewind. Потом предлагается понять характер зависимости частоты дефектов от времени, затраченного на тестирование, и если, к примеру, зависимость будет экспоненциальной, то использовать модель Musa-Okumoto.

К сожалению, среди всех опубликованных статей по этой тематике очень мало тех, которые описывают практический опыт применения таких моделей в промышленной разработке. Но две статьи мне всё-таки получилось найти:

Первая статья Software Reliability Growth Models (pdf) был написана сотрудниками Tandem computers.

Вторая статья Using Software Reliability Growth Models in Practice (pdf) сотрудниками NXP Semiconductors.

Компании малоизвестные (вы про них слышали?), но Википедия говорит, что Tandem Computers «была ведущим производителем отказоустойчивых компьютерных систем для сетей банкоматов, банков, бирж, требующих максимального времени безотказной работы и без потери данных». Была основана в 1974 году и в 1997 году стала подразделением Hewlett Packard. А NXP Semiconductors является производителем полупроводников, входит в двадцатку ведущих мировых лидеров продаж полупроводников.

Вдохновившись почерпнутыми знаниями я решил попробовать применить существующие модели к расчётам количества дефектов в тестировании. Если получатся интересные результаты - я вам расскажу :)