maran program engineering (830029), страница 29
Текст из файла (страница 29)
В ходе тестирования вновь подключенныхмодулей дополнительно протестируются и ранее подключенные. При этом тестирование не обязательно проводить уровень за уровнем, можно выделитьчасть модулей, которые обеспечивают решение значительной части, например,75% задач, и начинать их внедрение, предупредив пользователя, что пока частьзадач не решается.
В ходе использования программный комплекс проходит дополнительную проверку по многим критериям.Из сказанного ясно, что более предпочтительным является пошаговоетестирование, но полностью забыть о монолитном не следует, мы к этому ещевернемся. Вопрос о том, как лучше проводить пошаговое тестирование сверху — вниз или снизу — вверх, не имеет однозначного ответа.Тестирование сверху — вниз.Преимущества:• Тестирование всего комплекса упрощается при подключениисредств ввода/вывода, которые часто находятся в главном модуле и вызываются непосредственно из него.• Рано формируется каркас всего комплекса, это позволяет проверить и правильность проектирования всего комплекса; результаты можно показать заказчику.• Легко тестировать логику модулей верхних уровней.Недостатки:• Трудно обеспечить тестирование логики модулей нижних уровней. Это может создать условия для недобросовестных разработчиков и тестировщиков при приближении сроков сдачи работы(в каком-то «хитром» случае модуль нижнего уровня не работает, но он редко встречается).
Правда, современные среды диалоговой разработки позволяют в какой-то степени снять эту проблему. При тестировании сверху — вниз можем поставить в модули точки прерывания и проверить, какие исходные данные онполучил и какой дал ответ: правильный или нет. Трудностьобеспечения прохождения всех необходимых тестов модуляминижних уровней сохраняется.• Требуется разработать заглушки.Тестирование снизу — вверх.Преимущества:• Легко протестировать логику модулей нижнего уровня, но тамчасто и реализованы самые сложные алгоритмы.175Недостатки:• Долго программа не существует как единое целое, ошибки проектирования могут проявляться слишком поздно.
Кроме того,это плохо психологически.• Требуются драйверы.Рекомендации по разработке драйверов были рассмотрены выше. Поговорим и о заглушках. Задача заглушки — имитировать работу заменяемогопрограммного модуля, она должно выполнять такое же преобразования вводных данных в выходные, как и «настоящая» программа. Согласитесь, в общемслучае реализовать это совсем не просто, особенно когда значения исходныхданные заменяемого ею модуля будут определены лишь в ходе работы другихмодулей. Кроме того, алгоритм работы самой заглушки должен быть настолькопрост, чтобы не возникла в принципе задача ее тестирования. Конечно, могутбыть случаи, когда полученный от заглушки ответ в ходе дальнейшего решенияни на что не влияет, и мы можем возвращать произвольное значение.Ниже приведен вариант заглушки для программы нахождения суммыэлементов массива в заданном интервале.
Действительно, ввиду простоты задачи ее длина сопоставима с длиной самой функции. Принцип следующий. В заглушку ставим точку прерывания. Когда программа на ней остановится, ставимкурсор мыши по очереди на исходные данные функции и на этой основе определим правильный ответ, который затем и будет введен.
Некоторые среды позволяют после останова на точке прерывания менять данные в самой программе, тогда задача ввода ответа упростится, но принцип один: человек определяетправильный ответ, который затем и будет использован вызываемыми в дальнейшем программами. Повторяем, так целесообразно поступить, если прощеполучить требуемый ответ невозможно.static double SumD(double[]mas, double c1, double c2,out int sig){double temp;if (mas.Length == 0){temp = 0;sig = 1;Console.WriteLine("Массив пуст.Ответы sum=0 и sig=1");return 0;}// На следующий оператор ставим точку прерывания.Console.WriteLine("Если массив не пуст и искомые элементы имеются вводите 0, если массив не пуст,но их нет - вводите 2 ");176sig = Int16.Parse(Console.ReadLine());if (sig != 0 && sig != 2){Console.WriteLine("Ошибка. Повторите ввод!");Console.WriteLine("Если массив не пусти искомые элементы имеются - вводите 0,если массив не пуст, но их нет –вводите 2 ");sig = Int16.Parse(Console.ReadLine());}if (sig == 2) return 0;else{Console.WriteLine("Введите сумму ");temp = Double.Parse(Console.ReadLine());return temp;}Подведем итоги.
В общем случае сказать, какой подход лучше: сверху —вниз или снизу — вверх, сложно. Рекомендуется тестировать сверху — вниз, нокаждый модуль ДО подключения к комплексу подвергать монолитному тестированию, особенно это касается модулей со сложными алгоритмами.
При постепенном подключении прошедших монолитное тестирование модулей снимается проблема «большого скачка». В средах диалоговой разработки созданиедрайверов и заглушек не такая уж и проблема! В первую очередь, тестировать иподключить модули, обслуживающие ввод/вывод, это упрощает тестированиеостальных. Очередность подключения модулей целесообразно выбрать пофункциональному признаку, чтобы комплекс в целом стал функционироватьдля решения хотя бы части задач. Это позволит проверить удобство использования, а также подвергать уже внедренные модули дополнительной проверке.Конечно, нельзя в таком случае забыть об ограничениях на применение, ведь невсе еще закончено!6.4.
Тестирование программных комплексов,построенных по объектно-ориентированной методикеПрограммный комплекс, построенный по объектно-ориентированной методике, представляет иерархическую структуру классов, и его функционирование заключается в создании переменных типа класс — объектов и передаче сообщений между ними. С программистской точки зрения передача сообщенияозначает вызов функции или свойства своего и/или другого класса. Функциибывают синхронными — с возвращаемым значением или асинхронными, гдевозврат значения отсутствует.177Как мы неоднократно повторяли выше, основной моделью жизненногоцикла программного обеспечения, разрабатываемого по объектно-ориентированной методике, является спираль. Согласно этой модели, программное обеспечение разрабатывается итерационно, версия за версией, и каждая новая версия добавляет новые функциональные возможности.
Поэтому важно проверитьпри добавлении новых возможностей, выполняются ли корректно те задачи, которые уже были реализованы в предыдущих версиях. Это называется регрессионным тестированием. Регрессионное тестирование заключается в том, что перед проверкой работы новых возможностей мы запустим тесты, на которыхпроверили предыдущую версию. Разумеется, не запрещено проведение регрессионного тестирования и при разработке по другим методикам.Различают:• Тестирование примитивных классов.• Тестирование взаимодействия классов.• Тестирование иерархии классов.Тестирование примитивных классов. Класс называется примитивным,если он только принимает сообщения и не создает динамически экземплярыдругих классов. Класс имеет обязанности: функции, вызываемые извне.
Ониобразуют интерфейсную часть, имеют открытый доступ. Если они сложные, тоони могут быть подвергнуты функциональной декомпозиции, таким образом,возникают внутренние (закрытые) функции класса. Тестирование класса в таком случае мало чем отличается от рассмотренного выше, за исключением одного весьма существенного момента.В построенном по методике функциональной декомпозиции программном комплексе каждая функция получает исходные данные при вызове и передает свой результат при возвращении.
Правда, имеются еще глобальные данные, но их рекомендуют использовать ограниченно, лишь для данных, которыедолжны с одинаковыми значениями быть доступными во многих модулях. Приобъектно-ориентированном подходе функции — члены класса кроме значений,полученных при вызове, могут обрабатывать и данные класса, как в качествеисходных, так и результата. Так и должно быть, ведь класс — это сочетаниеданных и методов их обработки! В классе могут существовать и функции, которые лишь записывают данные в класс и/или изменяют их, не возвращая результата при вызове.
Методика объектно-ориентированного программированиярекомендует ограничить доступ к данным извне. Выходом из ситуации является открытие доступа к данным, за значениями которых надо следить во времятестирования и отладки, а при их завершении поставить окончательные атрибуты доступа. Аналогичная ситуация возникает при тестировании функций, невходящих в интерфейс класса. Их тестирование аналогично тестированиюфункций нижних уровней при тестировании сверху — вниз.
При необходимости более подробного тестирования можно их для этого временно открыть.Функции класса, как правило, получают исходные данные, хотя бы частично, при вызове от класса-интерфейса или от другой функции или класса. Нолюбая функция может быть выполнена при определенных предусловиях, и по178сле ее завершения должны выполняться постусловия.
Мы об этом выше поговорили!Существуют два подхода к построению объектно-ориентированных программ: контрактное и защитное программирование.При контрактном подходе выполнение предусловий обеспечивают вместеотправитель и получатель. Отправитель должен обеспечить принадлежностьисходных данных допустимым классам эквивалентности. Но в общем случаеэто является достаточным, но не необходимым условием успешного выполнения функции.
Например, требуется 2 билета на определенный рейс. Все данныекорректные, но билетов может не быть. Если корректность исходных данныхдостаточное условие для выполнения функции — то этот вопрос не стоит. Вывод для тестирования: при контрактном подходе тестирование на неправильныхклассах эквивалентности не требуется.При защитном программировании гарантии корректности исходных данных нет, и функция сама должна обеспечить, чтобы «мусор на входе не превратили мусором на выходе».
Допустимы оба подхода, но тесты должны разрабатываться с учетом применимого подхода.Тестирование взаимодействия классов. Речь идет о тестировании класса, получающего и отправляющего сообщения. Мы рассматриваем только пассивные классы, поэтому любой класс может отправить сообщение после получения другого сообщения извне. Сообщения, получаемые таким классом, можно разделить на две категории: сообщения, полностью обрабатываемые этимклассом, и сообщения, которые вызывают отправку сообщения другому классу.Тестирование первых ничем не отличается от рассмотренного выше.
Тестирование сообщений второй категории похоже на тестирование модулей промежуточных уровней при функциональной декомпозиции: функция класса вызывается, и она, в свою очередь, вызывает другую функцию. При применении контрактного программирования должно быть установлено, что никакая функцияпри допустимых классах эквивалентности на входе не порождает недопустимых классов на выходе. Хорошим помощником при составлении тестов длятестирования взаимодействия классов являются диаграммы последовательностей, которые показывают реализацию вариантов использования со всеми возможными альтернативными путями. Все возможные пути их реализации должны быть протестированы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
