Готовая Лабораторная работа №1 Тестовые примеры

Лабораторная работа №1
Тестовые примеры

1. Разработка тестовых примеров
Непосредственно для тестирования программного обеспечения необходимо определить проверочные задания, выполняемые системой или ее отдельной частью. Такие задачи называются тестовыми примерами.
Можно выделить два подхода к созданию тестовых примеров – исходя из функциональных требований (или из любой другой документации описывающей систему) и исходя из кода. Построение тестовых примеров, исходя из кода, и построение покрытия кода мы будем изучать позднее, а сейчас рассмотрим подробнее первый случай. При тестировании функциональности программы применяется подход "черного ящика", то есть для каждого требования к системе формируются тест-требования, которые, как правило, детализируют функциональные требования так, что на одно функциональное требование может приходиться несколько тест-требований. Сами тест-требования определяют, что должно быть протестировано, но не определяют, как. Конкретные значения задаются в тестовых примерах. Таким образом, одному тест-требованию может соответствовать сразу несколько тестовых примеров.
Начнем мы с тестирования отдельных составляющих программы (в данном случае – модуль математика) на допустимые данные и, в частности, на допустимые граничные данные.
Рассмотрим пример. Для этого возьмем требование 4.2.4.1.
Требование 4.2.4.1: Для чисел, меньших либо равных MAXINT и больших либо равных MININT, частное которых меньше либо равна MAXINT и больше либо равна MININT и делитель не равен 0, функция деления должна возвращать правильное частное с точки зрения математики.
Функция, которую будем тестировать:
///
/// частное
///
/// делимое
/// делитель
/// частное
public static long Div(long a, long b)
В принципе, тестирование такой функции легко автоматизируется при помощи Unit Testing, так как у нее уровень доступа public, т.е. к ней можно обратиться из любого класса. К тому же она является статической, что позволит вызывать ее, не создавая экземпляр класса CalcClass. Однако на этом семинаре мы рассмотрим ручное тестирование.
Прежде всего по этому функциональному требованию составим тест-требования. На первый взгляд, очевидно, что вопрос для проверки звучит так: "Проверить, что для чисел, меньших либо равных MAXINT и больших либо равных MININT, частное которых меньше либо равно MAXINT и больше либо равно MININT и делитель не равен 0, функция деления возвращает правильное частное с точки зрения математики". Однако, это не совсем так. Фраза "меньших либо равных" сразу же наводит на мысль о проверке двух случаев – 1) хотя бы одно из чисел строго равно MAXINT и 2) все числа меньше, чем MAXINT.
Замечание. Стоит заметить, что сейчас мы пишем очень подробные тест-требования, которые практически сразу можно отобразить в тестовые примеры. Такая ситуация наблюдается, например, в проектах, в которых тест-требования отсутствуют, а тестовые примеры пишутся сразу на основании функциональных требований.
Тест-требования
1. Проверить, что для чисел, меньших MAXINT и больших 0, функция деления возвращает правильное частное с точки зрения математики.
2. Проверить, что для делимого, меньшего MAXINT и большего 0, и делителя, меньшего 0 и большего MININT, функция деления возвращает правильное частное с точки зрения математики.
3. Проверить, что для делимого, меньшего 0 и большего чем MININT, и делителя, большего 0 и меньшего MAXINT, функция деления возвращает правильное частное с точки зрения математики.
4. Проверить, что для чисел, меньших 0 и больших MININT, функция деления возвращает правильное частное с точки зрения математики.
5. Проверить, что для делимого, равного 0, и делителя, меньшего MAXINT и большего 0, функция деления возвращает правильное частное с точки зрения математики.
6. Проверить, что для делимого, равного 0, и делителя, большего MININT и меньшего 0, функция деления возвращает правильное частное с точки зрения математики.
7. Проверить, что для делимого, равного MAXINT, и делителя, меньшего MAXINT и большего MININT, функция деления возвращает правильное частное с точки зрения математики.
8. Проверить, что для делимого, равного MININT, и делителя, меньшего MAXINT и большего MININT, функция деления возвращает правильное частное с точки зрения математики.
9. Проверить, что для делителя, равного MAXINT, и делимого, меньшего MAXINT и большего MININT, функция деления возвращает правильное частное с точки зрения математики.
10. Проверить, что для делителя, равного MININT, и делимого, меньшего MAXINT и большего MININT, функция деления возвращает правильное частное с точки зрения математики.
11. Проверить, что для делителя, равного MAXINT, и делимого, равного MININT, функция деления возвращает правильное частное с точки зрения математики.
12. Проверить, что для делителя, равного MAXINT, и делимого, равного MAXINT, функция деления возвращает правильное частное с точки зрения математики.
13. Проверить, что для делителя, равного MININT, и делимого, равного MININT, функция деления возвращает правильное частное с точки зрения математики.
14. Проверить, что для делителя, равного MININT, и делимого, равного MAXINT, функция деления возвращает правильное частное с точки зрения математики.
Замечание: на самом деле, еще можно проверить, что функция корректно работает с однозначными и многозначными числами. К тому же надо убедиться, что она правильно обрабатывает все цифры в числах, а, например, не генерирует исключение, если одно из чисел содержит цифру 9, или результат ее работы не зависит от того, делится ли одно число на другое нацело или нет.
Составим тестовые примеры и запишем их в виде таблицы (табл.1.1).
Таблица 1.1. Тестовые примеры для требования 4.2.4.1
№ Входные значения: делимое, делитель Ожидаемый результат Номер тест-требования Примечания
1) 43 / 21 2 1) Самый частый случай – корректные входные данные
2) 87/-56 -1 2) -//-
3) -9/2 -4 3) -//-
4) -4321/-50 86 4) -//-
5) 0/1234567890 0 5) Часто ошибки проявляются при нулевых значениях переменных
6) 0/-1098765432 0 6) -//-
7) 2147483647/95 22605091 7) и 1) Проверка граничных условий
8) -2147483648/9 -238609294 8) и 2) -//-
9) 99/2147483647 0 9) и 1) -//-
10) -87/-2147483648 0 10) и 4) -//-
11) -2147483648/2147483647 -1 11) А здесь - ошибка
12) 2147483647/2147483647 1 12) -//-
13) -2147483648/-2147483648 1 13) Ошибка
14) 2147483647/-2147483648 0 14) Ошибка

Заметим, что, мы не можем точно сказать, где произошла ошибка, — это хорошо видно из рис.1.1.


Рис. 1.1. Определение местоположения ошибки
Части рисунка, помеченные вопросом – те части программы, в которых могла быть ошибка. Это сами вычисления, преобразование типов, ошибка GUI или передачи параметров (возможно, с некорректным преобразованием типов). О выявленных ошибках составляется отчет, который отдается разработчикам. При этом исправление ошибки в обязанности тестировщика не входит, так как он занимается именно тестированием, а не отладкой приложения.
В первом тесте мы ввели два числа и получили верный результат. Все остальные тесты точно такие же. Но перебрать их все не получится, так как всевозможных комбинаций – 429496736 * 429496735= 184467445805156960. Очевидно, что большинство входных значений приведут к одному и тому же результату, и нет смысла проверять их все. Если программа пройдет первый тест, то она, вероятнее всего, пройдет и остальные.
Если от двух тестовых примеров ожидается получить один и тот же результат, значит, они принадлежат одному классу. Такие множества примеров называются классами эквивалентности. Классы эквивалентности — это, в первую очередь, способ уменьшения необходимого числа тестовых примеров. При тестировании достаточно выполнить только один тестовый пример для каждого класса эквивалентности. Разбиение на классы эквивалентности особенно полезно, когда на вход системы может быть подано большое количество различных значений; тестирование каждого возможного значения привело бы к слишком большому объему тестирования.
2 Классы эквивалентности
Рассмотрим другой пример.
Требование 4.2.1.1: Для чисел, каждое из которых меньше либо равно MAXINT и больше либо равно MININT, функция суммирования должна возвращать правильную сумму с точки зрения математики.
Функция, которую будем тестировать:
///
/// Сложение
///
/// слагаемое
/// слагаемое
/// сумма
public static long Add(long a, long b)
По сравнению с предыдущим требованием у этого явно есть недостатки. Здесь ничего не говорится об ограничениях на сумму. Можно легко подобрать два таких числа, которые будут удовлетворять заявленному требованию, а их сумма будет выходить за границы int. Скорее всего, это ошибка проектирования программы. Тогда необходимо исправить спецификацию и сообщить об этом остальным участникам разработки, прежде всего ее составителю.
После исправлений функциональное требование 4.2.1.1. будет выглядеть так:
Требование 4.2.1.1: Для чисел, меньших либо равных MAXINT и больших либо равных MININT, сумма которых меньше либо равна MAXINT и больше либо равна MININT, функция суммирования должна возвращать правильную сумму с точки зрения математики.
Тестирование на допустимые данные ничем не будет отличаться от тестирования функции деления. Составим классы эквивалентности.
В простейшем случае любое из слагаемых делится на 3 класса эквивалентности: MININT, MAXINT и промежуточное значение. Если подходить более серьезно, то можно выделить 7 допустимых классов эквивалентности: MININT, MININT+1, отрицательное не граничное число, 0, положительное не граничное число, MAXINT-1, MAXINT.
Учитывая то, что у нас два идентичных входных параметра, для полного рассмотрения всех классов эквивалентности необходимо составить и проверить 7*7=49 тестовых примеров, что все равно гораздо меньше, чем полный перебор.
При этом, как показал тест с делением, ошибка может проявиться лишь в нескольких из этих примеров, которые не сильно отличаются от остальных граничных классов эквивалентности.
Некоторые классы эквивалентности не удовлетворяют требованию 4.2.1.1. так как выводят сумму за допустимые пределы. Поведение метода на таких входных данных описано в требовании 4.2.1.2.
На рис.1.2 показано возможное выделение классов эквивалентности (цветами изображены области корректных и некорректных значений, а кружками — сами классы эквивалентности):


Рис. 1.2. Классы эквивалентности
Иногда удобнее составить классы эквивалентности по выходному параметру (в данном случае их будет 7) и уже по ним подбирать входные данные и составлять тестовые примеры.
Основной способ поиска дефектов – передача системе данных, не предусмотренных требованиями: слишком длинных или слишком коротких строк, неверных символов, чисел за пределами вычислимого диапазона и т.п. Неверные данные, как и допустимые, также можно разделять на различные классы эквивалентности. В качестве простого примера снова рассмотрим функцию сложения.
Замечание. Как уже отмечалось выше, тест-требования составлены очень подробно и, фактически, соответствуют тестовым примерам. Поэтому поведение метода на некорректных данных описано в спецификации, хотя подобная ситуация в жизни редко встречается.
В требовании 4.2.1.2. Для чисел, сумма которых больше чем MAXINT и меньше чем MININT, а также в случае, если любое из слагаемых больше чем MAXINT или меньше чем MININT, программа должна выдавать ошибку Error 06 (см 2.3).
Интерфейс метода Add не позволяет нам узнать об ошибке, произошедшей во время выполнения метода. Среда .NET предоставляет мощное средство для отлавливания и обработки ошибок (и не только) во время выполнения программы – Exception(исключение). Именно с использованием исключений и будут работать методы класса CalcClass, но так как знакомство с ними произойдет позднее, то сейчас воспользуемся другим методом – создадим в классе математических функций глобальную статическую переменную типа string lastError. В нее будем записывать коды ошибок, произошедшие во время работы программы, а в сами методы вставим код, выводящий на экран сообщение об ошибке.
Составим тест-требования.
1. Если одно из слагаемых больше, чем MAXINT, то функция должна выдать сообщение "Слишком малое или слишком большое значение числа для int. Числа должны быть в пределах от -2147483648 до 2147483647 " и записать в переменную lastError "Error 06".
2. Если одно из слагаемых меньше, чем MININT, то функция должна выдать сообщение "Слишком малое или слишком большое значение числа для int. Числа должны быть в пределах от -2147483648 до 2147483647 " и записать в переменную lastError "Error 06".
3. Если сумма слагаемых больше, чем MAXINT, то функция должна выдать сообщение "Слишком малое или слишком большое значение числа для int. Числа должны быть в пределах от -2147483648 до 2147483647" и записать в переменную lastError "Error 06".
4. Если сумма слагаемых меньше, чем MININT, то функция должна выдать сообщение "Слишком малое или слишком большое значение числа для int. Числа должны быть в пределах от -2147483648 до 2147483647 " и записать в переменную lastError "Error 06".
При составлении тестовых примеров этим тест-требованиям будет соответствовать более четырех примеров, так как необходимо проверить случаи, когда одно число больше MAXINT, а другое удовлетворяет требованиям или больше MAXINT и так далее. В то же время некоторые тестовые примеры могут покрывать сразу несколько тест-требований. Так, пример "Если первое слагаемое больше MAXINT, а второе слагаемое меньше MININT, при этом сумма чисел больше MAXINT, то функция возвращает сообщение "Слишком малое или слишком большое значение числа для int. Числа должны быть в пределах от -2147483648 до 2147483647 " и записывает в переменную lastError "Error 06" проверяет сразу первое, второе и третье тест-требование.
Для недопустимых данных также можно составить классы эквивалентности, причем как по входным, так и по выходным параметрам, и по ним подобрать тестовые примеры. В нашем случае на каждую переменную можно выделить 4 класса: много меньше MININT,MININT-1, MAXINT+1, много больше MAXINT. Таким образом, надо проверить 16 тестовых примеров.
На самом деле, взглянув на любую из рассмотренных функций, в общем случае выделяют 4 основных класса эквивалентности (рис.1.3).


Рис. 1.3. Структурная схема функции деления
1. Оба входных параметра принадлежат допустимой области, и выходное значение принадлежит допустимой области.
2. Первый входной параметр принадлежит допустимой области, второй не принадлежит допустимой области
3. Первый входной параметр не принадлежит допустимой области, второй принадлежит допустимой области
4. Оба входных параметров принадлежат допустимой области, а значение функции не принадлежит допустимой области.
Это тот минимум, на котором и надо протестировать метод. Однако интуиция и опыт тестировщика подсказывают, что эти классы можно разбить на более мелкие подклассы, в которых часто возникают ошибки. Так, первый класс для функции нахождения частного мы разбили на 14 подклассов, в результате чего и обнаружили ошибку.
Помимо рассмотренных классов тестовых примеров, направленных на выявление различных дефектов в работе программной системы, выделяют также тестовые примеры реинициализации системы, повторного ввода данных, устойчивости системы и другие.

2. Тестовое окружение
Теоретическое вступление
Основной объем тестирования практически любой сложной системы обычно выполняется в автоматическом режиме. Кроме того, тестируемая система обычно разбивается на отдельные модули, каждый из которых тестируется вначале отдельно от других, затем в комплексе.
Это означает, что для выполнения тестирования необходимо создать некоторую среду, которая обеспечит запуск и выполнение тестируемого модуля, передаст ему входные данные, соберет реальные выходные данные, полученные в результате работы системы на заданных входных данных (рис. 1). После этого среда должна сравнить реальные выходные данные с ожидаемыми и на основании данного сравнения сделать вывод о соответствии поведения модуля заданному.
Тестовое окружение также может использоваться для отчуждения отдельных модулей системы от всей системы. Разделение модулей системы на ранних этапах тестирования позволяет более точно локализовать проблемы, возникающие в их программном коде. Для поддержки работы модуля в отрыве от системы тестовое окружение должно моделировать поведение всех модулей, к функциям или данным которых обращается тестируемый модуль.
Поскольку тестовое окружение само является программой (причем, часто реализованной не на том языке программирования, на котором написана система), оно тоже должно быть протестировано. Целью тестирования тестового окружения является доказательство того, что тестовое окружение никаким образом не искажает выполнение тестируемого модуля и адекватно моделирует поведение системы.


Рис. 1. Обобщенная схема среды тестирования
Тестовое окружение для программного кода на структурных языках программирования состоит из двух компонентов – драйвера, который обеспечивает запуск и выполнение тестируемого модуля, и заглушек, которые моделируют функции, вызываемые из данного модуля. Разработка тестового драйвера представляет собой отдельную задачу тестирования, сам драйвер должен быть протестирован, дабы исключить неверное тестирование. Драйвер и заглушки могут иметь различные уровни сложности, требуемый уровень сложности выбирается в зависимости от сложности тестируемого модуля и уровня тестирования. Так, драйвер может выполнять следующие функции:
1. Вызов тестируемого модуля
2. 1 + передача в тестируемый модуль входных значений и прием результатов
3. 2 + вывод выходных значений
4. 3 + протоколирование процесса тестирования и ключевых точек программы
Заглушки могут выполнять следующие функции:
1. Не производить никаких действий (такие заглушки нужны для корректной сборки тестируемого модуля и
2. Выводить сообщения о том, что заглушка была вызвана
3. 1 + выводить сообщения со значениями параметров, переданных в функцию
4. 2 + возвращать значение, заранее заданное во входных параметрах теста
5. 3 + выводить значение, заранее заданное во входных параметрах теста
6. 3 + принимать от тестируемого ПО значения и передавать их в драйвер
Тестовое окружение для объектно-ориентированного ПО выполняет те же самые функции, что и для структурных программ (на процедурных языках). Однако, оно имеет некоторые особенности, связанные с применением наследования и инкапсуляции.
Если при тестировании структурных программ минимальным тестируемым объектом является функция, то в объектно-ориентированным ПО минимальным объектом является класс. При применении принципа инкапсуляции все внутренние данные класса и некоторая часть его методов недоступна извне. В этом случае тестировщик лишен возможности обращаться в своих тестах к данным класса и произвольным образом вызывать методы; единственное, что ему доступно – вызывать методы внешнего интерфейса класса.
Существует несколько подходов к тестированию классов, каждый из них накладывает свои ограничения на структуру драйвера и заглушек.
1. Драйвер создает один или больше объектов тестируемого класса, все обращения к объектам происходят только с использованием их внешнего интерфейса. Текст драйвера в этом случае представляет собой т.н. тестирующий класс, который содержит по одному методу для каждого тестового примера. Процесс тестирования заключается в последовательном вызове этих методов. Вместо заглушек в состав тестового окружения входит программный код реальной системы, соответственно, отсутствует изоляция тестируемого класса. Именно такой подход к тестированию принят сейчас в большинстве методологий и сред разработки. Его классическое название – unit testing (тестирование модулей).
2. Аналогично предыдущему подходу, но для всех классов, которые использует тестируемый класс, создаются заглушки
3. Программный код тестируемого класса модифицируется таким образом, чтобы открыть доступ ко всем его свойствам и методам. Строение тестового окружения в этом случае полностью аналогично окружению для тестирования структурных программ.
4. Используются специальные средства доступа к закрытым данным и методам класса на уровне объектного или исполняемого кода – скрипты отладчика или accessors в Visual Studio.
Основное достоинство первых двух методов – при их использовании класс работает точно таким же образом, как в реальной системе. Однако в этом случае нельзя гарантировать того, что в процессе тестирования будет выполнен весь программный код класса и не останется непротестированных методов.
Основной недостаток 3-го метода – после изменения исходных текстов тестируемого модуля нельзя дать гарантии того, что класс будет вести себя таким же образом, как и исходный. В частности, это связано с тем, что изменение защиты данных класса влияет на наследование данных и методов другими классами.
Тестирование наследования – отдельная сложная задача в объектно-ориентированных системах. После того, как протестирован базовый класс, необходимо тестировать классы-потомки. Однако, для базового класса нельзя создавать заглушки, т.к. в этом случае можно пропустить возможные проблемы полиморфизма. Если класс-потомок использует методы базового класса для обработки собственных данных, необходимо убедиться в том, что эти методы работают.
Таким образом, иерархия классов может тестироваться сверху вниз, начиная от базового класса. Тестовое окружение при этом может меняться для каждой тестируемой конфигурации классов.
На примере "Калькулятора"
Тесты, проделанные нами на прошлом семинаре, как правило, проводятся не вручную. Для целей тестирования пишут специальную программу — тестовый драйвер, который и проводит тестирование. Более того, такие программы часто пишутся на другом языке, нежели тестируемая программа, или создаются автоматически, с помощью специальных утилит.
На этом семинаре мы сами напишем простой тестовый драйвер на C# для тестирования функций "Калькулятора", используя спецификацию второго семинара.
Замечание. Код программы слегка изменен для упрощения компиляции отдельных модулей. Так, исключена работа с переменнойProgram.res, а класс CalcClass объявлен как public.
Для начала рассмотрим функцию деления. Тест-требования к ней мы уже составили. Для простоты будем пользоваться лишь четырьмя общими тест- требованиями.
1. Оба входных параметра принадлежат допустимой области, и выходное значение принадлежит допустимой области.
2. Первый входной параметр принадлежит допустимой области, второй не принадлежит допустимой области
3. Первый входной параметр не принадлежит допустимой области, второй принадлежит допустимой области
4. Оба входных параметров принадлежат допустимой области, а значение функции не принадлежит допустимой области.
Составим программу:
private void buttonStartDel_Click(object sender, EventArgs e)
{
try
{
richTextBox1.Text = "";
richTextBox1.Text += "Test Case 1\n";
richTextBox1.Text += "Входные данные: a= 78508, b = -304\n";
richTextBox1.Text += "Ожидаемый результат: res = 78204 &&
error = \"\""+"\n";
int res = CalcClass.Add(78508, -304);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " +"res = "+
res.ToString() +" error = "+error.ToString() +"\n";
if (res == 78204 && error == "")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 2\n";
richTextBox1.Text += "Входные данные: a= -2850800078, b =
3000000000\n";
richTextBox1.Text += "Ожидаемый результат: res = 0 && error =
\"Error 06\"\n";
int res = CalcClass.Add(-2850800078, 3000000000);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 0 && error == "Error 06")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 3\n";
richTextBox1.Text += "Входные данные: a= 3000000000, b = -
2850800078\n";
richTextBox1.Text += "Ожидаемый результат: res = 0 && error =
\"Error 06\"\n";
int res = CalcClass.Add(3000000000, -2850800078);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error+"\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 0 && error == "Error 06")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 4\n";
richTextBox1.Text += "Входные данные: a= 2000000000, b =
2000000000\n";
richTextBox1.Text += "Ожидаемый результат: res = 0 && error =
\"Error 06\"\n";
int res = CalcClass.Add(2000000000, 2000000000);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error +"\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 0 && error == "Error 06")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}
}
Листинг 1. Текст программы
Каждый тестовый пример находится внутри блока try-catch для того, чтобы перехватить любое сгенерированное исключение внутри методов Add().
При этом файл CalcClass.dll, в котором и реализованы все математические методы, необходимо добавить в References проекта.
Проведем тестирование и получим следующий результат:
Test Case 1
Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 78204 && error = ""
Код ошибки:
Получившийся результат: res = 78204 error =
Тест пройден

Test Case 2
Входные данные: a= -2850800078, b = 3000000000
Ожидаемый результат: res = 0 && error = "Error 06"
Код ошибки: Error 06
Получившийся результат: res = 0 error = Error 06
Тест пройден

Test Case 3
Входные данные: a= 3000000000, b = -2850800078
Ожидаемый результат: res = 0 && error = "Error 06"
Код ошибки: Error 06
Получившийся результат: res = 0 error = Error 06
Тест пройден

Test Case 4
Входные данные: a= 2000000000, b = 2000000000
Ожидаемый результат: res = 0 && error = "Error 06"
Код ошибки: Error 06
Получившийся результат: res = 0 error = Error 06
Тест пройден
Точно такой же результат мы бы получили и при ручном тестировании, если бы выявленные ошибки были исправлены. Заметим, что при таком подходе к тестированию нам удается локализовать ошибки. Если что-то работает не так, как надо, то можно с уверенностью утверждать, что ошибка содержится именно в функции деления, в то время, как на прошлом семинаре мы не могли сказать, где именно она произошла.
Замечание. Мы считаем, что тестовый драйвер сам не содержит ошибок. Тестирование тестового драйвера выходит за пределы изучаемой темы.
Задание
Составить тестовые требования и провести ручное модульное тестирование одного из следующих методов (на выбор):
1. Нахождение остатка.
2. ///
3. /// Деление по модулю
4. ///
5. /// делимое
6. /// делитель
7. /// остаток
public static int Mod(long a, long b)
8. Унарный плюс.
9. ///
10. /// унарный плюс
11. ///
12. ///
13. ///
public static int ABS(long a)
14. Унарный минус.
15. ///
16. /// унарный минус
17. ///
18. ///
19. ///
public static int IABS(long a)
20. Вычитание.
21. ///
22. /// вычитание
23. ///
24. /// уменьшаемое
25. /// вычитаемое
26. /// разность
public static int Sub(long a, long b)
27. Умножение.
28. ///
29. /// умножение
30. ///
31. /// множитель
32. /// множитель
33. /// произведение
public static int Mult(long a, long b)
34. Деление.
35. ///
36. /// частное
37. ///
38. /// делимое
39. /// делитель
40. /// частное
public static int Div(long a, long b)