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

Содержание

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

// Метод вычисляет неотрицательную // степень n числа x static public double PowerNonNeg(double x, int n) < double z=1; Console.WriteLine(«x=z= n=», x,z,n); if (n>0) < Console.WriteLine(«x=z= n=», x,z,n); for (int i=1;n>=i;i++) < z = z*x; Console.WriteLine( «x=z= n=» + » i=»,x,z,n,i); > > else Console.WriteLine( «Ошибка ! Степень» + » числа n должна быть больше 0.»); return z; >
2.4. Исходный код с фиксацией результатов выполнения операторов

double PowerNonNeg(double x, int n) < double z=1; int i; printf(«x=%f z=%f n=%dn»,x,z,n); if (n>0) < printf(«x=%f z=%f n=%dn»,x,z,n); for (i=1;n>=i;i++) < z = z*x; printf(«x=%f z=%f n=%d i=%dn», x,z,n,i); >> else printf( «Ошибка ! Степень » «числа n должна быть больше 0.n»); return z; >
2.4.1. Исходный код с фиксацией результатов выполнения операторов

Пример результатов тестирования с RaDoTech Елена Серебро

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

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

Тестирование заканчивается, когда выполнилось или «прошло» (pass) успешно достаточное количество тестов в соответствии с выбранным критерием тестирования .

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

The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [ 9 ] .

The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [[IEEE Std.610-12.1990], [ 9 ] .

Сквозной пример тестирования

Возьмем несколько отличающуюся от Пример 2.4 программу:

// Метод вычисляет степень n числа x static public double Power(int x, int n) < int z=1; for (int i=1;n>=i;i++) < z = z*x; >return z; > [STAThread] static void Main(string[] args) < int x; int n; try < Console.WriteLine(«Enter x:»); x=Convert.ToInt32(Console.ReadLine()); if ((x>=0) =999)) < Console.WriteLine(«Enter n:»); n=Convert.ToInt32(Console.ReadLine()); if ((n>=1) =100)) < Console.WriteLine(«The power n» + » of x is <0>», Power(x,n)); Console.ReadLine(); > else < Console.WriteLine(«Error : n » + «must be in [1..100]»); Console.ReadLine(); >> else < Console.WriteLine(«Error : x » + «must be in [0..999]»); Console.ReadLine(); >> catch (Exception e) < Console.WriteLine(«Error : Please enter » + «a numeric argument.»); Console.ReadLine(); >>
Пример 2.5.

Другой пример вычисления степени числа
#include double Power(int x, int n) < int z=1; int i; for (i=1;n>=i;i++) < z = z*x; >return z; > void main(void) < int x; int n; printf(«Enter x:»); if(scanf(«%d», if ((x>=0) =999)) < printf(«Enter n:»); if(scanf(«%d», if ((n>=1) =100)) < printf(«The power n of x is %fn», Power(x,n)); >else < printf(«Error : n must be in [1..100]n»); >> else < printf(«Error : Please enter a numeric argumentn»); >> else < printf(«Error : x must be in [0..999]n»); >> else < printf(«Error : Please enter a numeric argumentn»); >>
2.5.1. Другой пример вычисления степени числа

Пример оформления отчета о тестировании: минимум данных, максимум информативности

Как оформить отчет о тестировании, если у Вас нет никаких средств для его создания (таск-трекера и т.д.)?

Дано : MVP-версия десктоп-приложения для Win-ОС с минимальной функциональностью отображения рекламных баннеров.

Необходимо : протестировать приложение по ТЗ и составить максимально информативный баг-репорт.

Допустим : приложение протестировано, обнаружены дефекты.

Встает вопрос — как оформить отчет о тестировании с баг-репортом?

Сначала определимся с набором минимальных характеристик, необходимых для формирования отчета:

Тема/Наименование — раскрываем кратко суть дефекта
Последовательность действий — описание шагов, которые привели к некорректному поведению приложения
Ожидаемый и Фактический результат — наши ожидания от выполнения последовательности действий и то, что мы получили по факту
Категория дефекта — градации могут быть разными, но они помогают классифицировать дефект. Например: функциональность, удобство, контент, дизайн, логика.
Критичность — пользуемся стандартной шкалой (Critical, Blocker, Medium, Minor, Trivial)
Приоритет — пользуемся стандартной шкалой (High, Medium, Low)
Скриншот — ссылка на скриншот экрана с ошибкой

Ниже представлен пример оформления отчета с разбивкой по критичности дефектов.

Начинаем с наивысшего уровня критичности, переходя к минорным дефектам.

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

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

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

2. Введение

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

3. Определение отчёта о результатах тестирования

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

4. Цель написания отчёта о результатах тестирования

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

5. Отчет о результатах тестирования

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

6. Периодичность выпуска отчёта о результатах тестирования

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

7. Структура отчёта о результатах тестирования

1.
2.
3.
4.
5.
6.
7.
8.
Команда тестировщиков
Описание процесса тестирования (testing
process description)
Краткое описание (summary)
Расписание (testing timetable)
Рекомендации (recomendations)
Статистика по ошибкам (bugs statistics)
Список новых ошибок (new bugs found)
Статистика по всем ошибкам (all bugs statistics)

8. Команда тестировщиков

В этой части TRR перечисляются все
задействованные в процессе тестирования
сотрудники с указанием занимаемой должности и
роли на проекте в подотчётный период.
ФИО
Должность
Роль в подотчетный
период

9. Описание процесса тестирования (testing process description)

10. Краткое описание (summary)

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

11. Краткое описание (summary). Пример

Билд 1.0.78 был успешно инсталирован под обеими
платформами (Windows XP sp2.en, FedoraCore 6.0).
Смоук-тест пройден успешно. Приложение работает
стабильно, основная функциональность
работоспособна. Существующие проблемы в основном
связаны с функциональностью, реализованной с
момента выпуска последнего билда. Большинство
найденных ранее ошибок успешно устранено и
верифицировано. Наблюдается значительный прогресс
в качестве приложения. На текущий момент
выполнено более 80% запланированных тестов
(остальные планируется выполнить до конца
следующей недели). Было обнаружено всего четыре
новых ошибки с важностью «высокая».

12. Расписание (testing timetable)

В данном разделе отчёта приводится
детализированное описание того, какая работа и
на протяжении какого времени выполнялась
каждым тестировщиком.
ФИО
Дата
Описание
Длительность, ч

13. Рекомендации (recomendations)

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

14. Примеры

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

15. Статистика по ошибкам (bugs statistics)

Здесь приводится сводная таблица, содержащая
информацию об ошибках, с которыми команде
тестировщиков приходилось иметь дело в
подотчётный период.
Статус
Количество
Важность
Критическая
Высокая
Средняя
Минимальная
Исправлено
28
3
7
10
8
Проверено
17
5
2
5
5
Открыто
заново
2
0
1
1
0
Найдено
36
5
11
8
12
Отклонено
4
0
0
1
3

16. Список новых ошибок (new bugs found)

Здесь приводится список ошибок, обнаруженных
командой тестировщиков за подотчётный
период.
Список ошибок легко извлечь из баг-трекинговой
системы.
Идентификатор
Важность Описание
VWS10070800723 Высокая
На форуме гость получает права
пользователя
VWS10070800724 Критичес
кая
СУБД зависает при достижении БД
объема 400 Mb

17. Статистика по всем ошибкам (all bugs statistics)

Здесь приводится сводная таблица, содержащая
информацию об ошибках, с которыми команде
тестировщиков приходилось иметь дело за всё
время работы с проектом.
Статус
Количество
Важность
Критическая
Высокая
Средняя
Минимальная
Исправлено
280
30
70
100
80
Проверено
170
50
20
50
50
Открыто
заново
20
0
10
10
0
Найдено
360
50
110
80
120
Отклонено
40
0
0
10
30

18. Статистика по всем ошибкам (all bugs statistics)

Статистика по всем ошибкам также отражается в
виде графика:

19. Кому нужен отчет об ошибках?

Отчёт о результатах тестирования в основном
нужен:
Менеджеру проекта
Лидеру команды разработчиков
Лидеру команды тестировщиков
Заказчику
Обычно, TRR предоставляется для ознакомления
всей проектной команде и заказчику

20. Менеджер проекта

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

21. Лидер команды разработчиков

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

22. Лидер команды тестировщиков

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

23. Заказчик

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

24. Финальный отчёт о результатах тестирования

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

Источник: ppt-online.org