скачать (254.3 kb.)
Доступные файлы (16):
| 10.doc | 34kb. | 27.01.2006 23:07 |  скачать |
| 12-13.doc | 36kb. | 27.01.2006 23:13 | скачать |
| 14.doc | 44kb. | 27.01.2006 23:30 | скачать |
| 16.doc | 23kb. | 27.01.2006 23:33 | скачать |
| 18.doc | 23kb. | 27.01.2006 19:24 | скачать |
| 1.doc | 43kb. | 27.01.2006 20:28 | скачать |
| 20.doc | 32kb. | 27.01.2006 23:43 | скачать |
| 21-22.doc | 22kb. | 27.01.2006 22:00 | скачать |
| 26-27.doc | 107kb. | 27.01.2006 19:49 | скачать |
| 2.doc | 68kb. | 27.01.2006 22:25 | скачать |
| 3.doc | 82kb. | 27.01.2006 20:21 | скачать |
| 4.doc | 25kb. | 27.01.2006 20:19 | скачать |
| 5.doc | 24kb. | 27.01.2006 19:51 | скачать |
| 6.doc | 27kb. | 27.01.2006 21:20 | скачать |
| 7.doc | 25kb. | 27.01.2006 20:52 | скачать |
| 8.doc | 23kb. | 27.01.2006 22:49 | скачать |
12-13.doc
Тестирование программного обеспечения охватывает целый ряд видов деятельности, аналогичных последовательности процессов разработки программного обеспечения. В него входят /1/:а) постановка задачи для теста,б) проектирование теста,
в) написание тестов, г) тестирование тестов,
д) выполнение тестов,е) изучение результатов тестирования.
Решающую роль играет проектирование тестов. Возможны разные подходы к проектированию тестов. Первый состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей, либо спецификаций сопряжения программы или модуля. Программа при этом рассматривается как ‘черный ящик’ (стратегия ‘черного ящика’ или функциональный подход). Существо такого подхода - проверить соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание.
Второй подход основан на анализе логики программы (стратегия ‘белого ящика’ или структурный подход). Существо подхода - в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.
Тестирование по принципу белого ящика характеризуется степенью, какой тесты выполняют или покрывают логику (исходный текст программы).
Покажем реализацию разных методов структурного тестирования на примере, фрагмент схемы программы которого приведен на рис. 2.1.
2.1. Метод покрытия операторовЦелью этого метода тестирования является выполнение каждого оператора программы хотя бы один раз. Для фрагмента на рис. 2.1 можно выполнить каждый оператор, записав один единственный тест, который реализовал бы путь ace. Т.е., если бы на входе было: А=2, В=0, Х=3, каждый оператор выполнился бы один раз.
^
Согласно данному методу каждое направление перехода должно быть реализовано по крайней мере один раз.
Покрытие решений обычно удовлетворяет критерию покрытия операторов. Поскольку каждый оператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа программы, при выполнении каждого направления перехода каждый оператор должен быть выполнен.Для программы, приведенной на рисунке 2.1, покрытие решений может быть выполнено двумя тестами, покрывающими пути {ace, abd}, либо {aсd,abe}. Пути {aсd,abe}покроим, выбрав следующие исходные данные: {A=3, B=0, X=3} и {A=2, B=1, X=1}.
^
Лучшие результаты по сравнению с предыдущими методами может дать метод покрытия условий. В этом случае записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз.
В предыдущем примере имеем четыре условия: {A>1, B=0}, {A=2, X>1}. Для реализации метода требуется достаточное число тестов, такое, чтобы реализовать ситуации, где A>1, A1, B=0 и B0 в точке а и A=2, A2, X>1 и X1 в точке в. Тесты, удовлетворяющие критерию покрытия условий и соответствующие им пути:
A=2, B=0, X=4 ace A=1, B=1, X=0 abd.
^
Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз, все результаты каждого решения выполнялись по крайней мере один раз и, кроме того, каждой точке входа передавалось управление по крайней мере один раз.
^
а) A=2, B=0, X=4 ac eб) A=1, B=1, X=0 abd
отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)&(В=0)) примет значение ложь. Следовательно, недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий.
Д
ругая реализация рассматриваемого примера приведена на рисунке 2.2. Многоусловные решения исходной программы разбиты на отдельные решения и переходы. Для удовлетворения критерию решений необходимо покрытие тестами всех результатов каждого простого решения. Для этого нужно покрыть пути HILP (тест А=2, В=0, Х=4), HIMKT (тест А=3, В=1, Х=0), HJKT (тест А=0, В=0, Х=0), HJKR (тест А=0, В=0, Х=2).Рисунок 2.2. Реализация фрагмента программы с простыми логическими условиямиПротестировав алгоритм на рисунке 2.3, нетрудно убедиться в том, что критерии покрытия условий и критерии покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.
^ й
Критерием, который отчасти более чувствителен к ошибкам в логических условиях, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз. Набор тестов, удовлетворяющих критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.
По этому критерию в рассматриваемом примере должны быть покрыты тестами следующие восемь комбинаций:
а) A>1, B=0;б)A>1, B0;в) A1, B=0;г) А1, B0;д) A=2, X>1;е) A=2, X1;ж) А2, X>1;з) А2, X1;Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами:
- A=2, B=0, X=4 {покрывает а, д};
- A=2, B=1, X=1 {покрывает б, е};
- A=0,5, B=0, X=2 {покрывает в, ж};
- A=1, B=0, X=1 {покрывает г, з}.
Скачать файл (254.3 kb.)