Романова Т.Н. Тестирование программного обеспечения - файл n1.doc

приобрести
Романова Т.Н. Тестирование программного обеспечения
скачать (260.5 kb.)
Доступные файлы (1):
n1.doc261kb.08.07.2012 20:58скачать

n1.doc

  1   2   3



Московский государственный технический университет

имени Н.Э. Баумана



Романова Т.Н.

Тестирование программного обеспечения



Учебное пособие по курсу


«Технология программирования» по специальности «Программное обеспечение ЭВМ и информационные технологии»

Москва 2003 г.


Содержание

Стр.

Введение................................................................................................3


  1. Основные понятия процесса тестирования ................................4

1.1. Особенности тестирования программных компонент............................4

    1. Виды и методы тестирования.......................................................................5

    2. Структурное тестирование. Критерии структурного тестирования....6

      1. Тестирование на основе потока управления..................................6

      2. Тестирование на основе потока данных..........................................7

      3. Методы проектирования тестовых путей.......................................7

      4. Оценка степени тестированности программного проекта.........9

      5. Примеры построения тестов «белого ящика»............................12

    3. Функциональное тестирование – принцип « черного ящика ».........13

1.4.1. Метод эквивалентного разбиения....................................................14

      1. Анализ граничных значений...........................................................14

      2. Метод функциональных диаграмм причинно-следственных

Связей...................................................................................................15

1.4.4. Тестирование потока транзакций...................................................15

      1. Метод предположения об ошибке..................................................16

      2. Общая стратегия функционального тестирования....................17

      3. Примеры функционального тестирования..................................17

  1. Разработка эффективных наборов тестов « черного ящика »29

2.1. Характеристики хорошего теста................................................................29

2.2. Тестирование переходов между состояниями.........................................30

2.3. Условия гонок и другие временные зависимости..................................32

2.4. Нагрузочные испытания.............................................................................34

2.5. Тестирование функциональной эквивалентности.................................35

2.6. Применение технологии эквивалентности..............................................41

3. Задание для самостоятельной работы...........................................42

Литература ........................................................................................43
Введение
Данная работа имеет цель – познакомить студентов с приемами и методами современного тестирования. В первой части учебного пособия рассказывается о современном подходе к тестированию программного продукта, о методике интегральной оценки тестированности программного проекта, представляющей возможность управления качеством создаваемого продукта. Приводятся примеры построения тестов по методикам, описанным в данном разделе. Во второй части учебного пособия приводятся практически советы и рекомендации специалисту по тестированию, который будет тестировать программые коды, написанные кем-то другим. Предлагаемые подходы к разработке эффективных наборов тестов помогут выявить все проблемы, которые могут возникнуть при работе с программным продуктом, и сделать все возможное для улучшения его качества.

Чтобы процесс тестирования был эффективным, он должен быть задокументированным и повторяемым. В данной работе предлагается простой и удобный подход к проведению и документированию всех этапов тестирования. Кроме того, приводится актуальный подход к построению численной оценки тестированности программного обеспечения, которая может служить одной из метрик общей оценки качества программного продукта.

1. Основные понятия процесса тестирования

    1. Особенности тестирования программных компонент.

Опыт создания и применения сложных информационных систем выявил множество ситуаций, при которых сбои и отказы их функционирования были обусловлены дефектами комплексов программ и отражались большим ущербом. Вследствие ошибок в программах автоматического управления погибло несколько российских, американских и французских спутников, происходили отказы и катастрофы в сложных административных, банковских и технологических информационных системах.

Все возрастающая сложность разрабатываемых программных комплексов диктует повышенные требования к качеству и надежности информационных систем. Контроль надежности и безопасности создаваемых и модифицируемых программ должен сопровождать весь жизненный цикл программных средств (ПС). Следует тестировать ПС на всех этапах разработки и применять различные методы и виды тестирования.

Масштаб компонент имеет принципиальное значение при создании или выборе методов и технологии их разработки. Невысокая размерность программного модуля (ПМ) обеспечивает их обозримость и возможность детального анализа функций, структуры и процесса решения задач. Нужно стремиться к снижению сложности отладки путём многократного использования программных компонент.Этого можно достичь только при чёткой формализации их функций и условий применения. Поэтому завершать отладку и испытания ПМ следует их аттестацией с приложением характеристик полноты тестирования и диапазонов варьирования тестовых данных.

Особенности тестирования компонент ПМ

Любые методы отладок ориентированы на обнаружение ошибок определённых типов.

1.2. Виды и методы тестирования.

Детерминированное тестирование (ДТ)– это наиболее эффективный метод тестирования, при котором задаются конкретные совокупности исходных данных, которым соответствуют также конкретные значения эталонных результатов. Этот метод позволят не только обнаружить ошибку, но и в ряде случаев локализовать её.

ДТ основывается на двух подходах:

1.3. Структурное тестирование. Критерии структурного подхода

1.3.1. Тестирование на основе потока управления

Тестирование по принципу «белого ящика» характеризуется степенью, в какой тесты выполняют или покрывают логику программы (исходный текст). Элементами, которые должны быть покрыты при прохождения тестов, являются вершины, дуги или подпути управляющего графа программы (УГП), условие, комбинации условий и т. п.

С0 – критерий покрытия операторов, заключается в выполнении каждого оператора хотя бы один раз. Это очень слабый критерий и не является достаточным.

С1 - критерий покрытия решений, заключается в том, что хотя бы по одному разу должны быть выполнены каждый возможный результат всех решений и передача управления при вызове программы или подпрограммы каждой точке входа. С точки зрения УГП, покрытие решений заключается в том, чтобы каждая его дуга и входная вершина содержались по крайней мере в одном из путей тестирования.

Критерий С1 также не может гарантировать выявления всех ошибок в программе.

С2 - критерий покрытия всех путей в УГП .

Например, рассмотрим фрагмент программы на С,С++,ADA:

If (cond1 && ( cond2 || func1()))

statment1;

else statment2;

Покрытие решений (ветвей) может быть достигнуто без вызова func1().

Условия cond1 и cond2, принимая значение true, как бы закрывают вызов функции func1(), что при условии cond1=false может привести к ошибкам в непокрытой тестами части программы.

Исходя из важности проверки всех возможных вариантов значений в булевских выражениях , вводиться критерий покрытия всех условий (булевских).

Критерий покрытия условий/решений совмещаеткритерий С1 и критерий покрытия условий.

1.3.2. Тестирование на основе потока данных

Первоначально анализ потока данных использовался при статистическом тестировании программ для выявления ссылок на не инициализируемые переменные и выявление избыточных присваиваний(аномалий потока данных). Данная стратегия требует тестирования всех взаимосвязей , включающих в себя ссылку и определение переменной, на которую указывает ссылка ,то есть должны покрываться дуги информационного графа программы. Недостаток стратегии заключается в том, что она не включает критерий С1 и не гарантирует покрытия решений.

Наиболее практичным является критерий СР (покрытие пар достижимых дуг). Этот критерий заключается в том, что покрываются все такие пары дуг V и W, что из дуги V достижима дуга W. То есть , фактически, кроме вершины , в которой определена переменная , тестируются и входящие в неё дуги.

1.3.3. Методы проектирования тестовых путей.

Процесс построения набора тестов при структурном тестировании принято делить на 3 фазы [2]: 1)конструирование УГП; 2) выбор тестовых путей; 3)генерация тестов, соответствующих тестовым путям.

Первая фаза - статическая. Получаем граф программы и, зависящие от него и критерия тестирования, множество элементов, которые необходимо покрыть тестами.

Вторая фаза – выбор тестовых путей. Методы построения тестовых путей делятся на:

  1. Статические методы( эвристические, адаптивные)

  2. Динамические методы

  3. Методы реализуемых путей.

На третьей фазе необходимо по путям тестирования найти подходящие тесты, реализующие прохождение этих путей.

Каждый путь описывается конъюнктивным предикатом:

Pred(i)=C1^C2^…^Сn, где каждый предикат Сi соответствует переходу из вершины – решения и задаётся в этой вершине.

Реальный предикат Pred(i) получается в процессе «обратной подстановки», т.е. в результате должна быть решена система нелинейных равенств и неравенств, реализующих тест.

Статические методы

Эвристические методы позволяют строить тестовый каждый путь по аналогии с выполнением программы путём постепенного удлинения графа за счёт добавления дуг, пока не будет построен УГП.

Адаптивные методы появились последнее время. Суть их состоит в том, что бы каждый раз добавлять только один тестовый путь (входной тест), используя предыдущие пути как руководство для выбора последующих путей в соответствии с некоторой индуктивной стратегией. Чаще всего адаптивные стратегии применяются по отношению к критерию С1. С точки зрения практической реализации для каждой покрытой вершины решения, из которой выходит хотя бы одна непокрытая дуга, необходимо модифицировать тест так, что бы при минимальных затратах (минимальность пути ) достичь указанную вершину. Статические методы трудно реализуемы для больших систем.

Динамические методы.

Дают возможность построить полную систему тестов, удовлетворяющих заданному критерию. Это построение покрывающего множества путей и тестовых данных одновременно. Основная идея методов – подсоединение к начальным реализуемым отрезкам путей дальнейших их частей так, чтобы не терять при этом реализуемости вновь полученных путей и покрыть требуемые элементы структуры программы.

Третья группа методов –методы реализуемых путей.Основная стратегия заключается в выделении из множества всех путей подмножества реализуемых путей и по ним построить покрывающее множество путей. Каждый из перечисленных методов имеет свои достоинства и недостатки. Поэтому их следует использовать совместно.

Достоинство статических методов в сравнительно небольших требуемых ресурсах как при использовании, так и при разработке ( последнее очень важно, т.к. пока промышленных систем построения покрывающего множества путей для основных языков программирования нет). Однако реализация этих систем может содержать заранее непредсказуемый процент брака (нереализуемых путей). Кроме того, в этих системах переход от покрывающего множества путей к полной системе тестов пользователь должен осуществить вручную, а это трудоёмко.

Динамические методы требуют больших ресурсов как при разработке, так и при эксплуатации, однако увеличение этих затрат происходит за счёт разработки и эксплуатации аппарата определения реализуемости путей( символический интерпретатор, решатель неравенств ). Методы реализуемых путей дают наиболее качественный результат. Однако их применение из-за сложности для широкого класса задач проблематично.

1.34. Оценка степени тестированности программного проекта.

Степень тестированности программы всегда считалась одним из показателей её качества. Из литературы известно, что построение полного набора тестов для программы невозможно. Поэтому необходимо проектировать разработку «эффективных» тестов, позволяющих достичь достаточного уровня тестируемости ПО при ограниченных трудозатратах, на практике не превышающих 30-40% от общего времени разработки проекта.

Введённые выше критерии тестирования С0, С1, С2 для структурного тестирования позволяют формализовать оценку достаточности проведенного тестирования для любой программы, т.к. всегда существует возможность построения графовой модели программы (ГМП) и, следовательно, точной оценки числа необходимых тестов. Данное свойство является преимуществом структурных критериев по сравнению с критериями и методами функционального тестирования.

Для описания математических оценок степени тестирования программы введем несколько базовых определений [2]:

1. Тестирование программы Р по некоторому критерию С заключается в покрытии множества М требуемых элементов mi , соответствующих элементам и/или взаимосвязям между элементами некоторой модели программы: - множество требуемых элементов для тестирования. Для структурного тестирования элементами mi являются вершины (узлы), дуги и подпути ГМП.

Пусть выполняемые тесты ti составляют упорядоченное множество тестов . Будем понимать под ti структуру теста – входные и выходные значения, среду выполнения.

  1. Тест ti называется неизбыточным для тестирования по критерию С, если существует покрываемый им элемент mi из множества М(Р, С), не покрытый ни одним из предыдущих тестов t1, t2, … , ti-1, ti . Каждому неизбыточному тесту ti также соответсвует неизбыточный путь Pi (последовательность вершин ГМП, начинающихся входом и заканчивающихся выходом).

  2. Сложностью тестирования V(P, C) программы Р по критерию С называется минимальное число неизбыточных тестов, покрывающих все элементы множества М(P, C).

  3. Остаточною сложностью тестирования DV(P, C, T) программы Р по критерию С будем считать минимальное число неизбыточных циклов, покрывающих все непокрытые после прогона текущего набора тестов Т требуемые элементы множества М(P, C).

Пусть множества Т и DT состоят из неизбыточных тестов, тогда

V(P, C)=min[T] (1)

DV(P, C)=min[DT] (2)

  1. Оптимальной оценкой тестированности программы Р по критерию С будет TV(P,C,T) = (V(P,C) – DV(P,C,T)) / V(P,C) . (3)

Таким образом , можно дать точную оценку уровня проведенного тестирования и вынести решение о его достаточности или необходимости продолжения работ.
Критерии для принятия такого решения TV(P, C, T)L, где L – уровень тестируемости P по C. Уровень тестируемости L () должен быть известен заранее из задания на тестирование или из критерия приемки.

Построение графовой модели программы (процедурный подход).

Первым, исторически более ранним, подходом к разработке ПО является процедурное (модульное) программирование, которое предполагает написание исходного кода в императивном (повелительном) стиле, строго предписывающем последовательность выполнения команд, а также описание программного проекта с помощью функциональной декомпозиции. Сложные программные проекты имеют модульно-иерархическое построение и тестирование модулей является начальным шагом процесса тестирования. Строится ГМП. Тестирование практически всегда проводится по критерию покрытия ветвей С1, то есть каждая дуга и каждая вершина графа модуля должна содержаться, по крайней мере, в одном из путей тестирования. В этом случае множество требуемых элементов для программы Р по критерию С1 М(Р,С) будет выражаться формулой:

M(P,C1) = E  Ni,j , (4)

где Е – множество дуг, - входные вершины ГМП.

Сложность тестирования модуля P по критерию С1 (топологическая сложность по Маккейбу) выражается следующей формулой:

V(P,C1) = q + kin , (5)

где q – число бинарных выборов из условия ветвления, kin – число входов графа.

1.3.5. Примеры построения тестов «белого ящика» .

Рассмотрим фрагмент участка программы, который представлен графом передачи управления. Каждая вершина графа это линейный участок программы, заканчивающейся оператором ветвления. Дуги указывают на передачу управления. Граф описывает программу из 10-12 операторов, включая цикл, который выполняется не менее 20 раз. Если предположить, что одновременно выполняются хотя бы 6 ветвей графа и цикл 20 раз, то число тестов для этого участка будет равно 120. Поскольку программы состоят из множества таких участков, то исчерпывающее тестирование невозможно. Целью отбора тестовых наборов данных является попытка уменьшить эту «неполноту». Если ввести ограничение на время, стоимость, машинное время и т.п., то основным вопросом детерминированного тестирования становится вопрос о том, какое подмножество тестов имеет наивысшую вероятность обнаружения большинства ошибок. Это подмножество называется эффективным.

  1. Покрытие операторов – критерий С0 (выполняется каждый оператор хотя бы один раз) . Критерий очень слабый и в больших программах невыполним.

2. Покрытие решений (или покрытие узлов ветвления ) – критерий С1 .

В каждом узле ветвления должен быть обеспечен переход по веткам “истина” и “ложь” хотя бы один раз.

да нет


Рис.1. Узел ветвления

Построим тесты для данного узла ветвления.

1) А>2 и С=Д (истина)

Тест1: A=3, С=0, Д=0.

2) А<=2 и СД (ложь)

Тест2: А=2, С=0, Д=1.

  1. Покрытие условий . Для выполнения таких ошибок используют комбинаторное покрытие условий. Этот критерий требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении и все точки входа выполнялись хотя бы один раз. Для условия на рис.1 по этому критерию надо покрыть тестами следующие 4 комбинации:

1) A>2; С=Д; 2) А>2; СД; 3) А2; С=Д; 4) А2; СД.

Тесты: 1) А=3; С=0; Д=0; 2) А=3; С=0; Д=1;

3) А=2; С=1; Д=1; 4) А=2; С=1; Д=0.

1.4. Функциональное тестирование – принцип «чёрного ящика»

Это тестирование, игнорирующее внутренние механизмы работы системы. Проверяются только данные на входе и выходе («чёрный ящик»). Структурное тестирование не может полностью заменить функциональное, т.к. подчас некоторые входные условия могут быть упущены при проектировании системы. Функциональное тестирование производиться для проверки соответствия системы специфицированным функциональным требованиям. Критерии функционального тестирования отличаются от критериев структурного тестирования, т.к. множество требуемых элементов , которое следует покрыть тестом другое. Рассмотрим наиболее широко применяемые методы функционального тестирования.

1.4.1. Метод эквивалентного разбиения

Разработка тестов по методу эквивалентного разбиения известного под названием метод тестирования доменов , осуществляется в 2 этапа:

  1. Выделение классов эквивалентности.

2. Построение тестов.

Классы эквивалентности выделяются путём выбора каждого входного условия ( обычно это предложения или фразы в спецификации) и разбиением его на две или более групп. Различают два класса эквивалентности: правильные и неправильные.

Правильные классы эквивалентности объединяют правильные входные данные.

Неправильные – ошибочные входные данные.

Построение тестов включает:

Сложность тестирования по данному методу оценить трудно из-за отсутствия их взаимосвязей.

1.4.2. Анализ граничных значений.

Метод заключается в анализе ситуаций, возникающих «выше» или «ниже» границ входных и выходных классов эквивалентности, а также на самой границе. Одним из недостатков этих двух методов является то, что они не исследуют комбинации входных условий. Для решения этой задачи полезен метод функциональных диаграмм причинно – следственных связей. Этот метод позволяет обнаружить неполноту и неоднозначность спецификации.

1.4.3. Метод функциональных диаграмм причинно-следственных связей.

Построение тестов этим методом осуществляется в несколько этапов:

  1. Разбиение спецификации на «рабочие» участки (факторизация).

  2. Определение причин и следствий. Причина – есть отдельное входное условие или класс эквивалентности данных условий. Следствие – есть выходное условие или преобразование системы ( остаточное действие, которое входное условие оказывает на состояние программы или системы).

  3. Анализируется семантическое содержание спецификации, которое преобразуется в булевский граф , связывающий причины и следствия. Этот граф и является функциональной диаграммой.

  4. Функциональная диаграмма снабжается примечаниями , задающими ограничения и описывающими комбинации причин и /или следствий, которые являются невозможными или обязательными из-за синтаксических или внешних ограничений.

  5. Диаграмма преобразуется в таблицу решений, каждый столбец которой соответствует тесту .

  6. Столбцы таблицы решений преобразуются в тесты.

1.4.4. Тестирование потока транзакций.

В основе этого метода лежит построение графа транзакций, который представляет собой модель поведения программы с точки зрения пользователя, т.е. модель, описывающую систему с функциональной точки зрения.

Транзакцией здесь называется единица работы системы с точки зрения пользователя. Она состоит в последовательности операций выполняемых программой, пользователем и аппаратными средствами.

Узлы ветвления в графе транзакций определяются действиями пользователя и состоянием системы , а линейные участки зависят от реального использования программы, ожидая внешних событий и т.п. Фактически это сценарий взаимодействия между ЭВМ и человеком. Тестирование по данному методу заключается в построении полного графа транзакций и проектировании тестов, покрывающих построенный граф. Подобная техника подходит для тестирования интерактивных приложений с развитым оконным интерфейсом. Недостатком этого метода является то, что в большом программном комплексе трудно отразить порождение и слияние новых транзакций.

Логическое тестирование: составляются таблицы решений и используются механизмы булевой алгебры.

Синтаксическое тестирование нацелено на формальную проверку данных, представленных в виде формы Бэкуса – Наура (БНФ).

Тестирование состояний.Основой для тестирования является граф состояний программы и соответствующие им таблицы состояний.

      1. Метод предположения об ошибке.

Человек, обладающий практическим опытом в программировании, часто подсознательно применяет метод проектирования тестов, называемый предположением об ошибке. Основная идея его заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка разработать тесты.

Если в качестве примера рассмотреть тестирование подпрограммы сортировки, то нужно исследовать следующие ситуации [1]:

  1. Сортируемый список пуст.

  2. Сортируемый список содержит только одно значение.

  3. Все записи в сортируемом списке имеют одно и то же значение.

  4. Список уже отсортирован.

Таким образом, перечисляем те случаи, которые могут быть не учтены при проектировании программы.

1.4.6. Общая стратегия функционального тестирования

Методологии проектирования тестов можно объединить в общую стратегию [1]:

  1. Если спецификация содержит комбинации входных условий, то начать рекомендуется с применения метода функциональных диаграмм.

  2. В любом случае необходимо использовать анализ граничных условий.

  3. Определить правильные инеправильные классы эквивалентности для входных и выходных данных.

  4. Метод предположения об ошибках.

Эта стратегия не гарантирует выявление всех ошибок, но ее применение позволит обеспечить приемлемый компромисс.

После проведения серии тестов рекомендуется провести так называемое регрессионное тестирование. Это выборочное перетестирование системы или компоненты с целью проверки факта , что внесённые изменения не вызвали незапланированных побочных эффектов и что система после изменений удовлетворяет специфицированным требованиям.

      1. Примеры функционального тестирования.

«Черный ящик» (неизвестны текст и логика программы), а исходной информацией для тестовых наборов служат её спецификации.

    1. Метод эквивалентного разбиения

Одним из ключевых понятий теории тестирования являются классы эквивалентности и гранич­ные условия. Классический тест граничных условий позволяет с наибольшей вероятностью вы­явить имеющуюся в программе ошибку. Обдумывая наборы таких тестов, специалист разделяет все возможные тесты на группы, выделяя в каждой из них наиболее эффективные. Если от выполнения двух тестов ожидается один и тот же результат, они считаются эквивалент­ными. Группа тестов представляет собой класс эквивалентности, если выполняются следующие ус­ловия.

• Все тесты предназначены для выявления одной и той же ошибки.

• Если один из тестов выявит ошибку, остальные, скорее всего, тоже это сделают.

• Если один из тестов не выявит ошибки, остальные, скорее всего, тоже этого не сделают.

Разумеется, кроме этих абстрактных критериев, необходимы еще и практические, позволяющие отнести к одному классу конкретную группу тестов. Вот на чем может основываться этот отбор.

• Тесты включают значения одних и тех же входных данных.

• Для их проведения выполняются одни и те же операции программы.

• В результате всех тестов формируются значения одних и тех же выходных данных.

• Либо ни один из тестов не вызывает выполнения блока обработки ошибок программы, либо

выполнение этого блока вызывается всеми тестами группы.

Поиск классов эквивалентности

Поиск классов эквивалентности — процесс субъективный. Два человека, анализирующих одну и ту же программу, составят различные перечни классов. Однако постарайтесь все же выявить как можно больше классов эквивалентности: это сэкономит время в дальнейшем и сделает тестирование более эффективным, избавляя вас от ненужного повторения эквивалентных тестов. Разбив все пред­полагаемые тесты на классы, можно затем выделить в каждом из них один или несколько тестов, которые покажутся вам наиболее эффективными — остальные выполнять ни к чему.

Вот несколько рекомендаций для поиска классов эквивалентности [3]:

• Не забывайте о классах, охватывающих заведомо неверные или недопустимые входные данные.

• Организуйте формируемый перечень классов в виде таблицы или плана.

• Определите диапазоны числовых значений.

• Для полей или параметров, принимающих фиксированные перечни значений, выясните, какие

из значений входят в перечень.

• Проанализируйте возможные результаты выбора из списков и меню.

• Поищите переменные, значения которых должны быть равными.

• Поищите классы значений, зависящих от времени.

• Выявите группы переменных, совместно участвующих в определенных вычислениях,

результат которых ограничивается конкретным набором или диапазоном значений.

• Посмотрите, на какие действия программа отвечает эквивалентными событиями.

• Продумайте варианты операционного окружения.

Часто недопустимые или неверные входные данные вызывают в программе самые разнообразные ошибки. Лишь очень немногие программисты тщательно продумывают и отлаживают реакцию своих программ на подобные данные. Поэтому, чем больше вы выделите типов неверного ввода, тем больше найдете ошибок. Например, если программа должна принимать числа от 1 до 99, существует как мини­мум четыре класса эквивалентных тестов.

• Допустим ввод чисел от 1 до 99.

• Любое число меньше 1 слишком мало.

Данный диапазон включает 0 и все отрицательные числа

.• Любое число больше 99 слишком велико.

• Если введена нечисловая информация, она не принимается.

(Действительно ли это верно для всего, что не является числом?)

Обычно классов эквивалентности оказывается очень много, так что не обойтись без удобного и продуманного способа организации собранной информации. Табличный формат информации более понятен, его легче читать, и одним взглядом можно охва­тить больше информации. В нем более очевидно разделение на допустимые и недопустимые вари­анты. Когда информация представлена в таком виде, ее легче анализировать, чтобы выяснить, все ли недопустимые варианты входных данных охваче­ны перечисленными классами эк­вивалентности.

Входное или выходное событие

Допустимые классы эквивалентности

Недопустимые классы эквивалентности

Ввод чисел

Числа от 1 до 99

0

> 99

Выражение результатом которого является недопустимое число, например, 5 – 5, результат которого равен 0.

Отрицательные числа

Буквы и другие нечисловые символы

Ввод первой буквы имени

Первый символ является заглавной буквой

Первый символ является прописной буквой

Первый символ не является буквой

Рисование прямой

От одной точки до четырех сантиметров длиной

Отсутствие рисунка
Длиннее четырех символов

Линия не является прямой


Рис. 2 Табличный формат описания классов эквивалентности

Определите диапазоны числовых значений

Каждый раз, когда обнаруживается новый диапазон значений, вместе с ним появляется и несколько классов эк­вивалентности. Обычно среди них имеется три недопустимых класса: все числа, которые меньше нижнего гра­ничного значения диапазона, все числа, большие его верхнего граничного значения, и нечисловые данные. Иногда один из этих классов отсутствует. Например, допускаются числа, любой величины. Убедитесь, что это и в самом деле так. Попробуйте ввести очень большое число и посмотрите, что получится.

Посмотрите также, нет ли у значений исследуемого параметра поддиапазонов, как, например, у налоговых ставок. Каждый поддиапазон будет отдельным классом эквивалентности. Недопустимые классы будут располагаться ниже самого нижнего диапазона и выше верхнего из них.

Если поля или параметры, принимают фиксированные перечни значе­ний, выясните, какие из значений в них входят.
Если для параметра допускается только определенный перечень значений, один из классов эквивалентности может включать все значения из этого перечня, а другой — все остальные значения. В дальнейшем эти два класса можно будет разделить на ряд меньших классов.

Например, если в некоторое поле вводится название страны, класс допустимых значений включает названия всех стран планеты. В класс недопустимых значений будет входить любое сочетание символов, которое является на­званием страны.

Однако как быть с аббревиатурами, ошибками при написании, особенностями национального произношения на­званий стран или старыми названиями, которые сейчас отсутствуют. Следует ли проверять подобные значения, выделив их в отдельные классы? Вполне вероятно, что, поскольку спецификацией все эти варианты не предусмот­рены, при попытке их ввести, можно столкнуться с ошибкой.

При вводе названий программа может сразу же проверять вводимые символы. Они должны быть буквами верхнего или нижнего регистра. Все, что не является буквами, относится к классу недопустимых значений. Его, в свою очередь, можно разбить на подклассы. Следует учесть и символы разных языков, в том числе и акцентиро­ванные символы, которых тоже достаточно много.
  1   2   3


Московский государственный технический университет
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации