Методы тестирования программного обеспечения: обзор литературы

---

Аннотация

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

Ключевые слова

Методологии тестирования, жизненный цикл тестирования ПО, фреймворки тестирования, автоматизированное тестирование, разработка через тестирование, оптимизация тестирования, показатели качества

---

Введение

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

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

На рисунке 1 показана взаимосвязь между стоимостью тестирования и количеством обнаруженных ошибок. Рисунок 1 наглядно демонстрирует, что стоимость тестирования резко возрастает при обоих типах тестирования, т.е. функциональном и нефункциональном. Принятие решения о том, что тестировать или сокращать количество тестов, может привести к пропуску большого количества ошибок. Эффективная цель тестирования — проведение оптимального количества тестов, позволяющего минимизировать дополнительные затраты на тестирование [1].

Согласно рисунку 1, тестирование программного обеспечения является важным компонентом обеспечения качества ПО. Важность тестирования можно оценить на примере тестирования критически важного программного обеспечения (например, систем управления полётом), которое может быть очень дорогостоящим из-за риска задержек, перерасхода средств или полной отмены [2], и подробнее об этом [3][4].

Тестирование имеет определенные уровни и этапы, в соответствии с которыми человек, проводящий тестирование, различается от уровня к уровню. Три основных этапа тестирования программного обеспечения - это модульное тестирование, интеграционное тестирование и системное тестирование. Каждый из этих этапов тестируется либо разработчиком программного обеспечения, либо инженером по обеспечению качества, который также известен как тестировщик программного обеспечения [5]. Упомянутые выше этапы тестирования включены в жизненный цикл разработки программного обеспечения (SDLC). Важно разбить разработку программного обеспечения на набор модулей, где каждый модуль назначен отдельной команде или отдельному лицу. После завершения каждого модуля или блока разработчик тестирует его, чтобы проверить, работает ли разработанный модуль в соответствии с ожиданиями, это называется модульным тестированием. Вторым этапом тестирования в SDLC является интеграционное тестирование. После того, как модули одной программной системы были разработаны независимо, они интегрируются вместе, и часто ошибки возникают в сборке после завершения интеграции. Заключительным этапом тестирования в SDLC является системное тестирование, которое представляет собой тестирование всего программного обеспечения со всех точек зрения. Кроме того, тестирование программного обеспечения гарантирует, что интегрированные модули не мешают программированию других модулей. Однако тестирование больших или очень сложных систем может быть чрезвычайно трудоемкой и длительной процедурой, поскольку чем больше компонентов в приложении, тем сложнее тестировать каждую комбинацию и сценарий, что, следовательно, приводит к острой необходимости в улучшенном процессе тестирования программного обеспечения для оптимизации премиум-класса [6].

Цикл тестирования в основном состоит из нескольких этапов: от планирования тестирования до анализа его результатов. Планирование тестирования, будучи первым этапом, представляет собой, главным образом, план всех тестовых мероприятий, которые должны быть выполнены в течение всего процесса тестирования. Разработка тестов — это второй этап жизненного цикла тестирования, на котором разрабатываются тестовые случаи, которые будут использоваться в процессе тестирования. Выполнение тестов — это следующий этап цикла тестирования, который включает в себя выполнение тестовых случаев, а соответствующие ошибки сообщаются на следующем этапе — этапе отчётности по тестированию. Анализ результатов тестирования — это последний этап процесса тестирования, на котором анализ дефектов выполняется разработчиком, создавшим систему или программное обеспечение. Этот этап также может выполняться совместно с клиентом, поскольку он помогает лучше понять, что следует игнорировать, а что именно следует исправить, улучшить или просто изменить [7].

Существующие методы тестирования

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

Основными методами тестирования являются тестирование методом «черного ящика», тестирование методом «белого ящика» и тестирование методом «серого ящика» [8]. Тестирование методом «белого ящика» чрезвычайно эффективно, поскольку оно позволяет не только проверить функциональность программного обеспечения, но и проверить внутреннюю структуру приложения. При разработке тестовых случаев для проведения тестирования методом «белого ящика» необходимы навыки программирования. Тестирование методом «белого ящика» также называется тестированием «чистого ящика» или «стеклянного ящика». Этот вид тестирования может применяться на всех уровнях, включая модульное, интеграционное или системное тестирование. Этот вид тестирования также называется тестированием безопасности, то есть оно позволяет определить, защищают ли информационные системы данные и поддерживают ли они заданную функциональность. Поскольку этот тип процесса тестирования использует внутреннюю логическую структуру программного обеспечения, он способен протестировать все независимые пути модуля, проверяет каждое логическое решение, все циклы на каждом граничном уровне, а также внутренние структуры данных. Однако тестирование методом белого ящика служит цели быть сложным процессом тестирования из-за включения навыков программирования в этот процесс [9][10].

Тестирование методом черного ящика — это метод тестирования, который, по сути, проверяет функциональность приложения, не вдаваясь в детализацию на уровне реализации. Этот метод может применяться на любом уровне тестирования в рамках SDLC. В основном он выполняет тестирование таким образом, чтобы охватить каждую функциональность приложения, чтобы определить, соответствует ли оно первоначально заданным требованиям пользователя. Он способен обнаруживать некорректные функции, тестируя их функциональность при каждом минимальном, максимальном и базовом значении. Это самый простой и распространенный метод тестирования, используемый во всем мире [9][10].

Тестирование методом серого ящика представляет собой комбинацию методов белого и черного ящика, сочетающую преимущества обоих. Необходимость в таком виде тестирования возникла, поскольку при этом тестировщик знает внутреннюю структуру приложения, что позволяет лучше тестировать функциональность, учитывая внутреннюю структуру приложения. Рисунок 2 взят из работы автора Дж. Ирена [8] и далее дополнен в нашей исследовательской работе.

Жизненный цикл тестирования программного обеспечения

На рисунке 3 показаны этапы, стадии и фазы ЖЦТПО, которые проходит программное обеспечение в процессе тестирования. Однако не существует единого стандарта для программного обеспечения или приложения, проходящего ЖЦТПО, и он варьируется в зависимости от региона мира [11].

На первом этапе команда обеспечения качества анализирует требования к программному обеспечению, выявляя основные требования, в соответствии с которыми будет проводиться тестирование. В случае возникновения конфликта интересов команда должна координировать свои действия с командой разработки для лучшего понимания и разрешения конфликта. Планирование тестирования — второй и наиболее важный этап STLC, поскольку именно на нём определяется вся стратегия тестирования. На этом этапе разрабатывается план тестирования, который станет конечным результатом этого этапа. План тестирования — это обязательный документ, ориентированный на функциональное тестирование приложения, без которого процесс тестирования невозможен [11].

Этап проектирования теста — это этап, на котором разрабатывается тестовый сценарий, и на этом деятельность по планированию тестирования завершается. Соответствующие тестовые сценарии пишутся командой обеспечения качества вручную, а в некоторых случаях генерируются автоматизированные тестовые сценарии. Тестовый сценарий определяет набор тестовых входных данных или данных, условия выполнения и ожидаемые результаты. Указанный набор тестовых данных должен быть выбран таким образом, чтобы он обеспечивал как ожидаемый результат, так и преднамеренно ошибочные данные, которые приведут к ошибке во время тестирования. Обычно это делается для проверки условий, при которых приложение перестает выполняться [11].

Фаза выполнения теста включает в себя выполнение тестовых случаев на основе плана тестирования, составленного до фазы выполнения. Если функциональность проходит фазу выполнения без каких-либо сообщений об ошибках, тест считается пройденным или пройденным, и каждый невыполненный тестовый случай будет связан с обнаруженной ошибкой. Результатом такой деятельности является отчет о дефекте или отчет об ошибке. Отчет о тестировании — это отчет о результатах, полученных после выполнения тестовых случаев, который также включает отчеты об ошибках, которые затем передаются команде разработчиков для их исправления [11].

Жизненный цикл выпуска программного обеспечения

Этот жизненный цикл начинается после и включает в себя дальнейшее тестирование, включающее альфа- и бета-тестирование.

Альфа-тестирование, где альфа-тестирование относится к первому этапу тестирования приложения разработчиком, может проводиться по методу «белого ящика» или «серого ящика». Тестирование на интеграционном или системном уровне может проводиться по методу «черного ящика», что называется альфа-релизом. Альфа-тестирование завершается заморозкой функций, что обычно означает, что больше не будет добавляться никаких функций для расширения функциональности или для каких-либо других целей [13][14].

Фаза бета-тестирования наступает после альфа-тестирования и может рассматриваться как формальное приемочное тестирование, поскольку оно проводится пользователем после альфа-релиза. Программное обеспечение или приложение выпускается для определенной целевой группы пользователей в целях тестирования. Обычно бета-версия приложения предоставляется целевой аудитории для получения отзывов до официального релиза. Целевую аудиторию часто называют бета-тестерами, а приложение может называться прототипом программного обеспечения, главным образом для демонстрационных целей. Таким образом, финальная версия программного обеспечения выпускается после бета-тестирования [15][16].

Улучшение процессов тестирования

Приоритизация тестовых наборов улучшает процесс тестирования благодаря комбинационным критериям. Основной методологией такой приоритизации тестовых случаев является преобразование веб-блогов в тестовые наборы, соответствующие сеансу пользователя, и их последующая запись в XML-формат. Алгоритм, используемый для этого подхода, должен быть точно приоритизирован по покрытию на основе комбинаторных тестовых наборов. Более того, необходимо провести эмпирические исследования для анализа эффективности конкретного приложения и соответствующих ему тестовых наборов [17]. Инструмент, используемый для этой цели, известен как C-PUT, который, по сути, форматирует журналы веб-приложений в тестовые наборы в формате XML; затем он используется для предоставления функциональности для приоритизации этих тестов.

В настоящее время ведутся исследования о том, могут ли эти методы приоритизации тестовых наборов использоваться для повышения коэффициента обнаружения ошибок [18][19]. Использование генетических алгоритмов (ГА) для автоматизированной генерации тестовых данных для тестирования приложений является ещё одним усовершенствованием процесса тестирования. Ранее динамические средства генерации тестовых данных оставались серьёзной проблемой в процессе тестирования программного обеспечения. Поэтому использование генетических алгоритмов для тестирования является эффективным средством генерации тестовых данных, способным обрабатывать данные в соответствии со сложностью программы [20].

Автоматизация тестирования

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

Метод автоматизации тестирования эффективен по времени, поскольку экономит время ручного тестирования, которое может быть довольно трудоёмким. В SDLC автоматизация тестирования применяется как на этапе реализации, так и на этапе тестирования. Во всём мире автоматизация тестирования практикуется вместо ручного тестирования, поскольку она значительно экономит время и позволяет проводить тестирование в более короткие сроки. Автоматизация тестирования взяла на себя управление процессом ручного тестирования, сократив его необходимость и выявив количество ошибок и недостатков, которые невозможно выявить вручную.

Регрессионное тестирование, будучи одним из основных видов тестирования, требует много времени при ручном выполнении. Обычно оно проверяет, правильно ли работает программное обеспечение или приложение после исправления любых ошибок. Иногда после исправления ошибок количество ошибок в коде или приложении становится ещё выше. Поэтому, чтобы сэкономить время, затрачиваемое на регрессионное тестирование, создается набор автоматизированных тестовых наборов, которые формируют регрессионный тестовый набор. Автоматизация тестирования также помогает обнаружить проблему на гораздо более ранней стадии, экономя значительные затраты на доработку и ресурсы на более поздних этапах [21].

Среда, обслуживающая термин, обычно известна как выполнение автоматизированного тестирования, называемое Testing Framework. Тестовый фреймворк в основном отвечает за выполнение тестов, а также за определение формата выражения ожиданий и за представление результатов. Отличительной особенностью Testing Framework, которая делает его широко применимым в различных областях по всему миру, является его независимость от приложений [21]. Тестовые фреймворки бывают разных видов, включая модульные, управляемые данными, управляемые ключевыми словами и гибридные. Модульный тестовый фреймворк основан на принципе абстракции, который предполагает создание различных сценариев для различных модулей тестируемого программного обеспечения или приложения, тем самым абстрагируя каждый компонент от другого уровня. Такое модульное разделение обеспечивает масштабируемость, а также упрощает обслуживание автоматизированных тестовых наборов. Кроме того, как только функционал доступен в библиотеке, создание различных сценариев драйверов для различных типов тестов становится простым и быстрым. Главный недостаток фреймворков такого типа заключается во встраивании данных в них, поэтому, когда требуется изменение или обновление тестовых данных, необходимо изменить весь код тестового сценария. Это и стало основной причиной создания фреймворка тестирования, управляемого данными. В этом типе фреймворка тестовые данные и ожидаемые результаты в идеале хранятся в разных файлах, что позволяет выполнять все тестовые сценарии с несколькими наборами данных. Такой тип фреймворка сокращает количество тестовых сценариев, а также минимизирует объем кода, необходимого для генерации тестовых сценариев, обеспечивая большую гибкость в исправлении ошибок.

Фреймворк тестирования, управляемый ключевыми словами, использует не требующие пояснений ключевые слова, называемые директивами. Такой тип фреймворка используется для объяснения действий, которые, как ожидается, будут выполнены тестируемым программным обеспечением или приложением. Этот вид тестирования, по сути, является расширением Data Driven Testing, поскольку данные и директивы хранятся в отдельных файлах данных. Он охватывает все преимущества фреймворка, основанного на Data Driven Testing. Кроме того, возможность повторного использования ключевых слов является ещё одним важным преимуществом. Недостаток этого типа фреймворка заключается в том, что использование ключевых слов усложняет фреймворк, делая тестовые случаи длиннее и сложнее. Следовательно, необходимо объединить сильные стороны всех фреймворков, смягчив их недостатки. Гибридный подход считается оптимальным, поскольку он представляет собой комбинацию всех трёх подходов, объединяя преимущества всех фреймворков тестирования, что делает его наиболее эффективным.

Фреймворки тестирования в Agile

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

Разработка через тестирование (TDD)

Это методология, использующая автоматизированные модульные тесты для управления проектированием программного обеспечения и ускорения процесса разделения зависимостей. При обычном процессе тестирования тестировщик часто обнаруживает один или несколько дефектов или ошибок, но TDD даёт чёткое представление об успешном завершении, когда тест больше не даёт сбоев, повышая уверенность в соответствии системы основным спецификациям. Использование подхода TDD позволяет сэкономить значительное количество времени, которое могло бы быть потрачено впустую на отладку [21].

BDD (разработка через поведение) — это, по сути, расширение разработки через тестирование, фокусирующееся на поведенческих аспектах системы, а не на аспектах уровня реализации. Таким образом, BDD даёт чёткое понимание того, что именно должна делать система, повышая эффективность процесса тестирования. Таким образом, BDD — это, по сути, разработка через тестирование, объединённая с приёмочным тестированием, которое обычно подразумевает проведение тестирования для определения соответствия продукта или программного обеспечения заданным требованиям. Если это выполняется предполагаемым заказчиком или пользователем, то это называется приемочным тестированием пользователя [22].

Метрики тестирования

Метрики приоритизации

Использование тестовых метрик имеет первостепенное значение, поскольку они могут значительно повысить эффективность процесса тестирования. Они служат важным индикатором эффективности, корректности и анализа определенных метрик. Они также могут помочь в выявлении областей, требующих улучшения, а также в определении последующих действий или шагов для их устранения. Тестовые метрики — это не просто один из этапов STLC, а своего рода зонтик для постоянного совершенствования всего процесса тестирования [23][24]. Метрики тестирования программного обеспечения фокусируются на аспектах качества, относящихся к процессу и продукту, и подразделяются на метрики качества процесса и качества продукта. Обе метрики направлены на улучшение не только процесса тестирования, но и качества продукта.

Однако в существующем процессе тестирования возникает критическая проблема: соответствие подхода к тестированию разрабатываемому приложению. Не каждый подход к тестированию может быть реализован в каждом разрабатываемом приложении. Например, тестирование программного обеспечения сетевого протокола по сравнению с тестированием определенного приложения электронной коммерции будет существенно отличаться из-за совершенно разной сложности тестовых случаев, что подчеркивает критичность участия человека в процессе тестирования, а не просто опоры на существующие тестовые случаи. Метрики приоритизации включают в себя продолжительность теста, основанную на некоторых HTTP-запросах в тестовом случае. Приоритизация на основе частоты улучшает процесс тестирования, так как тестовые случаи, охватывающие наиболее часто используемые страницы, выбираются для выполнения раньше, чем тестовые случаи, использующие менее часто используемые [25][26].

Метрики качества процесса

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

Измерение эффективности процесса – ключевая метрика качества процесса, которая включает в себя такие показатели, как кривая прогресса тестирования, отражающая запланированный прогресс этапа тестирования согласно плану тестирования [27][28].

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

Кроме того, использование RTM (матрицы отслеживания требований) может привести к улучшению процесса тестирования, поскольку она сопоставляет каждый тестовый случай с конкретным требованием, что делает тестирование более точным [23][24].

Заключение и будущие работы

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

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

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

Ссылки

1. 1. P. Ron. Software testing. Vol. 2. Indianapolis: Sam’s, 2001.
2. 2. S. Amland, "Risk-based testing:" Journal of Systems and Software, vol. 53, no. 3, pp. 287–295, Sep. 2000.
3. 3. Redmill and Felix, “Theory and Practice of Risk-based Testing”, Software Testing, Verification and Reliability, Vol. 15, No. 1, March 2005.
4. 4. B. Agarwal et al., “Software engineering and testing”. Jones & Bartlett Learning, 2010.
5. 5. K. Bogdan. “Automated software test data generation”. Software Engineering, IEEE Transactions on 16.8 (1990): 870-879.
6. 6. Jacobson et al. The unified software development process. Vol. 1. Reading: Addison-Wesley, 1999.
7. 7. Everett et al., “Software testing: testing across the entire software development life cycle”. John Wiley & Sons, 2007.
8. 8. J.Irena. “Software Testing Methods and Techniques”, 2008, pp. 30-35.
9. 9. Guide to the Software Engineering Body of Knowledge, Swebok, A project of the IEEE Computer Society Professional Practices Committee, 2004.
10. 10. E. F. Miller, “Introduction to Software Testing Technology”, Software Testing & Validation Techniques, IEEE, 1981, pp. 4-16.
11. 11. M. Shaw, “Prospects for an engineering discipline of software,” IEEE Software, November 1990, pp.15-24.
12. 12. D. Nicola et al. "A grey-box approach to the functional testing of complex automatic train protection systems." Dependable Computing-EDCC 5. Springer Berlin Heidelberg, 2005. 305-317.
13. 13. J. A. Whittaker, “What is Software Testing? And Why Is It So Hard?” IEEE Software, 2000, pp. 70-79.
14. 14. N. Jenkins, “A Software Testing Primer”, 2008, pp.3-15.
15. 15. Luo, Lu, and Carnegie, "Software Testing TechniquesTechnology Maturation and Research Strategies’, Institute for Software Research International-Carnegie Mellon University, Pittsburgh, Technical Report, 2010.
16. 16. M. S. Sharmila and E. Ramadevi. "Analysis of performance testing on web application." International Journal of Advanced Research in Computer and Communication Engineering, 2014.
17. 1. S. Sampath and R. Bryce, Improving the effectiveness of Test Suite Reduction for User-Session-Based Testing of Web Applications, Elsevier Information and Software Technology Journal, 2012.
18. 18. B. Pedersen and S. Manchester, Test Suite Prioritization by Costbased Combinatorial Interaction Coverage International Journal of Systems Assurance Engineering and Management, SPRINGER, 2011.
19. 19. S. Sprenkle et al., "Applying Concept Analysis to User-sessionbased Testing of Web Applications", IEEE Transactions on Software Engineering, Vol. 33, No. 10, 2007, pp. 643 - 658.
20. 20. C. Michael, “Generating software test data by evolution, Software Engineering”, IEEE Transaction, Volume: 27, 2001.
21. 21. A. Memon, “A Uniform Representation of Hybrid Criteria for Regression Testing”, Transactions on Software Engineering (TSE), 2013.
22. 22. R. W. Miller, “Acceptance testing”, 2001, Data retrieved from (http://www.dsc.ufcg.edu.br/~jacques/cursos/map/recursos/Testing05.pdf).
23. 23. Infosys, “Metric model”, white paper, 2012. Data retrieved from (http://www.infosys.com/engineering-services/whitepapers/Documents/comprehensive-metrics-model.pdf).
24. 24. B. Boehm, “Some Future Trends and Implications for Systems and Software Engineering Processes”, 2005, pp.1-11.
25. 25. R. Bryce, “Test Suite Prioritisation and Reduction by Combinational based Criteria”, IEEE Computer Society”, 2014, pp.21-22.
26. 26. M. I. Babar, “Software Quality Enhancement for value based systems through Stakeholders Quantification”, 2005, pp.359-360. Data retrieved from (http://www.jatit.org/volumes/Vol55No3/10Vol55No3.pdf).
27. 27. R. Ramler, S. Biffl, and P. Grunbacher, "Value-based management of software testing," in Value-Based Software Engineering. Springer Science Business Media, 2006, pp. 225– 244.
28. 28. D. Graham, "Requirements and testing: Seven missing-link myths," Software, IEEE, vol. 19, 2002, pp. 15-17.