Анализ результатов тестирования программы это

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

Этапы STLC-цикла

Цикл состоит из шести основных этапов:

1. Анализ требований
2. Планирование тестирования
3. Создание тест-кейсов
4. Настройка тестового окружения
5. Выполнение тестирования
6. Завершение цикла тестирования

Каждый из этих этапов имеет четкие критерии начала и завершения.

Какие критерии начала и завершения STLC-цикла?

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

Есть критерии начала и завершения для всех этапов STLC.

Тест-план и тест-стратегия / Отчет по тестированию

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

Анализ (оценка) требований

Этап оценки требований (анализа требований). На этом этапе QA-команда оценивает требования с точки зрения тестирования. Для этого QA-команда может обращаться к представителям заказчика. Требования могут быть «функциональными» или «нефункциональными», то есть касаться или не касаться функциональной составляющей софта. Также на этом этапе проводится оценка возможности применения автоматизированного тестирования.

Действия на этапе оценки требований

• Определение типов тестирования
• Сбор информации о приоритетах в тестировании
• Подготовка матрицы отслеживания требований (RTM — Requirement Traceability Matrix)
• Определение тестового окружения
• Анализ возможности автоматизации тестирования (если нужно)

Результаты этапа оценки требований

• Матрица отслеживания требований (RTM)
• Отчет о возможности автоматизации (если нужно)

Планирование тестирования

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

Действия на этапе планирования

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

Результаты

• Документ со стратегией тестирования
• Документ с оценкой ресурсов

Этап создания тест-кейсов

На этом этапе происходит подготовка тестовых данных и создаются тест-кейсы.

Performance testing, Анализ результатов тестирования. QA

Действия

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

Результаты

• Тест-кейсы и/или скрипты
• Тестовые данные

Настройка тестового окружения

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

Действия

• Понять нужную архитектуру, настройки окружения и подготовить список требований к харду и софту
• Настроить тестовое окружение и тестовые данные
• Провести smoke-тест окружения

Результаты

• Настроенное окружение для проведения тестирования
• Результаты smoke-тестирования окружения

Этап выполнения тестов

На этапе выполнения тестов QA проводит тестирование, выполняя подготовленные тест-кейсы. Процесс состоит из выполнения тестовых скриптов (при необходимости эти скрипты могут корректироваться). Далее идет создание баг-репортов. Если найдены баги, информация о них передается команде разработки для исправления и повторного тестирования QA-командой.

Действия

• Выполнение тестирования в соответствии с планом
• Получение результаты тестирования
• Обновление RTM-матрицы (тест-кейсы из RTM-матрицы связываются с найденными багами)
• Повторное тестирование исправленных багов

Результаты

• Завершенная RTM-матрица
• Обновленные тест-кейсы
• Найденные и описанные баги

Завершение тестирования

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

Действия

• Оценка критериев завершения цикла (основывается на времени, трудозатратах, покрытии тестами)
• Подготовка документа с выводами, сделанными во время тестирования
• Подготовка отчета о завершении тестирования
• Подготовка отчета для клиента с количественными и качественными характеристиками тестируемой системы
• Анализ результатов тестирования

Результаты

• Отчет о завершении тестирования

Этапы STLC-цикла и критерии их начала и завершения (входа и выхода)

Этап	Критерии входа	Действия	Критерии выхода	Результаты
Анализ требований	— Есть документ о требованиях (как функциональных, так и нефункциональных). — Описаны критерии приемлемости. — Есть документ, описывающий архитектуру приложения.	— Анализ планируемой функциональности приложения. — Определение ролей пользователей. — Сбор требований о пользовательских интерфейсах, аутентификации, локализации и других особенностях. — Определение типов тестирования, которые будут проводиться. — Сбор информации о приоритетах тестирования. — Создание RTM-матрицы (матрицы отслеживания требований). — Определение тестового окружения, в котором будет проводиться тестирование. — Анализ возможности автоматизации (если нужно).	— Заполнена RTM-матрица. — Подготовлен и согласован отчет о возможности автоматизации.	— RTM-матрица. — Отчет о возможности автоматизации (если нужно).
Планирование	— Есть документы с требованиями. — Есть RTM-матрица. — Есть документ о возможности автоматизации тестирования.	— Анализ возможности различных методов тестирования. — Финализация наиболее подходящего метода тестирования. — Подготовка документа со стратегией/планом тестирования — Подбор инструментов тестирования. — Оценка трудозатрат. — Планирование ресурсов и определение ролей и ответственности.	— Готов и согласован документа со стратегией тестирования. — Одобрен документ по оценке трудозатрат.	— Документ со стратегией тестирования. — Документ с оценкой трудозатрат.
Создание тест-кейсов	— Есть документы с требованиями. — Есть RTM-матрица и план тестирования. — Есть отчет о возможности автоматизации.	— Создание тест-кейсов, автоматизированных тестов (если нужно). — Обновление тест-кейсов и автоматизированных тестов. — Создание тестовых данных.	— Готовы тест-кейсы и скрипты. — Готовы тестовые данные.	— Тест-кейсы и скрипты. — Тестовые данные.
Настройка тестового окружения	— Готовы документы по дизайну системы и ее архитектуре. — Есть план по настройке окружения.	— Оценка архитектуры. — Настройка окружения. — Создание списка требований к аппаратной и программной части окружения. — Финализация требований к качеству. — Подготовка задач по настройке окружения. — Настройка тестового окружения. — Подготовка и проведение smoke-тестов билда приложения.	— Окружение работает согласно списка требований. — Завершена подготовка тестовых данных.	— Готовое окружение.
Выполнение тестирования	— Есть базовая RTM-матрица, план тестирования, тест-кейсы и/или автоматизированные скрипты. — Готово тестовое окружение. — Завершена настройка тестовых данных.	— Выполнение тестов. — Документирование результатов тестирования. — Создание баг-репортов. — Обновление тест-плана и тест-кейсов (если нужно). — Обновление RTM-матрицы. — Повторное тестирование проблемных мест. — Регрессионное тестирование приложения. — Отслеживание проблемных мест, до закрытия тестирования.	— Все запланированные тесты проведены. — Созданы баг-репорты.	— Полностью заполненная RTM-матрица. — Обновленные по результатам тестирования тест-кейсы. — Баг-репорты.
Завершение тестирования	— Тестирование завершено. — Есть результаты тестирования. — Есть баг-репорты.	— Оценка цикла на основе времени, покрытии тестами, трудозатрат. — Подготовка метрик тестов. — Подготовка документа с итогами проекта. — Подготовка отчета о завершении тестирования. — Подготовка отчета о качестве продукта. — Анализ результатов тестирования.	— Отчет о завершении тестирования утвержден клиентом.	— Отчет о завершении тестирования. — Метрики тестов.

Источник: testengineer.ru

2.4 Анализ результатов тестирования программы

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

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

Заключение

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

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

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

1. Сжатие изображений и информации

2. Сокрытие информации на изображении, в звуке

3. Шифрование данных с помощью фрактальных алгоритмов

4. Создание фрактальной музыки

5. Моделирование систем[7].

Данное приложение можно использовать для ознакомления с графическими средствами среды программирования Borland Delphi, а также для приобретения представлений о практическом применении фрактальных множеств.

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

Таким образом, поставленные цели были достигнуты, задачи работы были выполнены.

Список использованых источников

Бобровский С.И. Delphi 7. Учебный курс / С.И. Бобровский. – Санкт-Петербург: Питер, 2004. – 736 с.

Бугров Я.С. Высшая математика / Я.С. Бугров, С.М. Никольский. – Москва: Дрофа, 2004. – 288 с.

Культин Н. Б. Основы программирования в Delphi 8 для Microsoft.NET

Framework. Самоучитель.– Санкт-Петербург, 2004. – 400с.

Кроновер Р.М. Фракталы и хаос в динамических системах. Основы теории./ Р.М Кроновер. – Москва: Постмаркет, 2000. – 352 с.

Приложение А

Листинг программы

unit Unit1;

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls, XPMan;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

implementation

uses unit2;

procedure gf;

iterations = 500000; //Кол-во итераций

p:real; //Случайная величина

mid_x, mid_y, radius: integer;

mid_x := form1.width div 2;

mid_y:=form1.height-200 ;//Масштабирование и координирование изображения

radius := trunc(0.1 * mid_y);

for k := 1 to iterations do

x := 0.84 * x -0.045 * y;

y := 0.045 * t + 0.86 * y + 1.6;

x := 0.25 * x — 0.26 * y;

y := 0.23 * t + 0.25 * y + 1.6;

x := -0.135 * x + 0.28 * y;

y := 0.26 * t + 0.245 * y + 0.44;

Form1.image1.Canvas.Pixels[mid_x+round(radius*x), mid_y round(radius*y)+35]:=col;

end; //Вывод изображения

procedure TForm1.Button1Click(Sender: TObject); //Инициализация построения фрактала

case radiogroup1.ItemIndex of

procedure TForm1.Button2Click(Sender: TObject); //Кнопка «Об авторе»

procedure TForm1.Button3Click(Sender: TObject); //Кнопка «Очистить форму»

procedure TForm1.FormCreate(Sender: TObject); //Исходные параметры формы

procedure TForm1.FormActivate(Sender: TObject);

Приложение Б

Источник: studfile.net

Документирование результатов тестирования. Процесс Тестирования План Тестирования Выбор стратегии Тест-план Анализ Документации Подробное описание тестов. — презентация

Презентация на тему: » Документирование результатов тестирования. Процесс Тестирования План Тестирования Выбор стратегии Тест-план Анализ Документации Подробное описание тестов.» — Транскрипт:

1 Документирование результатов тестирования

2 Процесс Тестирования План Тестирования Выбор стратегии Тест-план Анализ Документации Подробное описание тестов и оборудования Тест кейсы Выполнение тестов Поддержка, редактирование тестов Обнаружение и документирование ошибок Отчеты об ошибках Журналы испытаний Анализ результатов Финальный отчет

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

4 Отчёт о результатах тестирования Отчёт о результатах тестирования (test result report, TRR) – часть тестовой документации, включающая в себя описание процесса тестирования, суммарную информацию о протестированных за подотчётный период биллах, информацию о деятельности тестировщиков, а также некоторые статистические данные. Цель написания TRR – предоставление лицам, заинтересованным в проекте, полной и объективной информации о текущем состоянии качества проекта. Эта информация выражается в конкретных фактах и цифрах. Обычно, TRR предоставляется для ознакомления всей проектной команде и заказчику.

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

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

7 Индивидуальный отчет Индивидуальный отчет является кратким описанием (примерно 1-1/2 стр.) проделанной самостоятельной работы за отчетный период Новости -Есть ли какие-нибудь новости? Качество -Найдены ли серьезные проблемы? -Сколько багов назначено, исправлено, отклонено? -Какого типа баги встречались чаще всего? -Как ситуация изменилась по сравнению с прошлой неделей? -и д.р.

Ваше задание -Что вы делали на прошлой неделе? Вложились в расписание? Рекомендации -Что тебе еще необходимо для выполнения твоей работы? Твой план -Описание корректного плана работы на следующую неделю Риски -Какие проблемы могут скоро возникнуть?

8 1. Команда тестировщиков 2. Проверенные билды 2. Проверенные билды (Builds released) Описание процесса тестирования 3. Описание процесса тестирования (Testing Process Description) Краткое описание 4. Краткое описание (Summary) Расписание 5. Расписание (Testing Time) Сстатистика по ошибкам за данный период 6. Сстатистика по ошибкам за данный период (Bugs Status Progression over a Period) Список новых ошибок 7. Список новых ошибок (List of New Bugs Found) статистика по ошибкам 8. Общая сстатистика по ошибкам (Overall Bugs Status) 9. Рекомендации (Recommendations) Структура отчета

9 В этой части TRR перечисляются все задействованные в процессе тестирования сотрудники с указанием занимаемой должности и роли на проекте в подотчётный период. Например: ФИОДолжность на данном проекте Роль в подотчётный период Василий Пупкин Лидер команды тестировщиков Координирование работы команды, базовая проверка билдов, ревизия тестовых сценариев Василиса Пупкина Старший тестировщик Автоматизированное тестирование Структура отчета. Команда тестировщиков (test team)

10 Проверенные билды (Builds released) — Название, краткое описание, версия проверенных билдов В краткое описание может быть включено краткое описание работы, назначение, взаимодействие с другими биллами и д.р. Описание процесса тестирования (testing process description) В этой части TRR даётся краткое описание того, как происходило тестирование: какие использовались методы, техники, инструментальные средства и т.п.

Пример: Приложение было протестировано под ОС Windows XP sp2. en с использованием браузера FireFox 3.0. Смоук-тест был выполнен с использованием средства автоматизации JUnit 4.0. Тест критического пути и расширенный тест были выполнены вручную согласно документу «Тесты для ручного тестирования VWS версия doc».

Подробная информация о стратегии тестирования представлена в документе «Стратегия тестирования VWS версия doc». Структура отчета. Проверенные билды. Описание процесса тестирования

11 Краткое описание (summary) В этой части TRR даётся краткое описание того, какие билды были протестированы, есть ли в качестве приложения прогресс или регресс, есть ли какие-либо проблемы, требующие внимания руководства. Пример: Билд был успешно инсталлирован под обеими платформами (Windows XP sp2.en, FedoraCore 6.0). Смоук-тест пройден успешно.

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

На текущий момент выполнено более 80% запланированных тестов (остальные планируется выполнить до конца следующей недели). Было обнаружено всего четыре новых ошибки с важностью «высокая». Структура отчета. Краткое описание (summary)

12 В данном разделе отчёта приводится детализированное описание того, какая работа и на протяжении какого времени выполнялась каждым тестировщиком. Например: ФИОДата ОписаниеДлительность, ч Василиса Пупкина Подготовка тестового окружения 5 Василиса Пупкина Проведение смоук- теста под Windows XP 2 Василиса Пупкина Общение с коллегами по вопросам проекта 1 Структура отчета. Расписание (testing time)

13 Здесь приводится сводная таблица, содержащая информацию об ошибках, с которыми команде тестировщиков приходилось иметь дело в подотчётный период. Пример: Статус Количество Важность Критич.Высок.Средн.Мин. Исправл Провер Откр. заново Найдено Отклон Структура отчета. Сстатистика по ошибкам за данный период (Bugs Status Progression over a Period )

14 Здесь приводится список ошибок, обнаруженных командой тестировщиков за подотчётный период. Список ошибок легко извлечь из баг-трекинговой системы. Пример: Идентификатор ВажностьОписание VWS Высокая На форуме гость получает права пользователя VWS КритическаяСУБД зависает при достижении БД объёма 400 Mb Структура отчета. Список новых ошибок (List of New Bugs Found)

15 Здесь приводится сводная таблица, содержащая информацию об ошибках, с которыми команде тестировщиков приходилось иметь дело за всё время работы с проектом. Пример: Статус Количество Важность Критич.Высок.Средн.Мин. Исправл Провер Откр. заново Найдено Отклон Структура отчета. Сстатистика по всем ошибкам (Overall Bugs Status)

16 Сстатистика по всем ошибкам также отражается в виде графика: Найденные баги. Отражает количество найденных за отдельный подотчётный период багов. Закрытые баги. Отражает количество закрытых за отдельный подотчётные период багов. Всего найдено багов. Отражает количество багов, найденных за всё время работы с проектом.

Всего закрыто багов. Отражает количество багов, закрытых за всё время работы с проектом. Структура отчета. Сстатистика по всем ошибкам (Overall Bugs Status)

17 В этой части TRR следует подчеркнуть те важные моменты, на которые следует обратить внимание руководству или лидерам проектных команд. Здесь также, возможно, будет дана рекомендация на передачу проекта заказчику («передачу в продакшн»). Примеры: 1. Билд 3.45 рекомендован в продакшн. Билд работает стабильно. Все найденные баги закрыты.

2. Рекомендуется уделить особое внимание регрессионному тестированию в связи с резким возрастанием количества багов, найденных в ранее реализованной и протестированной функциональности. 3. В связи с возникшими сложностями по тестированию приложения под FreeBSD рекомендуется рассмотреть возможность подключения к проекту специалистов по тестированию под данной платформой. Структура отчета. Рекомендации (recomendations)

18 Выводы строятся на основе целей (которые были отражены в плане). Выводы дополняются рекомендациями. Как выводы, так и рекомендации строго обосновываются. Обоснование опирается на объективные факты.

19 Выводы должны быть: Краткими. Информативными.

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

Источник: www.myshared.ru