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

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

1.1 Введение в процесс тестирования
Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


4. Тестирование для разработчиков (Developer Testing)


5. Приемочное тестирование (Acceptance Test)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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