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

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

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

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

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

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

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

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

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

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

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

Также предлагаю Вам список интересных статей по тестированию:

                                                "УТВЕРЖДАЮ"

                                         Начальник управления

                                         информационных технологий

                                         ________________________

                                            (подпись, фамилия)

                                         "__" ___________ ____

                             ПРОТОКОЛ

              о проведении комплексного тестирования

              ______________________________________

                     (указать наименование ПО)

                                           "____" ________ ____ г.

    Настоящий  протокол составлен  по результатам  тестирования на

базе  программно-технических   средств   МИ ФНС   России  по  ЦОД,

проведенного    рабочей    группой,    назначенной   распоряжением

заместителя   Руководителя   ФНС  России,    курирующего   вопросы

информатизации, N _______ от "__" ________ ____ г.

    Тестирование проводилось в период с "__" __________ ____ г. по

"__" ___________ ____ г.

    1. Условия, в которых проводилось тестирование:

    2. В ходе тестирования выявлено:

    1. (указываются  выявленные   недостатки   и  замечания   либо

"ошибок не выявлено");

    2. ...

    Предложения:

    1. ...;

    2. ...

    Выводы по результатам тестирования:

    1. (указывается общая оценка по возможности применения);

    2. (указываются, при необходимости, частные выводы)

    Члены рабочей группы:

    1. (Должность, фамилия, подпись)

    2. ...

План-конспект урока по пм 04 мдк 04.01

Дата: 31.01.14

Группа: 3В

Тема: Работы по тестированию, протоколы тестирования, отчет
о тестировании

 Цели
урока:

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

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

•        
воспитывать в
учениках средствами урока уверенность в своих силах;

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

Ход урока

1.     Орг. момент: Приветствие. Отметка
отсутствующих.

2.     Актуализация прежних знаний:

–      
Что такое
тестирование ПО?

–      
Что изучали на
прошлых уроках?

3.     Изучение нового материала:

 Работы по тестированию

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

– должны быть протестированы
на соответствие требованиям раздела 3;

– могут быть протестированы
на соответствие рекомендациям раздела 3.

Цели тестирования должны быть
определены исходя из требований раздела 3 и должны охватывать все эти
требования (полноту, непротиворечивость и т.д.).

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

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

– они оказывают
незначительное влияние на соответствие названной рабочей задаче;

– они могут быть
протестированы в принципе, но с неоправданными затратами ресурсов.

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

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

Протоколы по каждому тесту должны
содержать информацию, достаточную для повторения теста (Руководство ИСО/МЭК 25
[6]). Данная информация должна включать:

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

– все результаты, связанные с
контрольными примерами, включая все ошибки, выявленные при выполнении теста;

– штат персонала,
вовлеченного в тестирование.

Отчет о тестировании

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

1 Обозначение продукта.

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

3 Использованные документы
(включая их обозначения).

4 Результаты тестирования описания
продукта, документации пользователя, программ и данных.

5 Перечень несоответствий
требованиям.

6 Либо перечень несоответствий
рекомендациям, либо перечень не учтенных в продукте рекомендаций, либо
формулировка того, что продукт не был протестирован на соответствие
рекомендациям.

7 Дата окончания тестирования.

8 раздел 4 отчета о тестировании
(Результаты тестирования) должны быть включены формулировки, соответствующие
наименованию каждого пункта 3.1-4.2.

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

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

– формулировку, что
результаты тестирования относятся только к протестированным компонентам
продукта;

– формулировку, что полная
копия отчета о тестировании не может быть изготовлена без письменного
разрешения соответствующей испытательной лаборатории (Руководство ИСО/МЭК 25
[6]).

Отчет о тестировании должен
соответствовать положениям Руководства ИСО/МЭК 25 [6], относящимся к отчетам о
тестировании.

4.     Закрепление
нового материала:

–       Расскажите
о категориях ошибок»?

–       Что
такое отладка программы?

5.     Итоги
урока:

–       Что
нового узнали на этом уроке?

–       Что
было непонятным (сложным)?

6.     Домашнее
задание: выучить лекцию.

План-конспект урока по пм 04 мдк 04.01

Дата: 31.01.14

Группа: 3В

Тема: Лабораторная работа№62-63 Тестирование и отладка программ.

Цели
урока:

•        
Формирование навыков тестирования и отладки приложений в среде
Delphi 7.

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

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

•        
воспитывать в
учениках средствами урока уверенность в своих силах;

•        
в приобретении учащимися определенного круга знаний, умений и
навыков; Оборудование:

1).
Персональный компьютер;

2).
Среда Microsoft Office;

3).Среда
Delphi7

Ход урока

1.     Орг. момент: Приветствие. Отметка
отсутствующих.

2.     Актуализация
прежних знаний:

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

3.     Изучение нового материала:

Методические
указания к выполнению лабораторной работы

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

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

3.
Выполнить отладку приложения.

4.
Охарактеризовать типы ошибок, которые возникали в процессе отладки/

4.
Оформить отчет.

Содержание
отчета

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

4.     Закрепление
нового материала:

–       Расскажите
о категориях ошибок»?

–       Что
такое отладка программы?

5.     Итоги
урока:

–       Что
нового узнали на этом уроке?

–       Что
было непонятным (сложным)?

6.     Домашнее
задание: выучить лекцию.

План-конспект урока по пм 04 мдк 04.01

Дата: 1.02.14

Группа: 3В

Тема: Лабораторная работа№64 Работы по тестированию( составление
протоколов , отчетов)

Цели
урока:

•        
Целью работы является освоение
инструментальных средств отладки программ на языке ассемблера в программной
среде Turbo Assembler.

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

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

•        
воспитывать в
учениках средствами урока уверенность в своих силах;

•        
в приобретении учащимися определенного круга знаний, умений и
навыков; Оборудование:

1).
Персональный компьютер;

2).
Среда Microsoft Office;

3).Среда
Delphi7

Ход урока

1.     Орг. момент: Приветствие. Отметка
отсутствующих.

2.     Актуализация
прежних знаний:

 1. Какие группы регистров выделяются в микропроцессоре и каковы
особенности их использования?

2. Какую функцию в
микропроцессоре выполняет регистр флагов?

3. Как используется
регистр команд IP?

4. Какие шаги
необходимо выполнить для получения из программы на языке ассемблера исполняемого
модуля?

5. Прокомментируйте
содержание листинга программы.

6. В каких окнах и в
каком виде отображается состояние микропроцессора при отладке программ с
применением отладчика td.exe?

3.      Изучение нового материала:

Чтобы проверить
работоспособность созданной программы и увидеть результаты ее работы (если не
использован вывод на дисплей), применяют программу отладчик. Тестирование и
отладка исполняемой программы выполняется отладчиком TD
или DEBUG.

Отладчик td.exe, разработанный фирмой  Borland
International представляет собой оконную среду отладки программ
на уровне исходного текста на языках Pascal, C, ассемблер. Основные возможности отладчика,
наиболее широко используемые студентами – это:

–   выполнение
трассировки программы в прямом направлении, при котором за 1 шаг выполняется
одна машинная инструкция;

–   просмотр
и изменения состояния аппаратных ресурсов микропроцессора во время командного
выполнения программы.

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

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

–   локального,
учитывающего особенности окон и становящегося активным щелчком правой мыши или
нажатием клавиш Alt+F10.

Специфика программы
на ассемблере в том, что делать выводы о правильности ее функционирования
можно, отслеживая работу на уровне микропроцессора, обращая внимание на то, как
изменяется состояние ресурсов микропроцессора и компьютера в целом. Общее
поведение программы позволяет просмотреть режим безусловного выполнения,
который вызывается нажатием клавиши F9. Однако для
детального изучения работы программы рекомендуется применять режим выполнения
программы по шагам, для вызова которых выбираются пункты меню Run -> Trace into (прерывание или внутренняя процедура будут
выполняться по шагам) или Run -> Step
over (вызов процедуры или
прерывание отрабатываются как одна обычная команда). При этом используется окно
CPU, вызов
которого осуществляется через глобальное меню командой  View -> CPU. Окно CPU
состоит из 5 подчиненных окон:

–              
окно с исходной программой в машинных кодах,

–   Register – окно регистров микропроцессора, отражающее текущее состояние
регистров,

–   окно
флагов, отражающее состояние флагов микропроцессора в соответствии с таблицей
1;

Таблица 1

Обозначения и
значения флагов

Имя флага	Обозначение флага	Установлен	Сброшен
Флаг переполнения	O	1	0
Флаг направления	D	1	0
Флаг прерывания	I	1	0
Флаг знака	S	1(<0)	0(>0)
Флаг нуля	Z	1	0
Флаг вспомогатель-ного переноса	A	1	0
Флаг четности	P	1	0
Флаг переноса	C	1	0

–   окно
стека, в котором отражается содержимое области памяти, отведенной для стека,

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

Рекомендуемый порядок
работы с отладчиком:

а) вызвать на
выполнение td.exe.;

б) выбрать файл
исполняемой программы, набрав комбинации клавиш FILE ->OPEN и имя Вашей
программы в окне запроса. После ответа OK на сообщение об
отсутствии символьной таблицы в окно CPU загружается программа с нулевого адреса относительно начала сегментного
регистра кодов (для приведенного в конце описания лабораторной работы примера
это будет команда PUSH DS);

в) выбрать режим
пошагового выполнения Run -> Step
over. В окне CPU
появляется окрашенный треугольник между относительным адресом
команды и машинным кодом команды. Он показывает очередную команду, которая
будет выполнена процессором после нажатия функциональной клавиши F8. Изменения, которые происходят в сегментных регистрах после
выполнения команды, отмечаются белым цветом соответствующей строки в окне
регистров. Пошаговый процесс выполнять до тех пор, пока не появится сообщение
об окончании программы (с ключевым словом terminated);

г) после выполнения
команд, связанных с изменением содержимого ячеек памяти, нужно просматривать
эти изменения командой VIEW ->
DUMP. При отсутствии
мыши скрыть окно дампа памяти можно нажатием функциональной клавиши F6.

 Порядок выполнения работы

1.
Необходимо также создать командный файл для отладчика:

@echo
off

c:<название
папки>tasmtd.exe %1.com 

2. Набрать приведенную
в тексте программу формата .com на ассемблере с
использованием редактора текста.

3. Оттранслировать
программу в объектный код.

4. Скомпоновать
программу (получить исполнимый файл). Изучить листинг программы.

5. Провести отладку
программы и проверить получаемые результаты.

6. Внести в программу
следующие изменения: написать своё имя и фамилию.

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

4. СОДЕРЖАНИЕ
ОТЧЕТА

Отчет должен
включать:

а) титульный лист;

б) формулировку цели
работы;

в) описание
результатов выполнения пунктов 3-7:

• листинги программ;

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

г) выводы,
согласованные с целью работы.

4.
Закрепление нового материала:

–       Расскажите
о категориях ошибок»?

–       Что
такое отладка программы?

5.
Итоги урока:

–       Что
нового узнали на этом уроке?

–       Что
было непонятным (сложным)?

6.Домашнее
задание: выучить лекцию.

Our Test Protocols

This page describes “our conventions” to document test protocols (both
automated and manual).

What Are Tests?

Consider the following:

1. Tests may be automated (preferred) or manual (if necessary).
2. Tests are implicitly “requirements” (at the SR or SSR level).
3. Tests may be in support of:
4. Unit testing
5. Component testing
6. Functional testing
7. Verification testing (internal)
8. Verification testing (in support of SSRs)
9. Validation testing (in support of UNs, DIs, and SRs)

Documenting Test Protocols

Test protocols in support of internal testing, verification testing, and
validation testing may be performed through automated or manual tests.
Documenting the test protocol consists of:

1. Document the protocol within individual tests.
2. Document the protocol across all tests in support of a “requirement”
   or “feature”.
3. Document the protocol across all tests in a given “release”.

Our tests are documented at the most-specific level (individual test),
and “tagged” with zero-or-more “feature/requirement-tags” for automated
report generation that aggregates all tests associated with a
requirement/feature or release.

Test Protocols In GTest Header-Blocks

As our preferred automated test mechanism is to use gtest, and
each implemented automated test has a “header-comment-block” above
the test, a script can recursively descend our development
workspace, parse all gtest files, extract the commented header-blocks
that define the test protocols, and generate reports that aggregate all
test protocols by feature/requirement.

Thus, test protocol documentation is efficiently maintained where the test
logic itself is maintained, and reports are guaranteed to aggregate all
test protocols associated with a feature or release.

Because of our convention to auto-generate the complete test protocol
report from automated protocol extraction from all gtest instances
that are tagged for a feature/requirement, convention extends this
practice to similarly document all manual tests in a gtest
commented header block, where the “test body” is empty (because the test
is intended to be executed manually). In the future, some manual tests
may eventually be converted to manual tests with some level of protocol
modification.

Example Test Protocol Documentation

Note that all tests are expected to be derived from our convention for
test fixtures. Further, tests are aggregated between “automated” tests
where execution actually performs the test, and “manual” tests where
the gtest actually represents test instructions that are to be
manually executed.

This aggregation separation between manual and automated tests are
made through use of the test fixture, either TfMyGTest or
TfMyGTestManual.

An example gtest documented header block for an automated test
(using Doxygen code block comment conventions, and our convention for
the {{{featureref}}} tag, and which derives from our TfMyGTest
test fixture:

#include "CppFix.hpp"

#include "TfMyGTest.hpp"

//------------------------------------------------------------------------
// Define our "main()"
//------------------------------------------------------------------------
MY_GTEST_MAIN_PROTOTYPE
{
  MY_GTEST_MAIN_BODY;
} // <==SET BREAKPOINT HERE
//------------------------------------------------------------------------
//------------------------------------------------------------------------

//------------------------------------------------------------------------
// Define our "test(s)"
//------------------------------------------------------------------------

/// TEST that MyNewFeature defaults to established values.
///
///   1. Create MyObject that implements MyNewFeature.
///   2. VERIFY MyObject is in "valid" state.
///   3. Interrogate values established through default
///      construction:
///        * VERIFY property-A
///        * VERIFY property-B
///        * VERIFY property-C
///
/// Supports testing for the following features:
/// - featureref feature_6-2-7_MyNewFeature_1
/// - featureref feature_6-2-8_MyOtherFeature_1
TEST_F(TfMyGTest, testMyNewFeature1)
{
  // ...insert automated-test code here...
  EXPECT_TRUE(true);
}

An similar example gtest documented header block for a manual test
(using Doxygen code block comment conventions, and our convention for
the featureref tag, and which derives from our TfMyGTestManual
test fixture:

#include "CppFix.hpp"

#include "TfMyGTestManual.hpp"

//------------------------------------------------------------------------
// Define our "main()"
//------------------------------------------------------------------------
MY_GTEST_MAIN_PROTOTYPE
{
  MY_GTEST_MAIN_BODY;
} // <==SET BREAKPOINT HERE
//------------------------------------------------------------------------
//------------------------------------------------------------------------

//------------------------------------------------------------------------
// Define our "test(s)"
//------------------------------------------------------------------------

/// TEST that MyNewFeature works in GUI.
///
///   1. Start instrument, go to CytoPanel=>SomeScreen.
///   2. VERIFY MyNewFeature button is present.
///   3. Press MyNewFeature button.
///   4. VERIFY the blizzle toggled the fiddlebop.
///
/// Supports testing for the following features:
/// - featureref feature_6-2-7_MyNewFeature_1
TEST_F(TfMyGTestManual, testMyNewFeature2)
{
  // ...do nothing (is manual test instructions)
  EXPECT_TRUE(true);
}

Glossary

• DI – Design Inputs
• SR – System Requirements
• SSR – (Software) Sub-System Requirement
• UN – User Needs