ПОЗНАВАТЕЛЬНОЕ

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

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Принципы организации тестирования.

Курсовая работа по дисциплине «Тестирование ПО»

Задание.

1.Написать приложение, которое будет тестироваться, в соответствии с вариантом задания. Номер варианта совпадает с порядковым номером в списке группы. В интерфейсе пользователя необходимо отразить сортировку с помощью визуальных объектов (например, в виде диаграммы). Архитектура MVC.

№ варианта	задание
Тип сортировки	Интерфейс пользователя	Метод хранения данных
Быстрая сортировка	Сортировка слиянием	Пирамидальная сортировка	Корневая сортировка	Сортировка Шелла	Пузырьковая сортировка	Сортировка вставками	графический	веб	файл txt	файл xml
	+							+		+
		+							+		+
			+					+		+
				+					+		+
					+			+		+
						+			+		+
							+	+		+
	+								+		+
		+						+		+
			+						+		+
				+				+		+
					+				+		+
						+		+		+
							+		+		+
	+							+		+

2.Задание по тестированию. Результаты работы над курсовым проектом необходимо оформить в виде документа, содержание которого соответствует приведенному ниже. Для создания документации можете попробовать использовать https://github.com/allure-framework. Вся тестовая документация должна быть оформлена в соответствии со стандартом IEEE-829-1998 (при желании можно взять стандарт 2008 года). В случае исключения какого-либо пункта требуется обосновать свое решение во введении. Работы, с одинаковыми выводами и тестами не принимаются! Библиотечные функции сортировки не использовать!

1.Титульник

2.Задание

3.Введение (каковы цели, задачи тестирования, зачем оно нужно, контроль качества ПО…)

4.Схема проекта (отразить все классы, их методы и поля, а также связи между классами). Можно нарисовать в DPAToolkit.

5.Тест-план (строго в соответствии со стандартом IEEE-829-1998 или 2008).

6.Тест-кейсы (должны быть оформлены в соответствии с примерами).

7.Выводы (копии с работ одногруппников не принимаются).

8.Литература.

Теоретические сведения

1.Все чаще используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process . На рисунке можно увидеть жизненный цикл продукта по RUP. При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл.

Жизненный цикл продукта по RUP.

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

В соответствие с соотношением различных задач в итерации они группируются в фазы. В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рисунок. Итерации жизненного цикла программного продукта.

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

2. Методология тестирования. В терминологии тестирования фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

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

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

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

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

Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика».

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

Системное тестирование (System testing) - это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы. Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI).

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

Рисунок. Уровни тестирования.

Статическое тестирование (Static testing)– тестирование, в ходе которого тестируемая программа (код) не выполняется (запускается). Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. Примеры статического тестирования:

– обзоры (Reviews);

– инспекции (Inspections);

– сквозные просмотры (Walkthroughs);

– аудиты (Audits).

Динамическое тестирование (Dynamic testing) – тестирование, в ходе которого тестируемая программа (код) выполняется (запускается).

Альфа-тестирование — тестирование в процессе разработки. Бета-тестирование — тестирование выполняется пользователями (end-users). Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован.

Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения. После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.

4.Виды тестирования.

Функциональное тестирование (Functional testing) - цель данного тестирования состоит в том, чтобы убедиться в надлежащем функционировании объекта тестирования:

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

– проверятся, все ли функциональные требования действительно запрограммированы/реализованы.

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

– продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях;

– измерить, какая часть системы является причиной «плохой» производительности системы;

– измерить время реакции на действие пользователя, время отклика на запрос, и т.д.

Стрессовое тестирование (Stress testing) - обычно используется для понимания пределов пропускной способности приложения. Этот тип тестирования проводится для определения надёжности системы во время экстремальных нагрузок и отвечает на вопросы о достаточной производительности системы в случае, если текущая нагрузка сильно превысит ожидаемый максимум.

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

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

Тестирование удобства использования (Usability testing) - исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как вебстраница, пользовательский интерфейс или устройство) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействие человек-компьютер в целом — формулируют универсальные принципы. Это метод оценки удобства продукта в использовании, основанный на привлечении пользователей в качестве тестировщиков, испытателей и суммировании полученных от них выводов. При испытании многих продуктов пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания. Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства — с целью последующего более детального анализа. Если юзабилити-тестирование выявляет какие-либо трудности (например, сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование.

Тестирование интерфейса пользователя (UI testing) - тестирование графического интерфейса пользователя для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям. Проверяется, как приложение обрабатывает ввод с клавиатуры и «мышки» и как отображаются элементы графического интерфейса (текст, кнопки, меню, списки и прочие элементы).

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

5.Процесс тестирования.

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

Тестирование может использоваться для достаточно уверенного вынесения оценок о качестве программного обеспечения. Для этого необходимо иметь критерии полноты тестирования, описывающие важность различных ситуаций для оценки качества, а также эквивалентности и зависимости между ними. Этот критерий может утверждать, что все равно в какой из ситуаций, A или B, проверять правильность работы программного обеспечения, или, если программа правильно работает в ситуации A, то, скорее всего, в ситуации B все тоже будет правильно. Часто критерий полноты тестирования задается при помощи определения эквивалентности ситуаций, дающей конечный набор классов ситуаций. В этом случае считают, что все равно, какую из ситуаций одного класса использовать в качестве теста. Такой критерий называют критерием тестового покрытия, а процент классов эквивалентности ситуаций, случившихся вовремя тестирования, — достигнутым тестовым покрытием. Таким образом, основные задачи тестирования: построить такой набор ситуаций, который был бы достаточно представителен и позволял бы завершить тестирование с достаточной степенью уверенности в правильности программного обеспечения вообще, и убедиться, что в конкретной ситуации программное обеспечение работает правильно, в соответствии с требованиями.

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

Рисунок. Схема процесса тестирования.

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

Принципы организации тестирования.

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

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

Необходимая часть любого теста — описание ожидаемых выходных данных или результатов. Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда глаз видит то, что хочет увидеть. Чтобы совсем исключить такую возможность, лучше разрабатывать самопроверяющиеся тесты, либо пользоваться инструментами тестирования, способными автоматически сверять ожидаемые и фактические результаты. Иногда, например, при тестировании математического программного обеспечения, приходится допускать исключения. Математическое программное обеспечение обладает тем свойством, что выходные данные являются только приближением правильного результата. Это происходит из-за использования конечных вычислительных процессов вместо бесконечных математических процессов, из-за ошибок округления, связанных с конечной точностью машинной арифметики и неточностью представления чисел, а также ошибок из-за конечной точности представления входных данных и констант. Поэтому во многих случаях оказывается важной не абсолютная точность, а корреляция ошибок. Например, когда математическая программа возвращает массив чисел, может оказаться важным, чтобы вычисленное решение было точным решением для набора входных данных, аппроксимирующего реальные выходные данные. Поэтому при тестировании математического программного обеспечения прогнозирование точных выходных данных затруднительно.

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

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

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

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

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

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

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

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

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

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

Однако вне зависимости от модели разработки при планировании тестирования необходимо ответить на пять вопросов, определяющих этот процесс:

– кто будет тестировать и на каких этапах? Разработчики продукта, независимая группа тестировщиков или совместно;

– какие компоненты надо тестировать? Будут ли подвергнуты тестированию все компоненты программного продукта или только компоненты, которые угрожают наибольшими потерями для всего проекта;

– когда надо тестировать? Будет ли это непрерывный процесс, вид деятельности, выполняемый в специальных контрольных точках, или вид деятельности, выполняемый на завершающей стадии разработки;

– как надо тестировать? Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано;

– в каком объеме тестировать? Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование.

Все ответы на поставленные вопросы и многое другое фиксируется в документе – Тест-план.

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

Тест-план содержит:

1) перечень тестовых ресурсов;

2) перечень функций и подсистем, подлежащих тестированию;

3) тестовую стратегию:

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

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

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

4) график (расписание) тестовых циклов;

5) указание конкретных параметров аппаратуры и программного окружения;

6) определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п.

Тест план должен как минимум отвечать на следующие вопросы:

1) что надо тестировать? Описание объекта тестирования: системы, приложения, оборудование;

2) что будете тестировать?Список функций и описание тестируемой системы и её компонент в отдельности;

3) как будете тестировать? Сстратегия тестирования, а именно: методологии, виды тестирования и их применение по отношению к тестируемому объекту, приоритеты, автоматизация и пр.;

4) когда будете тестировать? Последовательность проведения работ: фазы, циклы тестирования, процедура тестирования - подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки;

5) где будете тестировать?

– окружение тестируемой системы – описание;

– необходимое для тестирования оборудование и программные средства.

6) кто будет тестировать?

– роли и обязанности;

– имена и фамилии.

7) критерии начала тестирования:

– готовность окружения;

– готовность тест кейсов;

– законченность разработки требуемого функционала;

– выполнение юнит-тестов;

– билд построен и удовлетворяет определенным критериям.

8) критерии окончания тестирования:

– результаты тестирования удовлетворяют определенным критериям;

– требования к количеству открытых багов выполнены (определяются заранее).

9) критерии передачи системы для приемочного тестирования:

– приемочные тесты – где хранятся и когда выполняются;

– процедура приемки.

10) какие риски существую и как мы ими будет управлять? Риски и их разрешение

11) метрики и отчеты:

– продуктовые метрики – кто собирает, с какой периодичностью;

– отчеты - кто создает, кому отправляет, и т.п.

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

– окружение тестируемой системы (описание программно-аппаратных средств);

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

– риски и пути их разрешения.

c)Виды тест-планов. Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

1)мастер тест-план (Master Plan or Master Test Plan);

2)тест-план (Test Plan);

3)план приемочных испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные и т.д.;

4) план автоматизации (Test Automation Plan) - документ, описывающий набор действий, связанных с автоматизацией тестированием: стратегия, правила, ответственные и т.д.

Явное отличие Master Test Plan от просто Test Plan в том, что мастер тест-план является более статичным в силу того, что содержит в себе высокоуровневую информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте. В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.