теория_2 (Методичка и инструкции на ЛР №8), страница 2

На рис.5.2 показано возможное выделение классов эквивалентности (цветами изображены области корректных и некорректных значений, а кружками — сами классы эквивалентности):

Рис. 5.2.  Классы эквивалентности

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

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

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

В требовании 4.2.1.2. Для чисел, сумма которых больше чем MAXINT и меньше чем MININT, а также в случае, если любое из слагаемых больше чем MAXINT или меньше чем MININT, программа должна выдавать ошибку Error 06(см 5.2.3).

Интерфейс метода Add не позволяет нам узнать об ошибке, произошедшей во время выполнения метода. Среда .NET предоставляет мощное средство для отлавливания и обработки ошибок (и не только) во время выполнения программы – Exception (исключение). Именно с использованием исключений и будут работать методы класса CalcClass, но так как знакомство с ними произойдет позднее, то сейчас воспользуемся другим методом – создадим в классе математических функций глобальную статическую переменную типа string lastError. В нее будем записывать коды ошибок, произошедшие во время работы программы, а в сами методы вставим код, выводящий на экран сообщение об ошибке.

Замечание. Описание класса Exception и его применение можно прочитать по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ frlrfsystemexceptionclasstopic.asp

О перехвате и обработке исключений — по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/ cpconexceptionhandlingfundamentals.asp

Составим тест-требования.

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 основных класса эквивалентности (рис.5.3).

Рис. 5.3.  Структурная схема функции деления

1. Оба входных параметра принадлежат допустимой области, и выходное значение принадлежит допустимой области.

2. Первый входной параметр принадлежит допустимой области, второй не принадлежит допустимой области

3. Первый входной параметр не принадлежит допустимой области, второй принадлежит допустимой области

4. Оба входных параметров принадлежат допустимой области, а значение функции не принадлежит допустимой области.

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

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

5.3. Возможности MVSTE по ручному тестированию и описанию тестовых примеров (Manual Testing)

Замечание. Подробнее о ручном тестировании можно почитать по адресу http://msdn2.microsoft.com/en-us/library/ms182615(VS.80).aspx

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

Ручное тестирование в MVSTE представляет собой сценарий выполнения теста.

Рассмотрим процесс создания ручного теста.

Сначала создадим новый тестовый проект. Для этого зайдем в File->New->Project… (можно также нажать Ctrl+Shift+N или нажать на иконке на панели Standart)

В появившемся диалоговом окне New Project выберем тип проекта Visual C#->Test-> Test Project (если язык C# не выбран по умолчанию в MVSTE, то выберите Test Project->Test Documents-> Test Project). В поле Name зададим имя нашего проекта (например, ManualTestProject). Нажмем ОК. (рис. 5.4)

Рис. 5.4.  Диалоговое окно New Project

Новый тестовый проект создан.

Теперь посмотрим на окно Solution Explorer (рис.5.5). Созданный тестовый проект содержит три файла, связанных с тестированием:

Рис. 5.5.  Окно Solution Explorer

Замечание. Файл UnitTest1.cs нам не понадобится для ручного тестирования, поэтому его можно удалить из проекта. Для этого в Solution Explorer щелкнем по нему правой кнопкой мыши и нажмем в появившемся контекстном меню Delete. В появившемся окошке подтверждаем удаление, нажав OK.

Замечание. Если на вашем компьютере не установлен Microsoft Office 2003, то файл ManualTest1.mht не будет создан. Для добавления в проект шаблона для ручного тестирования нужно в меню Test выбрать New Test. В появившемся диалоговом окне Add New Test выбрать Manual Test(text format). В поле Test Name нужно ввести название теста, например ManualTest1.mtx. Ни в коем случае нельзя менять разрешение этого файла. В поле Add to Test Project выберем созданный нами ранее ManualTestProject. Нажмем OK. (рис. 5.6) В наш тестовый проект будет добавлен файл с ручным тестом ManualTest1.mtx.

Рис. 5.6.  Диалоговое окно Add New Test

Теперь убедимся, что ручной тест добавлен и готов к выполнению. В меню Test нажмем на пункт Windows и в открывшемся подменю выберем Test View. Откроется окно Test View, в котором виден тест MyManualTest (рис. 5.7).

Р
ис. 5.7.  Окно Test View

Новый ручной тест добавлен, и теперь все готово к его редактированию. Необходимо открыть шаблон теста (например, сделав двойной клик мышкой по ManualTest1.mht (ManualTest1.mtx) в Solution Explorer). Далее, следуя инструкции, вводим информацию о тесте в шаблон. Шаблон включает в себя название теста (Test Title), описание теста (Test Details), функциональность, которую надо проверить (Test Target), действия, которые необходимо совершить для проведения теста (Test Steps), и описание истории изменений теста (Revision History). После завершения редактирования необходимо сохранить шаблон.

Следующий этап – выполнение теста тестировщиком.

В окне Test View нажмем правой кнопкой мыши по созданному нами ручному тесту (ManualTest1) и выберем Run Selection (или нажмем в окне Test View на кнопку ).

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

Откроется окно Test Results, в котором наш тест будет помечен как Pending (выполняется), и окно MyManualTest[Running], начинающее выполнение теста. Следуя сценарию теста и оставляя свои комментарии в верхней части окна, тестировщик выполняет тест, после чего указывает, пройден тест или нет (Pass/Fail), и нажимает Apply в верхней части экрана. В окне Test Results отобразятся изменения, то есть вместо Pending будет Passed или Failed (в зависимости от того, что вы указали в окне MyManualTest[Running] после выполнения ручного теста).

Замечание. Результаты выполнения тестов можно экспортировать в отдельный файл. Для этого в окне Test Result надо нажать на кнопку Export Test Run Results , указать имя и местоположение файла.

5.4. Раздаточный материал

5.4.1. Программа

Будут выданы .exe и .dll файлы, которые нужно протестировать (тестирование черного ящика).

5.4.2. Шаблон отчета о проблеме

5.5. Задание

Составить тест-требования и провести ручное тестирование своей программы