ТЕСТИРОВАНИЕ КОМПОНЕНТ ИНФОРМАЦИОННОЙ СИСТЕМЫ




 

Описание информационной системы

 

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

 

Составление тест-кейсов

 

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

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения – Разработка кода – Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40%, из чего следует, что наибольший эффект в снижении трудоемкости может быть получен прежде всего на фазах Design и Testing. Поэтому основные вложения в автоматизацию или генерацию кода следует осуществлять, прежде всего, на этих фазах. Хотя в современном индустриальном программировании автоматизация тестирования является широко распространенной практикой, в то же время технология верификации требований и спецификаций пока делает только свои первые шаги. Задачей ближайшего будущего является движение в сторону такого распределения трудоемкости (60%-20%-20%), чтобы суммарная цена обнаружения большинства дефектов стремилась к минимуму за счет обнаружения преимущественного числа на наиболее ранних фазах разработки программного продукта.

Отладка (debug, debugging) – процесс поиска, локализации и исправления ошибок в программе [IEEE Std.610-12.1990].

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

Тестирование обеспечивает выявление (констатацию наличия) фактов расхождений с требованиями (ошибок).

Как правило, на фазе тестирования осуществляется и исправление идентифицированных ошибок, включающее локализацию ошибок, нахождение причин ошибок и соответствующую корректировку программы тестируемого приложения (ApplicationUnderTesting (AUT) или ImplementationUnderTesting (IUT)).

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

Тестирование разделяют на статическое и динамическое:

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

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.

Реализация тестирования разделяется на три этапа:

1) создание тестового набора (testsuite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testingenvironment).

2) прогон программы на тестах, управляемый тестовым монитором (testmonitor, testdriver [IEEE Std 829-1983]) с получением протокола результатов тестирования (testlog).

3) оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.

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

Самым часто используемым способом тестирования являются тест-кейсы. Тест-кейс – это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.Набор тест-кейсов называется тестовым набором (testsuite).

Стандартные атрибуты тест-кейса:

1) номер – уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге);

2) название – краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко;

3) предварительные шаги – описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется;

4) шаги – описание действий, необходимых для проверки (например, создание элемента);

5) ожидаемый результат (ОР) – сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").

Каждый выполненный тест-кейс, дает один из трех результатов:

1) положительный результат, если фактический результат равен ожидаемому результату;

2) отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка;

3) выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка;

Одним тест-кейсом проверяется одна конкретная вещь, и для этой вещи должен быть только один ожидаемый результат.

Чего не должно быть в тест-кейсе:

1) зависимостей от других тест-кейсов;

2) нечеткой формулировки шагов или ожидаемого результата;

3) отсутствия необходимой для прохождения тест-кейса информации;

4) излишней детализации.

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

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

Если описание шагов или ожидаемое результата будет не четким, то это блокирует прохождение тест-кейса.

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

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

Для тестируемой информационной системы были составлены следующие тест-кейсы.

Тест-кейс №01

Выбор пункта меню, которого нет в списке.

Шаги:

1) запустить программу;

2) написать цифру, отличающуюся от 1,2,3,4,5;

3) нажать Enter.

Ожидаемый результат:

Сообщение об отсутствии данного пункта и возвращение к главному меню.

Тест-кейс №02

Ввод нечисловых данных в выборе пункта меню.

Шаги:

1) запустить программу;

2) ввести любую букву;

3) нажать Enter.

Ожидаемый результат:

Сообщение об отсутствии данного пункта и возвращение к главному меню.

Тест-кейс №03

Просмотр отчёта.

Шаги:

1) запустить программу;

2) ввести цифру 1;

3) нажать Enter.

Ожидаемый результат;

Вывод сообщения со списком всех домов и их площадей на текущий момент.

Тест-кейс №04

Удаление несуществующего дома.

Шаги:

1) запустить программу;

2) ввести цифру 4;

3) ввести цифру, отличную от 1,2.

Ожидаемый результат:

Вывод сообщения об отсутствии такого дома в списке.

Тест-кейс №05

Удаление существующего дома.

Шаги:

1) запустить программу;

2) ввести цифру 4;

3) ввести цифру 2;

4) в главном меню ввести цифру 1.

Ожидаемый результат:

В списке домов останется только одна позиция.

 

Результаты тестирования

 

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

Тест-кейс №01 – полученный результат соответствует ожидаемому.

Тест-кейс №02 – программа выводит ошибку о несовместимом типе данных.

Тест-кейс №03 – полученный результат соответствует ожидаемому.

Тест-кейс №04 – программа выводит ошибку об отсутствии такого элемента.

Тест-кейс №05 – полученный результат соответствует ожидаемому.

 


 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2018-01-31 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: