Государственный университет – Высшая Школа Экономики
Факультет бизнес-информатики
Реферат
на тему:
Принципы и инструменты тестирования программных продуктов
Выполнил:
Студент гр.171мУРПО
Реднев Н.С.
Проверил:
Авдошин С.М.
Москва, 2009
СОДЕРЖАНИЕ
Введение. 3
Концепция тестирования. 4
Планирование тестирования. 5
Организация тестирования. 7
Циклы тестирования. 7
Критерии тестирования и требования к ним.. 9
Системное тестирование. 13
Автоматизация тестирования. 14
Заключение. 15
Список литературы.. 17
Введение
Использование любого программного продукта подразумевает оценку качества его работы. Тот или иной продукт оценивается с точки зрения заинтересованных сторон, т.е. как с точки зрения конечных пользователей, так и с точки зрения разработчиков, тестировщиков продукта, а также спонсоров и заказчиков программного продукта. У каждой из заинтересованных сторон есть свое собственное представление о продукте, в том числе и том, насколько качественно он работает.
Одним из наиболее устоявшихся методов оценки качества программного продукта является его тестирование, которое входит в набор эффективных средств современной системы обеспечения качества программного продукта. Тестирование не позиционируется в качестве единственного способа обеспечения качества. Оно является частью общей системы обеспечения качества продукта, элементы которой выбираются по критерию наибольшей эффективности применения в конкретном проекте.
Данный реферат и будет посвящен основным инструментам и принципам тестирования программного продукта.
Начиная разговор об инструментах и принципах тестирования программного продукта, стоит отметить, что с технической точки зрения тестирование подразумевает выполнение приложения на некотором множестве исходных данных и сверке получаемых результатов с так называемыми эталонными данными. Это проводится для того, чтобы установить соответствие различных свойств и характеристик приложения заказанным свойствам.
Являясь одной из ключевых стадий разработки программного продукта, тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Из практики известна оценка распределения трудоемкости между фазами создания программного продукта - 40%-20%-40%[1]
. Данные цифры говорят о том, что наибольший эффект в снижении трудоемкости может быть получен прежде всего на стадиях разработки и тестирования продукта.
Концепция тестирования
Программа – это аналог формулы в обычной математике.
Формула для функции f, полученной суперпозицией функций f1, f2, ... fn – выражение, описывающее эту суперпозицию[2]
.
f = f1* f2* f3*... * fn. Если аналог f1,f2,... fn – операторы языка программирования, то их формула – программа.
Существует два метода обоснования истинности формул[3]
:
1)
Формальный подход или доказательство применяется, когда из исходных формул-аксиом с помощью формальных процедур (правил вывода) выводятся искомые формулы и утверждения (теоремы). Вывод осуществляется путем перехода от одних формул к другим по строгим правилам, которые позволяют свести процедуру перехода от формулы к формуле к последовательности текстовых подстановок:
A**3 = A*A*A
A*A*A = A -> R, A*R -> R, A*R -> R
Преимущество формального подхода заключается в том, что с его помощью удается избегать обращений к бесконечной области значений и на каждом шаге доказательства оперировать только конечным множеством символов.
2)
Интерпретационный подход применяется, когда осуществляется подстановка констант в формулы, а затем интерпретация формул, как осмысленных утверждений в элементах множеств конкретных значений. Истинность интерпретируемых формул проверяется на конечных множествах возможных значений. Сложность подхода состоит в том, что на конечных множествах комбинации возможных значений для реализации исчерпывающей проверки могут оказаться достаточно велики.
Интерпретационный подход используется при экспериментальной проверке соответствия программы своей спецификации
Применение интерпретационного подхода в форме экспериментов над исполняемой программой составляет суть отладки и тестирования.
Если программа не содержит синтаксических ошибок и может быть выполнена на компьютере, она обязательно вычисляет какую-либо функцию, осуществляющую отображение входных данных в выходные. Это означает, что компьютер на своих ресурсах доопределяет частично определенную программой функцию до тотальной определенности. Следовательно, судить о правильности или неправильности результатов выполнения программы можно, только сравнивая спецификацию желаемой функции с результатами ее вычисления, что и осуществляется в процессе тестирования.
Планирование тестирования
Тестовый план
Тестовый план
- это документ, или набор документов, содержащий следующую информацию[4]
:
· Тестовые ресурсы.
· Перечень функций и подсистем, подлежащих тестированию.
· Тестовую стратегию, включающую[5]
:
1) Анализ функций и подсистем с целью определения наиболее слабых мест, то есть областей функциональности тестируемой системы, где появление дефектов наиболее вероятно.
2) Определение стратегии выбора входных данных для тестирования. Так как множество возможных входных данных программного продукта, как правило, практически бесконечно, выбор конечного подмножества, достаточного для проведения исчерпывающего тестирования, является сложной задачей. Для ее решения могут быть применены такие методы, как покрытие классов входных и выходных данных, анализ крайних значений, покрытие модели использования, анализ временной линии и тому подобные. Выбранную стратегию необходимо обосновать и задокументировать.
3) Определение потребности в автоматизированной системе тестирования и дизайн такой системы
4) Расписание тестовых циклов
5) Фиксацию тестовой конфигурации: состава и конкретных параметров аппаратуры и программного окружения.
Определение списка тестовых метрик, которые на тестовом цикле
необходимо собрать и проанализировать. Например, метрик, оценивающих степень покрытия тестами набора требований, степень покрытия кода тестируемой системы, количество и уровень серьезности дефектов, объем тестового кода и другие характеристики.
Типы тестирования
В тестовом плане
определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных[6]
.
Ниже представлены типы тестирования по виду подсистемы или продукта:
Тестирование основной функциональности
, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом
Тестирование инсталляции
включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.
Тестирование пользовательской документации
включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п.
Типы тестирования по способу выбора входных значений:
Функциональное тестирование
, при котором проверяется:
· Покрытие функциональных требований.
· Покрытие сценариев использования.
Стрессовое тестирование
, при котором проверяются экстремальные режимы использования продукта.
Тестирование граничных значений
.
Тестирование производительности
.
Тестирование на соответствие стандартам
.
Тестирование совместимости
с другими программно-аппаратными комплексами.
Тестирование работы с окружением
.
Тестирование работы на конкретной платформе
В реальных разработках используются и комбинируются различные типы тестов для обеспечения спланированного качества продукта.
Организация тестирования
Тестирование осуществляется на заданном заранее множестве входных данных X и множестве предполагаемых результатов Y – (X,Y), которые задают график желаемой функции[7]
. Кроме того, зафиксирована процедура Оракул (oracle), которая определяет, соответствуют ли выходные данные – Yв (вычисленные по входным данным – X) желаемым результатам – Y, т.е. принадлежит ли каждая вычисленная точка (x,yв) графику желаемой функции (X,Y).
Оракул дает заключение о факте появления неправильной пары (x,yв) и ничего не говорит о том, каким образом она была вычислена или каков правильный алгоритм – он только сравнивает вычисленные и желаемые результаты. Оракулом может быть даже Заказчик или программист, производящий соответствующие вычисления в уме, поскольку Оракулу нужен какой-либо альтернативный способ получения функции (X,Y) для вычисления эталонных значений Y.
Циклы тестирования
В тестировании выделяются три основных уровня, или три фазы:
· Модульное тестирование.
· Интеграционное тестирование.
· Системное тестирование.
Задача планирования активности тестирования состоит в оптимальном распределении ресурсов между всеми типами тестирования. В дальнейшем изложении мы сконцентрируемся на системной фазе тестирования, как на наиболее важной и критичной активности для разработки качественного программного продукта.
Фазы процесса тестирования[8]
В процессе тестирования выделяют следующие фазы:
Определение целей
(требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
Планирование
: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов
. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы (Implementation Under Testing (IUT)
или Application Under Testing (AUT)
– часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
Разработка тестов
, то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
Выполнение тестов
: реализация тестовых циклов
.
Анализ результатов
.
После анализа результатов возможно повторение процесса тестирования, начиная с пунктов 3, 2 или даже 1.
Тестовый цикл
Тестовый цикл
– это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса[9]
. Тестовый цикл
заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build
. Тестовый цикл
включает следующую последовательность действий:
· Проверка готовности системы и тестов к проведению тестового цикла
включающая:
· Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
· Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
· Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
· Проверки некоторых дополнительных критериев.
Критерии тестирования и требования к ним
Существуют так называемые критерии тестирования, однако прежде чем рассмотреть данные критерии, приведем основные требования к критериям[10]
:
· Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.
· Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.
· Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы
· Критерий должен быть легко проверяемым, например вычисляемым на тестах
· Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Существует 4 класса критериев:
Структурные критерии (класс I).
Структурные критерии используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing).
Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей).
Функциональные критерии (класс II)
Функциональный критерий - важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Поскольку требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. При функциональном тестировании преимущественно используется модель "черного ящика". Проблема функционального тестирования - это, прежде всего, трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), как правило, достаточно объемны, тем не менее, соответствующая проверка должна быть всеобъемлющей[11]
.
.
Тестирование пунктов спецификации
- набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом
Тестирование классов входных данных
- набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза.
При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что перебирая в соответствии с критерием величины входных переменных (например, различные файлы - источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
Тестирование правил
- набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации фазы тестирования)
Тестирование классов выходных данных
- набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out).
При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
Тестирование функций
- набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза.
Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту).
Критерий тестирования функций объединяет отчасти особенности структурных
и функциональных критериев
. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
Комбинированные критерии для программ и спецификаций
- набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Стохастические критерии (класс III)
Стохастическое тестирование применяется при тестировании сложных программных комплексов - когда набор детерминированных тестов (X,Y) имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестирования, можно применить следующую методику[12]
.
Разработать программы - имитаторы случайных последовательностей входных сигналов {x}.
Вычислить независимым способом значения {y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y).
Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
Детерминированный контроль - проверка соответствия вычисленного значения yв{y} значению y, полученному в результате прогона теста на наборе {x} - случайной последовательности входных сигналов, сгенерированной имитатором.
Стохастический контроль - проверка соответствия множества значений {yв}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества.
Критерии стохастического тестирования
Cтатистические методы
окончания тестирования - стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента (St), метод Хи-квадрат (χ2
) и т.п.
Метод оценки скорости выявления ошибок
- основан на модели скорости выявления ошибок, согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования приложения.
Мутационный критерий (класс IV).
Утверждается, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Подход базируется на следующих понятиях[13]
:
Мутации
- мелкие ошибки в программе.
Мутанты
- программы, отличающиеся друг от друга мутациями
.
Метод мутационного тестирования
- в разрабатываемую программу P вносят мутации
, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты
тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует
мутационному критерию, а тестируемая программа объявляется правильной[14]
.
Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X,Y) и продолжать тестирование.
Системное тестирование
Системное тестирование
рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов.
На уровне системы часто сложно и малоэффективно анализировать прохождение тестовых траекторий внутри программы или отслеживать правильность работы конкретных функций. Основная задача системного тестирования
- в выявлении дефектов, связанных с работой системы в целом, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и тому подобное[15]
.
Системное тестирование
производится над проектом в целом с помощью метода «черного ящика». Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.
Категории тестов
системного тестирования[16]
:
Полнота решения функциональных задач.
Стрессовое тестирование - на предельных объемах нагрузки входного потока.
Корректность использования ресурсов (утечка памяти, возврат ресурсов).
Оценка производительности.
Эффективность защиты от искажения данных и некорректных действий.
Проверка инсталляции и конфигурации на разных платформах.
Корректность документации
Поскольку системное тестирование
проводится на пользовательских интерфейсах, создается иллюзия того, что построение специальной системы автоматизации тестирования не всегда необходимо. Однако объемы данных на этом уровне таковы, что обычно более эффективным подходом является полная или частичная автоматизация тестирования, что приводит к созданию тестовой системы гораздо более сложной, чем система тестирования
, применяемая на уровне тестирования модулей или их комбинаций.
Автоматизация тестирования
Использование различных подходов к тестированию определяется их эффективностью применительно к условиям, определяемым промышленным проектом. В реальных случаях работа группы тестирования планируется так, чтобы разработка тестов начиналась с момента согласования требований к программному продукту (выпуск Requirement Book, содержащей высокоуровневые требования к продукту) и продолжалась параллельно с разработкой дизайна и кода продукта. В результате, к началу системного тестирования создаются тестовые наборы, содержащие тысячи тестов. Большой набор тестов обеспечивает всестороннюю проверку функциональности продукта и гарантирует качество продукта, но пропуск такого количества тестов на этапе системного тестирования представляет проблему. Ее решение лежит в области автоматизации тестирования, т.е. в автоматизации разработки.
Собственно использование эффективной системы автоматизации тестирования сокращает до минимума время пропуска тестов, без которого невозможно подтвердить факт роста качества (уменьшения числа оставшихся ошибок) продукта. Системное тестирование осуществляется в рамках циклов тестирования (периодов пропуска разработанного тестового набора над созданием разрабатываемого приложения). Перед каждым циклом фиксируется разработанный или исправленный build, на который заносятся обнаруженные в результате тестового прогона ошибки. Затем ошибки исправляются, и на очередной цикл тестирования предъявляется новый build. Окончание тестирования совпадает с экспериментально подтвержденным заключением о достигнутом уровне качества относительно выбранного критерия тестирования или о снижении плотности не обнаруженных ошибок до некоторой заранее оговоренной величины. Возможность ограничить цикл тестирования пределом в одни сутки или несколько часов поддерживается исключительно за счет средств автоматизации тестирования.
Статистика тестового цикла, содержащая: 1) результаты пропуска каждого теста из тестового набора и их сравнения с эталонными величинами; 2) факты, послужившие основанием для принятия решения о продолжении или окончании тестирования; 3) критерий покрытия и степень его удовлетворения, достигнутая в цикле тестирования.
Результатом анализа каждого цикла тестирования является список проблем, в виде ошибок и дефектов, который заносится в базу развития проекта[17]
. Далее происходит работа над ошибками, где каждая поднятая проблема идентифицируется, относится к соответствующему модулю и разработчику, приоритезируется и отслеживается, что обеспечивает гарантию ее решения (исправления или отнесения к списку известных проблем, решение которых по тем или иным причинам откладывается) в последующих build. Исправленный и собранный для тестирования build поступает на следующий цикл тестирования, и цикл повторяется, пока нужное качество программного комплекса не будет достигнуто. В этом итерационном процессе средства автоматизации тестирования обеспечивают быстрый контроль результатов исправления ошибок и проверку уровня качества, достигнутого в продукте. Некачественный продукт зрелая организация не производит.
Заключение
Итак, в данной работе были рассмотрены основные принципы и инструментарий тестирования программного обеспечения.
Технология тестирования базируется на тестовых процедурах с определенными данными на входе, начальными условиями и ожидаемым результатом. Данные процедуры разрабатываются для проверки отдельной программы или для нахождения соответствия на определенное требование. Тестовые процедуры могут проверять различные аспекты функционирования программы — от правильной работы отдельной функции до адекватного выполнения бизнес-требований.
При выполнении тестирования той или иной программы необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться эта процедура. Необходимо также обозначить какие инструменты будут использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.
В заключение стоит также сказать и том, что частота обнаружения ошибок на единицу затрат и надежность тесно пересекаются со временем тестирования и, следовательно, с гарантией качества продукта. Чем больше трудозатрат вкладывается в тестирование программного продукта, тем меньше ошибок в продукте остается незамеченными.
Стремление к уменьшению числа оставшихся ошибок или к увеличению качества продукта приводит к применению различных методов отладки и тестирования в процессе создания продукта.
Список литературы
1. Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. 204 с.
Запуск и анализ тестов программных продуктов при помощи инструмента управления тестированием Rational ClearQuest // http://www.ibm.com/developerworks/ru/edu/r-testmgtclearquest/section5.html
Описание типов тестирования// http://www.a1qa.ru/service/software_testing/description_testing_type/
Баранцев Алексей. Эссе о критериях//http://software-testing.ru/library/testing/general-testing/4-2008-09-28-17-12-35
Евгений Балыков. Владимир Царев. Тестирование программных средств// http://www.rsdn.ru/article/testing/SoftwareTesting.xml
Системное тестирование// http://www.protesting.ru/testing/levels/system.html
Как автоматизировать тестирование программного обеспечения?// http://www.interface.ru/home.asp?artId=7382
[1]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.9
[2]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.17
[3]
Там же
[4]
Запуск и анализ тестов программных продуктов при помощи инструмента управления тестированием Rational ClearQuest // http://www.ibm.com/developerworks/ru/edu/r-testmgtclearquest/section5.html
[5]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.122
[6]
Описание типов тестирования// http://www.a1qa.ru/service/software_testing/description_testing_type/
[7]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.22
[8]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.33
[9]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.121
[10]
Баранцев Алексей. Эссе о критериях//http://software-testing.ru/library/testing/general-testing/4-2008-09-28-17-12-35
[11]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.43
[12]
Евгений Балыков. Владимир Царев. Тестирование программных средств// http://www.rsdn.ru/article/testing/SoftwareTesting.xml
[13]
Там же
[14]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.51
[15]
Системное тестирование// http://www.protesting.ru/testing/levels/system.html
[16]
Основы современного тестирования программного обеспечения. Под редакцией проф. В.П. Котлярова. Стр.95
[17]
Как автоматизировать тестирование программного обеспечения?// http://www.interface.ru/home.asp?artId=7382