1. О данном материале
Как показывает наша практика построения жизненного цикла разработки ПО и внедрения технологий тестирования, в России (последние 1-1,5 года) идет лавинообразный всплеск интереса у разрабатывающих ПО организаций к правильному построению процессов жизненного цикла разработки ПО, и особенно к процессу тестирования.
Руководители и разработчики начинают понимать важность процесса тестирования, для повышения качества программных систем. Становится очевидным, что чем позже начать тестировать программную систему, тем выше риски, тем менее надежной она может получиться. Нам приятно осознавать, что тестирование из прикладного процесса с невысоким приоритетом переходит в разряд особо важных процессов, чей жизненный цикл начинается параллельно с разработкой программных систем.
1.1 Введение
в процесс тестирования
Введение
Очень часто при разработке программного обеспечения приходится сталкиваться с одной из двух проблем. Либо качество разработанного продукта много ниже самых минимальных разумных требований, либо затраты на тестирование превосходят все разумные пределы. К сожалению, бывает и так, что обе проблемы существуют одновременно. И денег на тестирование истрачено много, а качества достичь так и не удалось.
Увы, для большинства фирм низкое качество выпускаемого ПО — верный путь если не к полному исчезновению фирмы, то, по крайней мере, к потере клиентов и существенным финансовым потерям.
Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!
Одной из причин такой ситуации является объективная сложность процесса тестирования ПО. Ведь под словом Тестирование может скрываться множество самых различных действий, направленных на решение множества разнообразных задач. Тут и запуск и исполнение программы с целью проверки отсутствия ошибок, и оценка производительности, и контроль наличия и полноты документации и даже качества принятых проектных решений.
Как же наладить процесс тестирования? Какими инструментами лучше воспользоваться? Какой подход выбрать?
Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.
В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.
Первая статья представляет собой краткий обзор содержания серии и знакомит читателей с кругом вопросов, которые будут обсуждаться в последующих статьях.
Что такое тестирование
Прежде, чем разбираться с деталями, необходимо определить, что же такое тестирование. Даже этот, казалось бы простой вопрос не так прост. Разные источники определяют тестирование его по-разному.
В соответствие с RUP Тестирование — одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов:
поиск и документирование дефектов качества; общие рекомендации относительно качества; проверка выполнения основных предположений и требований на конкретных примерах; проверка, что продукт функционирует так, как было запроектировано; проверка, что требования выполнены соответствующим образом.
По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.
В сумме эти процессы и составляют то, что обычно называют тестированием.
Как не запутаться в этих определениях, на какое из лих лучше опираться в ежедневной деятельности — этому будет посвящен следующий выпуск. (следите за обновлениями)
Tестируемость
Далее предполагается рассмотреть понятие Тестируемости. Почему одни продукты можно протестировать существенно быстрее, полнее и надежнее, чем другие? Какие проектные решения упрощают, а какие усложняют качественное тестирование? Как связаны Тестирование и Управление рисками?
При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.
Жизненный цикл продукта и Тестирование
Все чаще в наше время используются итеративные процессы разработки ПО. Одним из примеров такого подхода является RUP. При использовании такого подхода Тестирование перестает быть процессом “на отшибе“, который запускается после того, как программисты написали весь необходимый код. Тестирование оказывается вовлеченным в гущу событий буквально с самого начала работы над проектом. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов.
В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл. Дефект заносится в базу дефектов. Аналитик определяет, не является ли он повтором внесенного ранее дефекта. Действительно ли он является дефектом? Руководитель утверждает исполнителя, который приступает к устранению дефекта в соответствие с назначенным дефекту приоритетом. Тестировщик повторяет выполнение теста и убеждается (или не убеждается) в устранении дефекта. Строгое соблюдение жизненного цикла дефекта позволяет существенно улучшить управление проектом, а также избежать “расползания“ требований под видом исправления ошибок. И избежать ненужной работы по излишней “полировке» продукта.
Выгоды от использования автоматизации процесса тестирования в цифрах и фактах.
Наверное, можно сколь угодно долго говорить о технологии и об инструментах, поддерживающих ее. Но для того чтобы конечного потребителя окончательно склониться к правильному выбору, приведем реальные цифры и графики эффективности использования предлагаемой технологии и инструментальных средств. В России очень много компаний, которые, так или иначе используют технологии IBM Rationa l, но это, скорее использование отдельных инструментов, а не процесса. Хотя такое использование и дает эффект, но он не так велик, как было бы при полном переходе на технологию IBM Rational. Для иллюстрации эффективности технологии мы приведем реальные данные по одной из компаний, где полностью внедрили процесс тестирования по RUP в большой проект разработки нескольких последовательных версий большой системы (из области коммуникации).
Рисунок 5 демонстрирует то, каким образом снижается число ошибок в версиях программного продукта при применении технологии IBM Rational. В данном случае речь идет о применении регрессионных тестов. Обратите внимание на точку «пика». Это точка обозначает одновременно максимальную нагрузку, максимальное число найденных ошибок и максимальную задействованность тестировщиков, так как трудоемкость на данном шаге достаточно большая, так как сценарным языком тестирования необходимо сымитировать весь спектр функциональных возможностей тестируемого ПО. Как видно из графика, во всех последующих версиях программного продукта количество найденных ошибок уменьшается. А поскольку процесс тестирования автоматизирован, то сокращаются трудозатраты тестировщиков, соответственно, возрастает объем тестов, и, как следствие программное обеспечение тестируется все более и более полно.
Количество ошибок, найденных в версиях программного обеспечения.
Следующий рисунок демонстрирует рост числа тестов в ходе разработки. Отправной точкой были 50 ручных тестов, по которым тестировалось программное обеспечение. Ручной труд, как известно, не очень производителен. Автоматизация тестирования позволила кардинально увеличить число тестов (теперь тестировать не только самые главные функции) и довести его число до 450. Разумеется, ручное выполнение такого количества тестов потребовало бы огромных ресурсов. При автоматизации тестирования удалось обойтись прежним количеством тестировщиков.
Количество тестов во времени.
И в заключении еще несколько характеристик объема тестирования. 50 тестов выполнялись изначально для одной версии, сейчас же тестирование проводится 4 версий для 30 заказчиков. При этом затраты на тестирование каждой версии уменьшились. К сожалению, в рамках одной статьи мы не можем более полно рассказать о видах тестов, например, о нагрузочных тестах моделирования нагрузок на клиент-серверные системы (снова же из практики: одна из компаний отказалась от разработки своей перспективной коммуникационной системы после проведения всего комплекса нагрузочных тестов, так как система не была готова к реальной нагрузке. Компания оценила риски, сделала выводы, и основываясь на полученных знаниях по другому спроектировала и реализовала систему).
Давайте подведем итоги:
Снижение основных рисков заказчика, и разработчика; Экономию ресурсов за счет автоматизации регрессионного тестирования; Улучшение качества ПО за счет многократных проверок изменений; Улучшение качества тестирования за счет использования современных технологий.
2. Основные концепции тестирования
2.1 Жизненный цикл тестирования
Следует понимать, что тестирование не есть обособленный вид деятельности или поток работ, оторванный от остальных. Если говорить про обычные проекты, то это не соответствует действительности. Процесс тестирования идет непосредственно после кодирования и происходит достаточно обособленно. В таком подходе кроется существенный недостаток: получается так, что команда разработчиков сама по себе, а тестировщики сами по себе - две разрозненные группы, порой плохо согласованные друг с другом. Отсюда проблемы межгруппового взаимодействия, что отрицательно влияет на сроки и качество тестирования. Также подобная рассогласованность ведет к удорожанию тестирования, о котором говорилось выше.
RUP оговаривает процесс тестирования, как процесс неотрывный от этапа определения требований и этапа разработки программного продукта. То есть тестирование производится на протяжении всего жизненного цикла разработки программного продукта. Организуется такой процесс при котором любое видоизменение (перекомпиляция) программного продукта приводит к его тестированию. И получается, что различные скрипты функционального тестирования начинают появляться сразу после того, как разработчик создал определенную графическую форму.
Последующее добавление различных компонент приводит к появлению новых скриптов тестирования, и так до тех пор, пока не выйдет стабильная версия программного продукта, удовлетворяющая заданному качеству.
Отдельного разговора заслуживает процедура связи тестировщиков и разработчиков. Тестировщик, обнаружив ошибку, документирует, а разработчик ее исправляет, перекомпилирует программный продукт (или его модуль), а затем передает тестеру. Тестер повторно запускает наработанные тесты для данного программного продукта. В зависимости от результатов (ошибка действительно была исправлена или все-таки нет) ошибка позиционируется либо как исправленная, и в этом случае к ней больше не возвращаются, либо признается неисправленной, и тогда разработчик проводит еще одну итерацию для ее исправления. И так до тех пор, пока программный продукт или модуль не будут удовлетворять нужному качеству. Зачастую, такой вид тестирования называют регрессионным.
Основные преимущества итерационного подхода можно выразить так:
проводить тестирование с ранних прототипов программного продукта; получить точную информацию о ходе прогресса (или регресса) в работе над программным продуктом (с целью своевременной корректировки неудачных решений); происходит постепенное создание библиотеки тестовых скриптов ; при тестировании массивных приложений облегчается жизнь тестеров (за счет автоматической проверки каждого релиза программного продукта) проводить регрессионное тестирование.
Программный продукт совершенствуется через итерации. В каждой итерации коллектив разработчиков выполняет сборку программы. Каждая сборка является потенциальным кандидатом для тестирования. Для каждой сборки могут разрабатываться или уточняться тесты. Поскольку процесс разработки является итерационным некоторые тесты, используемые при тестировании ранних сборок, могут быть использованы и при тестировании последующих сборок. Такой процесс тестирования называется регрессионным тестированием. Каждая новая итерации подразумевает повторное тестирование всех компонентов, разработанных на предыдущей итерации, плюс разработка тестов для тестирования новых компонент и их тестирование.
Пример тестируемых компонент на различных итерациях
Итерационный подход позволяет получить наибольший эффект в регрессионном тестировании. Большинство итерации Х присутствует в итерации Х+1, а итерация Х+2 содержит в себе все компоненты всех предыдущих итерации, плюс новые. Так как одни и те же операции повторяются достаточно часто, то необходимо иметь определенный набор инструментальных средств, которые обеспечат автоматизированное тестирование уже имевшихся компонентов в предыдущих итерациях (более развернуто об инструментах будет развернуто в следующих главах).
Обратите внимание на жизненный цикл тестирования вне остальной части проекта. Это тот путь, которым различные действия по тестированию связаны и обобщены, если смотреть на них в не итеративном представлении.
Традиционный подход в тестировании
Обратите внимание на то, что подобный и часто практикуемый подход не поддерживает обратных связей и течет линейно. Соответственно, полноценно реализовать качественное тестирование – невозможно.
Итерационная модель
Данный рисунок показывает преимущество итеративного подхода в сравнении с традиционным. Здесь нашли полное отражение методология регрессионного тестирования.
Жизненный цикл тестирования – часть жизненного цикла разработки программного обеспечения. Они должны запускаться одновременно. Дизайн и разработка механизмов тестирования, определения тактики и стратегии тестирования, такие же трудоемкие задачи, как и задачи разработки программного кода. Из этого следует, что любое упущение в тестировании, будь то: поздний старт, недостаточная проработка тестов, пагубно сказывается как на эффективности самого тестирования, так и на качестве итогового программного продукта.
Пути, которые вы изберете для реального проекта будет зависеть от нескольких факторов, таких как: прикладная область реализации, бюджет, политика компании и сложившиеся традиции, число сотрудников в штате.
То, сколько денег вы готовы вложить в тестирование зависит от того, насколько вы серьезно относитесь к качеству и насколько вам хочется нивелировать риски.
2.2 Стадии тестирования
Обычно тестирование используется для различных целей на разных стадиях жизненного цикла программного обеспечения.
По RUP процесс тестирование можно разбить на следующие стадии:
Модульное тестирование (Unit Test);
Комплексное тестирование (Integration Test);
Тестирование системы (System Test).
Тестирование для разработчиков (Developer Testing)
Приемочное тестирование (Acceptance Test)
Комплексное тестирование проводится для того, чтобы гарантировать, что компоненты в модели этапа реализации работают должным образом совместно, реализуя соответствующую функцию системы. При этом тестируется подсистема или набор подсистем модели этапа реализации. Комплексное тестирование позволяет выявить неполноту или ошибки в спецификациях интерфейсов подсистем.
Тестирование системы проводится, когда программное обеспечение уже функционирует в целом, или когда отдельные функциональные подсистемы полностью реализованы. Тестированию системы обычно подвергается полная модель стадии реализации.
Приемосдаточные испытания выполняются перед развертыванием программного продукта в среде конечных пользователей. Цель этих испытаний показать, что программный продукт готов и может быть использован пользователями при выполнении ими свих функциональных обязанностей.
Тестирование для разработчиков (Developer Testing). Определяет объем работ по тестированию на этапе разработки программистом программного кода. Для осуществления данного вида тестирования определен специальный набор программных инструментов, которые используют как разработчики, так и независимые тестировщики. Предметная область и набор инструментов совместного тестирования (тестировщики+разработчики) способствует улучшению качества конечного продукта. Данный вид тестирования может содержать дополнительный требования на качество разрабатываемого кода - на соответствие его определенным стандартам разработки (подробнее смотрите в главе инструментальной поддержки).
Приемочное тестирование - конечный этап тестирования. Пользовательского тестирования. Определяет последние шаги по тестированию перед сдачей продукта заказчику (перед внедрением). Цель тестирования заключается в финальной проверке приложения на соответствие ранее установленным требованиям по интерфейсу, стабильности, и т. д
2.3 Основные метрики тестирования Основными характеристиками тестирования являются характеристики тестового покрытия и качества.
Тестовое покрытие является мерой полноты тестирования и основывается на покрытии требований к системе или покрытии исполняемого кода.
Качество системы или приложения определяется его надежностью и производительностью.
Для оценки характеристик тестового покрытия, надежности и производительности используют различные метрики.
Для оценки тестового покрытия требований к системе используются следующие метрики :
тестовое покрытие; планируемое тестовое покрытие; разработанное тестовое покрытие; исполняемое тестовое покрытие;
Метрики покрытий могут вычисляться как по отношению к контрольным задачам, так и тестовым процедурам. Например, метрика тестовое покрытие определяется как отношение общего числа запланированных, разработанных, исполняемых, успешных контрольных задач или тестовых процедур к общему числу требований.
Для оценки тестового покрытия исполняемого кода используются метрика, вычисляемая как отношение числа строк исполняемого кода при тестировании к общему числу строк кода.
Оценки надежности и производительности определяются на основе анализа результатов тестирования и запросов на изменения, возникших во время тестирования.
Для оценки надежности, например, могут использоваться следующие метрики :
время наработки на отказ; время восстановления (как долго автоматизированная система может не работать после появления неисправности); точность в соответствие с известными стандартами, если это требуется для результатов программного продукта на выходе; максимальное число программных ошибок или коэффициент ошибок (число программных ошибок на тысячу строк кода или на функцию).
Для оценки производительности, например, могут использоваться следующие метрики :
время отклика - получения результатов на типовое задание; пропускная способность - число типовых заданий, исполняемых в единицу времени.
2.4 Качество. Что влияет?
Термин, под которым подразумевается многое, если не все, что связано с понятием отсутствие дефектов в приложении. Основной целью тестирования является оценка качества будущего программного продукта. Это общая оценка, подобная средней температуре пациентов в больнице. То есть этот критерий отражает общее соотношение ценакачество для конечного пользователя. Но программный продукт вещь достаточно большая и выводить общую оценку качества нужно по многим критериям.
Давайте, определим те артефакты, которые влияют на качество:
Развернутый, исполняемый код (приложение, система, библиотека… и т. д.), как более ощутимая часть артефактов. Развернутый неисполняемый артефакт (пользовательские инструкции, описание системы, материалы курсов) Не развернутые исполняемые артефакты (скрипты тестирования, а также средства разработки для поддержания реализации) Не развернутые, не исполняемые артефакты (различного вида планы: разработки, тестирования)
Развернутый, исполняемый код
Данный критерий относится к самому коду программы, тому, из которого вырастает приложение, тестируемое в дальнейшем по функциональному сценарию. Но перед тем как модуль (приложение или его часть) будут подвергаться функциональному тестированию, разработчики должны проверить код своих модулей таким образом, чтобы он удовлетворял следующим критериям:
Надежность. Полученный в разработке код устойчив к падениям при каждом запуске программного продукта (то есть ПО не содержит ошибок связанных с неправильным разделениям памяти, не содержит run-time ошибок, и т. д); Функциональность. Код удовлетворяет предыдущему критерию, а также тем требованиям, которые были выявлены на вышестоящих этапах (моделирование, анализ и дизайн, определение требований); Производительность. Код удовлетворяет двум вышеприведенным требованиям и показывает наивысшую производительность при исполнении.
Совокупность трех критериев дает качественный продукт уже на этапе его разработки. То есть разработчики отдают тестерам программный модуль с нужной (определенной) функциональностью и свободным от всех логических ошибок в коде. То есть код практически без ошибок и находится в состоянии божественной нирваны.
Развернутый неисполняемый артефакт
Качество неисполняемого артефакта важно не меньше. Участники проекта должны находиться в едином информационно-терминологическом пространстве, знать проектные цели и задачи:
Слажено изъясняться (терминологически, семантически); Согласовываться с принятыми рекомендациями и стандартами, а также требованиями (терминология, содержание, формат).
Качества для данных критериев можно добиться используя одинаковый набор программных средств для каждого участника проекта (то есть данные по проекту передавать не устно, а через набор специальных программных продуктов), а так же широкого применения универсальных шаблонов различного вида словарей для избежания рассогласования в терминах. Качество всех компонентов, составляющих приведенные группы, должно быть измерено и оценено. И что немаловажно, при оценке качества нужно оперировать не только материальными критериями (артефактами), но и такими как моментами организации и качеством самих процессов, протекающих в компании.
Не развернутые исполняемые артефакты
Качественные, вовремя созданные скрипты тестирования позволят наиболее тщательным образом проводить итеративное регрессионное тестирование компонентов приложения (элементов графического интерфейса).
Не развернутые, не исполняемые артефакты
Основной документ этапа тестирования «тест–план» - регламент всех плановых работ, связанных с тестированием. Точно определение целей тестирование и их ясное изложение в плане позволит наиболее оптимально использовать ресурсы компании, как аппаратные, так и человеческие.
Серьезное отношение должно быть ко всем регламентирующим документам. КО всем планам.
Кто в ответе за качество?
Как не прискорбно отмечать, но за конечное качество продукта ответственны все участники проекта. И здесь ничего не поделать. Если продукт получился некачественным, то в этом виновны все. Ведь если качества изначально не было заложено в продукт, то потом оно туда никоим образом не выстроится, а стало быть, неряшливые моменты, и моменты попустительства будут только наслаиваться один на другой, порождая своеобразный «снежный ком».
Задача тестирования состоит не в том, чтобы гарантировать качество, а в том, чтобы его оценить, обеспечив при этом обратную связь со всеми участниками проекта. А стало быть, главная задача тестера состоит в оценке качества тестируемого программного продукта и организации обратной связи с коллективом разработчиков (для исправления найденных дефектов). Основная же роль «остальных» участников состоит в предоставлении артефактов, удовлетворяющих требованиям и критериям качества.
Оценку качества программного продукта следует производить для следующих типов требований:
1.Функциональных (Functionality);
2.Удобства использования (Usability);
3.Надежности (Reliability);
4.Производительности (Performance);
5.Требований к сопровождению системы (Supportability).
6.Проектных ограничений (Design Requirement);
7.Требований к реализации (Implementation Requirement);
8.Требований к интерфейсу (Interface Requirement);
9.Требований к физическим характеристикам системы (Physical Re Requirement).
2.5 Стратегия тестирования
Основополагающее понятие, как в тестировании, так и во всех жизненных областях. На этапе стратегии предопределяются вся дальнейшая политика, все дальнейшие действия, связанные с тестированием. Определяются стадии тестирования и типы тестов. Оформляется и разрабатывается тест план, определяется состав участников и их роли.
Стратегия определяет:
какие инструментальные средства и методы будут применяться;
критерии завершения итераций;
единицы измерения качества конечного программного продукта;
процентную установку области охвата кода (то есть, что считать полностью протестированным приложением? 100% кода, или 95%);
специальные соображения, затрагивающие ресурсы;
типы отчетов и способы автоматизированного их хранения;
виды применяемых тестов: «черный ящик» или «стеклянный ящик», либо их комбинации на различных стадиях.
2.6 Виды тестов
Рассмотрим основные виды тестов:
функциональное тестирование; тестирование целостности баз данных; тестирование бизнес циклов; тестирование пользовательского интерфейса; профилирование производительности; нагрузочное тестирование; стрессовое тестирование; объемное тестирование; тестирование управления доступом. Тестирование безопасности тестирование восстановления после сбоев; конфигурационное тестирование; инсталляционное тестирование.
Описанные виды тестов позволят осуществить всестороннее тестирование программного продукта. RUP регламентирует все виды работ, а также методику подготовки тестовых наборов. В том числе регламентируются такие параметры как: цель тестирования, методика тестирования, критерии тестирования, а также определяются особые условия, необходимые для проведения всестороннего тестирования. Рассмотрим подробно основные виды тестов, дополнительные условия тестирования, требования к тестам и критерии завершения.
Функциональное тестирование
Функциональное тестирование объекта-тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают диаграммы use-case, бизнес-функции и бизнес-правила. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям.
В основе функционального тестирования лежит методика "черного ящика". Идея тестирования сводится к тому, что группа тестировщиков проводит тестирование, не имея доступа к исходным текстам тестируемого приложения. При этом во внимание принимается только входящие требования и соответствие им тестируемым приложением.
При необходимости (в соответствии с выбранной ранее стратегией тестирования) можно воспользоваться на этапе функционального тестирования подходом, называемым «стеклянным ящиком». В режиме «стеклянного ящика» тестировщик должен владеть языком реализации и тестировать код приложения в соответствии с принятыми стандартами на разработку, например такими, как проверка кода на отсутствие операторов перехода (goto). Также на тестировщика возлагается ответственность по установке соответствия текущей разработки на соответствие определенным канонам программирования.
На этапе функционального тестирования не применяется тестирование «стеклянного ящика» в чистом виде – используется комбинация двух видов тестирования. Подход «стеклянного ящика» для функционального тестирования несет ряд ограничений, и способен проводить тестирование по следующим категориям:
Тест на производительность; Тест на наличие ошибок с памятью; Тест на покрытие кода.
Комбинированное тестирование позволит получить тестировщику на выходе наиболее полный отчет о соответствии тестируемого приложения всем установленным требованиям на графический интерфейс, производительность кода и его устойчивость.
Цель тестирования:
Убедиться в надлежащем функционировании объекта тестирования. Тестируется правильность навигации по объекту, а также ввод, обработку и вывод данных.
Методика:
Необходимо исполнить (проиграть) каждый из use-case, используя как верные значения, так и заведомо ошибочные, для подтверждения правильного функционирования, по следующим критериям:
-продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные);
-продукт адекватно реагирует на неправильно вводимые данные (появляются соответствующие сообщения об ошибках);
-каждое бизнес-правило реализовано надлежащим (установленным) образом.
Критерии Завершения:
Все запланированные действия по тестированию выполнены.
Все найденные дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов)
Тестирование целостности данных и баз данных
Цель Тестирования:
Убедиться в надежности методов доступа к базам данных, в их правильном исполнении, без нарушения целостности данных.
Методика:
Необходимо последовательно испробовать максимально возможное число способов обращения к базе. Используется подход, при котором тест составляется таким образом, чтобы «нагрузить» базу последовательностью, как верных значений, так и заведомо ошибочных.
Оценить правильность внесения данных и убедиться в корректной обработке базой входящих значений.
Критерии Завершения:
Все способы доступа функционируют, в соответствии с требованиями.
Действия скрипта не приводят к потере данных или нарушению целостности базы, либо к другим неадекватным реакциям.
Тестирование бизнес циклов
Тестирование Бизнес Циклов должно эмулировать действия, выполняемые в проекте в течение определенного временного интервала. Период должен быть определен длительностью в один год. Все с
|
