ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9512
Скачиваний: 184
d = 0
e = 0 -
для
определения
типа
и
существования
второй
прямой
;
f = 0
б
)
для
определения
точки
пересечения
:
.
0
,
0
,
0
=
=
=
y
x
δ
δ
δ
Выделяем
три
группы
причинно
-
следственных
связей
(
определение
типа
и
существования
первой
линии
,
определение
типа
и
существования
второй
линии
,
определение
точки
пересечения
)
и
строим
таблицы
истинности
для
определения
типа
первой
прямой
(
табл
. 9.1)
и
для
определения
результата
(
табл
. 9.2).
В
обеих
таблицах
X
означает
неопределенное
значение
.
Для
второй
прямой
таблица
истинности
будет
выглядеть
аналогично
табл
. 9.1.
Каждая
строка
этих
таблиц
преобразуется
в
тест
.
При
возможности
(
с
учетом
независимости
групп
)
берутся
данные
,
соответствующие
строкам
сразу
двух
или
всех
трех
таблиц
.
Таблица
9.1
А
= 0
B = 0
C = 0
Результат
0
0
0
1
1
1
0
1
1
0
0
1
X
0
1
0
1
X
прямая
общего
положения
прямая
,
параллельная
оси
ОХ
ось
ОХ
прямая
,
параллельная
оси
ОУ
ось
ОУ
множество
точек
плоскости
Таблица
9.2
0
=
δ
0
=
x
δ
0
=
y
δ
Единственное
решение
Множество
решений
Решения
нет
0
1
1
1
X
0
X
1
X
X
0
1
1
0
0
0
0
0
0
1
0
1
1
0
В
результате
к
уже
имеющимся
тестам
добавляются
:
15-21)
проверки
всех
случаев
расположения
обеих
прямых
- 6
тестов
по
первой
прямой
совмещают
с
6-
ю
тестами
по
второй
прямой
так
,
чтобы
варианты
не
совпадали
(6
тестов
);
22)
проверка
несовпадения
условия
0
0
=
=
y
x
или
δ
δ
(
в
зависимости
от
того
,
какой
тест
был
выбран
по
методу
граничных
условий
) —
тест
также
можно
совместить
с
предыдущими
6-
ю
тестами
.
П о
м е т о д у
п р е д п о л о ж е н и я
о б
о ш и б к е
д о б а в и м
т е с т
:
23)
все
коэффициенты
-
нули
.
Всего
получили
23
теста
по
всем
четырем
методам
.
Для
каждого
теста
перед
применением
необходимо
указать
ожидаемый
результат
.
Если
попробовать
вложить
независимые
проверки
,
то
,
возможно
,
число
тестов
можно
еще
сократить
.
9.5.
Тестирования
модулей
и
комплексное
тестирование
Как
уже
упоминалось
в
§ 2.3
при
тестировании
модулей
программного
обеспечения
,
так
же
,
как
при
проектировании
и
кодировании
возможно
применение
как
восходящего
,
так
и
нисходящего
подходов
.
Восходящее
тестирование
.
Восходящий
подход
предполагает
,
что
каждый
модуль
тестируют
отдельно
на
соответствие
имеющимся
спецификациям
на
него
,
затем
собирают
оттестированные
модули
в
модули
более
высокой
степени
интеграции
и
тестируют
их
.
При
этом
проверяют
межмодульные
интерфейсы
,
используемые
для
подключения
модулей
более
низкого
уровня
ие
-
рархии
.
И
так
далее
,
пока
не
будет
собран
весь
программный
продукт
(
рис
. 9.3).
Такой
подход
обеспечивает
полностью
автономное
тестирование
,
для
которого
просто
генерировать
тестовые
последовательности
,
которые
передаются
в
модуль
напрямую
.
Однако
он
имеет
и
существенные
недостатки
.
Во
-
первых
,
при
восходящем
тестировании
так
же
,
как
при
восходящем
проектировании
,
серьезные
ошибки
в
спецификациях
,
алгоритмах
и
интерфейсе
могут
быть
обнаружены
только
на
завершающей
стадии
работы
над
проектом
.
Во
-
вторых
,
для
того
,
чтобы
тестировать
модули
нижних
уровней
,
необходимо
разработать
специальные
тестирующие
программы
,
которые
обеспечивают
вызов
интересующих
нас
модулей
с
необходимыми
параметрами
.
Причем
эти
тестирующие
программы
также
могут
содержать
ошибки
.
Нисходящее
тестирование
.
Нисходящее
тестирование
органически
связано
с
нисходящим
проектированием
и
разработкой
;
как
только
проектирование
какого
-
либо
модуля
заканчивается
,
его
кодируют
и
передают
на
тестирование
.
В
этом
случае
автономно
тестируется
только
основной
модуль
.
При
его
тестировании
все
вызываемые
им
модули
заменяют
модулями
,
которые
в
той
или
иной
степени
имитируют
поведение
вызываемых
модулей
(
рис
. 9.4).
Такие
модули
принято
называть
«
заглушками
».
В
отличие
от
тестирующих
программ
заглушки
очень
просты
,
например
,
они
могут
просто
фиксировать
,
что
им
передано
управление
.
Часто
заглушки
просто
возвращают
какие
-
либо
фиксированные
данные
.
Как
только
тестирование
основного
модуля
завершено
,
к
нему
подключают
модули
,
непосредственно
им
вызываемые
,
и
необходимые
заглушки
,
а
затем
проводят
их
совместное
тестирование
.
Далее
последовательно
подключают
следующие
модули
,
пока
не
будет
собрана
вся
система
.
Желательная
последовательность
сборки
обсуждалась
в
§ 2.3,
хотя
на
практике
ее
редко
удается
соблюдать
.
Основной
недостаток
нисходящего
тестирования
-
отсутствие
автономного
тестирования
модулей
.
Поскольку
модуль
получает
данные
не
непосредственно
,
а
через
вызывающий
модуль
,
то
гораздо
сложнее
обеспечить
его
«
достаточное
»
тестирование
.
Основным
достоинством
данного
метода
является
ранняя
проверка
основных
решений
и
качественное
многократное
тестирование
сопряжения
модулей
в
контексте
программного
обеспечения
.
При
нисходящем
тестировании
есть
возможность
согласования
с
заказчиком
внешнего
вида
(
интерфейса
)
программного
обеспечения
.
Комбинированный
подход
.
Чаще
всего
применяют
комбинированный
подход
:
модули
верхних
уровней
тестируют
нисходящим
способом
,
а
модули
нижних
уровней
-
восходящим
.
Этот
способ
позволяет
с
одной
стороны
начать
с
тестирования
интерфейса
,
с
другой
-
обеспечивает
качественное
автономное
тестирование
модулей
низших
уровней
.
Тестирование
программного
обеспечения
специалистами
.
Согласно
основным
принципам
нежелательно
тестирование
программного
обеспечения
его
автором
,
поэтому
эту
работу
,
как
правило
,
выполняют
другие
программисты
,
желательно
-
специалисты
в
этой
области
.
Задачей
специалиста
по
тестированию
является
обнаружение
максимального
количества
несоответствий
тестируемого
модуля
и
спецификаций
на
него
.
Для
выполнения
этой
задачи
специалист
по
тестированию
формирует
тесты
,
используя
как
структурный
,
так
и
функциональный
подходы
,
обеспечивая
всестороннее
тестирование
.
Каждое
отклонение
от
спецификации
обязательно
документируют
,
заполняя
специальный
протокол
(
рис
. 9.5).
Наиболее
интересными
полями
протокола
являются
тип
проблемы
и
ее
описание
.
В
поле
тип
проблемы
указывают
один
из
вариантов
:
1 -
ошибка
кодирования
-
программа
ведет
себя
не
так
,
как
следует
из
общепринятых
представлений
,
например
, 2 + 2 = 5 -
на
что
разработчик
может
выдать
резолюцию
«
соответствует
проекту
»;
2
-
ошибка
проектирования
—
программа
ведет
себя
в
соответствии
с
проектом
,
но
специалист
по
тестированию
не
согласен
с
данным
решением
в
проекте
-
на
что
разработчик
может
отреагировать
,
наложив
резолюцию
«
не
согласен
с
предложением
»; . 3 -
предложение
-
предложение
по
улучшению
проекта
;
4
-
расхождение
с
документацией
-
обнаружено
,
что
программа
ведет
себя
не
так
,
как
указано
в
документации
;
5
-
взаимодействие
с
аппаратурой
-
обнаружены
проблемы
при
использовании
определенного
вида
аппаратуры
;
6
-
вопрос
-
программа
делает
что
-
то
не
совсем
понятное
.
Описание
проблемы
должно
быть
коротким
и
понятным
,
например
:
«
Система
не
запоминает
настройки
принтера
,
выполняемые
в
окне
настройки
».
Если
программист
исправляет
ошибку
,
то
тестирование
повторяют
сначала
,
так
как
при
исправлении
ошибки
программист
может
внести
в
программу
новые
ошибки
.
Такое
тестирование
называют
«
регрессионным
».
Комплексное
тестирование
.
Особенностью
комплексного
тестирования
является
то
,
что
структурное
тестирование
для
него
практически
не
применимо
.
В
основном
на
данной
стадии
используют
тесты
,
построенные
по
методам
эквивалентных
классов
,
граничных
условий
и
предположении
об
ошибках
.
Критерии
завершения
тестирования
и
отладки
.
Одним
из
самых
сложных
является
вопрос
о
том
,
когда
следует
завершать
тестирование
,
поскольку
невозможно
гарантировать
,
что
в
разрабатываемом
программном
обеспечении
не
осталось
ошибок
.
Предложено
очень
много
критериев
.
Все
критерии
можно
разделить
на
три
группы
:
•
основанные
на
методологиях
проектирования
тестов
–
определенное
количество
тестов
,
полученных
по
методам
анализа
причинно
-
следственных
связей
,
анализа
граничных
значений
и
предположения
об
ошибке
,
перестают
выявлять
ошибки
;
•
основанные
на
оценке
возможного
количества
ошибок
-
возможное
количество
ошибок
оценивают
экспертно
,
или
по
специальным
методикам
[21],
а
затем
завершают
тестирование
при
нахождении
примерно
93-95%
ошибок
;
•
основанные
на
исследовании
результатов
тестирования
-
строят
график
зависимости
количества
обнаруженных
ошибок
от
времени
тестирования
,
если
он
напоминает
график
,
представленный
на
рис
. 9.6,
то
тестирование
можно
завершать
.