Описание информационной системы
В качестве тестируемой системы используется программное средство, позволяющее отображать, добавлять, изменять и удалять информацию о домах. Предметная область – жилищно-коммунальное хозяйство. Основной информацией о доме является его адрес и площади всех помещений: комнат, квартир, лестничных клеток, подъездов. Итоговая площадь дома рассчитывается как сумма этих площадей и уже в таком виде выдаётся на отчёт.
Составление тест-кейсов
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта.
С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения – Разработка кода – Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 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 – полученный результат соответствует ожидаемому.