Тестирование от А до Я. Часть 1 - Основополагающие принципы и подходы

Тестирование от А до Я. Часть 1 - Основополагающие принципы и подходы

1. О данном материале
 1.1 Введение в процесс тестирования
2. Основные концепции тестирования  
 2.1 Жизненный цикл тестирования
 2.2 Стадии тестирования 
 2.3 Основные метрики тестирования
 2.4 Качество. Что влияет?
 2.5 Стратегия тестирования
 2.6 Виды тестов
 2.7 Автоматизация и инструментарий
 2.8 Основные артефакты, создаваемые на этапе тестирования

1. О данном материале

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

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

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

Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!

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

Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.

В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.

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

Что такое тестирование

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

В соответствие с RUP  Тестирование — одна из дисциплин RUP . Она ориентирована в первую очередь на оценку качества с помощью следующих методов:

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

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

По ГОСТ Р  ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации , аттестации , совместного анализа и аудита . Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.

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

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

При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.

Жизненный цикл продукта и Тестирование

Все чаще в наше время используются итеративные процессы разработки ПО. Одним из примеров такого подхода является RUP . При использовании такого подхода Тестирование перестает быть процессом “на отшибе“, который запускается после того, как программисты написали весь необходимый код. Тестирование оказывается вовлеченным в гущу событий буквально с самого начала работы над проектом. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов.

В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл. Дефект заносится в базу дефектов. Аналитик определяет, не является ли он повтором внесенного ранее дефекта. Действительно ли он является дефектом? Руководитель утверждает исполнителя, который приступает к устранению дефекта в соответствие с назначенным дефекту приоритетом. Тестировщик повторяет выполнение теста и убеждается (или не убеждается) в устранении дефекта. Строгое соблюдение жизненного цикла дефекта позволяет существенно улучшить управление проектом, а также избежать “расползания“ требований под видом исправления ошибок. И избежать ненужной работы по излишней “полировке» продукта.

Наверное, можно сколь угодно долго говорить о технологии и об инструментах , поддерживающих ее. Но для того чтобы конечного потребителя окончательно склониться к правильному выбору, приведем реальные цифры и графики эффективности использования предлагаемой технологии и инструментальных средств . В России очень много компаний, которые, так или иначе используют технологии IBM Rationa l, но это, скорее использование отдельных инструментов, а не процесса. Хотя такое использование и дает эффект, но он не так велик, как было бы при полном переходе на технологию IBM Rational . Для иллюстрации эффективности технологии мы приведем реальные данные по одной из компаний, где полностью внедрили процесс тестирования по RUP  в большой проект разработки нескольких последовательных версий большой системы (из области коммуникации).

Рисунок 5 демонстрирует то, каким образом снижается число ошибок в версиях программного продукта при применении технологии IBM Rational. В данном случае речь идет о применении регрессионных тестов. Обратите внимание на точку «пика». Это точка обозначает одновременно максимальную нагрузку, максимальное число найденных ошибок и максимальную задействованность тестировщиков, так как трудоемкость на данном шаге достаточно большая, так как сценарным языком тестирования необходимо сымитировать весь спектр функциональных возможностей тестируемого ПО. Как видно из графика, во всех последующих версиях программного продукта количество найденных ошибок уменьшается. А поскольку процесс тестирования автоматизирован, то сокращаются трудозатраты тестировщиков, соответственно, возрастает объем тестов, и, как следствие программное обеспечение тестируется все более и более полно.

Количество  ошибок, найденных в версиях программного обеспечения.

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

Количество тестов во времени.

И в заключении еще несколько характеристик объема тестирования. 50 тестов выполнялись изначально для одной версии, сейчас же тестирование проводится 4 версий для 30 заказчиков. При этом затраты на тестирование каждой версии уменьшились. К сожалению, в рамках одной статьи мы не можем более полно рассказать о видах тестов, например, о нагрузочных тестах моделирования нагрузок на клиент-серверные системы (снова же из практики: одна из компаний отказалась от разработки своей перспективной коммуникационной системы после проведения всего комплекса нагрузочных тестов, так как система не была готова к реальной нагрузке. Компания оценила риски, сделала выводы, и основываясь на полученных знаниях по другому спроектировала и реализовала систему).

Давайте подведем итоги:

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

2. Основные концепции тестирования 

2.1 Жизненный цикл тестирования

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

Основные преимущества итерационного подхода можно выразить так:

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

 
Пример тестируемых компонент на различных итерациях

Итерационный подход позволяет получить наибольший эффект в регрессионном тестировании. Большинство итерации Х присутствует в итерации Х+1, а итерация Х+2 содержит в себе все компоненты всех предыдущих итерации, плюс новые. Так как одни и те же операции повторяются достаточно часто, то необходимо иметь определенный набор инструментальных средств , которые обеспечат автоматизированное тестирование уже имевшихся компонентов в предыдущих итерациях (более развернуто об инструментах будет развернуто в следующих главах).

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

Традиционный подход в тестировании

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

Итерационная модель

Данный рисунок показывает преимущество итеративного подхода в сравнении с традиционным. Здесь нашли полное отражение методология регрессионного тестирования.

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

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

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

2.2 Стадии тестирования 

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

По RUP процесс тестирование можно разбить на следующие стадии:

1. Модульное тестирование (Unit Test);

2. Комплексное тестирование (Integration Test);

3. Тестирование системы (System Test).

4. Тестирование для разработчиков (Developer Testing)
5. Приемочное тестирование (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, используя как верные значения, так и заведомо ошибочные, для подтверждения правильного функционирования, по следующим критериям:

-продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные);    

-продукт адекватно реагирует на неправильно вводимые  данные (появляются соответствующие сообщения об ошибках);

-каждое бизнес-правило реализовано надлежащим (установленным) образом.

Критерии Завершения:   

Все запланированные действия по тестированию выполнены.

Все найденные  дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов).

Тестирование целостности данных и баз данных

Цель Тестирования:                    
Убедиться в надежности методов доступа к базам данных, в их правильном исполнении, без нарушения целостности данных.

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

Оценить правильность внесения данных и убедиться в корректной обработке базой входящих значений.

Критерии Завершения:

Все способы доступа функционируют, в соответствии с требованиями.

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

Тестирование бизнес циклов 

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

Цель тестирования:            

Проверить  правильность функционирования объекта тестирования и связанных с ним процессов на соответствие  требованиям бизнес моделей и расписаний.

Методика:

Тестирование будет моделировать несколько бизнес циклов, с  выполнением следующего:

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

Критерии завершения:  

Все запланированные тесты выполнены.

Все выявленные дефекты обработаны и документированы.

Тестирование пользовательского интерфейса

  Цель Тестирования:

Проверить правильность навигации по объекту тестирования (в том числе межоконные переходы, переходы между полями, правильность обработки клавиш «enter» и «tab», работа с мышью, функционирование клавиш-акселераторов и полное соответствие  индустриальным стандартам);

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

Методика:

Создается или дорабатываются тесты для каждого из окон, на предмет соответствия навигации и состояний каждого из объектов;

Критерии завершения:

Каждое окно протестировано и удовлетворяет, базовой линии поведения, требованиям стандартов и не противоречит проектным требованиям;

Все выявленные дефекты обработаны и документированы.

Профилирование производительности

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

Цель Тестирования:

Проверить поведение производительности указанных транзакций или бизнес функций при

ожидаемой загрузке  и ожидаемая загрузка в наихудшем случае.

Методика: 

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

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

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

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

Критерии завершения:  

Одиночная Транзакция или единичный пользователь: Успешное завершение теста без каких либо сбоев  в течение ожидаемого или требуемого периода времени выполнения транзакции;

Все выявленные дефекты обработаны и документированы.

Нагрузочное тестирование

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

Цель Тестирования:            

• Проверить производительность объекта тестирования для обозначенных операций при изменяющихся внешних условиях. И ответить на следующие вопросы:
  Как много виртуальных пользователей может обслуживать сервер при нормальных условиях?
  Есть ли ситуации, в которых работа сервера при нормальных условиях ухудшается?
  Как работает ИС при выходе за границы нормальных условий? При самом неблагоприятном сценарии система постепенно ухудшает производительность или полностью выходит из строя?
  Какова производительность системы при различной аппаратно-программной конфигурации?

Методика:

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

Критерии завершения:

• Множественные транзакции от множества пользователей исполнены без  проблем (правильно, в определенном временном интервале)
• Все выявленные дефекты обработаны и документированы.

Стрессовое тестирование

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

Цель Тестирования:            

Убедиться в том, что целевые тесты выполнены без ошибок при следующих условиях проведения тестирования:

• исчерпана свободная память на сервере, или ее размер близок к критическому;
• одновременно к серверу обращается максимально возможное (заданное) число клиентов;
• одновременно множество пользователей выполняют одинаковые действия с одними и теми же записями (или разными записями).

Методика:

• Использовать тесты, созданные для нагрузочного тестирования и тестирования производительности;
• Для эффективного тестирования, машина, для которой проводится тестирование, должна намеренно иметь ограниченное число доступных ресурсов

Критерии завершения:

• Все запланированные тесты выполнены, системные пределы достигнуты и не выявлено сбоев в тестируемом приложении;
• Все выявленные дефекты обработаны и документированы.

Объемное тестирование

Цель Тестирования:            

Проверить правильность функционирования объекта тестирования при следующих сценариях:

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

Методика:

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

Критерии завершения:       

• Все запланированные тесты выполнены;
• Специфические системные ограничения достигнуты или превышены без ошибок;
• Все выявленные дефекты обработаны и документированы.

Тестирование управления доступом. Тестирование безопасности

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

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

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

Безопасность на уровне системы, гарантирует, что к системе получат доступ только те пользователи, которые имеют к ней доступ и только через соответствующие шлюзы.

Цель Тестирования:            

• (Безопасность на уровне приложения). Проверить, что пользователь  может обращаться только к тем функциям или данным, к которым он имеет доступ.
• (Безопасность на уровне системы). Проверить, что только тем пользователям, которые вошли  в систему (приложение),   разрешено  проводить различные операции.

Методика:

• Определить список пользователей  и функции (или данные) к которым каждый имеет доступ имеется доступ;
• Создать тесты для каждого пользовательского объекта тесты доступа с проверкой транзакций;
• Видоизменить пользовательские типы (ввести ограничения)и повторно пропускать их через тесты.
• Проверить корректно ли отклонены дополнительные функции или данные, которые были ограничены.

Критерии завершения:       

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

Тестирование восстановления после сбоев

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

Тест на аппаратную устойчивость должен продемонстрировать, что объект тестирования удачно справляется с такими ошибками как: ошибка ввода\вывода, отказы системы и недопустимые системные указатели баз данных.

Цель Тестирования:

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

Следующие типы состояний должны быть учтены при составлении тестов:

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

Методика:

• Использовать  функциональные тесты и тесты бизнес циклов;

Смоделировать в процессе тестирования следующие ситуации:

• выключить питание компьютера;
• сымитировать обрыв в сети;
• отключить DASD или сымитировать отключение;

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

Критерии завершения:       

• Тестируемый объект должен вернуться в исходное состояние, либо выдать соответствующие команды для ручной корректировки состояния.
• Все выявленные дефекты обработаны и документированы.

Конфигурационное тестирование

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

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

RUP имеет разветвленный механизм по планированию и одновременному запуску конфигурационных тестов на различных платформах одновременно.

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

Цель Тестирования:            

• Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Методика:

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

Критерии завершения:       

• Тестируемое приложение правильно  в любой аппартно-программной среде.
• Все выявленные дефекты обработаны и документированы.

Инсталляционное тестирование

Цель Тестирования:            

Удостовериться в том, что объект тестирования правильно инсталлируется на систему, удовлетворяющую всем программно-аппаратным требованиям из  инструкции по инсталляции. Особое внимание уделяется следующим видам установки:

• новая инсталляция, новая машина, не инсталлировалась на нее ранее;
• обновление существующей версии (переинсталляция);
• обновление со старой версии (апгрейд);
• попытка установки старой версии поверх новой.

Методика:

• Разработать скрипты для проверки всех перечисленных комбинаций.

Критерии завершения:

• Установка, обновление и деинсталляция происходят корректно;
• Исключительные ситуации обрабатываются корректно.
• Все выявленные дефекты обработаны и документированы.

Тестирование удобства использования

Существуют  следующие виды испытаний: 

• человеческий фактор. Учитывает привлечение к тестированию людей далеких от тестирования, например, менеджеров компании, чтобы они начинали тестировать приложение не с точки зрения правильности, а сточки зрения удобства. Также данный критерий учитывает работу с клиентом (заказчиком ПО): общение с пользователями, документирование работы клиентов, и так далее;
• эстетичность. Соответствие графического интерфейса текущим требованиям на интерфейс;
• логичность пользовательского интерфейса. Оценивается число пунктов меню, их вложенность, легкость нахождения. Иными словами интерфейс должен быть выстроен по принципу интуитивной понятности;
• наличие и логичность справочной системы. Программное обеспечение можно осваивать по справочной системе. Справочная система должна содержать описание всех основных и вспомогательных функций системы. Содержать механизмы поиска информации. Быть контекстно-зависимой;
• удобство шаблонов, «агентов», «мастеров». Разновидность тестирования пользовательского интерфейса;
• пользовательская документация. Ясный язык изложения и незапутанная схема документации;
• сопроводительные материалы и материалы курсов. Начальное обучение продукту как правило проводится стороной подрядчиком. Материалы курса и сам курс также должны быть продуманными. Должны концентрировать внимание слушателей на  основных моментах разработанной системы. Слушатели к концу курса должны уметь без внешней помощи проводить специфичные для себя операции, оговоренные штатным расписанием.

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

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

Разобьем инструменты на 3 категории:

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

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

• средства сбора данных. Данная категория должна включать в себя весь возможный инструментарий по сбору, обработке и конвертации данных. Данные могут быть получены как из use-case, так и из различных проектных спецификаций;
• средства статического измерения. Анализируют информацию, содержащуюся в моделях, исходных текстах приложения и внешних библиотек. Результат анализа - выдача информации относительно логических потоков, потоков данных или метрик качества, сложности или строк кода;
• средства динамического измерения. Данная категория позволяет осуществлять сбор и анализ данных по ходу исполнения тестируемого модуля\приложения. Под данную категорию попадают утилиты нахождения run-time ошибок и утечек памяти, а также различные профилировщики производительности;
• эмуляторы и драйверы. Подразумевает использование различных дополнительных утилит, без которых невозможно прямое воздействие на объект тестирования;
• средства управления тестированием. Набор программных продуктов, осуществляющих планирование тестирования, ведения отчетности. Продукты должны включать в себя также средства автоматизированного и ручного тестирования.
  

  «Черный» или «белый ящики»
Набор продуктов, предопределяющий все дальнейшее тестирование. Либо выбирается схема «черного ящика», и тогда возможно только тестирование в соответствии с требованиями без обращения к коду, либо «белого ящика», когда анализируется сам код приложения.
Вполне возможно, что придется искать компромиссные варианты одновременного использования обоих подходов. Инструментальная поддержка RUP позволит осуществить подобное комбинирование подходов.

Инструменты специализации:

• запись и воспроизведение. Набор инструментов, позволяющих записывать и воспроизводить скрипты тестирования;
• метрики качества. Утилиты, позволяющие оценить качественность модели тестирования или качество программного кода (например, на строгость соответствие стандартам разработки);
• мониторинг области охвата кода. Данная группа инструментов должна идентифицировать % отношение исполненных и неисполненных строк кода, а также графически показывать дерево исполнений модулей тестируемого приложения;
• генераторы тест данных. Группа утилит, способных генерировать наборы случайных последовательностей для тестирования графических компонент на предмет адекватного поведения на ввод произвольных данных;
• утилиты сравнения. Под данную категорию попадают и простые текстовые утилиты сравнения (входящие в состав средств версионного управления), так и средства бинарного сравнения, и сравнения графических имиджей.

2.8 Основные артефакты, создаваемые на этапе тестирования

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

• План тестирования. Основной документ данного этапа. Содержит полную информацию о целях и задачах тестирования. Содержит перечисление всех возможных проектных тестов. Включает различные таблицы, помогающие в планировании тестирования;
• Модель тестирования. Графическая схема последовательности действий и описание ролей участников тестирования;
• Нагрузочная модель. Определяет все переменные и значения, используемые в различных тестах для моделирования внешних характеристик (функции, выполняемые пользователем). Описывает объем данных функций и создаваемой ими нагрузки;
• Дефекты. Основополагающие артефакты - результат обнаружения ошибок. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования.

27.01.2008

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"