Автоматическое и ручное тестирование

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

1. идентификатор ручного тестового примера

2. описание сценария ручного тестового примера или задачи экспертного анализа

3. имя лица, проводившего ручное тестирование

4. версии требований, на основании которых проводилось ручное тестирование

5. Ссылки на участки программного кода, для которого проводится ручное тестирование

6. Информацию о соответствии программного кода требованиям (результат ручного тестирования) – соответствует/не соответствует

7. Информацию о потенциально возможных проблемах внутри допустимого диапазона значений и за его пределами

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

9. Информацию об итоговом результате ручного тестового примера – успешно/неуспешно.

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

*****************************************************************************

Manual Analysis of Testcase 1 (1): verify that the IR scan goes at a 10Hz rate. (2)

*****************************************************************************

1. Activity Description: Independent Code Analysis.

Tester Name: Petrov P. (3)

Pass Criteria: Tester name is not the same as programmer name

2. Activity Description: Name and CM Version of file under review

Module and/or Function Name: IRDA.C CM Version: 56 (4,5)

Document chapter: 7.8.5 CM Version: 12 (4)

Pass criteria: All documents exists in respective versions

3. Activity Description: Requirements Implemented.

Identify which lines of code in the module under review incorporate requirements

PassCriteria: Code implements the requirements as defined in the requirement document

Result (Pass/Fail): Pass (6)

4. Activity Description: Code Robustness

Identify line numbers and give a brief description on the software design to handle the following cases

Analysis for at, Inside boundary: The variable refreshRate is set to 10 at line 235 of IRDA.C and later used in IR_Init() function to set NVRAM values on line 590. (5,7)

Analysis for out-of-boundary (robustness): N/A (7)

5. Activity Description: Structural Coverage Analysis

PassCriteria: Software and software structures (when applicable) are accessible under conditions specified by requirements

Y/N: YES (8)

6. Activity Description: Overall manual test result

Result (Pass/Fail): Pass (9)


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: