ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10776
Скачиваний: 8
166
6.4.5 Предположение об ошибке
Замечено,
что
некоторые
люди
по
своим
качествам
ока-
зываются
прекрасными
специалистами
по
тестированию
про-
грамм.
Они
обладают
умением
«выискивать»
ошибки
и
без
привлечения
какой-либо
методологии
тестирования
(такой,
как
анализ
граничных
значений
или
применение
функциональных
диа-
грамм).
Объясняется
это
тем,
что
человек,
обладающий
практиче-
ским
опытом,
часто
подсознательно
применяет
метод
проекти-
рования
тестов,
называемый
предположением
об
ошибке.
При
наличии
определенной
программы
он
интуитивно
предполагает
вероятные
типы
ошибок
и
затем
разрабатывает
тесты
для
их
обнаружения.
Процедуру
для
метода
предположения
об
ошибке
описать
трудно,
так
как
он
в
значительной
степени
является
интуитив-
ным.
Основная
идея
его
заключается
в
том,
чтобы
перечислить
в
некотором
списке
возможные
ошибки
или
ситуации,
в
кото-
рых
они
могут
появиться,
а
затем
на
основе
этого
списка
напи-
сать
тесты.
Например,
такая
ситуация
возникает
при
значении
0
на
входе
и
выходе
программы.
Следовательно,
можно
постро-
ить
тесты,
для
которых
определенные
входные
данные
имеют
нулевые
значения
и
для
которых
определенные
выходные
дан-
ные
устанавливаются
на
0.
При
переменном
числе
входов
или
выходов
(например,
число
искомых
входных
записей
при
поис-
ке
в
списке)
ошибки
возможны
в
ситуациях
типа
«никакой»
и
«один»
(например,
пустой
список,
список,
содержащий
только
одну
искомую
запись).
Другая
идея
состоит
в
том,
чтобы
опре-
делить
тесты,
связанные
с
предположениями,
которые
про-
граммист
может
сделать
во
время
чтения
спецификаций
(т.е.
моменты,
которые
были
опущены
из
спецификации
либо
слу-
чайно,
либо
из-за
того,
что
автор
спецификации
считал
их
оче-
видными).
Поскольку
данная
процедура
не
может
быть
четко
опре-
делена,
лучшим
способом
обсуждения
смысла
предположения
об
ошибке
представляется
разбор
примеров.
Если
в
качестве
примера
рассмотреть
тестирование
подпрограммы
сортировки,
то
нужно
исследовать
следующие
ситуации:
167
1.
Сортируемый
список
пуст.
2.
Сортируемый
список
содержит
только
одно
значение.
3.
Все
записи
в
сортируемом
списке
имеют
одно
и
то же
значение.
4.
Список
уже
отсортирован.
Другими
словами,
требуется
перечислить
те
специальные
случаи,
которые
могут
быть
не
учтены
при
проектировании
про-
граммы.
Если
пример
заключается
в
тестировании
подпрограммы
двоичного
поиска,
то
можно
проверить
следующие
ситуации:
1)
существует
только
один
вход
в
таблицу,
в
которой
ве-
дется
поиск;
2)
размер
таблицы
есть
степень
двух
(например,
16);
3)
размер
таблицы
меньше
или
больше
степени
двух
(на-
пример,
15
или
17).
Рассмотрим
программу
MTEST,
приведенную
в
разделе,
посвященном
анализу
граничных
значений.
При
тестировании
этой
программы
методом
предположения
об
ошибке
целесооб-
разно
учесть
следующие
дополнительные
тесты:
1.
Допускает
ли
программа
«пробел»
в
качестве
ответа?
2.
Запись
типа
2
(ответ)
появляется
в
наборе
записей
типа
3
(студент).
3.
Запись
без
2
или
3
в
последней
колонке
появляется
не
как
начальная
запись
(название).
4.
Два
студента
имеют
одно
и
то
же
имя
или
номер.
5.
Поскольку
медиана
вычисляется
по-разному
в
зависи-
мости
от
того,
четно
или
нечетно
число
элементов,
не-
обходимо
протестировать
программу
как
для
четного,
так
и
для
нечетного
числа
студентов.
6.
Поле
числа
вопросов
имеет
отрицательное
значение.
Для
команды
DISPLAY
из
предыдущего
раздела
целесо-
образно
рассмотреть
следующие
тесты
метода
предположения
об
ошибке:
1.
DISPLAY
100
—
(неполный
второй
операнд).
2.
DISPLAY
100.
(неполный
второй
операнд).
3.
DISPLAY
100
—
10А42
(слишком
большое
значение
операнда).
4.
DISPLAY
000
—
0000FF
(нули
слева).
168
6.4.6 Стратегия
Методологии
проектирования
тестов,
обсуждавшиеся
в
этом
разделе,
могут
быть
объединены
в
общую
стратегию.
Причина
объединения
их
теперь
становится
очевидной:
каждый
метод
обеспечивает
создание
определенного
набора
используе-
мых
тестов,
но
ни
один
из
них
сам
по
себе
не
может
дать
пол-
ный
набор
тестов.
Приемлемая
стратегия
состоит
в
следующем:
1.
Если
спецификация
содержит
комбинации
входных
ус-
ловий,
то
начать
рекомендуется
с
применения
метода
функцио-
нальных
диаграмм.
2.
В
любом
случае
необходимо
использовать
анализ
гра-
ничных
значений.
Напомним,
что
этот
метод
включает
анализ
граничных
значений
входных
и
выходных
переменных.
Анализ
граничных
значений
дает
набор
дополнительных
тестовых
ус-
ловий,
но
многие
из
них
(если
не
все)
могут
быть
включены
в
тесты
метода
функциональных
диаграмм.
3.
Определить
правильные
и
неправильные
классы
экви-
валентности
для
входных
и
выходных
данных
и
дополнить,
ес-
ли
это
необходимо,
тесты,
построенные
на
предыдущих
шагах.
4.
Для
получения
дополнительных
тестов
рекомендуется
использовать
метод
предположения
об
ошибке.
5.
Проверить
логику
программы
на
полученном
наборе
тестов.
Для
этого
нужно
воспользоваться
критерием
покрытия
решений,
покрытия
условий,
покрытия
решений/условий
либо
комбинаторного
покрытия
условий
(последний
критерий
явля-
ется
более
полным).
Если
необходимость
выполнения
критерия
покрытия
приводит
к
построению
тестов,
не
встречающихся
среди
построенных
на
предыдущих
четырех
шагах,
и
если
этот
критерий
не
является
нереализуемым
(т.е.
определенные
ком-
бинации
условий
невозможно
создать
вследствие
природы
про-
граммы),
то
следует
дополнить
уже
построенный
набор
тестов
тестами,
число
которых
достаточно
для
удовлетворения
крите-
рия
покрытия.
Эта
стратегия,
опять-таки,
не
гарантирует,
что
все
ошиб-
ки
будут
найдены,
но,
вместе
с
тем,
ее
применение
обеспечива-
ет
приемлемый
компромисс.
Реализация
подобной
стратегии
169
весьма
трудоемка,
но
ведь
никто
и
никогда
не
утверждал,
что
тестирование
программы
—
легкое
дело.
Контрольные
вопросы
1.
Определение процесса тестирования. Определение хо-
рошего теста. Определение хорошего прогона.
2.
Тестирование программы как черного и белого ящика.
3.
Принципы тестирования.
4.
Технологии ручного тестирования. Инспекции исход-
ного текста. Сквозные просмотры. Метод оценки про-
грамм посредством просмотра.
5.
Принципы проектирования теста.
6.
Технологии тестирования по принципу белого ящика.
Покрытие операторов. Покрытие решений. Покрытие
условий. Покрытие решений/условий. Комбинаторное
покрытие условий.
7.
Технологии тестирования по принципу черного ящика.
8.
Эквивалентное разбиение. Способы формирования
классов эквивалентности. Правила создания тестов по
классам эквивалентности.
9.
Анализ граничных значений.
10.
Применение функциональных диаграмм. Способы за-
дания ограничений на вход и выход. Технология по-
строения функциональных диаграмм. Технология по-
строения таблицы решений. Формирование тестов по
таблице решений.
11.
Предположение об ошибке.
12.
Стратегия тестирования.
170
7
ТЕХНОЛОГИЯ
РАЗРАБОТКИ
ПРОГРАММ
Хотя
разработка
программ
является
в
основном
творче-
ской
деятельностью,
существует
множество
стандартных
алго-
ритмов,
которые
могут
применяться
для
упрощения
данного
процесса.
Знание
этих
алгоритмов
часто
облегчает
формулиро-
вание
задачи.
7.1
Разбиение
задачи
на
независимые
подзадачи
Основным
алгоритмом,
используемым
для
решения
задач,
является
алгоритм
разбиения
на
независимые
подзадачи.
Для
того,
чтобы
решить
задачу
A
,
ее
первоначально
необходимо
разбить
на
независимые
подзадачи
B
,
C
,
D
и
т.д.
A: procedure;
Задача B;
Задача C;
Задача D;
end
A;
Решение
подзадач
может
производиться
по
любому
алго-
ритму.
7.2
Разбиение
задачи
на
одинаковые
по
сложности
части
Этот
метод,
как
и
первый,
наиболее
часто
используется
в
программировании.
Данный
подход
означает
разделение
задачи
на
подзадачи,
равные
примерно
по
сложности,
для
того
чтобы
перейти
к
решению
значительно
более
простых
задач,
чем
пер
-
воначальная.
Поиск
нужного
элемента
в
таблице
является
ха-
рактерным
примером
такого
алгоритма:
−
проверить
первый
элемент;
−
if
заданный
элемент
не
найден,
then
продолжить
поиск
среди
оставшихся
элементов.
Таким
образом,
задача
разбивается
на
две
части:
проверку
первого
элемента
и
поиск
среди
оставшихся.
Ясно,
что
такие