8.11. Пример тестирования программы

Пусть имеется заказ на разработку системы, обеспечивающей вычисление площади треугольника по формуле Герона.

Для наглядности связи между тестированием и этапами разработки системы выполним разработку такой системы в соответствии с СТБ ИСО/МЭК 12207-2003 (см. подразд. 4.1). Согласно данному стандарту в процессе разработки над системой выполняется 13 работ:

1) Подготовка процесса.

2) Анализ требований к системе.

3) Проектирование системной архитектуры.

4) Анализ требований к программному средству.

5) Проектирование программной архитектуры.

6) Техническое проектирование программного средства.

7) Программирование и тестирование модулей.

8) Сборка программного средства.

9) Квалификационные испытания программного средства.

10) Сборка системы.

11) Квалификационные испытания системы.

12) Ввод в действие программного средства.

13) Обеспечение приёмки программного средства.

Так как в нашем случае речь идёт исключительно о разработке программного средства, т.е. для реализации данного продукта нет необходимости в разработке специальных технических средств, ограничимся работами, связанными только с разработкой непосредственно программного средства. К таким работам относятся работы №№ 1, 4 – 9, 12, 13.

1) Подготовка процесса

С точки зрения разработки ПС, данная работа заключается в следующих действиях:

1. Выбор языка программирования;

2. Адаптации необходимых стандартов (применительно к данному классу ПС);

3. Должны быть предусмотрены возможные перспективы разработки новых версий, дополнений и др.

4. В выборе наиболее подходящей модели разработки для данного программного средства.

С точки зрения тестирования, если разрабатывается дополнение или обновление ранее разработанных ПС, данная работа заключается в исследовании результатов предыдущих тестов, т.е. необходимо вспомнить какие проблемы были встречены в предыдущих разработках, какие тесты применялись, какими путям были устранены ошибки и т.д.

Если же ПС такого типа или назначения разрабатывается впервые, то работа тестирования откладывается на более поздние этапы разработки.

4) Анализ требований к программному средству

Основной задачей с точки зрения разработки в ходе данной работы является разработка (или получение) требований к ПС. В процессе дискуссии с заказчиком уточняются функциональные требования, необходимые параметры защищенности, требования к интерфейсу, необходимые условия по сопровождению, определяются эксплуатационные требования и другие пожелания в формализованном виде.

Результатом действий разработчика должна быть сформулированная спецификация требований (Software Requirements Specification). Далее полученная спецификация подвергается «тестированию».

Под «тестированием» спецификации необходимо понимать процесс проверки установленных требований на непротиворечивость, полноту, осуществимость, избыточность (недостаточность),- т.е. не должно быть лишней информации, вносимой в ПС, а так же необходимо отследить достаточность исходных данных для выполнения программным средством установленных функций, и др. критерии.

Применительно к нашему примеру, после переговоров с заказчиком, были сформулированы следующие требования:

1. ПС должно состоять из модулей.

2. ПС должно получать только 3 значения.

3. ПС должно выводить на экран только значение площади треугольника.

4. ПС должно выводить на экран только значение центра масс треугольника.

5. ПС должно принимать значения углов треугольника.

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

После проведения анализа (тестирования) полученных требований можно увидеть:

1. Требования 3 и 4 не проходят проверку на непротиворечивость.

2. Поскольку разрабатываемое ПС должно осуществлять вычисление площади треугольника по формуле Герона, для применения которой необходимо лишь знание длин треугольника, значения углов треугольника в качестве исходных данных можно исключить, считая их избыточной информацией. (требование 5)

3. Проанализировав требование 2 можно увидеть, что данное требование сформулировано не полностью, поскольку исходя из него, остаётся загадкой какие именно и значения чего должно получать ПС. Т.е. это требование не корректно с точки зрения критерия «полноты описания требования».

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

1. ПС должно состоять из модулей.

2. ПС должно получать только 3 значения, а именно: величины длин сторон треугольника.

3. ПС должно обеспечивать отражение на дисплее значение площади треугольника.

Итогом данной работы является разработанная спецификация требований применительно к каждому программному объекту системы в целом. Т.е. должны быть описаны функциональные требования к каждому программному объекту системы.

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