A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |
Примеры тест-кейсов и баг-репортов | |||||||||||||||||||||||||
2 |
||||||||||||||||||||||||||
3 |
баг-репорты | |||||||||||||||||||||||||
4 |
variant A | |||||||||||||||||||||||||
5 |
Id | A1 | ||||||||||||||||||||||||
6 |
Name | FF53 — User can enter alphabetical and special symbols to DOB fie | ||||||||||||||||||||||||
7 |
Steps | 1. Log in to MiAgent portal | ||||||||||||||||||||||||
8 |
2. Search for a customer | |||||||||||||||||||||||||
9 |
3. Click on Edit icon near Income/Last Changed | |||||||||||||||||||||||||
10 |
4. Click on Occupant | |||||||||||||||||||||||||
11 |
5. Enter alphabetical and special symbols to DOB field | |||||||||||||||||||||||||
12 |
Actual result | User can enter alphabetical and special symbols to DOB field | ||||||||||||||||||||||||
13 |
Expected result |
User can’t enter alphabetical and special symbols to DOB field |
||||||||||||||||||||||||
14 |
Attachments | http://prntscr.com/jas795 | ||||||||||||||||||||||||
15 |
||||||||||||||||||||||||||
16 |
variant B | |||||||||||||||||||||||||
17 |
Id | Summary | Preconditions | Steps to reproduce | Actual Result | Expected Result | Attachments | |||||||||||||||||||
18 |
B1 | 404 error is displayed | 1. Go to http://www.example.com | 404 error is displayed | Authorization page is opened | http://prntscr.com/ic93kw | ||||||||||||||||||||
19 |
2. Click on «Login» button | |||||||||||||||||||||||||
20 |
||||||||||||||||||||||||||
21 |
||||||||||||||||||||||||||
22 |
тест-кейсы | |||||||||||||||||||||||||
23 |
ID | Summary | Precondition | Steps | Expected Result | |||||||||||||||||||||
24 |
R_1 | Регистрация пользователя через email | https://www.facebook.com/r.php?locale=ru_RU&display=page | 1. Ввести имя и фамилию в поля «Имя» и «Фамилия» | 1. Данные введены | |||||||||||||||||||||
25 |
2. Ввести email в поле «Номер телеофна….» |
2. Email введен, появилось поле «Ввведите повторно email» |
||||||||||||||||||||||||
26 |
3. Ввести email в поле «Ввведите повторно email» | 3. Email введен | ||||||||||||||||||||||||
27 |
4. Ввести пароль 6 символов в поле «Пароль» | 4. Пароль введен | ||||||||||||||||||||||||
28 |
5. Выбрать день, месяц и год рождения в выпадающих списках «день», «месяц» и «год» | 5. Дата рождения выбрана | ||||||||||||||||||||||||
29 |
6. Выбрать пол в radio button «Пол» | 6. Пол выбран | ||||||||||||||||||||||||
30 |
7. Нажать кнопку «Зарегистрироваться» | 7. Пользователь успешно зарегистрирован, переход на страницу «Подтвердите свой эл. адрес» | ||||||||||||||||||||||||
31 |
||||||||||||||||||||||||||
32 |
ID | Summary | Precondition | Steps | Expected Result | |||||||||||||||||||||
33 |
R_1 | Registration via email | Go to the https://www.facebook.com/r.php?locale=ru_RU&display=page | 1. Enter first and last name to the «Name» and «Last Name» fields | 1. Data is entered | |||||||||||||||||||||
34 |
2. Enter an email to the «Phone number ….» field | 2. Email is entered, the «Re-enter email» field appears | ||||||||||||||||||||||||
35 |
3. Enter email to the «Re-enter email» field | 3. Email is entered | ||||||||||||||||||||||||
36 |
4. Enter password (6 characters) to the «Password» field | 4. Password is entered | ||||||||||||||||||||||||
37 |
5. Select the day, month and year of birth to the «day», «month» and «year» drop-down lists | 5. Date of birth is selected | ||||||||||||||||||||||||
38 |
6. Select the gender in the «Gender» radio button | 6. Gender is selected | ||||||||||||||||||||||||
39 |
7. Click on «Register» button | 7. The user is successfully registered, redirects to «Confirm your e-mail address» page | ||||||||||||||||||||||||
40 |
||||||||||||||||||||||||||
41 |
||||||||||||||||||||||||||
42 |
||||||||||||||||||||||||||
43 |
||||||||||||||||||||||||||
44 |
||||||||||||||||||||||||||
45 |
||||||||||||||||||||||||||
46 |
||||||||||||||||||||||||||
47 |
||||||||||||||||||||||||||
48 |
||||||||||||||||||||||||||
49 |
||||||||||||||||||||||||||
50 |
||||||||||||||||||||||||||
51 |
||||||||||||||||||||||||||
52 |
||||||||||||||||||||||||||
53 |
||||||||||||||||||||||||||
54 |
||||||||||||||||||||||||||
55 |
||||||||||||||||||||||||||
56 |
||||||||||||||||||||||||||
57 |
||||||||||||||||||||||||||
58 |
||||||||||||||||||||||||||
59 |
||||||||||||||||||||||||||
60 |
||||||||||||||||||||||||||
61 |
||||||||||||||||||||||||||
62 |
||||||||||||||||||||||||||
63 |
||||||||||||||||||||||||||
64 |
||||||||||||||||||||||||||
65 |
||||||||||||||||||||||||||
66 |
||||||||||||||||||||||||||
67 |
||||||||||||||||||||||||||
68 |
||||||||||||||||||||||||||
69 |
||||||||||||||||||||||||||
70 |
||||||||||||||||||||||||||
71 |
||||||||||||||||||||||||||
72 |
||||||||||||||||||||||||||
73 |
||||||||||||||||||||||||||
74 |
||||||||||||||||||||||||||
75 |
||||||||||||||||||||||||||
76 |
||||||||||||||||||||||||||
77 |
||||||||||||||||||||||||||
78 |
||||||||||||||||||||||||||
79 |
||||||||||||||||||||||||||
80 |
||||||||||||||||||||||||||
81 |
||||||||||||||||||||||||||
82 |
||||||||||||||||||||||||||
83 |
||||||||||||||||||||||||||
84 |
||||||||||||||||||||||||||
85 |
||||||||||||||||||||||||||
86 |
||||||||||||||||||||||||||
87 |
||||||||||||||||||||||||||
88 |
||||||||||||||||||||||||||
89 |
||||||||||||||||||||||||||
90 |
||||||||||||||||||||||||||
91 |
||||||||||||||||||||||||||
92 |
||||||||||||||||||||||||||
93 |
||||||||||||||||||||||||||
94 |
||||||||||||||||||||||||||
95 |
||||||||||||||||||||||||||
96 |
||||||||||||||||||||||||||
97 |
||||||||||||||||||||||||||
98 |
||||||||||||||||||||||||||
99 |
||||||||||||||||||||||||||
100 |
Когда смотришь на специалистов по тестированию, которые пишут тест-кейсы, то понимаешь, что многие из них даже не имеют представления как это правильно делается. Я не буду приводить множество примеров, которые показывают вопиющие ошибки, а постараюсь озвучить основные принципы того, как надо писать тест-кейсы.
Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор.
Обязательные атрибуты для заполнения
- Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
- Заголовок — краткое, понятное и ёмкое описание сути проверки.
- Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
- Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
- Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.
В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д.
Правила написания тест-кейсов
- Заголовок:
- должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
- не может содержать выполняемые шаги и ожидаемый результат.
- Предусловие:
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
- не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
- не может содержать ожидаемый результат.
- Шаги проверки:
- должны быть чёткими, понятными и последовательными;
- следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; - должны использоваться безличные глаголы.
Правильно: нажать, ввести, перейти.
Неправильно: нажмите, введите, идите; - не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
- не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
- Ожидаемый результат:
- должен быть у каждого шага проверки;
- должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
- не должно быть избыточного описания.
- Общие требования к тест-кейсам:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
- в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
Примеры
Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.
Тест-кейс №1. Корректный
Номер | 1 |
Заголовок | Отправка сообщения через форму обратной связи на странице “Контакты” |
Предусловие | Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru |
Шаг | Ожидаемый результат |
В верхнем меню сайта нажать на ссылку “Контакты” | Открылась страница “Контакты” |
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы | В поле “Ваше имя” отображается введённое имя |
Ввести корректный email в поле “Ваш e-mail” | В поле “Ваш e-mail” отображается введённый email |
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Тема” отображается введённый текст |
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Сообщение” отображается введённый текст |
Ввести в поле капчи требуемое капчей значение | В поле капчи отображается введённое значение |
Нажать под заполняемой формой на кнопку “Отправить” | Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.” Все заполненные поля очищены. |
Проверить почту администратора сайта | На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5. |
Тест-кейс №2. Некорректный
В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения.
Номер | 1 |
Заголовок | Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?) |
Предусловие | Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага) |
Шаг | Ожидаемый результат |
Нажать на ссылку “Контакты” (Где она находится?) | Открылась страница (Какая?) |
Ввести имя в поле “Ваше имя” (Какие символы вводить?) | (Ничего не указано в ожидаемом результате, что должно произойти?) |
Ввести email в поле “Ваш e-mail” (корректный или некорректный?) | В поле отображается email (Какой? Введённый? В каком поле отображается?) |
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?) | В поле “Тема” отображается текст (Какой?) |
Ввести в поле “Сообщение” текст (Какие символы вводить?) | Видим в поле “Сообщение” введённый текст (Видим или отображается?) |
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести). | В поле капчи будет введённое значение (Что будет делать? Танцевать?) |
Нажать под заполняемой формой на кнопку (На какую?) | Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?) |
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи) |
Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:
Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.
Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.
Smartsheet Contributor
Kate Eby
January 25, 2019
In this article, you’ll find the most useful free, downloadable test case templates in Microsoft Excel and PDF formats. Learn how to use these templates to review and verify certain features and functions of an application, software, a trial, or a test and update those features and functions based on test results.
Test Case Planning and Execution Template
Download Test Case Planning and Execution Template
Excel | Word | PDF | Smartsheet
With this complete test case planning and execution template, you can map out test plans for individual components of a project or trial, seamlessly execute tests, and analyze the data that comes from a test. You can also track tests by test ID and name, identify each step of a test, add priority levels and notes, and compare actual versus expected results. This complete testing template is compatible for all tests, from clinical trials to software updates.
Test Case Point Estimate Template
Download Test Case Point Estimate Template
Excel | Smartsheet
Assess the approach needed to test software, determine testing checkpoints and preconditions, and analyze all test results with this comprehensive test case point estimate template. Use this template to rate priorities and complexities based on a high-to-low measure, allocate testing time for each specific step, and determine the amount of work associated with each test.
Manual Testing Test Case Template
Download Manual Testing Test Case Template
Excel | Word | PDF
With this manual testing test case template, you can record testing steps and data, analyze expected results versus actual results, and determine whether or not you can consider a test to be a success. With space to record each individual step of the testing process, the test ID and name, and additional notes to consider during analysis, this template allows you to run through every possible result in a trial and determine if it passed or failed inspection.
Automation Testing Test Case Template
Download Automation Testing Test Case Template
Excel | PDF
Use this automation testing test case template to review the success or failure of an automated software, application, or feature. Document the test name and ID, the test duration, each separate step and component, and any notes about the test, including the parts of the test that are automated. Simply download and fill out this form to fit the needs of whatever automated application you are testing.
User Acceptance Testing Test Case Template
Download User Acceptance Testing Test Case Template
Excel | PDF
With this user acceptance testing (UAT) test case template, test newly designed software to ensure that it matches the designated specifications and meets all user-provided requirements. Track individual applications, the steps to execute them, and both the expected and actual results with this comprehensive testing template.
SQL Server Integration Services Testing Test Case Template
Download SQL Server Integration Services Testing Test Case Template
Excel | PDF
Manage, test, and track all SQL server integration services with this detailed test case template. You can use this SQL test case template to ensure that all programming and data management systems are working correctly and test any updates or quick fixes.
What Is a Test Case Document?
A test case document is a set of steps that a team can execute to test certain scenarios based on the needs of the function, from clinical trials to software updates and even project management changes. Each test case includes a set of preconditions as well as test data, expected results, actual results, and post-conditions that help determine the success or failure of a test.
All steps of a test case are meant to check the functionality and applicability of each test, based on the preconditions and expected results. A test case is considered the smallest unit of a testing plan and contributes to the overall test script or user story.
To begin a test case, one must first describe the actions and parameters they mean to achieve, verify, or challenge regarding any expected behavior of a test. There are sets of conditions and variables that the tester uses to determine the quality and success of a system, trial, feature, or software, and the end results can confirm these facts.
What Is the Purpose of a Test Case?
A test case can help you easily identify any problems, unplanned issues, or missed details in a project, update, or trial. Additionally, test cases provide the following benefits for the individuals or teams who carry them out:
- Minimize ad-hoc testing
- Make manual test case management easier and more streamlined
- Save valuable time when testing and analyzing results
- Enable testers to develop individual test cases for specific scenarios
- Verify the success of updates or changes
- Make it easier to share results with stakeholders and gain buy-in from all involved parties
- Lessen the effort and error rate involved in testing
- Define and flesh out all positive and negative test results or behavior
- Divide tests into positive and negative segments
- Eliminate the number of bugs or errors in an end product
- Communicate all specific conditions from the start in order to eliminate confusion
- Keep management updated on the quality status of a test
- Help testers generate detailed summaries and reports on test status, defects, bugs, etc.
- Track productivity and trace all problems back to the source
- Help testers write and report on more comprehensive test case results
What Are the Components of a Test Case?
A test case is comprised of many different components: It assesses what is being tested, the expected results of a test, and the process involved in testing each specified element of a case.
In general, test cases should include the following:
- Test Process: This includes the test review and approval, the test execution plan, the test report process, use cases (if applicable), and performance risks.
- Positive and Negative Tests: Positive tests should help check whether the functionality is performing correctly, while negative tests should check every reverse situation where an error or issue could occur.
- Test Case ID: This helps you correctly and uniformly document each test case and its corresponding results; it also helps you avoid retesting the same things.
- Test Scenario: This includes all the information about a test in the form of specific, detailed objectives that will help a tester perform a test accurately. It will not, however, include specific steps or sequences.
- Test Steps: The steps should tell a tester, in detail, exactly what they should do during each step, including specific objectives.
- Test Data: This section includes all the information and data that a test collects throughout the duration of the process.
- Expected Results: This includes any detailed and precise information or data that a tester should expect to see and gather from a test.
- Actual Results: This includes all positive and negative results that you receive from a test and that help you confirm or reject the expected results and detect any issues or bugs.
- Confirmation: This is the part of the process during which testers discuss and review whether or not a test was a success or a failure, based on the results.
What Is the Difference between a Test Case and a Test Scenario?
Although they may seem quite similar, test cases and test scenarios are two very different aspects involved in testing the functionality of a new software, update, or process. Test cases are specific conditions under which a new functionality is tested, whereas a test scenario is the overall end-to-end functionality of an application when it is working correctly.
Test cases are usually lower-level actions that can be created or derived from test scenarios. They give information about preconditions, what is being tested, how the test will be carried out, and the expected results.
Test cases require detailed documentation in order to assess how a test is proceeding, and a test case verifies the output of a function.
On the other hand, test scenarios are made up of test procedures, which encompass many test cases. Test scenarios are generally considered to be higher level and include groups of test cases, depending on the following factors: the functionality being tested, the type of test being performed, and the duration of the test.
Overall, test scenarios help reduce the complexity and confusion involved in creating a new product or updating a new function.
Tips to Write, Implement, and Track Test Cases
In order to gain the most from the tests you are running, you must create comprehensive, detailed, and test-specific test cases that describe exactly what is being tested, why it is being tested, and what the expected results should be.
To run the most effective test cases and gain powerful, actionable insights, follow these simple tips:
- Make the test steps as clear as possible, avoiding vague objectives and directions.
- Ensure that the test has no more than 15 steps to avoid confusion. If there are more than 15 steps, break the test into separate tests.
- In the test directions, include any additional documents or references that might be relevant to the test itself.
- Include a detailed description of the requirement being tested, and explain in detail how the test should be carried out for each requirement.
- Provide details on all the expected results, so the tester can compare the actual results against them. Of course, this step is unnecessary if the expected results are obvious.
- Use active case language when writing the steps, and make sure they are as simple and clear as possible.
- Avoid repeating any of the same steps, as this could add confusion to an already complicated process.
- Include the test name and ID in the testing instructions.
- Keep the end user in mind as you develop the test and its variables.
- Reread and peer review the test case instructions before finalizing them.
- Remember that the test case should be repeatable, traceable, and accurate.
Test Case Use Cases
You can leverage test cases for a variety of purposes: to gain insight into how processes are performing; to determine how software updates are being used; and to figure out how business trials or tests are progressing.
Some of the most common use cases for test cases include the following:
- Confirming login functionality on a username and password combination
- Checking to see how the login function reacts to a valid or invalid username or password
- Seeing what happens when someone inputs an empty response for either the username or password component
Numerous companies, such as HP Quality Center and Jira, use test cases to track and update their processes.
Improve Your Test Cases with Free Test Case Templates in Smartsheet
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
Содержание
- Test Case Template – Download Excel & Word Sample Format
- What is Test Case Template?
- Test Case Template for Excel and Word
- Образец шаблона теста
- Шаблон тестового примера
- Free Test Case Templates
- Test Case Planning and Execution Template
- Test Case Point Estimate Template
- Manual Testing Test Case Template
- Automation Testing Test Case Template
- User Acceptance Testing Test Case Template
- SQL Server Integration Services Testing Test Case Template
- What Is a Test Case Document?
- What Is the Purpose of a Test Case?
- What Are the Components of a Test Case?
- What Is the Difference between a Test Case and a Test Scenario?
- Tips to Write, Implement, and Track Test Cases
- Test Case Use Cases
- Improve Your Test Cases with Free Test Case Templates in Smartsheet
Test Case Template – Download Excel & Word Sample Format
Updated March 4, 2023
What is Test Case Template?
A Test Case Template is a well-designed document for developing and better understanding of the test case data for a particular test case scenario. A good Test Case template maintains test artifact consistency for the test team and makes it easy for all stakeholders to understand the test cases. Writing test case in a standard format lessen the test effort and the error rate. Test cases format are more desirable in case if you are reviewing test case from experts.
The template chosen for your project depends on your test policy. Many organizations create test cases in Microsoft Excel while some in Microsoft Word. Some even use test management tools like HP ALM to document their test cases.
Click Below to download Test Case XLS
Irrespective of the test case documentation method chosen, any good test case template must have the following fields
Test Case Field | Description |
---|---|
Test case ID: | Each test case should be represented by a unique ID. To indicate test types follow some convention like “TC_UI_1” indicating “User Interface Test Case#1.” |
Test Priority: | It is useful while executing the test. |
- Low
- Medium
- High
Name of the Module: Determine the name of the main module or sub-module being tested Test Designed by: Tester’s Name Date of test designed: Date when test was designed Test Executed by: Who executed the test- tester Date of the Test Execution: Date when test needs to be executed Name or Test Title: Title of the test case Description/Summary of Test: Determine the summary or test purpose in brief Pre-condition: Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditions Dependencies: Determine any dependencies on test requirements or other test cases Test Steps: Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps ensure that you provide as much detail as you can Test Data: Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input Expected Results: Mention the expected result including error or message that should appear on screen Post-Condition: What would be the state of the system after running the test case? Actual Result: After test execution, actual test result should be filled Status (Fail/Pass): Mark this field as failed, if actual result is not as per the estimated result Notes: If there are some special condition which is left in above field
- Link / Defect ID: Include the link for Defect or determine the defect number if test status is fail
- Keywords / Test Type: To determine tests based on test types this field can be used. Eg: Usability, functional, business rules, etc.
- Requirements: Requirements for which this test case is being written
- References / Attachments: It is useful for complicated test scenarios, give the actual path of the document or diagram
- Automation ( Yes/No): To track automation status when test cases are automated
Test Case Template for Excel and Word
Click below to download Test Case Excel File
Click below to download Test Case Word File
Источник
Образец шаблона теста
Хороший Пример теста шаблон поддерживает тестовую последовательность артефакта для тестовой команды и делает его легким для всех заинтересованных сторон , чтобы понять тестовые случаи. Написание тестового примера в стандартном формате уменьшает нагрузку на тест и уровень ошибок. Формат тест-кейсов более желателен, если вы просматриваете тест-кейс от экспертов.
Шаблон, выбранный для вашего проекта, зависит от вашей политики тестирования. Многие организации создают контрольные примеры в Microsoft Excel, а некоторые — в Microsoft Word. Некоторые даже используют инструменты управления тестированием, такие как HP ALM, для документирования своих тестовых случаев.
Нажмите ниже, чтобы загрузить Test Case XLS
Независимо от выбранного метода документации тестового примера, любой хороший шаблон тестового примера должен иметь следующие поля
Поле теста | Описание |
---|---|
Идентификатор тестового примера: |
|
Приоритет теста: |
|
Наименование модуля : |
|
Тест разработан : |
|
Дата разработки теста : |
|
Тест выполнен : |
|
Дата проведения теста : |
|
Имя или название теста : |
|
Описание / Краткое содержание теста : |
|
Предварительное условие : |
|
Зависимости : |
|
Тестовые шаги : |
|
Тестовые данные : |
|
Ожидаемые результаты : |
|
Постусловие : |
|
Фактический результат : |
|
Статус (Fail / Pass): |
|
Примечания : |
|
При желании вы можете иметь следующие поля в зависимости от требований проекта
- Ссылка / Дефект ID : Включите ссылку на дефект или определить число дефектов , если статус тестов отказобезо-
- Ключевые слова / тип теста : для определения тестов на основе типов тестов можно использовать это поле. Например: юзабилити, функциональность, бизнес-правила и т. Д.
- Требования : требования, для которых написан этот контрольный пример
- Ссылки / Приложения : Полезно для сложных тестовых сценариев, указывать фактический путь к документу или диаграмме.
- Автоматизация (Да / Нет) : для отслеживания состояния автоматизации, когда тесты автоматизированы
Шаблон тестового примера
Нажмите ниже, чтобы скачать тестовый файл Excel
Нажмите ниже, чтобы загрузить тестовый файл Word.
Источник
Free Test Case Templates
January 25, 2019
In this article, you’ll find the most useful free, downloadable test case templates in Microsoft Excel and PDF formats. Learn how to use these templates to review and verify certain features and functions of an application, software, a trial, or a test and update those features and functions based on test results.
Test Case Planning and Execution Template
Download Test Case Planning and Execution Template
With this complete test case planning and execution template, you can map out test plans for individual components of a project or trial, seamlessly execute tests, and analyze the data that comes from a test. You can also track tests by test ID and name, identify each step of a test, add priority levels and notes, and compare actual versus expected results. This complete testing template is compatible for all tests, from clinical trials to software updates.
Test Case Point Estimate Template
Download Test Case Point Estimate Template
Assess the approach needed to test software, determine testing checkpoints and preconditions, and analyze all test results with this comprehensive test case point estimate template. Use this template to rate priorities and complexities based on a high-to-low measure, allocate testing time for each specific step, and determine the amount of work associated with each test.
Manual Testing Test Case Template
Download Manual Testing Test Case Template
With this manual testing test case template, you can record testing steps and data, analyze expected results versus actual results, and determine whether or not you can consider a test to be a success. With space to record each individual step of the testing process, the test ID and name, and additional notes to consider during analysis, this template allows you to run through every possible result in a trial and determine if it passed or failed inspection.
Automation Testing Test Case Template
Download Automation Testing Test Case Template
Use this automation testing test case template to review the success or failure of an automated software, application, or feature. Document the test name and ID, the test duration, each separate step and component, and any notes about the test, including the parts of the test that are automated. Simply download and fill out this form to fit the needs of whatever automated application you are testing.
User Acceptance Testing Test Case Template
Download User Acceptance Testing Test Case Template
With this user acceptance testing (UAT) test case template, test newly designed software to ensure that it matches the designated specifications and meets all user-provided requirements. Track individual applications, the steps to execute them, and both the expected and actual results with this comprehensive testing template.
SQL Server Integration Services Testing Test Case Template
Download SQL Server Integration Services Testing Test Case Template
Manage, test, and track all SQL server integration services with this detailed test case template. You can use this SQL test case template to ensure that all programming and data management systems are working correctly and test any updates or quick fixes.
What Is a Test Case Document?
A test case document is a set of steps that a team can execute to test certain scenarios based on the needs of the function, from clinical trials to software updates and even project management changes. Each test case includes a set of preconditions as well as test data, expected results, actual results, and post-conditions that help determine the success or failure of a test.
All steps of a test case are meant to check the functionality and applicability of each test, based on the preconditions and expected results. A test case is considered the smallest unit of a testing plan and contributes to the overall test script or user story.
To begin a test case, one must first describe the actions and parameters they mean to achieve, verify, or challenge regarding any expected behavior of a test. There are sets of conditions and variables that the tester uses to determine the quality and success of a system, trial, feature, or software, and the end results can confirm these facts.
What Is the Purpose of a Test Case?
A test case can help you easily identify any problems, unplanned issues, or missed details in a project, update, or trial. Additionally, test cases provide the following benefits for the individuals or teams who carry them out:
- Minimize ad-hoc testing
- Make manual test case management easier and more streamlined
- Save valuable time when testing and analyzing results
- Enable testers to develop individual test cases for specific scenarios
- Verify the success of updates or changes
- Make it easier to share results with stakeholders and gain buy-in from all involved parties
- Lessen the effort and error rate involved in testing
- Define and flesh out all positive and negative test results or behavior
- Divide tests into positive and negative segments
- Eliminate the number of bugs or errors in an end product
- Communicate all specific conditions from the start in order to eliminate confusion
- Keep management updated on the quality status of a test
- Help testers generate detailed summaries and reports on test status, defects, bugs, etc.
- Track productivity and trace all problems back to the source
- Help testers write and report on more comprehensive test case results
What Are the Components of a Test Case?
A test case is comprised of many different components: It assesses what is being tested, the expected results of a test, and the process involved in testing each specified element of a case.
In general, test cases should include the following:
- Test Process: This includes the test review and approval, the test execution plan, the test report process, use cases (if applicable), and performance risks.
- Positive and Negative Tests: Positive tests should help check whether the functionality is performing correctly, while negative tests should check every reverse situation where an error or issue could occur.
- Test Case ID: This helps you correctly and uniformly document each test case and its corresponding results; it also helps you avoid retesting the same things.
- Test Scenario: This includes all the information about a test in the form of specific, detailed objectives that will help a tester perform a test accurately. It will not, however, include specific steps or sequences.
- Test Steps: The steps should tell a tester, in detail, exactly what they should do during each step, including specific objectives.
- Test Data: This section includes all the information and data that a test collects throughout the duration of the process.
- Expected Results: This includes any detailed and precise information or data that a tester should expect to see and gather from a test.
- Actual Results: This includes all positive and negative results that you receive from a test and that help you confirm or reject the expected results and detect any issues or bugs.
- Confirmation: This is the part of the process during which testers discuss and review whether or not a test was a success or a failure, based on the results.
What Is the Difference between a Test Case and a Test Scenario?
Although they may seem quite similar, test cases and test scenarios are two very different aspects involved in testing the functionality of a new software, update, or process. Test cases are specific conditions under which a new functionality is tested, whereas a test scenario is the overall end-to-end functionality of an application when it is working correctly.
Test cases are usually lower-level actions that can be created or derived from test scenarios. They give information about preconditions, what is being tested, how the test will be carried out, and the expected results.
Test cases require detailed documentation in order to assess how a test is proceeding, and a test case verifies the output of a function.
On the other hand, test scenarios are made up of test procedures, which encompass many test cases. Test scenarios are generally considered to be higher level and include groups of test cases, depending on the following factors: the functionality being tested, the type of test being performed, and the duration of the test.
Overall, test scenarios help reduce the complexity and confusion involved in creating a new product or updating a new function.
Tips to Write, Implement, and Track Test Cases
In order to gain the most from the tests you are running, you must create comprehensive, detailed, and test-specific test cases that describe exactly what is being tested, why it is being tested, and what the expected results should be.
To run the most effective test cases and gain powerful, actionable insights, follow these simple tips:
- Make the test steps as clear as possible, avoiding vague objectives and directions.
- Ensure that the test has no more than 15 steps to avoid confusion. If there are more than 15 steps, break the test into separate tests.
- In the test directions, include any additional documents or references that might be relevant to the test itself.
- Include a detailed description of the requirement being tested, and explain in detail how the test should be carried out for each requirement.
- Provide details on all the expected results, so the tester can compare the actual results against them. Of course, this step is unnecessary if the expected results are obvious.
- Use active case language when writing the steps, and make sure they are as simple and clear as possible.
- Avoid repeating any of the same steps, as this could add confusion to an already complicated process.
- Include the test name and ID in the testing instructions.
- Keep the end user in mind as you develop the test and its variables.
- Reread and peer review the test case instructions before finalizing them.
- Remember that the test case should be repeatable, traceable, and accurate.
Test Case Use Cases
You can leverage test cases for a variety of purposes: to gain insight into how processes are performing; to determine how software updates are being used; and to figure out how business trials or tests are progressing.
Some of the most common use cases for test cases include the following:
- Confirming login functionality on a username and password combination
- Checking to see how the login function reacts to a valid or invalid username or password
- Seeing what happens when someone inputs an empty response for either the username or password component
Numerous companies, such as HP Quality Center and Jira, use test cases to track and update their processes.
Improve Your Test Cases with Free Test Case Templates in Smartsheet
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
Источник
Время на прочтение
4 мин
Количество просмотров 46K
Всем привет, я руководитель отдела тестирования, и недавно по работе появилась задача на тестирование API. Для ее решения освоил новый для меня инструмент Postman и JavaScript.
Первоначально на каждый API я писал свои коллекции и готовил тестовые данные в JSON формате. Это достаточно удобно, но при большом количестве тестов и коллекций поддерживать это становится накладно. Да и проводить валидацию данных в JSON не удобно.
Для решения этих проблем я написал макрос для Excel и коллекцию в Postman. Теперь в Postman у меня одна коллекция на все API и стандартный набор функций для обработки входящих данных и валидации возвращаемых результатов. Мне удалось перенести управление тестовыми данными и последовательность выполнения запросов в Excel.
Что было
1. JSON с данными
Раньше тестовый набор хранился в таком виде
2. 2. Последовательность выполнения запросов с обработчиками на JS хранилась в коллекциях Postman.
Что стало
1. Тестовый набор переехал в Excel
Все данные вносятся в Excel (управляющие ключевые символы: R, H, I и т.д. распишу ниже) и дальше при помощи макроса перегоняются в json формат:
2. В Postman
Эксперимент проводил на стандартном наборе CRUD операций, который в дальнейшем можно расширять.
Так как в Postman все операций выполняются только в рамках запроса, пришлось ввести пустой get запрос в конце выполнения которого определяется следующий запрос из последовательности. Выполнить JS код до запроса и определить первый запрос без пустого не получилось.
Во всех запросах Pre-request script и Test секции пустые, весь код унифицирован для запросов и хранится в общих секциях Pre-request script и Test папки API Collection.
Во всех запросах важно обратить внимание на url и на секцию Body в запросах POST и PUT, их значения определяются переменными, значения в которые вносятся из JSON с данными.
Теперь о самих тестах
Как читать Excel. Первой не пустой строкой идет номер тест кейса, то есть тест кейс хранится вертикально и на этой странице 9 тест кейсов. В текущем наборе в каждом тест кейсе будут выполнены сначала POST запрос, потом Delete.
Как запустить генерацию Json из Excel. В Excel нажать F11 и перейти на «ЭтаКнига», там запустить макрос.
Ключевые слова
R – request, означает начало нового запроса, во второй ячейке строки хранится тип запроса, в третьей адрес, по которому надо обращаться. Обратите внимание, что в url можно указывать переменные Postman
Значение из переменной подтянется
H – Данные для сверки в заголовке, пока ввел только response code, в Postman зашита проверка только на него. Важно чтобы в Excel название было таким же «response code», либо поправить в Postman
I, I2 … – Секция входных данных, поддерживает хранение моделей данных любой вложенности, цифра справа от I отвечает за уровень вложенности. Следующий набор данных вот так завернется в JSON. Если переменная, которая хранит данные пустая, то она не добавится. То есть если в переменной inn не будет значения, то она не добавится, а переменная chief добавится, так как она хранит модель. При этом если вся модель пустая, то она также не добавится.
Данные этой секции будут поданы в теле запроса
O, O2 … — Секция выходных параметров, они будут сравнены с теми, что возвращает response. Как и секция Input поддерживает хранение моделей.
При сравнении данные конвертируются в string, еще я дополнительно ограничил уровень рекурсии, это можно убрать
PO – Postman Output, значения из этой секции будут по имени переменной браться из response body запроса и записываться в переменную Postman.
В Excel достаточно поставить любой символ, в переменную запишется значение из response, а не excel
Эта секция нужна, чтобы хранить данные между скриптами, например чтобы удалить объект с id, который был создан в предыдущем реквесте
PC – Postman command, ввел только одну команду “terminate”, она используется для принудительного обрывания после выполнения текущего запроса. Полезно при негативном тесте, чтобы не вызывать шаг с удалением созданного объекта.
Ввод этой команды позволил на одном листе хранить и позитивные и негативные тесты
PI – Postman Input, значения из этой секции будут записаны в переменные Postman перед определением url
Может быть полезным, если надо переопределить переменные, которые указаны в url запроса.
Кстати, в подаваемых данных можно использовать данные из Postman переменных, для этого требуется использовать специальную конструкцию
В кейсе 1 мы внесли полученное значение в переменную, в кейсе 2 его использовали. Можно использовать не только в следующем кейсе, но и в текущем при следующем запросе. Например может потребоваться, если определение объекта для изменения идет не по url, а по значению переменной в запросе.
Подготовка к прогону
А теперь прогон, запускаем Postman runner, в нем выбираем нужную коллекцию и подгружаем файл с тестовыми данными:
Подавать будем следующий набор:
Здесь описано 15 тестов, при этом шаги 1-11, 13, 15 положительные с результатом 200 при POST запросе и шаги 12, 14 негативные с результатом 400. По ним информация в базу не будет внесена и поэтому секция Output пустая, а также указана команда terminate. Эта команда прервет выполнение последовательности и запрос на удаление «Delete» отправлен не будет.
После кейсов 1-11, 13, 15 мы запоминаем id который присвоился новому объекту, чтобы потом его удалить.
Запускаем
Все 15 тестов прошли успешно, на картинке виден тест 14, в котором не вызывается Delete после POST
В тестах 1-11,13,15 после POST вызывается удаление созданного объекта:
Резюме
- Последовательность выполнения запросов для тестирования API вынесена в Excel и обрабатывается в Postman.
- Все тестовые данные также вынесены в Excel ими удобно управлять и валидировать их. По крайней мере удобней чем в JSON формате.
- Коллекция Postman стандартизирована и при тестировании схожих API не требует доработки.
Ссылки
- Репозиторий на GitHub, там лежит Excel и коллекция Postman
- При разработке использовался VBA-JSON инструмент за авторством Tim Hall
Update от 15.10.2019
1. Доработал возможность генерации json файлов без запуска excel, выложил в гит GenerateAll.cmd, который запускает vb скрипт GenerateJsonFiles.vbs. Вызванный скрипт пройдет по текущей папке и всем вложенным и сгенерирует json файлы
2. RunAll.cmd запускаем для прогона всех сгенерированных json файлов с данными, также пройдет текущую папку и все вложенные папки. Рядом с каждым из них положит output-report.log с результатами прогона.
Теперь прикрутить к CI не должно быть проблемой. Также можно прикрутить генерацию json к git deploy и проводить сравнение данных в excel по изменениях в json файлах.