How to write better Test Cases

上一篇 / 下一篇  2008-09-08 13:38:04 / 个人分类:读书笔记

How to write better Test Cases

by Dianne L. Runnels

Investing in test cases

好的case包括三项:

 1. Productivity - less time to write and maintain cases

2. Testability - less time to execute them

3. Scheduling reliability- better reliability in estimates

1. Productivity-书写和维护需要较少的时间

2. Testability-执行test cases需要较少的时间

3. Scheduling reliability-评估时可靠性更高。

Looking inside test cases

Cases包括的元素:

1.    测试的目的或是描述出哪个需求被测试到;

2.    测试方法;

3.    测试步骤:应用程序的版本号,硬件,软件,操作系统,数据文件,安全接入,时间,逻辑或物理数据,及其他测试的前提提条件和设备相关的建立信息;

4.    期望结果,输入或暑促;

5.    附件(可选).

 

Quality of test cases:

case的质量是客观并可测量的。建立客观的checklist很简单。Cases必须要满足的质量标准:

Accurate:根据case的描述测试。

 

Economical:只是描述测试目的相关的步骤,不给出软件使用的向导。

 

Repeatable, self standing:测试的每一条case,无论测试时间和测试者的结果都是一样的。如果一条case不同的测试人员得出不同的测试结果,就需要在case的建立和步骤上多做些工作,看case是否写得准确。

 

Appropriate:考虑case执行的测试者和测试环境的可实施性。如果理论上要求的技术测试者不具备,case就需要搁置。

 

Self cleaning:能够回到测试之前的测试环境。

 

Using test types

Best uses for each type of case

Step-by-step

一步的用例,每步都不同;

业务场景变化频繁;

许多处理的规则;

GUI接口;

输入和输出很难表现在matrix上。

 

Matrix

有许多变量去填表格,相同的域,不同的值,输入文件;

相同的输入,不同的平台,浏览器,配置;

Character based screens;

输入和输出能够很好的表现在matrix上。

Choosing a test type

 

错误观念一:Step-by-step test cases需要花费很多时间,承担不起。

Reality:也不全需要很多时间写cases细的颗粒度让cases更强健,维护更简单,如需要充分详尽测试某些功能,就要采用step-by-step test cases

 

错误观念二:Matrix是最好的选择。

RealityMatrix上必须有配置的信息,经常这些信息被遗漏,如果是不同的配置和种类,很难放到matrix上。

 

错误观念三:高技术就是最好的,如果能实用自动化,就用。

Reality:使用自动测试由好多因素决定。

 

错误观念四:没有时间写手动的test cases,就采用自动测试。

Reality:自动测试的用例要比两外两种的用例花费更长的时间。

Improving test cases

Improving testability of test cases

Testability的定义就是准确的容易测试,容易的程度可以用执行测试的时间长短来度量,准确是指按照测试步骤执行,测试通过和不过的结果是正确的。

Improving testability with language

写测试用例要实用主动语态,告诉测试人员要做什么;

An easy habit to fall into if we know a subject inside and out is to refer to the same thing in different ways.

Testing can be accelerated if you build in structured fields for the tester to note inputs that will be verified later.

Improving testability by controlling length

Step-by-step的用例的最佳长度是10-15个步,用例简短有以下几个好处:

测试每步花较短的时间;

测试人员不易犯错,或不知道如果执行而需要帮助;

测试精力能准确估计测试需要的时间;

测试结果更容易追踪。

Matrix的最贱长度是执行差不多20分钟的时间。

自动测试脚本的问题不是长度的问题,而是内容,维护和缺陷追踪的管理问题,业务场景或用例是否充分,是否可以载入不同数据可变量组合执行多次。

Pros and cons of cumulative cases

Cumulative cases是指那些依赖于以前casecase。我们的目标是尽量保证每条测试用例的独立性,这个对时间安排测试很灵活,并且能减少维护时间,但是,弊端局势和其它的一些标准违背,比如保持case的简短,并且不重复。

Improving productivity with templates

Improving productivity with clones

Improving productivity with clones

Mistakes and challenges

The seven most common test case mistakes

1. Making cases too long

2. Incomplete, incorrect, or incoherent setup

3. Leaving out a step

4. Naming fields that changed or no longer exist

5. Unclear whether tester or system does action

6. Unclear what is a pass or fail result

7. Failure to clean up

1.Case太长;

2.Setup信息不完整,不正确;

3.遗留了某个测试步骤;

4.对改变的或是不存在的域命名;

5.不清楚测试者或系统是否可以执行测试步骤;

6.不清楚通过与否的结果是什么;

7.不能回复到测试之前。

 


TAG: 读书笔记

 

评分:0

我来说两句

我的栏目

日历

« 2024-04-17  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 37699
  • 日志数: 56
  • 建立时间: 2007-09-12
  • 更新时间: 2009-03-12

RSS订阅

Open Toolbar