• 
  Окружение тестируемой системы;
  
• 
  Необходимое для тестирования оборудование и программные средства;
  
• 
  Риски и их разрешение.
  

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

• 
  Мастер Тест План (Master Plan or Master Test Plan);
  
• 
  Тест План (Test Plan, назовем его детальный тест план);
  
• 
  План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные работники и т.д. (Шаблон плана приемо-сдаточных испытаний от RUP).
  

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте.

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

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

• 
  Ведущий тестировщик;
  
• 
  Тест менеджер (менеджер по качеству);
  
• 
  Руководитель разработки;
  
• 
  Менеджер Проекта.
  

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

2.2 ТЕСТ-ДИЗАЙН. ПРИНЦИПЫ РАЗРАБОТКИ ТЕСТОВ

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

---

Цели тест дизайна

• 
  Обеспечить покрытие функционала приложения тестами:
  
• 
  Тесты должны покрывать весь функционал
  
• 
  Тестов должно быть минимально достаточно
  

Тест дизайн задачи

• 
  Проанализировать требования к продукту
  
• 
  Оценить риски возможные при использовании продукта
  
• 
  Написать достаточное минимальное количество тестов
  
• 
  Разграничить тесты на приемочные, критические, расширенные
  

Рисунок 4 - Техники текст-дизайна

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

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

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

Таблица 1 - Пример таблицы

Входные условия	Правильные классы	Неправильные классы
	эквивалентности	эквивалентности

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

---

Алгоритм использования:

1. 
   Определить классы эквивалентности.
   
2. 
   Это главный шаг техники, т.к. во многом от него зависит эффективность её применения.
   
3. 
   Выбрать одного представителя от каждого класса эквивалентности.
   
4. 
   На этом этапе следует выбрать один тест из эквивалентного набора тестов.
   
5. 
   Выполнение тестов.
   
6. 
   На этом шаге следует выполнить тесты от каждого класса эквивалентности.
   
7. 
   Если есть время, можно протестировать еще несколько представителей от каждого класса эквивалентности. Следует иметь ввиду, при правильном определение классов эквивалентности дополнительные тесты скорее всего будут избыточными и дадут такой же результат.
   

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

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

---

На каждой границе диапазона следует проверить по три значения:

• 
  граничное значение;
  
• 
  значение перед границей;
  
• 
  значение после границы.
  

Цель этой техники — найти ошибки, связанные с граничными значениями.

Алгоритм использования техники граничных значений:

1. 
   Выделить классы эквивалентности;
   
2. 
   Как и в предыдущей технике, этот шаг является очень важным и от того, насколько правильным будет разбиение на классы эквивалентности, зависит эффективность тестов граничных значений.
   
3. 
   Определить граничные значения этих классов;
   
4. 
   Нужно понять, к какому классу будет относиться каждая граница;
   
5. 
   Нужно провести тесты по проверке значения до границы, на границе и сразу после границы.
   

Количество тестов для проверки граничных значений будет равен количеству границ, умноженному на 3. Рекомендуется проверять значения вплотную к границе. К примеру, есть диапазон целых чисел, граница находится в числе 100. Таким образом, будем проводить тесты с числом 99 (до границы), 100 (сама граница), 101 (после границы).

Попарное тестирование

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

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.

Пример 

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Пример:

№ Браузер Операционная система Язык

1 Opera Windows RU

2 Google Chrome Linux RU

3 Opera Linux EN

4 Google Chrome Windows EN

При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех. 

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT).

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

---

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

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

2.3 РАЗРАБОТКА И ДОКУМЕНТИРОВАНИЕ ТЕСТОВ

Разработка дымового-теста

Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование[17].

Примеры

Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.

Ошибки при соединении с базой данных (актуально для архитектуры клиент-сервер).

Ошибки загрузки конфигурации и получения настроек для инициализации при запуске.

Если мы говорим про сайт интернет-магазина, то сценарий будет примерно следующим:

1. 
   Сайт открывается.
   
2. 
   Можно выбрать случайный товар и добавить его в корзину.
   
3. 
   Можно оформить и оплатить заказ.
   

Если мы говорим про мобильное приложение, например, messenger, то:

1. 
   Приложение устанавливается и запускается.
   
2. 
   Можно авторизоваться.
   
3. 
   Можно написать сообщение случайном контакту.
   

Что тестируем?

1. 
   Проверка сборки: первым и самым важным шагом дымового теста является проверка сборки, номера сборки и доступности среды. Все усилия по тестированию будут потрачены впустую, если сборка неправильная.
   
2. 
   Создание учетной записи: если ваше приложение предполагает создание пользователя, вам следует попытаться создать нового пользователя и проверить, успешно ли система позволяет вам это сделать. Это важный момент, который часто упускается из виду, поскольку тестировщики продолжают использовать старые учетные данные без тестирования для нового пользователя.
   
3. 
   Вход в систему и Выход из системы: если это возможно в вашей SUT (тестируемая система), в рамках дымового теста вы должны попытаться успешно войти в систему со старыми и вновь созданными учетными данными. Также убедитесь, что вы можете успешно выйти из системы без каких-либо ошибок.
   
4. 
   Критически важные для бизнеса функции: это очень важно. Для всех основных или критически важных функций мы должны провести простой тест, чтобы убедиться, что наиболее часто используемые функции не нарушены.
   
5. 
   Сценарии интеграции: это самая важная часть дымового теста. Эффективность этой части зависит от понимания тестером интеграции системы. Например, если тестировщик знает, что какие-то данные текут из системы A в систему B, то он должен сделать это как часть дымового теста (любое значение 1). Это также делается для того, чтобы система не сломалась ни в одной из этих точек интеграции.
   
6. 
   Добавить / изменить / удалить: данные всегда сохраняются в базе данных. Три основных операции в базе данных: добавление записи, редактирование записи и удаление записи. Таким образом, чтобы обеспечить надлежащее соединение с базой данных, в рамках дымового теста необходимо попытаться создать, отредактировать и удалить запись, которая применима в тестируемой системе.
   
7. 
   Общая навигация: последняя часть - общая навигация. То есть нужно пройти через приложение, попытаться коснуться часто используемых функций и страниц, чтобы убедиться, что вся навигация работает должным образом.
   

---

Смотрите также файлы

• Все мы едины, все мы оренбургцы так писал поэт и общественный деятель Гавриил Романович Державин.docx

• Протокол от 2022г. Рассмотрено на педагогическом совете Протокол .docx

• Отчет по производственной практике (по профилю специальности) Лит. Листов 100 втжт филиал ргупс содержание.pdf

• 10кл. Бжб2. Жер планетасындаы ауіпті алдытар, леуметтік тесіздік адам ытары жне кмек.docx

• Седьмая.docx