 |
Тестирование путем покрытия
|
|
|
|
Тестирование по принципу белого ящика характеризуются степенью покрытия тестами исходного кода программы. Если отказаться от исчерпывающего тестирования всех путей выполнения программы, то можно считать критерием покрытия выполнение каждого оператора хотя бы один раз. Это слабый критерий, поскольку мы сталкиваемся с необходимым, но недостаточным условием приемлемого тестирования.
Более сильный критерий называется покрытием решений. Согласно ему должно быть записано достаточное число тестов, такое, что каждое решение на этих тестах примет значение ИСТИНА и ЛОЖЬ по крайней мере один раз, то есть каждое направление перехода должно быть реализовано по крайней мере один раз.
Можно показать, что покрытие решений обычно удовлетворяет критерию покрытия операторов. Поскольку каждый оператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа в программу, при выполнении каждого направления перехода каждый оператор должен быть выполнен. Однако существует два исключения. Первое – ситуация, когда программа не имеет решений. Второе встречается в подпрограммах с несколькими точками входа.
Лучшим критерием по сравнению с предыдущими является покрытие условий. В этом случае составляют тесты так, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз.
Эквивалентное разбиение
Правильно составленный тест для подмножества оптимальных тестов должен обладать двумя свойствами:
1) уменьшать, причем более чем на единицу, число других тестов, которые должны быть разработаны для заранее определенной цели приемлемого тестирования;
|
|
|
2) покрывать значительную часть других возможных тестов, что свидетельствует о наличии или отсутствии ошибок до и после применения этого ограниченного множества значений входных данных.
Указанные свойства описывают два различных положения. Во-первых, каждый тест должен включать столько различных входных условий, сколько это возможно, с тем, чтобы минимизировать общее число необходимых тестов. Во-вторых, необходимо пытаться разбить входную область программы на конечное число классов эквивалентности так, чтобы можно было предположить, что каждый тест, являясь представителем определенного класса, эквивалентен другому тесту этого класса. Если один тест класса эквивалентности обнаруживает ошибку, то и другие тесты этого класса будут обнаруживать ту же ошибку.
Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:
1) выделение классов эквивалентности;
2) построение тестов.
Выделение классов эквивалентности.
Классы эквивалентности выделяются путем выбора каждого входного условия и разбиением его на две или более групп. Различают два типа таких классов: правильные классы эквивалентности, представляющие правильные входные данные программы, и неправильные классы эквивалентности, представляющие все другие возможные состояния условий.
При выделении классов эквивалентности существует ряд правил:
1. Если входное условие описывает область значений(например, «переменная может принимать целое значение от 0 до 100»), то определяется один правильный класс эквивалентности (0<=целое<=100) и два неправильных (целое <0 и целое>100).
2. Если входное условие описывает число значений (например, «студентов может быть не меньше двадцати и не больше двухсот»), то определяется один правильный класс и два неправильных (меньше двадцати и больше двухсот).
3. Если входное условие описывает множество входных значений и каждое значение трактуется особо, то определяется правильный класс эквивалентности для каждого значения и один неправильный класс.
|
|
|
4. Если входное условие описывает ситуацию «должно быть» (например, «первый символ строки – заглавная буква»), то определяется один правильный класс эквивалентности (первый символ – заглавная буква) и один – неправильный (первый символ – не заглавная буква).
5. Если есть основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс разбивается на меньшие классы эквивалентности.
Построение тестов.
Данный процесс включает в себя:
1. Назначение каждому классу эквивалентности уникального номера.
2. Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов, до тех пор, пока все правильные классы не будут покрыты.
3. Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов, до тех пор, пока все неправильные классы не будут покрыты тестами.
Причина покрытия неправильных классов индивидуальными тестами состоит в том, что определенные проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами.
Анализ граничных значений
Граничные условия – это ситуации, возникающие непосредственно на границах, выше или ниже границ входных и выходных классов эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:
4. Выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса.
5. При разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов (выходные классы эквивалентности).
Общая методика построения тестов может быть приведена как следующий набор рекомендаций:
1. Построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений.
2. Построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих значений, если входное условие удовлетворяет дискретному ряду значений.
|
|
|
3. Использовать правило 1 для каждого выходного условия.
4. Использовать правило 2 для каждого выходного условия.
5. Если вход или выход программы представляет собой упорядоченное множество (файл, список, таблица), то сосредоточить внимание на первом и последнем элементе этого множества.
6. Попробовать найти другие граничные условия.
Функциональные диаграммы
Одним из недостатков анализа граничных значений и эквивалентного разбиения является то, что они не используют комбинаций входных условий. Тестирование комбинаций входных условий является непростой задачей, поскольку их количество обычно очень велико. Если нет систематического способа выбора подмножества входных условий, то выбирается произвольное подмножество, приводящее к неэффективному тесту.
Метод функциональных диаграмм помогает выбирать высокорезультативные тесты, а также дает полезный побочный эффект по обнаружению полноту и неоднозначность исходных спецификаций.
Функциональная диаграмма (ФД) представляет собой формальный язык, на который транслируется спецификация, написанная на естественном языке. Диаграмме можно сопоставить цифровую логическую цепь (комбинаторную логическую цепь), но для ее описания используется более простая форма, чем запись, принятая в электронике.
Построение тестов осуществляется в несколько этапов:
1. Спецификация разбивается на рабочие участки небольшого размера.
2. В спецификации определяются причины и следствия. Причина есть отдельное входное условие или класс эквивалентности входных условий. Следствие есть выходное условие или результат преобразования системы. Например, если сообщение программе приводит к обновлению файла, то изменение в нем и является преобразованием системы. Причины и следствия определяются путем последовательного (слово за словом) чтения спецификации. При этом выделяются слова и фразы, которые описывают причины и следствия. Каждой причине и следствию приписывается отдельный номер.
|
|
|
3. Анализируется семантическое содержание спецификации, которая преобразуется в булевский граф, связывающий причины и следствия. Это и есть функциональная диаграмма.
4. Диаграмма снабжается примечаниями, задающими ограничения и описывающими комбинации причин и следствий, которые являются невозможными из-за синтаксических или внешних ограничений.
5. Путем методического прослеживания состояний условий диаграммы она преобразуется в таблицу решений с ограниченными входами. Каждый столбец таблицы решений соответствует тесту.
6. Столбцы таблицы решений преобразуются в тесты.
Прекращение тестирования
Когда можно считать программу протестированной?
Людям свойственно ошибаться при любом виде деятельности, в том числе и при создании программ. Конечно, эти ошибки неумышленные и человек, в конце концов, их исправит, но как говорят, программ без ошибок не бывает, и на некотором этапе тестирования возникает вопрос, стоит ли дальше искать ошибки или смириться с их некоторым количеством до поры до времени. Этот вопрос подводит нас к определению критериев, по которым можно судить, что программа более или менее работоспособна.
Сократить количество ошибок можно несколькими путями:
· применить специальные методы и средства написания программ, например, CASE-средства Rational Rose;
· применить надежные, многократно протестированные компоненты и библиотеки;
· строго соблюдать и главное контролировать соответствие создаваемых программ проектной документации.
Одной из основных особенностей тестирования является отсутствие эталона программы, с которым можно было бы сравнить нечто уже созданное. Из этого истекает трудность определения момента, когда необходимое качество программы достигнуто.
Основным эталоном в этом случае будет проектная документация, которая приводит разницу взглядов различных людей на качество программы к одному знаменателю. При отсутствии такой документации, в принципе невозможно протестировать программу, поскольку взгляд на объем и качество выполняемых функций не совпадает не только у разных людей, но и может различаться у одного человека в разные промежутки времени.
Поэтому важно определить несколько уровней достижения необходимого качества программ:
· отсутствие синтаксических ошибок и аварийных остановок в программе, что достигается прогоном программы с различными данными по максимальному числу ветвей. Для определения участков, которые ни разу небыли запущены при прогоне программы, существуют специальные средства, например Rational Pure Coverage.
|
|
|
· выполняемые функции программ соответствуют технической документации;
· расчетные значения, полученные при помощи процедур расчета, соответствуют эталонным.
Часто первые два уровня можно тестировать одновременно, внося коррективы в сопроводительную документацию. Последний пункт самый длительный и трудно тестируемый, невозможно подготовить тест на все возможные сочетания данных, поэтому существует так называемое бета-тестирование, т.е. тестирование самими пользователями.
Теперь, когда некоторые критерии тестирование были здесь упомянуты, можно ответить на вопрос, вынесенный в заголовок раздела.
Первый этап тестирования можно прекращать, когда есть уверенность, что большая часть синтаксических ошибок и аварийный остановов устранена. Остальные постепенно будут устраняться в процессе других этапов тестирования.
Второй этап тестирования можно прекращать, когда большая часть функциональности проверена и работает в соответствии с проектной документацией. Остальные несоответствия будут устраняться в процессе написания сопроводительной документации.
И наконец, третий этап тестирования можно прекращать, когда основные расчетные тесты дают правильные результаты.
Тестирование пользователями будет продолжаться на всем этапе жизненного цикла программного обеспечения, и вплоть до смены ПО на более современное, пользователи будут находить в нем неточности и ошибки.
Контрольные вопросы:
1) Что такое исчерпывающее входное тестирование?
2) В чем состоит суть технологии «белый ящик»?
3) Как можно протестировать программу, не имея ее исходного кода? Не имея ее исполняемого файла?
4) Какие методы тестирования включает в себя технология «белого ящика»?
5) Что означает термин «покрытие» применительно к тестированию?
6) Когда следует прекращать тестирование?
Лекция 5. Тестирование без компьютера
Цель : изучить процедуры проведения тестов без использования компьютера, а также рассмотреть вопрос о влиянии особенностей языка программирования на процесс тестирования.
Существует широко распространенное мнение, особенно у начинающих программистов, что проверить правильность функционирования программы можно только на компьютере, а исходный текст программы – дело малозначительное. Это -глубокое заблуждение, почти всегда граничащее с небрежностью оформления кода, низкой самодокументируемостью, а в конечном итоге – с ошибочностью. Конечно, подозревать плохо оформленный текст программы в некорректности можно не всегда, но полезно.
Главное условие выявления большинства ошибок еще на этапе подготовки программы заключается в таком ее оформлении, чтобы главные ошибки были обнаружены на этапе просмотра и изучения исходного текста. Плохо оформленная программа препятствует этому и тормозит процесс тестирования.
В этой лекции мы рассмотрим наиболее важные процедуры тестирования, связанные с анализом исходного кода. К ним относятся: инспекции, сквозные просмотры и обзоры программы.
Инспекции исходного текста и сквозные просмотры являются основными методами ручного тестирования. Они включают в себя чтение и визуальную проверку программы группой лиц (обычно 3-4 человека, среди них – автор программы или ее части). Оба этих метода развиты из идей Вейнберга [2].
Эксперименты по использованию этих методов показали, что с их помощью для типичных программ можно находить от 30% до 70% ошибок логического проектирования и кодирования [1, с.34]. Однако они не очень эффективны при определении ошибок проектирования высокого уровня, например, сделанных в процессе анализа требований.
|
|
|
