Целостность данных и баз данных
Цель Тестирования:
Убедиться в надежности методов доступа к базам данных, в их правильном исполнении, без нарушения целостности данных.
Методика:
Необходимо последовательно испробовать максимально возможное число способов обращения к базе. Используется подход, при котором тест составляется таким образом, чтобы «нагрузить» базу последовательностью, как верных значений, так и заведомо ошибочных.
После этого необходимо оценить правильность внесения данных и убедиться в корректной обработке базой входящих значений.
Критерии Завершения:
Все способы доступа функционируют, в соответствии с требованиями.
Действия скрипта не приводят к потере данных или нарушению целостности базы, либо к другим неадекватным реакциям.
Пользовательский интерфейс
Цель Тестирования:
Проверить правильность навигации по объекту тестирования (в том числе межоконные переходы, переходы между полями, правильность обработки клавиш «enter» и «tab», работа с мышью, функционирование клавиш-акселераторов и полное соответствие индустриальным стандартам);
Проверить объекты и их характеристики (меню, размеры, положения, состояния, фокус ввода и др.) на соответствия общепринятым стандартам на графический интерфейс пользователя.
Методика:
Создаются или дорабатываются тесты для каждого из окон, на предмет соответствия навигации и состояний каждого из объектов.
Критерии завершения:
|
|
|
Каждое окно протестировано и удовлетворяет, базовой линии поведения, требованиям стандартов и не противоречит проектным требованиям. Все выявленные дефекты обработаны и документированы.
Описание процесса тестирования как этапа разработки программного обеспечения
Процесс тестирования - один из основных процессов общего процесса разработки программного обеспечения. Для того чтобы выработать правильный алгоритм процесса тестирования, определить стратегии тестирования, запланировать процесс тестирования заданного программного комплекса необходимо знать место процесса тестирования в общем процессе разработки программного обеспечения. Покажем место тестирования в общем процессе разработки программного обеспечения, определим объекты тестирования, уровни тестирования на карте процесса тестирования, которая приведена на рисунке 4.
Рисунок 4 – Место тестирования в процессе разработки ПО
Анализируя карту процесса тестирования, мы видим, что процесс тестирования начинается на этапе проектирования и разработки технической документации на программный комплекс. Правильно построенный процесс тестирования не может начинаться на этапе программирования или внедрения и сопровождения. Только таким образом построенный процесс тестирования позволит на ранних стадиях разработки, а именно, на стадии разработки требований к программным комплексам, выявить дефекты, которые в будущем могут негативно сказаться на разрабатываемом программном комплексе. Объектами тестирования на этапе разработки требований к программному комплексу является техническая документация в виде технических заданий, спецификаций на отдельные модули или систему в целом, руководства пользователей. Этап тестирования заключается в регистрации и анализе требований к программному комплексу в системе поддержки процесса тестирования через модуль управления требованиями к ПО. Тестирование документации проводится на корректность, полноту, однозначность, непротиворечивость, тестируемость, упорядоченность, модифицируемость, отслеживаемость. На данном этапе процесса тестирования инженер по тестированию обращается к базе данных документов. В результате тестирования документации и ее анализа необходимо перейти к этапу планирования процесса тестирования конкретного модуля, интеграции модулей или системы в целом. Руководитель группы тестирования составляет план тестирования, определяет стратегии тестирования, при этом он работает с базой данных заданий на тестирование. Группа тестирования начинает проектирование тестов, подготовку тестовых данных, тестовой среды и окружения. Как только группа тестирования получает от разработчиков модуль, группу модулей или программный комплекс начинается этап выполнения тестов и регистрации дефектов. При этом идет пополнение базы данных тестов и дефектов. Руководитель группы тестирования, в свою очередь, работая с базами данных тестов и дефектов через подсистему генерации отчетности, получает информацию о ходе процесса тестирования и анализирует состояние тестируемого программного комплекса. Как только выполняется условие завершения работ (закончилось время, отведенное на тестирование; закончились денежные средства, выделенные на тестирование проекта; найдены дефекты, неисправленными остались лишь незначительные дефекты), руководитель группы тестирования составляет отчет о тестировании и программный комплекс передается в эксплуатацию. Таким образом, происходит тестирование программного комплекса на всех трех уровнях тестирования: модульном, интеграционном, системном, изменяется лишь объект тестирования.
|
|
|
|
|
|
Модель работы с дефектами
|
|
|
Каждый обнаруженный дефект программного комплекса должен быть зарегистрирован и с ним должна быть проведена работа, которая в конечном итоге должна привести к исправлению дефекта. Работа с дефектами осуществляется по выбранной модели работы с дефектами. Выбор модели работы с дефектами зависит от конкретного проекта, структуры подразделения разработчиков и инженеров по тестированию. Для разработанной системы поддержки процесса тестирования была спроектирована модель работы с дефектами, которая представлена на рисунке 5:
Рисунок 5 – Модель работы с дефектами
Как только дефект обнаружен, тестировщик регистрирует его в подсистеме работы с дефектами, присваивая ему статус «Новый» и направляет его на руководителя группы тестирования. Руководитель группы тестирования подтверждает дефект и направляет его на руководителя группы разработчиков или направляет дефект на инженера по тестированию на доработку. Далее руководитель группы разработчиков направляет дефект на программиста, отвечающего за дефект, программист изучает суть дефекта и проставляет статус «В процессе». Если в данный момент необходимо отложить исправление дефекта, то разработчик может присвоить дефекту статус «Отложен». После исправления дефекта разработчик присваивает ему статус «Исправлен» и направляет дефект на руководителя группы тестировщиков, а тот направляет дефект на тестировщика. Инженер по тестированию проверяет дефект и если он исправлен, присваивает ему статус «Исправлен». Если дефект не исправлен, то ему присваивается статус «Не исправлен» и направляется на программиста для исправления.
Всем дефектам со статусом «Исправлен» руководитель группы тестирования присваивает статус «Закрыт».
Кроме статусов атрибутами дефекта являются приоритет и важность. Приоритет дефекта показывает насколько быстро нужно исправить дефект, по приоритету определяется очередность выполнения задачи. Важность характеризует критичность дефекта по отношению к тестируемому приложению. Например, по признаку «важность» дефект может быть описан как «блокирующий» - не позволяющий приложению запуститься, «критичный» - некоторые функции приложения недоступны, «крупный» - какая-то функция не работает , «средний» - часть функции не работает и «второстепенный» - не влияющий не работу приложения (например, неправильное написание или неудобное расположение элементов управления). Приоритет в свою очередь может быть «высоким», «средним» и «низким».
Такая модель работы с дефектами позволяет полностью контролировать состояние тестируемого проекта, распределяет роли между участниками процесса тестирования и делает процесс работы с дефектами открытым и отслеживаемым как для тестировщиков, так и для разработчиков.
Рассмотрим пример создания unit-test.
СОЗДАНИЕ ПРОЕКТА ТЕСТИРОВАНИЯ
Откроем созданное решение, нажмем правой кнопкой мыши на решении и выберем «New Project»
Далее выберем Test – Unit Test Project. 
В решение добавится новый проект.
СОЗДАНИЕ ЮНИТ ТЕСТА
Добавим в проект базовый юнит-тест.
И напишем первый тест. Тест проверяет различные варианты ошибок.
Для тестирования проекта, подключим его к тестовому проекту. Для этого необходимо нажать правой кнопкой мыши по «References» и выбрать «Add Reference».
После чего выбрать нужный проект:
Для тестирования авторизации, нужно немного видоизменить форму авторизации:
Теперь можно начинать тестировать авторизацию. Создадим новый метод для проверки авторизации и напишем следующий код:
Запустим все тесты на выполнение:
После запуска можем увидеть какие тесты были пройдены, а какие нет.
Задание: Представьте себе, что ваша цель – тестирование приложения или сервиса, указанного в вашем варианте работы. Необходимо указать, какие тесты необходимы для покрытия различных видов, типов и областей тестирования, представленных в таблице 1. При этом нет необходимости перечислять все тесты. Необходимо привести 2-3 конкретных примера тестов (см. пример выполнения работы).
Таблица 1.
| Тесты | Пример тестов |
| Различные виды тестирования | |
| Функциональное тестирование (Functional testing) | |
| Тестирование производительности (Performance testing) | |
| Нагрузочное тестирование (Load testing) | |
| Тестирование совместимости (Compatibility testing) | |
| Различные типы тестов | |
| Позитивные тесты | |
| Негативные тесты | |
| Исследовательские тесты | |
| Различные области тестирования | |
| Модульное тестирование | |
| Интеграционное тестирование | |
| Системное тестирование | |
Пример выполнения работы: Тестирования форума тестировщиков (http://software-testing.ru/forum)
| Тесты | Пример тестов |
| Различные виды тестирования | |
| Функциональные тесты (Functional testing) | Переход по разделам форума. Поиск по сайту. Подписка на рассылку - письма с информацией приходят. |
| Тесты производительности (Performance testing) | Скорость перехода по вкладкам Скорость поиска по ключевым словам |
| Нагрузочные тесты (Load testing) | Большое количество пользователей обращаются к разделам форума. Большой апдейт нескольких разделов |
| Тестирование совместимости (Compatibility testing) | Корректная работа форума в разных браузерах |
| Различные типы тестов | |
| Позитивные тесты | Правильность ссылок - ведут куда предполагалось. Правильность поиска по ключевым словам – находят нужные темы. |
| Негативные тесты | Не авторизованный пользователь не может оставлять комментарии на форуме Не модератор не может закрыть тему на форуме |
| Исследовательские тесты | Ввод информации символами с диакритическими знаками |
| Различные области тестирования | |
| Модульное тестирование | Тестирование каждого раздела в отдельности Тестирование модуля регистрации |
| Интеграционное тестирование | Авторизация: залогиниться в одном разделе, перейти в другой, система не выкинула – «продолжает» узнавать Правильно ли работают вместе модуль учета статистики и модуль добавления сообщений. |
| Системное тестирование | Основные сценарии использования форума соответствуют ожиданию. Встроенное видео проигрывается, картинки отображаются, текст отображается корректно. |
Варианты:
1) Текстовый редактор Notepad.
2) Почтовый сервис Mail.Ru (www.mail.ru).
3) Графический редактор Paint.
4) Сервис хранения файлов Яндекс.Диск (http://disk.yandex.ru/).
5) Проигрыватель Windows Media Player.
6) Картографический сервис Google-карты (https://maps.google.ru/).
7) Браузер Internet Explorer.
8) Торрент-клиент µTorrent.
9) Архиватор WinRar.
10)
| Задание: 1) Изучить шаблоны тестовой документации https://drive.google.com/drive/folders/1NrRGxRfGmf0HGT4fTCFvZpe1oCLd-lkn; 2) Выполнить тестирование и оформить тестовую документацию в соответствие с заданием https://drive.google.com/drive/folders/1NrRGxRfGmf0HGT4fTCFvZpe1oCLd-lkn. |
ЧАСТЬ 3. СОДЕРЖАНИЕ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ ОСНОВНОЙ ПРОФЕССИОНАЛЬНОЙ ОБРАЗОВАТЕЛЬНОЙ ПРОГРАММЫ И МЕТОДИКА ПРЕПОДАВАНИЯ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ С УЧЕТОМ СТАНДАРТА ВОРЛДСКИЛЛС РОССИЯ ПО КОМПЕТЕНЦИИ «ПРОГРАММНЫЕ РЕШЕНИЯ ДЛЯ БИЗНЕСА»
Тема 3.1 Методика реализации основной профессиональной образовательной программы (программ) по профессии (специальности) 09.02.07 Информационные системы и программирование с учетом стандарта Ворлдскиллс Россия по компетенции «Программные решения для бизнеса»
Дата добавления: 2020-04-25; просмотров: 215; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!