howtowritebettertestcase资源-CSDN文库

design

test

需积分: 9 36 浏览量 2007-06-26 12:46:18 上传评论收藏 69KB PDF 举报

资源推荐

资源详情

资源评论

How to Write Better Test Cases

by Dianne L. Runnels, CQA, CSTE

Interim Technology Consulting

Investing in test cases

What is it worth to improve test cases? What risk would impel you to invest in better test cases? As long

as they cover the software requirements, isn't that good enough? The answer to these questions is that

poor test cases do indeed expose you to considerable risk. They may cover the requirements in theory,

but are hard to test and have ambiguous results. Better tests have more reliable results as well as

lowering costs in three categories:

1. Productivity - less time to write and maintain cases

2. Testability - less time to execute them

3. Scheduling reliability- better reliability in estimates

This paper describes how to avoid the losses that are inevitable with poor test cases. It will look under the

hood of different kinds of test cases and show where and how to build in the quality that controls risk. It

will give practical advice on how to improve productivity, usability, scheduling reliability, and asset

management. Once you understand the whats and whys of test cases, you can use a checklist of

standards, like the one attached as Appendix A, to identify areas of risk and improve your current and

future test cases.

The most extensive effort in preparing to test software is writing test cases. The incentive to build robust

test cases is spurred by the likelihood they will be reused for maintenance releases. Over half of all

software development is maintenance projects. How can you write quality test cases that will deliver

economical testing the first time plus live again as regression tests? Let's get started with the answer by

lifting the hood of a test case and looking at what's inside.

Looking inside test cases

Elements of test cases

For our purposes, a test case is a set of actions with expected results based on requirements for the

system. The case includes these elements:

• The purpose of the test or description of what requirement is being tested

• The method of how it will be tested

• The setup to test: version of application under test, hardware, software, operating system, data files,

security access, time of day, logical or physical date, prerequisites such as other tests, and any

another other setup information pertinent to the requirement(s) being tested

• Actions and expected results, or inputs and outputs

• Any proofs or attachments (optional)

These same elements need to be in test cases for every level of testing -- unit, integration, system, or

acceptance testing. They are valid for functional, performance, and usability testing. The "expected

results" standard does not apply to diagnostic or other testing of an exploratory nature. Even diagnostic

testing needs the other elements in its cases. However, if the test measures performance that should fall

in a range, this is an expected result.

An alternate description of test cases is that the description, purpose, and setup is the case or

specification. The steps to accomplish it are called a script. Yet another view calls the purpose or

description a scenario or use case. These views are all compatible with the quality assessments and

improvements suggested in this paper.

Quality of test cases

There is a misconception that quality of writing is subjective, like looking at a painting, where beauty is in

the eye of the beholder. In fact, quality of writing is objective and measurable. It is simple to set up an

objective checklist, like the one in Appendix A, of the structural elements of test cases -- purpose,

Dianne L. Runnels How to write better test cases Page 2 of 12

method, setup, inputs and outputs. Then walk though each case. Is the element there or not? In addition

to their structure, the cases must also meet these standards of quality:

Accurate. They test what their descriptions say they will test.

Economical. They have only the steps or fields needed for their purpose. They don't give a guided tour of

the software.

Repeatable, self standing. A test case is a controlled experiment. It should get the same results every

time no matter who tests it. If only the writer can test it and get the result, or If the test gets different

results for different testers, it needs more work in the setup or actions.

Appropriate. A test case has to be appropriate for the testers and environment. If it is theoretically sound

but requires skills that none of the testers have, it will sit on the shelf. Even if you know who is testing the

first time, you need to consider down the road -- maintenance and regression.

Traceable. You have to know what requirement the case is testing. It may meet all the other standards,

but if its result, pass or fail, doesn't matter, why bother?

Self cleaning. Picks up after itself. It returns the test environment to the pre-test state. For example, it

doesn't leave the test system set at the wrong date. Automated scripts may call other scripts to do this.

Don't confuse this standard with being destructive. Tests should be destructive, including trying to break a

simulated production environment in controlled, repeatable ways.

These standards are also objective and measurable. They could also be added to your checklist.

Someone who knows the requirements and application under test could fill out the checklist as part of a

peer review. Compliance with some of the standards can't be known until after testing, but they are all

measurable. This is an especially helpful exercise for new test writers to see where they consistently miss

one of the elements, or don't meet a standard.

Format of test cases

What does a test case look like? They seem to fall into three major groups: step-by-step, matrix, and

automated script. While the automated script will run as an online document, there is no assumption that

the other two must be paper-based. They, too, might be online. Let's look at each of the formats:

Step-by-step. Figure one shows what the basics of this format looks like. A complete view of this format,

in a template with other test elements is displayed as Appendix B.

Step Action Expected Result

1 Enter new name and address. Press <OK>. Displays screen 008 new name details.

2 Fill all blanks with natural data. Make screen

grab. Press <OK>.

Displays screen 005 maintenance.

3 Click on <Inquiry> button. Displays screen 009 inquiry details.

4 Enter name from screen grab. Press <OK>. Displays screen 010 record detail.

5 Compare record detail with screen grab. All details match exactly.

Figure 1 - Detail of step-by-step test case

Matrix or table. Figure two shows what the basics of this format looks like. A complete view of the format,

in a template with other test elements is displayed as Appendix C.

Date Hired

After 1/96

401K Life

Insurance

Payment

Computation

10/25/99 Y 1 3 $24.50

1/4/98 Y 3 1 $34.00

3/6/96 N 2 5 $48.00

8/15/96 Y 2 5 $86.25

8/15/96 N 2 5 $105.00

Figure 2 - Detail of matrix test case

Dianne L. Runnels How to write better test cases Page 3 of 12

Automated script. Figure three shows what this format looks like.

Figure 3 - Detail of automated script test case

Using test types

Best uses for each type of case

The most productive uses for step-by-step cases are:

Step-by-step

• One-off test cases, each one different

• Business scenario goes from screen to screen

• Many processing rules

• GUI interfaces

• Input and output hard to represent in a matrix

Step-by-step cases do not necessarily need to have a key press level of detail as shown in Figure 1. The

action steps can be at a higher level, such as: open "my account" page, search for transactions in a date

range, note the range: ______ , print report, forward report, and so forth.

Matrix. The most productive uses for matrix cases are:

• Many variations of filling out a form, same fields, different values, input files

• Same inputs, different platforms, browsers, configurations

• Character based screens

• Input and outputs best represented in a matrix

Nearly any test can be represented in a matrix, but the question to decide is whether a matrix is the best

way to test. It is most important that the matrix be supported by a description, setup, and how to record

results for the test. It may be obvious to the writer how to test the matrix, but without more guidance the

tester could flounder.

A variation of the matrix is a list of inputs. It can be inserted in a step-by-step test or stand as a matrix with

the explanatory elements of the test.

Automated scripts. A decision to use automated testing software is more related to the project and

organization doing the testing than to what is being tested. There are some technical issues that must be

met, varying from tool to tool, but most applications can find a technical fit. The project management must

understand that writing automated cases takes longer than manual tests because the manual tests must

be still be written first. When the interface is stable, then the tests can be recorded. The real payback of

automated testing comes in the maintenance phase of the software lifecycle. Then the scripts can be

executed repeatedly, even unattended, for great savings in testing time.

The management must provide someone to program in the tool language, such as C++ or Visual Basic.

Simple scripts can be recorded by most test analysts, but more powerful scripts, often utilizing custom

# Open the Fax Form

menu_select_item ("File;Fax Order...");

set_window("Fax Order");

# Retrieve the Fax Order information and compare it to data from the main window

edit_get_text("Arrival:", text);

if(main_data["arr_time"] != text)

{

failure_msg = arrival_fr_mismatch;

result = FAIL;

剩余11页未读，继续阅读

评论收藏

内容反馈

aotup

粉丝: 1
资源: 1

how to write better test case

最新资源

how to write better test case

how-to-write-test

how to write a better thesis - Wei Zhi.pdf

Learning ECMAScript 6(PACKT,2015)

Thoughtful Machine Learning with Python A Test-Driven Approach

Clean Code

Google C++ Style Guide(Google C++编程规范）高清PDF

微软内部资料-SQL性能优化2

VB编程资源大全（英文源码 数据库）

a project model for the FreeBSD Project.7z

一个跨平台的CString源码

BobBuilder_app

Java邮件开发Fundamentals of the JavaMail API

au3反编译源码

The Indispensable PC Hardware Book - rar - part1. (1/7)

i-vector的工具箱

四级英语真题

beginning_portable_shell_scripting_from_novice_to_professional.pdf

python3.6.5参考手册 chm

PHP基础教程 是一个比较有价值的PHP新手教程！

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

XCP协议的规范文档

VS2015安装证书，JavaScript_ProjectSystem.msi，JavaScript_LanguageService.msi

CANoe通过CAPL脚本实现自动测试

蓝牙BLE协议中文版.pdf

最新资源

VB编程资源大全（英文源码数据库）

PHP基础教程是一个比较有价值的PHP新手教程！

Qt 5实现串口调试助手（源工程文件、0积分下载）