* При перепечатке материалов ссылка на www.SeoLiga.ru обязательна! RSS



Создание плана блочного тестирования
8 февраля 2009

План блочного тестирования
Редкая программа, только что вышедшая «из-под пера» разработчика, не содержит
ошибок. Время от времени ошибаются даже весьма опытные программисты. По-
этому следует исходить из предположения, что любой только что написанный код
содержит ошибки. Естественно, от приложения, которое кишит «жучками» и рабо-
тает не так, как требуется, толку мало. Приложите все усилия, чтобы в окончатель-
ной версии приложения ошибок оказалось как можно меньше. Тестирование спо-
собно превратить полный ошибок опытный образец приложения в стабильную вер-
сию, пригодную для выпуска.
Тестирование и отладка — это два различных и в тоже время взаимосвязанных
мероприятия. Под отладкой понимают непосредственный поиск ошибок в коде и
их исправление, а тестированием называют процесс, позволяющий выявить эти
ошибки. Обычно тестированию подвергают каждый метод приложения, заставляя
его обработать всевозможные параметры в разных условиях. Такой подход называ-
ют блочным тестированием, поскольку при этом выполняется тестирование отдель-
ных компонентов приложения. Однако приложения, как правило, слишком слож-
ны, чтобы проверить все возможные параметры и условия исполнения. Рассмот-
рим следующий метод DisplayName:
Visual Basic .NET
Public SuD DisplayNamefflyVal Name As String)
System. Windows. Forms. MessageSox. Show(Narne)
End Sub
Visual C#
public void DisplayName(string Name)
System.Windows.Forms.MessageBox.Show(Name);
}
Предположим, что некоторый метод, вызывающий DisplayName, передает в па-
раметре Name строку длиной до восьми символов стандартного английского алфа-
вита. Это означает, что метод из нашего примера может получить 268 или примерно
200 миллиардов различных строк. Ясно, что протестировать их все в данном случае
невозможно.
Но столь строгое тестирование здесь и не требуется. В случае с предыдущим при-
мером мало вероятно, что различные строки будут вызывать различные ошибки. А
значит, для проверки работоспособности такого метода достаточно протестировать
его на нескольких представительных значениях аргументов. Подобные примеры
называются контрольными примерами (test cases).
Успех тестирования целиком определяется качественным выбором контрольных
примеров. Если их слишком мало, тестирование не даст результата и в окончатель-
ной версии программы непременно окажется много ошибок, а если их чрезвычай-
но много, вы потеряете время, деньги и превысите сроки, отведенные на разработ-
ку. Сбалансированным планом тестирования приложения считается тот, где доста-
точно полно представлены функции приложения и проверяются наиболее типич-
ные сценарии его использования.
Разработка контрольных примеров
Как говорилось ранее, следует исходить из того, что проверке подлежит каждая
строка кода. Следовательно, если в тестируемом методе есть структуры решений,
потребуется контрольный пример для проверки всех вариантов поведения этой
структуры. Рассмотрим следующий метод:
Visual Basic .NET
Public Sub TestMethod(ByVal X As Boolean, ByVal Y As Boolean)
If X = True Then
MessageBox.ShowC'X is True")
Else
MessageBox. ShowC'X is False.")
End If
If Y = True Then
MessageBox.Show("Y is True")
Else
MessageBox. ShowC'Y is False")
End If
End Sub
Visual C#
public void TestMethod(bool X, bool Y)
{
if (x == true)
MessageBox.ShowC'X is true");
else
MessageBox.ShowC'X is false");
if (Y == true)
MessageBox.Show("Y is true");
else
MessageBox.Show("Y is false");
}
Для проверки всех строк этого метода достаточно двух контрольных примеров: в
первом значения Хи К должны быть равны true, а во втором —false. Эти примеры
позволят задействовать все строки кода этого метода.
Однако, по некотором размышлении становится ясно, что этот подход не обес-
печивает необходимого охвата функциональности. Действительно, задействованы
все строки кода, но примеры статичны: они не обеспечивают тестирование с пере-
менным набором данных. Нашему методу могут быть переданы параметры, кото-
рые направят его исполнение по пути, не предусмотренному контрольным приме-
ром (например, Х= true и У'= false). Чтобы рассмотреть все возможные варианты
при тестировании этого метода, потребуется два дополнительных контрольные при-
мера: в первом Х= true, a Y— false, а во втором — Х=false, a ¥= true. Тестирование
всех возможных путей передачи данных составляет программу-минимум при раз-
работке плана блочного тестирования.
Составление тестовых данных
Проверка функциональности программы при обработке всех вариантов однотип-
ных данных — хорошая отправная точка для составления плана тестирования. Но
только тестирование обработки разных типов данных позволяет убедиться в надеж-
ности программы. Приложение должно не только нормально работать и генериро-
вать ожидаемые результаты на основе аргументов, на работу с которыми оно рас-
считано, но и корректно обрабатывать значения, которые выходят за пределы до-
пустимого диапазона. Тестирование считается законченным не раньше, чем будет
установлено, что оно корректно обрабатывает различные данные, в том числе и
значения, которые больше или меньше допустимых. Далее описаны приемы состав-
ления тестовых данных, которые пригодятся вам при создании контрольных при-
меров для тестирования собственных приложений.
Проверка типичных значений аргументов
Важно убедиться, что программа правильно обрабатывает данные, с которыми ей
придется сталкиваться чаше всего. В большинстве случаев проверить при тестиро-
вании все значения этого диапазона невозможно, однако в контрольных примерах
должно быть несколько вариантов типичных данных, которые будет обрабатывать
приложение.
Проверка обработки минимальных и максимальных значений аргументов
Особое внимание необходимо уделять проверке границ допустимого диапазона ар-
гументов. С этой целью в контрольные примеры включают не только крайние зна-
чения из этого диапазона, но и аргументы, которые на единицу больше и меньше
минимального и максимального значений. Например, чтобы протестировать верх-
нюю границу диапазона аргументов, необходимо проверить три значения: макси-
мальное допустимое значение, а также значения на единицу больше и на единицу
меньше его. Это позволит «отловить» ряд стандартных ошибок, например исполь-
зование оператора > вместо >=.
Использование заведомо недопустимых аргументов
Таким способом удается удостовериться, что ввод подобных данных не вызовет крах
приложений или, хуже того, что программа не будет возвращать некорректные ре-
зультаты, хотя внешне ее работа кажется нормальной. Для этого необходимо вклю-
чить в контрольные примеры аргументы, значения которых выходят за пределы
допустимого диапазона. Например, передать ноль в параметре, в котором ноль пе-
редавать нельзя; отрицательное число вместо положительного и т.п.
Комбинированные примеры
Рекомендуется включать в контрольные примеры различные комбинации упомя-
нутых тестовых данных. Некоторые ошибки могут не проявиться, пока приложе-
ние получает корректные комбинации данных. Например, метод функционирует
правильно, если его параметрам поочередно передаются максимальные допустимые
значения, но генерирует ошибку, если максимальные значения передаются всем его
параметрам сразу. И наоборот: определенные комбинации заведомо недопустимых
данных генерируют внешне нормальные результаты. Рассмотрим следующий метод:
Visual Basic .NET
Public Function.CalcjlateMySalary(ByVal Hours As Short, ByVal Weeks
As Short) As Integer
Этот метод предполагает наличие переменной WageConstant,
представляющую размер почасовой оплаты.
Dim mySalary As Integer
mySalary = Hours * Weeks * WageConstant
Return mySalary
End Function
Visual C#
public int CalculateMySalary(short Hours, short Weeks)
{
// Этот метод предполагает наличие переменной WageConstant,
// представляющую почасовую оплату.
int mySalary;
mySalary = Hours * Weeks * WageConstant;
return mySalary;
!
Этот метод нормально работает, если ему передаются допустимые аргументы:
значение Hours из диапазона 0—40, а также число недель от 0 до 52. Но что будет,
если вызвать его так:
Visual Basic .NET
Dim Hooray As Integer
Hooray = CalculateMySalary(-40, -52)
Visual C#
int Hooray;
Hooray = CalculateMySalary(-40, -52);
В этом случае метод, принимая комбинацию заведомо неверных данных, воз-
вращает внешне совершенно нормальный результат. Вывод очевиден, необходимо
разрабатывать контрольные примеры так, чтобы проверить различные комбинации
данных.
План блочного тестирования создают следующим образом.
1. Прежде всего создают контрольные примеры, которые позволят проверить каж-
дую строку тестируемого блока кода.
2. Далее разрабатывают контрольные примеры для тестирования всех вариантов
обработки данных тестируемым блоком.
3. Затем пишут контрольные примеры, которые позволят протестировать различ-
ные виды данных, обрабатываемых данным элементом. Помимо тестирования
обработки типичных значений необходимо уделить внимание проверке мини-
мальных и максимальных значений аргументов, обработке неверных данных и
их комбинадий, а также допустимых значений, в том числе минимальных л мак-
симальных.
4. Прежде чем приступать к тестированию, рассчитайте ожидаемые результаты для
всех контрольных примеров.
5. Выполните тесты и сравните полученные результаты с ожидаемыми.

Теги: .NET

Статьи по теме:

Создание и настройка объекта DataAdapter
Работа с фокусом ввода
Принципы дизайна интерфейса
Создание проекта установочной программы
Создание класса строго типизированного набора на основе класса CollectionBase
Свойства-наборы
Редактор нестандартных действий
Доступ к «плоским» файлам
Добавление элементов управления на панель Toolbox
Towards Cleaner Code, A C# Asynchronous Helper
Делегаты
Набор Listeners
Разделяемые сборки
Оптимизация приложений
Декларативная защита, основанная на ролях
| .NET | Pavel |
 


Пн Вт Ср Чт Пт Сб Вс
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31


     



Rambler's Top100

Данный сайт или домен продается ICQ: 403-353-727

© 2009 Seoliga.ru | .NET | Создание плана блочного тестирования. Регион сайта: Москва и Санкт-Петербург