Тестирование циклов.

Цикл - наиболее распространенная конструкция алгоритмов, используемых в ПО. Тестирование циклов производится по принципу «белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.

Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные.

Простые циклы.

Для проверки циклов с количеством повторений n может использоваться один из следующих наборов тестов:

· прогон всего цикла;

· только один проход цикла;

· два прохода цикла;

· m проходов циклов, где m<n;

· n-1, n, n+1 проходов цикла.

Вложенные циклы.

С увеличением уровня вложенности циклов количество возможных путей резко возрастает. Это приводит к нереализуемому количеству тестов. Для сокращения количества тестов применяется специальная методика, в которой используются такие понятия, как объемлющий и вложенные циклы.

Шаги тестирования:

· Выбирается самый внутренний цикл. Устанавливаются минимальные значения параметров всех остальных циклов.

· Для внутреннего цикла проводятся тесты простого цикла. Добавляются тесты для исключенных значений и значений, выходящих за пределы рабочего диапазона.

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

· Работа продолжается до тех пор, пока не будут протестированы все циклы.

Объединенные циклы.

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

Неструктурированные циклы.

Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан с помощью структурированных программных конструкций.

2.2. Тестирование «черного ящика»

Известны: функции программы.

Исследуется: работа каждой функции на всей области определения.

Основное место приложения тестов «черного ящика» - интерфейс ПО.

Эти тесты демонстрируют:

· Как выполняются функции программы.

· Как принимаются исходные данные.

· Как вырабатываются результаты.

· Как сохраняется целостность внешней информации.

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирования, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 10¹⁰ тестовых вариантов. Тестирование «черного ящика» не реагирует на многие особенности программных ошибок.

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

· Набор, образуемый такими входными данными, которые приводят к аномалиям в поведении программы (назовем его IT);

· Набор, образуемый такими входными данными, которые демонстрируют дефекты программы (назовем его OT).

Любой способ тестирования «черного ящика» должен:

· Выявить такие входные данные, которые с высокой вероятностью принадлежат набору IT;

· Сформулировать такие ожидаемые результаты, которые с высокой вероятностью являются элементами набора OT.

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

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

Принцип «черного ящика» не альтернативен принципу «белого ящика». Скорее это дополняющий подход, который обнаруживает другой класс ошибок.

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

· Некорректных или отсутствующих функций;

· Ошибок интерфейса;

· Ошибок во внешних структурах данных или в доступе к внешней базе данных;

· Ошибок характеристик (необходимая емкость памяти и т.д.);

· Ошибок инициализации и завершения.

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

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

Техника «черного ящика» ориентирована на решение следующих задач:

· Сокращение необходимого количества тестовых вариантов (из-за проверки не статистических, а динамических аспектов системы);

· Выявление классов ошибок, а не отдельных ошибок.

Способ разбиения по эквивалентности.

Разбиение по эквивалентности - самый популярный способ тестирования «черного ящика».

В этом способе входная область данных программы делится на классы эквивалентности. Для каждого класса эквивалентности разрабатывается один тестовый вариант.

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

Классы эквивалентности могут быть определены по спецификации на программу.

Класс эквивалентности включает множество значений данных, допустимых или недопустимых по условиям ввода.

Условие ввода может задавать;

· Определенное значение.

· Диапазон значений.

· Множество конкретных величин.

· Булево условие.

Сформулируем правила формирования классов эквивалентности.

1. если условие ввода задает диапазон n…m, то определяется один допустимый и два недопустимых класса эквивалентности.

2. если условие ввода задает конкретное значение a, то определяется один допустимый и два недопустимых класса эквивалентности.

3. если условие ввода задает множество значений {a,b,c}, то определяется один допустимый и один недопустимый класс эквивалентности.

4. если условие ввода задает булево значение, например true,то определяется один допустимый и один недопустимый класс эквивалентности.

После построения классов эквивалентности разрабатываются тестовые варианты.

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

Способ анализа граничных значений.

Как правило, большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения. Данный способ тестирования дополняет способ разбиения по эквивалентности.

Основные отличия анализа граничных значений от разбиения по эквивалентности:

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

· При создании тестовых вариантов учитывают не только условия ввода, но и область вывода.

Сформулируем правила анализа граничных значений.

1. если условие ввода задает диапазон n…m, то тестовые варианты должны быть построены:

1. для значений n и m.

2. для значений чуть левее n и чуть правее m на числовой оси.

2. Если условие ввода задает дискретное множество значений, то создаются тестовые варианты:

1. для проверки минимального и максимального из значений.

2. для значений чуть меньше минимума и чуть больше максимума.

3. Правила 1 и 2 применяются к условиям области вывода.

4. Если внутренние структуры данных программы имеют предписанные границы, то разрабатываются тестовые варианты, повторяющие эти структуры на их границах.

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

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

Способ диаграмм причин-следствий.

Диаграммы причинно-следственных связей - способ проектирования тестовых вариантов, который обеспечивает формальную запись логических условий соответствующих действий. Используется автоматный подход к решению задачи.

Шаги способа:

· Для каждого модуля перечисляются причины (условия ввода или классы эквивалентности условий ввода) и следствия (действия или условия вывода). Каждой причине и следствию присваивается свой идентификатор.

· Разрабатывается граф причинно-следственных связей.

· Граф преобразуется в таблицу решений.

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

ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

В качестве практической части нам было предложено протестировать фрагмент информационной системы «Учебно-методический ресурс», а именно - регистрацию пользователей. Так как информационная система «Учебно-методический ресурс» представляет собой WEB-сайт, то также было предложено протестировать и навигацию сайта.

Нами был выбран такой метод тестирования, как метод «черного ящика». Это обусловлено тем, что тестированием кода программы занимался непосредственно разработчик кода. Им был написан файл регистрации reg.php. В результате работы файла на главной странице информационной системы появляется следующая форма.

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

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

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

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

Для тестирования фрагмента информационной системы «Учебно-методический ресурс» нами была выбрана возможность создания курса лекций одного предмета.

На главной странице указывается количество лекций. В нашем случае их количество - 3. Нажатием кнопки «Лекции» вызывается форма, содержащая пустые поля для ввода названия лекции и пути, по которому находится файл с непосредственно содержанием (текстом) лекции. Файл с лекцией должен быть написан в текстовом редакторе Microsoft Office Word и сохранен как веб-страница с фильтром, иначе могут возникнуть ошибки в формировании конечной страницы. В результате проделанных действий должна формироваться веб-страница, содержащая все лекции, указанные пользователем. В нашем случае формирование страницы происходит успешно, и мы получаем веб-страницу с тремя лекциями с заданными названиями и с верным содержимым.

Помимо тестирования веб-страниц информационной системы «УМР» производилось визуальное тестирование исходного кода сценария reg.php. Проверка данного файла осуществлялась при помощи редактора PHP Expert Editor.

Файл сценария reg.php

<?php

session_start();

// создаем новую сессию или

// восстанавливаем текущую

$err_msg = array("lname"=>"Фамилия:", "fname"=>"Имя", "oname"=>"Отчество", "pass"=>"Не веден пароль","repass"=>"Не подтвержден пароль", "error"=>"Пароль не совпадает с подтверждением",

"login"=>"Пользователь с таким псевдонимом уже существует");

//print_r($err_msg);

/*-------Вспомогательные функции-------*/

function Check($var, $val=""){

if (!isset($var))

return $val;

else

return $var;

}

//Функция для проверки ФИО

//function FIO_OK($str){

// return ereg("^[А-Яа-я\' -]{l,25}$", $str);

//}

function LOGIN_OK($str){

$conn=mysql_connect("localhost","root");// устанавливаем соединение

$database = "users";

$table_name = "pass";

mysql_select_db($database); // выбираем базу данных

//проверка уникальности псевдонима

$sql = "SELECT login FROM $table_name WHERE `login` = "."'".$str."'";

$result=mysql_query($sql);

mysql_close($conn);

return mysql_num_rows($result);

}

//Функция для проверки email

function email_OK($str){

return preg_match("/^\w+([\.\w]+)*\w@\w((\.\w)*\w+)*\.\w{2,3}$/",$str);

}

//Функция для проверки телефона

function telefon_OK($str){

return preg_match("/\d{3}-\d{2}-\d{2}/",$str);

}

//Функция для проверки формы

function Form_OK(){

//Массив ошибок и соответствующих сообщений

global $errors, $err_msg;

/* if(!FIO_OK($_POST["fname"])){

$errors["fname"] = 1;

$_POST["fname"] ="";

}

if(!FIO_OK($_POST["oname"])){

$errors["oname"] = 1;

$_POST["oname"] ="";

}

if(!FIO_OK($_POST["lname"])){

$errors["lname"] = 1;

$_POST["lname"] ="";

}

*/

if(LOGIN_OK($_POST["login"])){

$errors["login"] = 1;

$_POST["login"] ="";

}

//проверка совпадения пароля и подтверждения

if(strcmp($_POST["pass"],$_POST["repass"])!=0){

$errors["error"]=1;

$_POST["repass"]="";

}

if(!$_POST["pass"]) {

$errors["pass"]=1;

$_POST["repass"]="";

}

if(!$_POST["repass"]) $errors["repass"]=1;

if(sizeof($errors)>0){

//Если существуют ошибки, выводятся соответствующие сообщения, и форма отображается заново

echo "<html><body><div align='center' style='font-size: 18'><b>ОШИБКА</b></div>";

echo "<div align='center' style='font-size: 14, color:red'>Обнаружены следующие ошибки:<br>";

foreach($errors as $key=>$value){

echo "<b>".$err_msg [$key]."</b><br>";

}

echo "</div>";

ShowForm();

echo "</body></html>";

}

else {

//Если ошибки отсутствуют, выводится соответствующее сообщение

echo "<h2 align='center'>Уважаемый(ая) ".$_POST["lname"]." ".$_POST['fname']."!</h2><br> <h3 align='center'>

Регистрация прошла успешно</h3>";

$_SESSION['login']=$_POST['login'];

// регистрируем переменную login

//$_SESSION['pass']=$_POST['pass'];

// регистрируем переменную pass

// теперь логин и пароль - глобальные

// переменные для этой сессии

echo "<center><a href =main_form.php>OK</a></center>";

//вносим данные в базу

$conn=mysql_connect("localhost","root");// устанавливаем соединение

$database = "users";

$table_name = "pass";

mysql_select_db($database); // выбираем базу данных

//проверка уникальности псевдонима

$list_f = mysql_list_fields($database,$table_name);// получаем список полей в базе

$n = mysql_num_fields($list_f); // число строк в результате предыдущего запроса

// составим один запрос сразу для всех полей таблицы

$sql = "INSERT INTO $table_name SET "; // начинаем создавать запрос, перебираем все поля таблицы

for($i=0;$i<$n; $i++){

$name_f = mysql_field_name ($list_f,$i); // вычисляем имя поля

$value = $_POST[$name_f]; // вычисляем значение поля

$j = $i + 1;

$sql = $sql . $name_f." = '$value'"; // дописываем в строку $sql пару имя=значение

if ($j <> $n) $sql = $sql . ", "; // если поле не последнее в списке, то ставим запятую

}

// перед тем как записывать что-то в базу,

// можно посмотреть, какой запрос получился

//echo $sql;

$result = mysql_query($sql,$conn); // отправляем запрос выводим сообщение успешно ли выполнен запрос

if (!$result) echo "Can't add ".$table_name;

else echo "Success!<br>";

mysql_close($conn);

}}

function ShowForm(){

echo $_SERVER['PHP_SELF'];

echo "

<h3 align=\"center\">Регистрация</h3>

<form action=\"{$_SERVER['PHP_SELF']}\" method=\"POST\">

<h4 align=\"center\"><b><font face=\"Courier New, Courier, mono\">Пожалуйста, заполните

форму, приведенную ниже. Спасибо!</font></b></h4>

<h4 align=\"center\"><font face=\"Courier New, Courier, mono\"><i><font size=\"2\">Не

обязательные поля помечены *</font></i></font></h4>

<div align=\"center\">

<table width=\"250\" border=\"0\">

<tr>

<td>

<div align=\"right\">Фамилия</div>

</td>";

if (!isset($_POST['lname'])) $value="";

else $value=Check($_POST["lname"]);

echo "

<td>

<input type=text name=\"lname\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">Имя</div>

</td>";

if (!isset($_POST['fname'])) $value="";

else $value=Check($_POST['fname']);

echo "

<td>

<input type=\"text\" name=\"fname\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">Отчество</div>

</td>";

if (!isset($_POST['oname'])) $value="";

else $value=Check($_POST['oname']);

echo "

<td>

<input type=\"text\" name=\"oname\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">*Звание</div>

</td>";

if (!isset($_POST['rank'])) $value="";

else $value=Check($_POST['rank']);

echo "

<td>

<input type=\"text\" name=\"rank\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">*Должность</div>

</td>";

if (!isset($_POST['post'])) $value="";

else $value=Check($_POST['post']);

echo "

<td>

<input type=\"text\" name=\"post\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">*Телефон</div>

</td>";

if (!isset($_POST['telefon'])) $value="";

else $value=Check($_POST['telefon']);

echo "

<td>

<input type=\"text\" name=\"telefon\" maxlength=\"10\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">*E-mail</div>

</td>";

if (!isset($_POST['email'])) $value="";

else $value=Check($_POST['email']);

echo "

<td>

<input type=\"text\" name=\"email\" maxlength=\"25\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">Псевдоним</div>

</td>";

if (!isset($_POST['login'])) $value="";

else $value=Check($_POST['login']);

echo "

<td>

<input type=\"text\" name=\"login\" maxlength=\"15\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">Пароль</div>

</td>";

if (!isset($_POST['pass'])) $value="";

else $value=Check($_POST['pass']);

echo "

<td>

<input type=\"password\" name=\"pass\" maxlength=\"10\" value=\"$value\">

</td>

</tr>

<tr>

<td>

<div align=\"right\">Подтверждение</div>

</td>";

if (!isset($_POST['repass'])) $value="";

else $value=Check($_POST['repass']);

echo "

<td>

<input type=\"password\" name=\"repass\" maxlength=\"10\" value=\"$value\">

</td>

</tr>

</table>

<input type=\"submit\" name=\"ok\" value=\"OK\">

</div>

</form>";

}

if (!isset($_POST['ok'])){

echo "

<html>

<head>

<title>Registration</title>

<meta http-equiv=\"Содержимое-Тип\" content=\"text/html; charset=windows-1251\">

</head>

<body background=..\\ris\\1.jpg text=\"#000000\">";

ShowForm();

echo "

</body>

</html>

";}

else Form_OK();

?>

ЗАКЛЮЧЕНИЕ

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

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

Далее были рассмотрены виды тестирования:

· Блочное тестирование;

· Тестирование компонента;

· Интеграционное тестирование;

· Регрессивное тестирование;

· Тестирование системы.

Выделены основные критерии и принципы тестирования, а также методы тестирования программного обеспечения, такие как:

· Метод «белого ящика».

· Метод «черного ящика».

Практической частью курсовой работы было тестирование фрагмента информационной системы «Учебно-методический ресурс».

Таким образом, задачи, сформулированные во введении, решены, а цель достигнута.

СПИСОК ЛИТЕРАТУРЫ

1. Липаев В.В.

Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993, 384 с.

2. Майерс Г.

Искусство тестирования программ.

М.: Финансы и статистика, 1982, 176 с.

3. Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд./ С.А. Орлов. - СПб.: Питер, 2004. - 527 с.: ил.

4. Макгрегор Дж., Сайкс Д.

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

К.: Диасофт, 2002. - 432 с.

5. Липаев В.В.

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

М.: Радио и связь, 1986. - 296 с.

6. Канер С., Фолк ДЖ., Нгуен Енг.

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

К.: Диасофт, 2000 - 544 с.

7. Шимаров В.А.

Тестирование программ: цели и особенности инструментальной поддержки

//Программное обеспечение ЭВМ / АН БССР. Институт математики.

Минск, 1994. - Вып. 100 - с.19 - 43

8. Борзов Ю.В., Уртанг Г.Б., Шимаров В.А.

Выбор путей программы для построения тестов

УСиМ. - 1989. - N.6 - с.29-36

9. Boehm, Barry W.

«A Spiral Model of Software Development and Enhancement»

IEEE Computer, Vol. 21, no. 5 (May 1988), pp 61-72.

10. Humphrey, Watts S.

Managing the Software Process.

Reading, MA: Addison-Wesley, 1989.

11. Marks, David M.

Testing Very Big Systems.

New-York: Bellcore (McGraw-Hill), 1992.

12. Карлбертсон Р., Браун К., Кобб Г.

Быстрое тестирование

Изд. Вильямс 2002, 216 с.

13. Дастин Э., Рэшка Дж., Пол Дж.

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

Изд. Лори 2003, 310 с.

ПРИЛОЖЕНИЕ. ПРИМЕНЕНИЕ СТАНДАРТА IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Стандарт IEEE 829 Software Test Documentation - «задает планку» для индустрии ИТ по организации процесса тестирования. Этот стандарт разрабатывался с 1977 года и был утвержден в 1983 году, а затем вновь подтвержден в 1991 и 1998 годах. Несмотря на свою зрелость, он актуален и в 21-м веке. Стандарт «ложится» как на каскадную, так и на спиральную, итерационную модель жизненного цикла (ЖЦ) разработки и сопровождения программного обеспечения, а также стандарт не противоречит идеологии объектно-ориентированного подхода. IEEE STD 829 предлагает основу - достаточный набор документов для того, чтобы:

· упорядочить работы по этапам, стадиям;

· разделить ответственность и объем работ;

· унифицировать документы в проекте или в организации.

Место и роль процесса тестирования в жизненном цикле разработки и сопровождения ПО описаны во многих стандартах, в том числе и в стандарте ГОСТ Р ИСО/МЭК 12207.

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

Данный стандарт относится к динамическому тестированию, т.е. с выполнением кода ПО, и не относится к менее популярному статическому тестированию.

Состав документов, рекомендованных в стандарте IEEE STD 829:

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

Рекомендованный состав плана тестирования:

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

Спецификация сценария теста:

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

Спецификация тестовой процедуры:

Название, цель, специальные требования, шаги выполнения процедуры.

Использование стандарта IEEE STD 829 в реальных проектах.

За последние три года данный стандарт эффективно использовался Центром тестирования департамента консалтинга компании АйТи в следующих проектах: нагрузочное тестирование биллинговых систем, функциональное тестирование CRM-системы, внедрение стандарта предприятия для учреждения Банк. Большой эффект экономии ресурсов и средств дает использование отработанных, адаптированных шаблонов документов, перечисленных в стандарте. Для каждого проекта можно определить степень стандартизации - создание СТП, методики или простое использование шаблона.

По практике данных работ видно, что стандарт можно дополнить, например, если используется объектно-ориентированное проектирование (ООП), то можно добавить следующие документы: описание тестовых классов, тестовых пакетов. Экономия при использовании шаблонов не только в том, что есть образец, но и в том, что логика и состав документа тщательно продуманы и проработаны, как оп смыслу, так и по оформлению, т.е. не нужно «изобретать велосипед». А для случаев, когда выполняется заказная работа, эти шаблоны готовы для рассмотрения и согласования с Заказчиком с первых дней и часов с начала работ. Для больших и/или достаточно формализованных проектов (RUP) требуется полный или расширенный список документов, а для малых проектов, которые очень распространены в последнее время в связи с популярностью аутсортинга, методологий RAD, XP - список документов может быть сокращен или упрощен.

Плюсы внедрения стандарта - унификация (ускорение работ, единая корпоративная структура), смысловая полнота.

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

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

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

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

Ресурсные затраты на разработку одинакового типа шаблона могут отличаться для разных организаций: создание в первый раз - от 8 часов, при наличие подходящего образца и опыта, до нескольких дней; адаптация отработанного шаблона для нового проекта - от 1 часа до 1дня. Некоторые методологии и пакеты инструментальных средств предлагают наборы типовых шаблонов по разным процессам, в том числе и для тестирования.

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