Тестирование готового продукта

Выходное тестирование

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

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

Приемочное тестирование

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

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

Существует еще две разновидности тестирования, отличающиеся друг от друга временем исполнения — альфа-тестирование и бета-тестирование.

Альфа-тестирование

Альфа-тестирование — это реальная работа с программным обеспечением потенциальными пользователями или заказчиками либо имитация реальной работы разработчиками.

Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но уже когда реализована вся или почти вся функциональность.

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

Альфа-тестирование может выполняться с использованием отладчика или какого-либо инструментария, который помогает быстро выявлять ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования.

Бета-тестирование

Бета-тестирование — это уже интенсивное использование почти готовой версии программного обеспечения с полным набором запланированных функций.

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

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

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

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

 

 

ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ПО

 

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

Возможны два подхода к тестированию производительности программного обеспечения:

1) программное обеспечение подвергается тестированию в ситуациях, соответствующих различным сценариям использования;

2) в рамках бета-тестирования, когда система испытывается реальными конечными пользователями.

В тестировании производительности различают следующие направления:

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

■ стресс-тестирование;

■ тестирование стабильности;

■ конфигурационное тестирование.

 

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

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

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

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

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

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

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

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

Существуют различные инструменты для обнаружения и исследования проблем в различных узлах системы.

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

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

2. Потребление оперативной памяти, (Мб) — метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:

■ объем виртуального адресного пространства, которое использует процесс. Этот объем подразумевает как использование соответствующего дискового пространства, так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти, принадлежащей другому процессу;

■ объем адресного пространства, занятого процессом и не разделяемого с другими процессами;

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

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

3. Потребление сетевых ресурсов — указывает на пределы производительности системы в целом.

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

5. Время выполнения запроса, (мс) — один из главных показателей производительности программного обеспечения. Это время может быть измерено на стороне сервера, как показатель времени, требуемого серверной части для обработки запроса; так и на стороне клиента, как показатель полного времени, которое требуется на пересылку и обработку запроса.

 

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

 

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

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

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

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

Основные направления применения стресс-тестирования:

■ общее исследование поведения системы при пиковых нагрузках;

■ исследование обработки ошибок и исключительных ситуаций системой при пиковых нагрузках;

■ исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках;

■ тестирование емкости системы.

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

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

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

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

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

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

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

Основная задача — наблюдая за потреблением ресурсов, проследить, чтобы скорость обработки данных и/или время отклика приложения в начале теста и с течением времени не уменьшалась. В противном случае вероятны сбои в работе продукта и перезагрузки системы.

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