1.7. Реализация

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

Целью реализации является удовлетворение требований способом, определенном в детальном проектировании. Детального проекта должно быть достаточно, поскольку это документ, на котором основывается программирование.

Типичная схема реализации следующая.

1) Определить стандарты кодирования для того чтобы код имел стандартный вид. (Ранее в разделе 1.3 был приведен перечень требований к оформлению программного кода).

2) Основываясь на архитектуре и спецификации классов реализовать методы каждого класса основываясь на требованиях детального проектирования.

3) Провести инспектирование каждого класса.

4) Провести тестирование каждого класса.

5) Провести интеграцию классов модули ПО.

Следует отметить, что популярное представление о программировании как о процессе подготовки текста программы для компиляции на самом деле отражает лишь незначительную часть общей картины. Действительной целью написания программы является создание правильного кода, то есть такого кода, который полностью соответствует сформулированным требованиям. Компиляторы же только проверяют корректность синтаксиса и генерируют объектный код. За правильность программы отвечает человек, и поэтому настоящий профессионал должен убедиться в правильности своей программы до такого, как ее компилировать. За более подробной информацией касающейся реализации программного кода, студентам рекомендуется обратиться к [1-4].

1.8. Тестирование

Сразу после реализации частей программного кода следует немедленно приступать к тестированию. При этом следует учитывать, что невозможно протестировать программу абсолютно во всех аспектах, поскольку число вариантов работы нетривиальной компьютерной программы может быть неограниченным. Следовательно, тестирование не может доказать отсутствие ошибок в программе. Тестирование может показать только присутствие ошибок.

Тестирование часто неправильно воспринимается как процесс подтверждения корректности кода, что можно выразить таким высказыванием: «Протестируй это, чтобы убедиться, что тут все правильно». Иногда, однако, это является целью тестирования, особенно незадолго до отсылки продукта или при регресси­онном тестировании. Главная цель тестирова­ния далека от подтверждения корректности. Его цель не в том, чтобы показать удовлетворительную работу программы, а в том, чтобы четко определить, в чем работа программы неудовлетворительна!

Время, использованное на тестирование, требует значительных затрат, и мы стараемся получить от этих затрат максимальную прибыль. Для данной тестируе­мой программы, чем больше дефектов будет найдено на каждый доллар зарплаты, тем выше выигрыш от вложений в тестирование. Следовательно, целью тестирова­ния является обнаружение как можно большего числа дефектов с высоким уровнем важности. Резюмируя сказанное выше, перечислим «золотые правила» тестирования.

♦ Цель тестирования: максимизировать число и важность обнаруженных де­фектов на каждый затраченный доллар.

♦ Поэтому: начинайте тестирование рано.

♦ Ограниченные возможности тестирования: тестирование может установить только присутствие дефектов, и никогда — их отсутствие.

♦ Для установления факта отсутствия дефектов используйте доказательст­ва корректности.

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

Что касается идеальной гарантии качества в общем, тестирование кода долж­ны проводить люди, не участвовавшие в его разработке. Когда инженер разраба­тывает код, он создает для себя представление того, что код должен выполнять. Поэтому в то же время он разрабатывает типичную среду, в которой этот код должен выполняться. Можно смело считать, что код дает немного ошибок в этой конкретной среде. Следовательно, эта среда является основой тестов разработ­чика. Именно поэтому, когда человек тестирует свой собственный код, он часто прячет каждый дефект, который необходимо найти.

Модульное тестирование является ранним типом тестирования. Следующий уровень состоит из интегрального тестирования. Здесь валидируется общая функциональность каждой стадии конкретной программы. Наконец, система и различные приемосдаточные тесты валидируют финальный продукт. Уже разработанные варианты использования также берутся в качестве основы для некоторых из этих тестов. Типы тестирования и связь меж­ду ними проиллюстрированы на рис. 6.

Рис. 6. Тестирование: общая картина

Цель модульного тестирования — проверить структуру, в то время как цель всех других видов тестирования обычно заключается в проверке функциональности. В качестве аналогии представьте себе тестирование каждой опоры моста на заво­де. Это является неким подобием модульного тестирования, поскольку в этом случае тест затрагивает элементы структуры. Тест, состоящий из проезда авто­мобиля по частично сконструированному мосту, напротив, не будет модульным тестированием. Функции обычно являются наименьшими частями программы, к которым может быть применено модульное тестирование (см. рис. 6). Следую­щим по величине элементом является модуль (класс в случае объектно-ориенти­рованной ориентации). Иногда комбинации модулей рассматриваются в целях тестирования как модули.

Модули, к которым применяется модульное тестирование, являются блоками при построении программы, а не отдельными кирпичами, на которых строится дом. Хотя на дом не сильно повлияют несколько бракованных кирпичей, программ­ное приложение может оказаться очень чувствительным к дефектам в отдельных блоках конструкции. Если дефектные части будут встроены в программы, может понадобиться огромное количество времени на их нахождение и исправление. Поэтому блоки программы должны быть абсолютно надежными, что и является целью модульного тестирования.

Типичный план модульного тестирования, основанный на стандарте IEEE 1008-1987, показан на рис. 8.4. Далее объясняются шаги процесса модульного тестиро­вания.

1) Входными данными для процесса планирования теста являются требова­ния и детальный проект. Вспомните, что каждое требование соответствует хорошо определенному коду (функции, где возможно). Детальный проект обычно состоит из дополнительных классов и методов. Они также сказы­ваются на качестве программы и должны быть протестированы в том же объеме, что и отдельные требования. Выходными данными процесса планирования теста является модульный план тестирования (например, «(1) тест метода 84; (2) тест метода 14;...; (10) тест класса 26,...»).

2)Следующим шагом является получение входных и выходных данных, ас­социирующихся с каждым тестом. Некоторые из этих данных могут быть уже получены из предыдущих тестов (например, предыдущие итерации, предыдущие версии продукта или предыдущие выпуски). Результатом на этом шаге является набор тестов.

3)Наконец, тесты исполняются.

Рис. 7. План модульного тестирования

Далее приведены этапы, требуемые стандартом IEEE для модульного тести­рования (1008-1987). Они расширяют только что описанный план модульного тестирования.

1)Спланировать общий подход, ресурсы и расписание.

2)Определить характеристики, которые следует протестировать, исходя из требований.

3)Обновить общий план.

4)Разработать набор тестов.

5)Реализовать обновленный план и проект.

6)Выполнить тестовые процедуры.

7)Проверить окончание работы.

8)Оценить тестирование и модули.