Нотации, аббревиатуры и определения принятые в документе



Государственное бюджетное профессиональное образовательное учреждение

Астраханской области
«Астраханский колледж вычислительной техники»

 

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

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

по МДК.03.03
Тестирование информационных систем
по специальности
09.02.07 Информационные системы и программирование

 

Астрахань


 

одобрена

Утверждаю

 

Цикловой комиссией 09.02.07 Информационные системы и программирование

 

Зам. директора по УМВР

  Протокол от «

 

»   20   г.     «   »

 

20   г.
 

Председатель

 

Ю.С. Андрианова

 

 

С.В. Расторгуева

                                         

 

Разработчики: Р.Р. Заитова, преподаватель ГБПОУ АО «АКВТ»
   
   

Организация-разработчик:

государственное бюджетное профессиональное образовательное учреждение Астраханской области «Астраханский колледж вычислительной техники» (далее – ГБПОУ АО «АКВТ»)

 


Содержание

 

1   Описание тестируемой системы и ее окружения. 4

2   Локализация и типизация ошибок. 16

3   Системное тестирование. 22

4   Планирование тестирования. 25

5   Программа и методика испытаний. 32

6   Тестирование безопасности. 38

7   Инсталляционное тестирование. 41

8   Создание Unit тестов. 46

9   Документация по тестированию.. 62

ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ.. 64

 

 


Описание тестируемой системы и ее окружения

Цель работы

1.1.1 Ознакомиться с понятием описания тестируемой системы и ее окружения.

1.1.2 Научиться оформлять тест план.

Приборы и оборудование

1.2.1 Методические указания к выполнению практического занятия.

Порядок выполнения работы

1.3.1 Выполнить постановку задачи, согласно индивидуальному варианту.

1.3.2 Составить тест план для данной системы.

Контрольные вопросы

1.4.1 Что такое тестирование программного продукта?

1.4.2 Что такое тест план?

1.4.3 Из чего состоит тест план?

 


 

Приложение А

ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

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

Test Plan (Тест план) — это документ, подробно определяющий, и описывающий что и как теcтировать.

Из чего состоит Тест План

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

Компоненты, которые должны тестироваться

Этот раздел тест-плана содержит списки тестируемых компонентов:

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

Раздел «Характеристики и свойства, которые не должны тестироваться»

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

В раздел «План проведения испытаний»

вы можете включить такие темы:

· статическое и динамическое тестирование, которое должно проводиться на
стадиях тестирования программных модулей и кодов,

· тестирование свойств,

· испытания под нагрузкой, при перегрузках, тестирование производительности,

· тестирование установки, обновления программного продукта и средств дублирования, восстановления,

· приемочные испытания: альфа-, бета- и другие виды испытаний на месте,

· использование системы отслеживания дефектов.

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

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

 

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

Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

 

Пример плана тестирования 1

 

Предисловие

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

Документ показал свою высокую полезность. Но. На то чтобы научиться пользоваться этим типом документом нужно время. Чтобы научиться его писать нужно еще больше времени.

Пробуйте. Возможно вам этот тип документа окажется полезен. А может и нет.

Да еще. Размер и форма должны выбираться в зависимости от размера и типа проекта. Расширенная форма приведенная ниже неплохо подходит для проектов размером “десятки человеколет” - “несколько человековеков”. Для проекта поменьше я использовал форму “две страницы А4 цветными ручками в тетради”. Тоже хорошо работало. Не факт, что приведенный ниже документ использовался в реальном проекте. Но факт, что использовались похожие документы. Термин “план” используется в значении близком к “стратегия”. Это не календарный график и не перечень тестовых примеров.

План тестирования системы

Версия 1.1

История исправлений

Дата Версия Описание Автор

02.01.20хх 1.0 Создан

07.01.20хх 1.1 Подготовлен черновик

Содержание

1 Введение

1.1 Цель

1.2 Состав документа

1.3 Нотации, аббревиатуры и определения принятые в документе

1.4 Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93

1.5 Ссылки

2 Идентификация объектов тестирования

4 Стратегия тестирования

4 Виды проводимых тестов

4.1 Функциональное тестирование

4.2 Тестирование бизнес цикла

4.3 Конфигурационное тестирование

4.4 Тестирование производительности

4.5 Стресс тестирование

4.6 Юзабилити тестирование

4.7 Тестирование инсталляции

5 Требования к численности и квалификации персонала

5.1 Оценка объема работ

5.2 Распределение по ролям и квалификации

6 Необходимые ресурсы

6.1 Программные средства

Введение

Цель

Цель документа “План тестирования системы” - координация усилий участников проекта в части контроля качества.

Документ предназначен руководству проекта, проектному офису и руководству департамента для согласования планов и оценки затрат.

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

Состав документа

Документ содержит описание общих для подсистем стратегии, подходов и видов тестов. Также определяет численные и квалификационные требования к персоналу, необходимые для успешного тестирования; необходимое программное и аппаратное обеспечение.

Информация, специфическая для отдельных подсистем, описывается в отдельных планах тестирования для каждой конкретной подсистемы.

Нотации, аббревиатуры и определения принятые в документе

TBD (To Be Defined) - будет определено в дальнейшем. Указывает, что данный раздел документа еще не разработан.

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

Описание дефекта - формализованное описание, составленное в той или иной системе учета дефектов. Дефект существует вне зависимости от того описали его или нет и от того нашли его или нет.

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

Контроль качества продукта - более широкое определение, нежели тестирование, включающее в себя, в том числе тестирование. Так например просмотр кода, также называемый code review или статическим тестированием обеспечивает контроль такой метрики как “Сопровождаемость->Изменяемость” (в классификации ГОСТ 9126), но при этом не используется прогон программы. Кроме, собственно, программы (исполняемого кода) контролю качества подвергаются другие конечные артефакты: руководство пользователя, руководство администратора, …

Также может контроль качества может применяться не к конечным, а рабочим артефактам (ЧТЗ, прототипы интерфейсов, …)

QA (Quality assurance) - работы по улучшению и поддержанию процессов, контролю соответствия процессам. Не имеют отношения к тестированию.

Метрика программного обеспечения (англ. software metric) - это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

Конечный артефакт - самостоятельная часть продукта, передаваемая заказчику

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

Тестирование методом свободного поиска (exploratory testing) - также называется тестированием на основе сеансов. Не предполагает жестко заданных, формализованных сценариев тестирования. Часто, проводится в парах.


Дата добавления: 2021-02-10; просмотров: 169; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!