如何在有限的时间内编写完整有效的测试用例？（08-04-07）（获奖名单已公布）

51testing

在测试工作中，有一种直接拿到软件就测试的做法，它已经被大家认为是无效的测试，那么怎么分配时间来完成测试用例的编写，并且还要在有限的时间里？欢迎大家进行讨论与交流！

问题征集：“每周一问”活动面向广大会员征集问题，如你有什么问题想提出来和大家一起讨论，请发邮件至:webmaster#51testing.com(请将#改为@)，说不定下期讨论的问题就是由你提出的哦，请快快参与吧！问题模式请参考每期的问题形式，包括“问题的题目”和“问题的描述”。

非常感谢各位会员积极参与，截止至4月11日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	duola1119	当当购物卡50元	12#
二等奖	huior	300论坛积分	33#
	土土的豆豆		45#
三等奖	清风随雨	100论坛积分	50#
	wangxiang0823		38#
	lan_7366		11#

smallsky

沙发
我感觉应该是，写一份类似测试提问单一样的测试用例！这中用例只是提到应该测试的点！对于这个点必须是有一定的涵盖意义！

luming

有需求就对应需求写一个简略的测试用例，以后有时间再慢慢细化。

其实我一向认为，测试用例应该从check list开始，因为很多的东西其实都是很公共的，比如增、删、改、查，这些用了，下次大部分还是这些东西，只是对应在具体的项目里面而已。这样就可以有一个公共的用例库，需要的时候，直接代入，这样其实大部分的基础性用例已经出来了。

真正需要测试人员思考的，更多应该是流程、接口、数据等部分，这些都可以随着对文档和软件不停的熟悉了解而加深用例的适应程度。

换句话，测试用例是一个逐步细化的过程，开始的时候，可以粗糙，可以套用，有时间就不停的展开，没有时间就按照最开始的test list测试也没有什么不可以的。

上面仅仅是个人的一些看法。

sxyu

最近才开始比较系统的接触测试,但是最近一直都在写用例,感触挺深的.
由于系统很大,但是写下来的过程中,自己和同事都发现一直在做重复工作.比如每一张表都会有增、删、改这类的操作，每张表都写一次，浪费太多的时间。最后我们总结了两条：
一、先整理测试需求
    整理测试需求其实只是将软需换种方式来表述。软需中一般描述的都是一个流程或是一个操作过程，而我们的测试点都是从其中支离出来。先整理测试需求其实就是先写出某个操作过程中需要考虑的测试点。这样的好处是产品经理可以直接看我们的测试需求，如果对需求理解有误，写出来的用例肯定也是错误的，自然也就业没有了查看的意义。同样这样做，对以后的测试结果有一定的指导意义，测试出现争议的部份，也许在需求中就是体现。
二、抽取测试模版
    由于有很多的重复操作，例如表单的增、删、改，可能不同的只是每张表的字段要求不同，尽可能的将同样的操作写成用例模版，方便以后调用。不过这方面现在本人也遇到很多困难，不知道应该如何抽取共同操作组建模版才会更好。因为模版太范会使测试的覆盖率减低，但模版写的太细，就会调用变的复杂，不利于今后的用例维护等其它操作。
望各位指点迷津！

watcher001

分析软件需求 并不断细化为每个测试点
然后根据测试点的多少和时间的多少分配计划
然后按软件测试计划一步步实施设计，执行，分析测试报告等

调皮精灵

不知道大家有没有听过一种说法，就是说向做开发一样的做测试，首先拿到一篇设计文档，所以从测试的角度就进行分快，对每块抽取测试点。。对每个测试点进行输入输出的抽取，再采取一些常用的设计方法，比如说正交分析，边界值等方法，如果确实是时间比较紧，则可以分大的功能模块，每个模块的测试点，及其每个测试点的相关输入输出组合，可以使用EXCEL表格进行分析。另外就是公司应该对一些常用的设计方法进行自动化。对于后来的测试人员只要分析出那些常用测试设计方法的输入即可。
。另外分析常用的测试逻辑进行固化。。以后还碰到这种类似的话，直接可以参考，只需要改具体的内容即可，姑且可以等同与开发的组件化。

xuwh

我最近也在写测试用例，现在还有很多疑惑，导致工作一直做的都不是很满意
我认为OA系统软件的测试用例大致分为两个方向，第一是工作流测试用例，第二是功能测试用例。
问题一：在设计测试用例时，每个页面都是增删改查和导出，剩下的就是页面连接了。所以用例的书写显的就没什么意义了。
问题二：流程的测试用例，有一个流程图就完全足够了，就更没有必要写用例了，更何况流程测试的用例是不可复用的
那位老师能帮我解决一下上面的两个问题？

lily_liuyun

原帖由 xuwh 于 2008-4-8 09:12 发表
我最近也在写测试用例，现在还有很多疑惑，导致工作一直做的都不是很满意
我认为OA系统软件的测试用例大致分为两个方向，第一是工作流测试用例，第二是功能测试用例。
问题一：在设计测试用例时，每个页面都是增删 ...

没做过OA系统的测试，不过对于测试来说，应该有很多思想是相通的吧。说说我的理解吧。
关于问题一，简单的看确实只是增、删、查、改，但是任何的增、删、查、改肯定有很多业务上的约束条件，这个才应该是我们主要测试的内容吧？
关于问题二，流程图应该只是用例的一部分，实际编写用例的时候，还有前置条件，输入数据等等很多的的说明；如果把这些也画在了流程图里，那么其实这个流程图就是一份测试用例了，只是换了一种表现方式。

abens0426

如果要有限的时间内编写完整有效的测试用例
1）首先就要先具备丰富的测试用例编写经验
2）将一些公用的测试用例在这之前先写好，如Add/Delete/Edit/View等用例。再针对具体的测试对象进行适当的修改
3）针对软件需求进行测试需求的细化和提取，如果没有具体的需求文档，那只能够凭以往经验来提取测试需求了。每个测试需求点都要有对应的测试用例，覆盖正反面和异常面
4）编写完测试用例，进行简单的同行评审，保证全面性和完整性

lan_7366

前段时间我也写了一个项目的测试用例，我们面临的问题就是：时间紧。任务重。最郁闷的问题是，需求还没有正式定下来。等到代码提交开始测试的时侯，需求已经变动很大。导致我们的用例没有什么参考意义。对此我是感触颇深。下面谈一下我的认识：（不足之处多多指教）
第一，我个人觉得一个项目的核心主旨就是业务流程。只要业务流程弄明白了。界面的问题好解决。所以，时间比较紧张的情况下，首先把主要流程写清楚，每一个流程分支都走一遍。以便后来进入项目的同事，结合需求说明书和用例便能更快的进入到项目中来。
第二，还有就是那些公共的测试用例。比如：超链接测试、表的增删改查测试。系统登陆退出测试，等等。每个项目都会用到这些测试用例。不用每个项目都写。只要写好共性的用例。其他项目调用即可。

我个人认为，依目前国内的测试行业的情况来看，在国内一些中小企业，编写测试用例并不是一个必要的环节。测试用例的完整性和有效性在于它的指导意义。时间有限就把关键业务点写清楚。以后有时间再进一步细化。当然对于大公司来说，测试用例这个环节必不可少。但是大公司的公共测试用例早已经有了模版，我个人觉得还是业务流程最重要。呵呵。

duola1119

楼主的问题看来只有一句话，但实际包含了很多方面的问题，不同的人文环境、公司文化、公司资质等因素都会产生不同的结果。
分析这个问题，我想先从两个方面回答：
1.如何在有限的时间内完成测试用例
2.如何编写完整有效的测试用例
有限的时间顾名思义工时不足。那么凡事都是有果必有因，解决问题就要先找到其原因，并加以解决，问题就会迎刃而解。
在软件行业中，时间是一个非常重要的概念，时间有限也是经常提到的一个词，归其产生原因不外乎以下几点：
1.项目经理缺乏项目管理经验，对项目工期估计不准确，导致工时吃紧，时间有限。
2.项目开发人员（包括测试小组人员）缺乏实际工作经验或者说知识匮乏，相比之下不能在相等的时间内完成自己的任务，导致时间有限。
3.项目开发周期已经确定，但由于客户的临时需求变更导致的工作量增大，无法继续在规定的时间内完成任务，导致时间有限。
4.社会关系导致的公司内部人员拉帮结派，出现的争功躲弊的人群在有权利条件的基础上为夺取管理阶层对自己的好感，谎报项目的开发周期，致使承诺的工时远远低于实际工时，导致时间有限。
5.其他原因（事假、病假、人员变动、突发事件等）而导致的项目人力资源不足，时间有限。
用CMMI的理念讲以上这些原因就是风险，针对这些风险，就要采用风险识别，风险评估，风险减缓，风险跟踪将问题扼杀在萌芽中。
第一，根据风险检查表，识别出项目的风险（时间不足）
第二，估计风险严重性、风险可能性、风险系数（以上列举的5条分别进行评估）
第三，对于风险系数超过“容许值”的每一个风险，都应采取减缓措施（量化风险的严重性，定义容许值）
第四，跟踪风险减缓过程，记录风险的状态
第五，制定风险解决方案
1.项目经理需提高系统分析能力，增加自身技能水平，提高预测准确度。必要时可以更换。
2.提高工作人员自身技能水平，评估其工作能力，定期考核，安排适当人群执行适当工作。公司提拔的不算。
3.严格控制需求变更，制定需求变更管理，需求发生变更要经过会议评审，必要时员工需加班工作。
4.社会关系复杂，如果想被提拔，升职或加薪那就乖乖的加班工作。
5.减少工作对单人的依赖，保证每份任务必须由两人或两人以上负责，突发事件另作处理。
虽然回答没有针对如何在有限时间内编写测试用例，但以上答案完全可以解决这个问题了。
回答了第一个问题，下面回答第二个问题。说一下怎么样设计完整有效的测试用例
第一，覆盖率100%，保证完整性
第二，对测试环境，用户环境，模拟用户环境，及之间的差别进行描述。
第三，设计场景测试法虚拟业务流程
第四，建立测试公共数据，并根据系统内部关系组织数据的关联性
第五，其他人可以看懂你的用例，并且是可以执行的
第六，如果有标准的用例模板，可以使用用例模板
现在将这两个问题合二为一，不同的问题可以根据给出的答案互相结合找出解决问题的办法。
但是根据我的经验，一般编写测试用例的时间都是很充足的，除非是某些项目为了应付监理公司，临时对项目的相关资料进行补充的时候才会出现这种情况。

yl.victory

就我先在的工作环境来讲，写测试用例也都是产品都已经出来的时候赶时间写，这样就造成了一边要测产品一边还要些测试用例的堵塞现象，分析一下轻重缓急的话肯定是先测产品重要，所以就在测试产品之前先列一个表单，分有效测试、无效测试、边界测试、压力测试四类，就像小学写作文先列一个提纲一样，等产品的第一个版本测试一遍之后，再进行测试用例的细化；
测试用例的目的是强化我们的测试，以免遗漏一些细节的东西，因此还是不能因为写测试用例耽误测试产品

rting

看了，大家写的觉得自己好落后哦
我们都是产品出来了照着产品写测试用例呢
汗!

shark097

看了大家写的,感觉俺们都不算测试,因为俺们是程序员做出来一点认为可以测的,俺们就先测着.然后有问题他再改,改完俺们再测....
本人认为先列一下需要测试的内容,然后针对性的测试,比如超长录入,特殊数据录入之类的有没有处理好等等,这部分完成之后再随便浏览性的测试,看看界面什么的,这个过程中很可能发现一些数据处理上的问题哦~
因为俺们公司没几个人测试的,而且基本都是临时性的,所以需要测的时候要么是我自己一个人,要么是别人测半天了让我再看看,让我带人测的时候嘛,兄弟俺都是用说的,告诉他们测哪些内容,然后就测,需要考虑多用户时再大家一起测.以前的程序根本没考虑什么压力测试,因为同时用的人不会很多,,现在公司又要做个WEB查询的程序,可能挺多人一起用,结果需要进行压力测试,俺看了半天也没弄明白那些工具怎么用,没办法,俺早就把编程忘差不多了.
不好意思跑这来诉苦了,大家鄙视我吧,让鄙视来得更猛烈些吧.

xingyuwei

目前国内大部分公司都是赶着写的，完全按照套路来的好像没几家吧

lmy

确定软件的功能点
根据功能点确定功能点的测试点
根据测试点写测试用例
就像一个树型结构细化
测试用例是测试的向导
时间紧的话也不用写得很详细吧

个人的理解，因为没有经历过一个项目完后才进行测试，测试和开发是同时进行的，不足之处请多多指教
谢谢

39033261

个人感觉，根本就不可能有完整的测试用例.
在有限的时间里，只能尽可能的分析当前的需求，优先整理出用户最频繁的操作。
在操作的过程中设置测试点。

贱王之王

写流程测试用例，比如这个模块的改变会影响其他模块的改变的测试用例，而简单的按钮啊，功能啊，不写

modyzhou

我要说的就这两方面
1.熟悉业务，我想这个大家都应该知道，但是说句实话，没几个人是真的做到位的，我来公司就是的，别说用例覆盖到不到，就是用例编码都还犯错呢，那个时候我就开始设计用例了，导致的结果就是覆盖覆盖不行，规范规范没起作用，有时连语句都让人读不懂。
究其原因其中当然有我是初次写用例了，但是更多的实际上应该归罪于我对业务的不熟练，考虑问题考虑的不够全面，做用例只能说是一步一步的来，但是却是跳着来的，左一下右一下的，最后导致用例的设计文档写了12次，可是每次都是改了很多。所以先要了解熟悉业务，它是很耗时间，但是当你没有熟悉业务的时候反倒花更多的时间去完善，得不偿失。
2.适当的方法，开始的时候设计用例是纯手工的，想到那是那，想到一种可能就是一种可能，导致用例设计多次更改不说，最最危险的是覆盖不到位，实际上每种方法也都是有这各种缺陷的，也就是每种方法都不可能达到100%的覆盖率，甚至有的方法覆盖率很低，但是方法的好处不是去覆盖，而是让你可以在一种方式或是方面内做到全面，这就少了很多波折了。

-----------------------------------我的回答不求全面，但求自己的亲身感难受！！！

[ 本帖最后由 modyzhou 于 2008-4-10 18:46 编辑 ]

retifax_test

有限时间内编写完整的测试用例?这好像是不可能的.编写有效的倒有可能.
因为流程安排不完善或者紧急情况导致的实现和测试总时间短好像是国内公司经常遇到的事情.
1.拿到软件就测不是完全无用,特别是对于一个很有经验的测试人员来说,往往在这样的测试中就可以发现大量的问题
2.针对需求理清思路,整理相应的测试功能点和测试风险点
3.注意精力主要放在功能主干或容易出问题的部分,即在测试中要把精力放在重点上
4.做好测试计划,按计划执行,不要做无头苍蝇
5.用例和测试方法不是非要形成文档不可,在心里构建测试框架,设计测试用例和方法,也可以边测试边针对功能点进行思考.但这只针对时间紧的情况,毕竟在这种情况下想做到充分测试是不现实的.
6.如同第一点所说,在测试时间紧的情况下,对业务积累和测试技术的经验在这时非常重要
7.通用测试用例的建立是在平时工作中需要被注意的