Особливості інтеграційного тестування для об’єктно-орієнтовного програмування.
1) Это событийно-управляемое программирование (передача управления не только явным путем, но и ОС передает события).
2) Разработка идет путем порождения собственной иерархии классов от стандартных библиотек классов.
3) Разработка программного кода идет согласно стандартам “Look & Feel”
Исходя из этих трех особенностей, необходимо исключить провал работоспособностей элементов стандартной библиотеки.
Для того чтобы протестировать ООП-код – построим графа отдельного класса
Данный класс можно представить в виде графа. Узлы – методы; дуги – вызовы этих методов. Вызов может исходить двумя способами:
– Прямым вызовом одного метода из кода другого, в случае, если вызываемый метод виден (не закрыт для доступа средствами языка программирования) из класса, содержащего вызывающий метод, присвоим такой конструкции название Р-путь (P-path, Procedure path, процедурный путь).
– Обработкой сообщения, когда явного вызова метода нет, но в результате работы «вызывающего» метода порождается сообщение, которое должно быть обработано «вызываемым» методом.
Для второго случая «вызываемый» метод может породить другое сообщение, что приводит к возникновению цепочки исполнения последовательности методов, связанных сообщениями. Подобная цепочка носит название ММ-путь (MM-path, Metod/Message path, путь метод/сообщение). ММ-путь заканчивается, когда достигается метод, который при отработке не вырабатывает новых сообщений (т. е. вырабатывает «сообщение покоя»).
Пусть Kmsg – число методов класса, которые обрабатывают разные сообщения;
Kem – число методов класса, которые не закрыты от прямого вызова.
При тестировании ООП программ в отличие от процедурного стиля программирования можно отнести следующее:
1) Количество точек входа, которые могут быть вызваны извне и количество методов, которые могут быть вызваны из других классов, определяется разработчиком. Следовательно, по UML-диаграмме мы можем получить Kmsg и Kem.
2) Тестовый набор состоит из ММ и Р-путей.
Методы класса «непрозрачны» для внешних объектов, поэтому упростить граф, как ранее нельзя.
Поэтому, сложность графа есть функция V(P,C) = F(Kmsg,Kem).
Поскольку математическая запись сложно применима, следовательно, методика тестирования:
1) Тестируются методы каждого класса (модульное тестирование).
2) Тестируются методы класса, как будто они модули некой программы (это и есть наш класс).
3) Тестируется дерево классов.
Для того, чтобы реализовать II и III шаги мы вводим понятие атомарной системной функции – множество, которое состоит из:
1) Внешнее событие на вход программы;
2) Реакция системы на это событие в виде одного или более ММ-путей
3) Сгенерированное событие на выходе программы.
Задача тестировщика – создать тестовый набор, который состоит из атомарной системной функции.
Для тестирования атомарных системных функций лучше всего применять фиксацию временных значений переменных в локальных файлах.
Структурні критерії вибору тестів.
Структурные критерии предполагают знание исходных кодов, или наличие UML-диаграмм. Данные критерии используются на этапе модульного и интеграционного тестирования.
Критерий С0 – тестирование команд: тестовый набор должен обеспечить похождение каждой команды не менее одного раза. Это слабый критерий, который, как правило, применим к большому количеству кода.
С1 – критерий тестирования ветвей: тестовый набор должен обеспечить прохождение каждой ветви не менее одного раза.
С2 – тестирование путей: тестовый набор должен обеспечить прохождение каждого пути не менее одного раза.
Замечание: если программа имеет цикл с неявно заданным количеством итераций, мы проходим только две.