Ряд программ имеет функциональные границы, порождающие большое количество тестовых комбинаций. Предположим, что необходимо проверить модуль, выполняющий контроль вводимых записей. Функциональные границы проявляются в том случае, когда введенный список пуст, содержит только одну запись, введенные записи уже рассортированы и когда введенные данные имеют равные значения. По каждому из возможных вариантов следует выполнять проверки и принимать решение.
Обязательным условием тестирования является назначение тестовых комбинаций для недействительных условий. Если проверяемый модуль не полностью определен, то его проведение следует считать недействительным.
Недействительные вводы, используемые в программах тестирования, могут лежать вне пределов действительных входных данных.
Завершающие шаги назначения тестовых комбинаций базируются на проверке логики модуля. Для выбираемого множества тестовых комбинаций в качестве критерия полноты может выступать утверждение о том, что каждая команда контролируемого модуля выполняется хотя бы один раз. Этот критерий необходим, но он не является часто выполнимым. Лучшим критерием является обеспечение достаточного количества тестовых условий, позволяющих для каждой проектируемой конструкции в модуле, которая порождает многовариантный переход, прохождение каждой ветви. Для автоматизации выполнения контроля лучшим решением будет построение графсхемы программы модуля и на ее основе получение необходимых тестовых комбинаций, которые обеспечивают пошаговый контроль за выполнением программы.
Последним шагом проектирования тестовой программы является проверка логической схемы модуля на чувствительность к различным входным характеристикам. Здесь же необходимо предусмотреть контроль границ обрабатываемых массивов.
Получение полного набора тестовых комбинаций для модуля может показаться трудоемким, но никто и никогда не утверждал, что проверка - короткое и необременительное занятие. Следуя перечисленным выше шагам тестовых комбинаций, придем к принципиальной спроектированной программе тестирования с высоким уровнем обнаружения ошибок. Этот процесс займет больше времени, чем случайный процесс подбора тестовых комбинаций, но если он ведет к возможности обнаружения одной двух дополнительных ошибок, стоит пренебречь потерей времени тщательного подбора программы тестирования.
Очевидным этапом тестирования является написание и контроль проверочных программ. Физическая форма проверочных программ в определенной мере диктуется методом проведения интеграции, рассмотренным ранее. Сам процесс написания проверочных программ прост и сводится к написанию небольших программ вызова проверяемых модулей, подключений их на пропуск тестовых комбинаций и документирование результатов пропуска. С целью уменьшения объема выдаваемых результатов лучшим вариантом признается программирование контроля выходных результатов в программе формирования обращения к модулю там, где это возможно.
В идеальном случае проверочная программа должна быть проконтролирована перед тем, как использовать ее для тестирования. Это могут выполнить только разработчики, создавшие такую программу. Однако ясно, что такие программы могут, в принципе, содержать ошибки.
Критической частью работы по тестированию модуля является пропуск проверочной программы и проверка получаемых результатов. Общей ошибкой проектирования тестовых программ являются большие затраты времени для обнаружения ошибок, а также то, что до получения действительного вывода важно получить ожидаемый вывод каким-либо возможным способом.
Существует много способов, которые не могут быть обнаружены в результате рассмотрения входных характеристик модуля. Ряд ошибок может быть классифицирован как ошибочные побочные эффекты, определение которых затруднено. Единичную проверку модуля лучше выполнять не непосредственному разработчику, а лицу, которое разрабатывало модуль, вызывающий этот проверяемый модуль.
Если программа состоит из наиболее мелких независимых модулей, то каждый модуль может быть независимо проверен для всех возможных комбинаций, поскольку их количество для небольших модулей невелико. Если программа хорошо структурирована, необходимо проверять только интерфейс между различными проверенными ранее модулями, что осуществимо и при проверке всех вариантов интерфейса. Чтобы иметь возможность строить программу, таким образом, необходимо при определении структуры включить требования "проверяемости".
Известно, что обычные методы отладки не удовлетворяют всем необходимым требованиям, за исключением небольших программ, а методы доказательства математической корректности программ находятся еще в периоде становления. Тем не менее, первые шаги к созданию таких методов уже сделаны. Однако, до тех пор, пока не станут доступными общие методы доказательства корректности, большинство программистов вынуждено будет работать с тестовыми данными. Существует несколько средств отладки, позволяющих исключить (упростить) трудоемкие отладочные методы.
Тестирование структуры программных модулей
Тестирование структуры программ или потоков управления может проводиться вручную на символическом уровне и при детерминированном исполнении программы в процессе обработки реальных тестовых данных. При планировании тестирования структуры программ возникают две задачи:
а) формирование критериев выделения маршрутов для тестирования;
б) выбор стратегий упорядочения выделенных маршрутов.
Критерии выделения маршрутов
Критерии выделения маршрутов для тестирования соответствуют критериям определения структурной сложности программных модулей.
В реальных программах часть маршрутов может быть нереализуемой вследствие противоречий в условиях, анализируемых на последовательных участках маршрута. Это обстоятельство может приводить к значительному сокращению числа маршрутов по любому критерию. Невыполнение правил структурного построения программ, наоборот, может приводить к возрастанию числа маршрутов. К значительному возрастанию числа маршрутов обычно приводят циклы в программах.
Стратегии упорядочения маршрутов
Для эффективного тестирования необходимо все множество выделенных маршрутов упорядочить по некоторому показателю и подготавливать тесты в соответствии с выбранной стратегией. Проверка основной группы маршрутов с экстремальными значениями показателя в пределах ресурсов, выделенных для тестирования, характеризует достигнутую корректность данной программы по выбранному критерию. Упорядочение маршрутов при планировании тестирования базируется на использовании в основном трех характеристик программных модулей: (рисунок 2.2) числа команд в выделенных маршрутах или расчетной длительности их реализации (стратегия 1); числа альтернатив или условных переходов, определяющих образование каждого маршрута (стратегия 2); вероятности исполнения маршрутов при реальном функционировании программы (стратегия 3).
Рисунок 2.2 - Стратегии упорядочения маршрутов
Скачать реферат