51Testing软件测试论坛

标题: 如何在有限的时间内编写完整有效的测试用例？（08-04-07）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-4-7 16:32
标题: 如何在有限的时间内编写完整有效的测试用例？（08-04-07）（获奖名单已公布）
在测试工作中，有一种直接拿到软件就测试的做法，它已经被大家认为是无效的测试，那么怎么分配时间来完成测试用例的编写，并且还要在有限的时间里？欢迎大家进行讨论与交流！

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

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

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

作者: smallsky 时间: 2008-4-7 16:46
沙发
我感觉应该是，写一份类似测试提问单一样的测试用例！这中用例只是提到应该测试的点！对于这个点必须是有一定的涵盖意义！

作者: luming 时间: 2008-4-7 17:02
有需求就对应需求写一个简略的测试用例，以后有时间再慢慢细化。

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

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

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

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

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

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

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

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

作者: lily_liuyun 时间: 2008-4-8 09:49

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

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

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

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

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

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

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

作者: rting 时间: 2008-4-8 16:20
看了，大家写的觉得自己好落后哦
我们都是产品出来了照着产品写测试用例呢
汗!

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

作者: xingyuwei 时间: 2008-4-8 17:17
目前国内大部分公司都是赶着写的，完全按照套路来的好像没几家吧

作者: lmy 时间: 2008-4-8 18:45
确定软件的功能点
根据功能点确定功能点的测试点
根据测试点写测试用例
就像一个树型结构细化
测试用例是测试的向导
时间紧的话也不用写得很详细吧

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

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

作者: 贱王之王 时间: 2008-4-8 19:43
写流程测试用例，比如这个模块的改变会影响其他模块的改变的测试用例，而简单的按钮啊，功能啊，不写

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

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

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

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

作者: 87950461 时间: 2008-4-9 12:00
标题: 新手个人见解
最近本人也一直在写用例,对这块也是感触良多。
在写过这么多用例后个人觉得编写用例相对比较快的方法可以这么做：
第一：根据需求文档和规约把该项目的功能点和流程做个比较详细的统计。要做的事情如下：
      1.了解产品的运行环境。
      2.了解产品的功能。
      3.了解产品的各个操作流程（常规操作流程以及非常规操作流程）。
第二：根据操作流程对功能点进行分布，确认好各个功能点在该流程中的影响范围和影响程度。要做的事情如下：
      1.详细了解流程中涉及到的功能点，分析它在流程的主导地位。
      2.详细了解功能点的数据操作范围以及各范围对流程的影响。
第三：找一个适合你的测试用例模版（个人觉得，模版没有最好的，只有更适合你的，如果你的模版用的顺手的话，写起来将会事半功倍）
第四：编写用例，根据第一、二步骤得到的相关信息，按照流程来编写用例，根据流程中各个功能点的操作组合来进行对各种情况测试，针对部分功能点需要单独详测的，则紧跟起流程之后或者之前追加用例。
第五：对测试用例进行检查，对遗漏项进行用例追加。（该步骤如前面两步做的好的话，出现遗漏现象可大大降低）
   以上是个人愚见，请各位前辈多多指教，小生在此先多谢指教的前辈！

作者: by1945 时间: 2008-4-9 13:30
我碰到这个情况的时候，就不写测试用例了，写一个测试要点，内容包括：
一。功能点（主要是增删改）：要求测试员有比较熟练的经验，因为这些东西都是相同的；
1.增
2.删
3.改
4.。。。。
二。业务点（需求点）
1.列出业务需求，针对一个需求点列出几点用例方法，不要求很细，只要求覆盖范围；
三。数据库：对应的表名；
完成功能点之后，重点开始业务点的设计，对于很关键很复杂的，就要设计测试路径，测试数据；通过的就备注一下，表示通过了，没有的就注明失败，以及失败的原因，然后提交bug；
我通常就在数据库分析器里面保存这个测试要点，如果是sqlserver就用sql分析器保存打开，如果是oracle，就用PLSQL 保存打开，方便随时查询数据，分析结果；

作者: bht2000 时间: 2008-4-9 14:56
我顶12楼~~~~

作者: h.guo 时间: 2008-4-9 15:09

作者: 梦之精灵 时间: 2008-4-9 15:11
标题: 回复 8# 的帖子
我没有编写过测试用例,但通过跑测试用例,我觉得流程图不错,这样可以避免一些不必要的重复

作者: Johnfu_test 时间: 2008-4-9 16:42
有限的时间内编写完整有效的测试用例，这个完整我想也不是100%覆盖，既然时间不够的话，就需要把测试点按照需求文档的要求来划分优先级，将优先级最高的测试用例写得很详细，优先级中等的测试用例稍微细化就可以了，优先级最低的只要列出测试点及其测试目标即可。

作者: Celery 时间: 2008-4-9 16:51
什么时候写测试用例呢? 开发工程师写完软件Spec之后,随即应进入编码过程.而在开发工程师进行初始编码的过程,就是软件测试工程师写测试用例的过程.当然如果开发工程师的初始版本已经放出,不论测试用例是否已经写完,都要首先进行测试.写的时候可以根据软件要求,按照功能划分为一个一个的模块. 每个模块写在一个文档里.
   怎么写呢? 写测试用例最好用一个Excel表, 主要可以包括以下几项: NO(唯一标记某个case), Item(指名是软件的哪个的模块下的小模块), test procedure, Expected result, Actual result, comment, tester & data.
   首先可以写软件的workflow. 这里主要写软件的工作流程, 保证软件最主要的功能实现. 设计时请注意工作流程中的每个环节. 这里还可以写综合case: 各个模块之间的调用, 互联关系等.
   然后就可以按照软件的功能划分一个一个的模块, 一个模块的一个模块的写. 写测试用例主要考虑的设计方法可以是等价类划分, 边界值, 因果图,和流程图法.
   当然测试用例不是写完就不动了,往往后面会有需求改动, 设计改动,这时候先前写的测试用力当然不能当作测试依据了,不过此时还要以测试为主, 等测试这个版本基本差不多了,开发工程师解提交上的bug的过程中,补充修改测试用例,
当然都是个人拙见, 仅是参考.

作者: zhangjinyan 时间: 2008-4-9 21:18
标题: 如何在有限时间内编写完整有效的测试用例
看了大家回答觉得都很不错，我有一个想法不知是否可行．
在有限的时间内编写完整有效的测试用例．
在进行测试时，我认为应该在计划中应定义预测试，如果通过了预测试，在看进度，如果进度紧张，就测试软件的基本功能，使软件的基本功能得到实现，让有效的功能模块全面覆盖，如果还有时间可以对软件功能的无效进行测试，并进行考虑它的异常情况．使它的基本功能得到全面的覆盖。

作者: liuhaibin 时间: 2008-4-9 22:59
通过对需求分析的了解，以及对整个系统的了解让，至于想要对整个系统方方面面测试的都很细致是不太可能而且还十分浪费时间，这就要对系统的主要功能编写测试用例进行测试，在有限的时间里做更多有效的测试用例！！！！

作者: lijiepig 时间: 2008-4-10 00:53

原帖由 retifax_test 于 2008-4-9 00:22 发表
有限时间内编写完整的测试用例?这好像是不可能的.编写有效的倒有可能.
因为流程安排不完善或者紧急情况导致的实现和测试总时间短好像是国内公司经常遇到的事情.
1.拿到软件就测不是完全无用,特别是对于一个很有经验 ...

比较同意这位兄弟的一些看法，换成我自己也是，如果现在时间紧，而人力又只有我一个，或者和我水平相当的组员，真的是可以考虑就直接开始测了，边测边做测试点的简要记录，一天下来，花半个小时总结一下是否有思路遗漏就可以了。

作者: sword_zhu_1 时间: 2008-4-10 11:58
标题: 回答问题
仔细分析被测对象的设计文档，给出被测内容的重要性（主要根据风险程度判断）。然后分析一下自己手头的测试工具和自己比较熟悉的测试方法。最后在看一下被测对象和以前所测的东西是否有可比性（一般多少都有一些）。根据以上内容，首先编写测试FRAMEWORK，安排好测试框架。然后就可以根据测试框架编写测试用例了。依据每一个测试用例的测试点不要太多、各个测试用例之间有一定相对独立性、被测数据量化的原则来编写测试。
最后如果测试框架设计的比较好，测试用例的编写应该比较顺手的，也可以保证在一定的时间里编写完。

作者: huior 时间: 2008-4-10 13:17
我的观点
http://www.51testing.com/?10851/ ... e_itemid_79249.html

作者: derxuan 时间: 2008-4-10 14:43
　　http://www.51testing.com/?180077/action_viewspace_itemid_79283.html

１、测试用例要根据测试大纲来编写

　　２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

　　３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

　　４、熟悉系统，对编写测试用例很有帮助。

　　５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

[ 本帖最后由 derxuan 于 2008-4-10 14:55 编辑 ]

作者: jaling 时间: 2008-4-10 16:15
对于一些不规范的公司，都是开发一个模块后，然后再让测试人员进行测试．有时候根本就没有写测试用例．都是临时发挥．
其实测试用例的编写一方面取决测试经验，另一方面就是对业务的熟悉程度．
如果这两方面满足了，再加上一点点技巧，测试用例的设计就省时省事了．

作者: wldtzzming 时间: 2008-4-10 18:00
写测试用例的前提还是要对需求有了解,对需求分析的越深,越透彻,就能写出更好的用例.
顶,以上师兄师姐的回答.

作者: 用户名密码 时间: 2008-4-10 21:26
1.明确需求含义，确认测试要点
2.分清类别及主次关系
3.根据测试方法及测试技术编写用例，尽可能的覆盖
4.根据经验简化测试点，但实际测试过程中不能省略

作者: wangxiang0823 时间: 2008-4-10 22:21
首先分析本周问题，如何在“有限”的时间内编写“完整”“有效”的测试用例
分析时间有限，并不是说没有时间，而是时间比较紧，问题是说，在时间比较紧的情况下写用例。
而写出的用例要求完整和有效，所谓完整应该是指覆盖率高，有效，这个就不用说了，大概就是不要写无用的测试用例。

对于这个问题的解答
首先，我们来谈论“完整”这一问题，如何能够写出完整的用例，自然是在对需求的全面分析之上的，我通常是写在测试方案之中。也就是说，完整的用例是建立在完整的分析，完整的测试方案的基础上的，如果时间真是紧到连方案都不完整，那么是没有办法保证测试用例完整的。

接下来，有了（比较）完整的方案，在接下来设计用例的时候是可能存在减少一些时间的。
比如，精简测试用例内容，可以简化到只有测试标题，当然你的测试标题需要是一个长句子，而不是一个词。当然这些用例内容后期需要补充。
再比如，减少界面的测试用例，说某某界面布局怎样怎样，某某按钮的激活与禁用，等等，这些用例可以节省，但是后期是要补充的，并且这些的分析已经体现在测试方案之中了。换句话来说，尽量减少无（多大）效（果）用例。

总结，基于以上
1、时间紧也要做好方案
2、只设计用例标题，已减少文档编写时间
3、减少界面用例，专心流程用例，以节省无效用例设计时间。

作者: jwj12402 时间: 2008-4-10 22:39
个人认为完整的测试用例是和需求、详细设计的完整程度息息相关，如果需求明确，设计详细，测试用例的设计者和设计人员进行充分的沟通把设计吃透，那么根据功能点一点点的完善测试用例不是难事。

当然中间需要一些技巧，如学会使用不同的测试方法，不停的查漏补缺，不同阶段的测试用例要有不同的侧重。
1.对于系统测试用例，根据系统设计将功能点划分，一个一个地完成，这个时候的用例即使做到全面覆盖系统设计，也会对功能有部分疏漏，需要在详细设计完成后再进行一些补充。系统测试用例的设计可能要更多地注重性能测试和其他一些测试（负载、压力、易用等），这些用例的完成就要一些经验和规范，根据规范来展开。
2.对于集成测试用例，需要对各个模块及相互之间的接口了解，并且根据集成的顺序完成用例，要尽量多的使用测试方法，还有不停的完善，常常会出现写着某个功能的用例时，忽然想到之前功能的用例可能遗漏了一些东西，要及时添加。
3.单元测试用例，这个比较难，主要侧重各种条件的覆盖，想要设计好单元测试用例，需要一定功底，我还没有这个水平，个人浅见，大方向还是功能和容错处理。

上面说的是需求明确的时候完成测试用例，在需求不明确，或者设计不完整的时候完成测试用例也是常遇到的事情，至少我经历过这些，这个流程其实是很不规范的，但是作为测试人员遇到这些情况还是要把能做的做到最好，这中间也需要一些方法：
1.首先要搭建出主要的框架，将你当前所知道的每个功能点先添加树中（使用测试工具）
2.对于能够了解的功能尽量细化，完成测试用例；对于目前不了解的功能可以适当的写一些，也许不完整，但是一定要把思路理出来（测试方法等），测试用例的完成其实很奇妙，不定什么时候就有什么样的想法，而且这些想法有时候是很不错的，所以一定要抓住。
3.有不少的项目是有继承性的，所以一些用例的设计是可以有预见性的。包括对于一些特定行业，即使设计没出来，也可以抓个大概，不用天天逼着设计，自己可以先做一些工作。

总之，对设计的详细理解，测试方法的熟练使用，不停的思考，不断完善查漏补缺，掌握好主次在有限时间内交出一份不错的测试用例是可以的。

作者: jency_moon 时间: 2008-4-10 22:50
标题: 回复 1# 的帖子
我认为经验很重呀

作者: gseraph 时间: 2008-4-11 00:57
我觉得，测试用例应该有模版，要按一定的要求进行规范化，这样可以提高效率。

作者: lhp0523 时间: 2008-4-11 09:20
说一说我的看法，在有限的时间不可能写出的测试用例能够覆盖到所有的测试需求，即使全部覆盖到了，测试用例的粒度也一定达不到要求。个人觉得，凡是系统，都可以根据需求划分为关键功能点和非关键功能点，对关键功能点，要罗列出一系列关键项，就每个关键项要仔细深度地设计用例；而对非关键项，只需测试一般的常规功能即可。也就是说，测试用例的设计，要根据功能使用的优先级和重要程度决定。

作者: amy@lee 时间: 2008-4-11 09:33
1、对需要测试的项目分为几个模块，并且编号
2、针对每一个模块明确验收内容，预置条件，操作过程，接收标准
3、最后得出结论

作者: kinghawk 时间: 2008-4-11 10:11
前面的大侠更多都已经说了很多，我就不再分析题目，直接进主题
1、软件已经出来，也就是功能已经明确，那么功能模块划分的问题应该可以解决，功能模块之间的耦合问题等不讨论，但原则是尽量低
2、之后，就是我们测试原则中的一条起重大作用的时候，八二原则，说白了就是抓重点，怎么抓，不是这个问题的讨论点
3、重点抓到了，后面就是常规测试方法的应用，对显式的测试点用等价类、边界值等方法，对隐式的测试点（比如逻辑关联性等）用错误猜测等方法，除非需要，这个时候，因果图、决策表之类的方法大家还是悠着点用。
4、如果可以，或者条件满足，能够使用工具的地方尽量使用工具（如果使用工具比直接人力测试的效率还要低，还是选中人力测试，这里需要衡量分析）
5、加班

作者: 土土的豆豆 时间: 2008-4-11 10:51
这个话题要拆分开来分析。
一、编写完整的测试用例
二、有效的测试用例
三、在有限的时间内
第一、个人认为，没有一个测试人员可以做到百分之百“完整”！何为“完整”？是测试路径覆盖率100%么？不是！即便覆盖了测试需求的全部功能，又如何保证100%的测试需求不变更、亦或满足了客户的需求呢？测试是保证软件产品的质量。而最“完整”的质量保障或者说测试覆盖，其实应该是满足了客户的当前需求。说白了，其他不是客户想要的质量，可以弱化点，要切入要点进行测试，从而在要害关卡编写测试用例。
第二、何为“有效”？是测试方法正确还是测试策略高深？不是！
1、是基本的测试规则。如同游戏一般需要定义规则，测试需要用标准规范来约束。没有良好的测试规则，恐怕难以称之为“有效”。我以为，从分析测试需求起，就可以同步建立测试模型/模式，开发有他们自己的模型/模式，测试当然也可以使用。譬如用UML来画流程图、活动图，理清测试步骤。或者用RUP的迭代测试，是否会比普通的模型要好些呢？
2、测试用例的根本是设计如何测试，不是测试什么。很多人仅简单把测试操作步骤记录在案，以为就是测试用例，那就错了。测试用例必须应用用例设计思路，保证其有效的结构性，可读性，渗透性。
3、依然是需求变更。倘若测试组无法从项目组及时获取到变更的信息，更有甚至连开发组织也没有对变更做出响应，那么用例肯定是无效的了。
4、测试用例必须进行交流评审。在开发组、测试组和项目总体组负责人员和相关分管岗位人员开会讨论后，最终拍板定案。
第三、时间限制。“有限时间内”这一说法，其实又得看具体情况。一周可以算有限时间，一天亦可以做有限时间结点。具体情况具体分析。通常的做法是：
1、测试管理。我们必须从测试管理机制上考虑，努力改善测试的环境，调整项目的管理流程，为有效的测试争取出时间。
2、工作效率。通过建立测试用例库来节省编写测试用例时间。现在都提倡复用的思想，不是仅代码可以复用、构件可以复用，公用测试用例的复用，可以极大程度，提高测试执行的效率。若把测试用例集应用于自动化工具中，这才是真正的会用工具，减少人工劳动力。
3、明确测试范围，严格按测试计划工作，利用有限的资源做有限的事情，使价值最大化。
4、规避风险。类似需求变更等是最大的风险，当然会影响工作效率，应该趁早定义清楚。

综上，要在有限的时间内编写完整有效的测试用例，所涉及到整个软件开发测试过程的方方面面，不是一两个知识点或者有些经验就可以定义的。而关键还是要明确需求，尽量减少需求变更，否则后续编写的用例，也只是做无功用罢了。

个人拙见，请指正。

作者: liuyan1 时间: 2008-4-11 11:04
标题: we
我是新手,可是我也写了很多用例,首先先写基本功能用例,然后在在基本功能用例上开拓就OK了!

作者: shhuangfy 时间: 2008-4-11 11:04
手上项目不紧时，一般是详细设计出来后，或是界面设计出来后就可以开用例
前段时间才根据界面详细设计写了用例，因为没有涉及太多业务，主体上流程用例不多
针对如add,modify,delete,search等共用功能点，我是把它们放在这个项目的公共用例中，在公共用例中把这些全写全，实际用例中调用就行
个人觉得并不是每个页面都重复写，除非有特殊情况。

作者: shhuangfy 时间: 2008-4-11 11:07
另外就是像界面详细设计，这个一般要求评审过后，也就是说这一块不会有大变化的情况下
要不然写的就全白费了
也就是在保证需要无大变化的情况下

作者: liuyan1 时间: 2008-4-11 11:27
标题: 回复 11# 的帖子
什么是业务流程?

作者: 清风随雨 时间: 2008-4-11 11:59
如何在有限的时间内编写完整有效的测试用例？
这是一个好问题,目前大多数中小型软件企业的测试部门都面临这样的问题.公司测试部门人力资源缺乏,同时又面临项目时间紧迫,项目质量又要求较高的问题.面对这样的项目,对我们测试部门来说,是一种严格的考验.这种考验,既是针对测试管理的考验又是针对测试方法和测试策略的考验.我个人认为,面临这样的问题,应从以下几个方面考虑应对方案.
1、首先是人的问题。当然指测试部门的负责人或者是该项目的测试负责人。一个项目的测试工作做的好坏，除了和测试技术和测试人员素质有关之外，关键是这个项目的负责人的态度。作为项目或部门的负责人，针对一个项目应该从项目的整体去把握该项目的测试深度、测试精度、测试工作重点划分、测试工作阶段重点划分、项目的重点模块指定、测试策略的制定等等。前提条件是考虑该项目的外置环境，包括时间资源、客户要求、项目精度要求、人力资源分配等。
2、其次是做好准备工作。个人认为，测试工作的计划性主要体现在对于测试的准备工作是否充分。包括针对需求管理的制定、测试关键路径的指定、测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。
3、最后是测试用例的编写。编写测试用例也有一定的原则。其一，尽可能的利用以往其他项目的测试用例，既测试用例的可重用性的体现；其二，将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改；其三，按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。
4、这点是我们公司现在正在使用的方法，不一定对，请大家给出评价。我们的测试工作在面临时间紧迫的时候，有时会压缩测试执行时间，并把压缩出来的时间用来编写测试用例。当然，有人会说这样测试执行的时间就不够了，测试就无法完成了。在这里我说明一下我的观点，测试工作的好坏起决定作用的是测试用例的质量高低，而不是测试执行阶段。因此，我们考虑扩充测试用例的编写阶段，同时调集技术支持以及办公室人员来执行测试用例。（因为测试计划中的测试执行是按照测试部成员来做的，我们这样做就可以把测试人员解放出来，调集更多的人手来做测试执行，因此，测试执行并没有被压缩，测试执行依然可以完成。）顺便说一下，BUG的提交还是测试人员来做，只不过测试人员提交BUG的依据变成对被调集人员的测试执行的BUG的重现而已。

作者: happybbh2008 时间: 2008-4-11 13:56
标题: "因地制宜"编写用例
测试用例编写要根据具体阶段和具体测试目标而定！如果软件开发很规范，按照软件工程要求在软件开发初期需求完成后就需要开始编写软件测试用例，当软件设计文档完成后，我们的用例也应该完成。这时测试用例的编写就可以根据软件文档和自己对软件的理解和软件有关的标准编写详尽，高覆盖率的测试用例。
以上说的状况是开发过程比较规范的情况，但大部分公司和项目的测试都存在时间不充足的状况，下面就不同状况具体分析：
1、根据测试任务所处的阶段：例如是针对某个已完成模块或功能进行单元测试阶段，还是系统测试、集成测试阶段或是回归测试阶段，根据不同测试阶段编写不同的测试用例。
2、根据测试任务的测试目标：所谓目标是本次测试需要达到什么样的测试结果。如整个软件达到可以正常使用，没有致命和严重的错误出现或是要求某个性能必需达到某个规范或是用户要求等。根据测试目标有针对性的编写测试用例。
如果出现阶段和目标都不明确，同时又要保证交付用户的质量，在有限的时间内要编写一个比较可行的测试用例那就需要像写开发中的概要设计那样：先划分测试模块，再详细列出测试模块中的测试项，然后尽可能比较全面的描写出每个测试项的测试点和每个测试点的预期结果。如果还有时间的化可以像写详细设计那样补充每个测试项的具体测试方法和步骤。
以上方法是我多年来在测试工作中的经验总结和体会，本次的问题也是很多公司的一种不规范的做法，还是希望软件公司能够尽可能规范的按照软件开发流程进行开发测试工作，为测试人员提供充足的时间了解产品并进行比较全面和深入的软件测试，真正有效的保证软件质量。

[ 本帖最后由 happybbh2008 于 2008-4-14 08:42 编辑 ]

作者: walker1020 时间: 2008-4-11 14:15
如何在有限的时间内编写完整有效的测试用例？我的经验是：
1，确定测试用例的优先级，首先编写优先级高的测试用例。这类的测试用例有：用户使用频率比较高的功能、客户比较关注的地方和对系统的性能、功能起重要影响作用的地方，还有一些关键路径等。作为一个系统，需要测试的地方有很多，在有限的时间内编写出所有的测试用例不太可能，也不现实。首先编写优先级高的测试用例可以起到事半功倍的效果。
2，对于一个系统的新Build的测试用例，对于那些没有发生变化的地方，我们可以借鉴以前的测试用例。这样我们只需编写新的功能测试、性能测试等需要的测试用例，同时修改那些发生了变化的用例。

[ 本帖最后由 walker1020 于 2008-4-11 14:17 编辑 ]

作者: 女孩 时间: 2008-4-11 14:39
有一年多没有做测试了，有以下几点愚见：
1、测试在需求阶段就介入，测试用例编写者必须对业务需求和产品需求的理解达到一定深度，然后完成测试用例初稿，即罗列出基本的测试点
2、详细设计出来后，补充测试用例，即细化测试用例的过程，当然细化程度得看时间上是否许可
3、具体测试开展后，还可以随时对测试用例进行补充

作者: hxc21st 时间: 2008-4-11 14:45
标题: 将用例划分模块再设计用例
（假定一个测试团队中测试工程师级别不一，用例撰写所需的文档已有，而且测试人员对模块的流程已掌握）
1、高级测试工程师根据特性文档划分模块并评估每个模块所需测试用例数，撰写用例时需用例的用例设计方法，然后评审；

2、高级、中级工程师定义测试用例模板、撰写每个模块的测试用例点（即不撰写测试步骤、预期结果、测试环境等，只写测试标题，定义测试级别），同时，初级工程师并行根据测试用例点展开测试用例撰写；

3、撰写完测试用例点后，高级、中级测试工程师开始着手撰写测试用例和评审测试用例。

PS：用例撰写是一个长期的、迭加的工作，需不定期更新、维护。

作者: sd17977827 时间: 2008-4-11 17:45

如果是我，在收到一个要求编写测试用例的工作要求后，首先通过和程序员沟通，了解尽可能多的程序执行逻辑，并制定出主干流程图，然后根据主干流程图对测试部分进行测试层次划分（主路径测试，烟雾测试，基本功能测试，详细功能测试），接着对需要测试的所有需求进行等价类划分（避免进行重复的测试），最后在流程图主干的基础上，按照测试层次设计出经过等价类划分的代表性功能点编写测试用例

偶是新人，么要笑偶

作者: testingFighter 时间: 2008-4-11 21:14
首先需要在有限的时间内尽量了解所要测试的软件规格以及使用场景，如果有详细的文档是最理想的；如果没有，那就需要和系统组、开发组相关人员进行确认，哪些功能点需要进行完备的测试，需要准备完备的测试用例，哪些功能点只需要基本功能可用就行了，是否需要做性能测试等；

然后，尽量在一个用例内实现功能点的多方面覆盖，比如：管理员的审批操作，我们可以测试管理员审批一个成员、两个成员或者多个成员的情况，而成员又可以申请不同的业务，有可能来自不同的地区，如果时间确实不够，我们可以这样设计用例：
管理员审批多个成员，每个成员来自不同的地区，而各自又申请了不同的业务，管理员审批，查看日志以及数据表检查测试结果是否符合预期

作者: apear 时间: 2008-4-14 10:01
q11111111

作者: corry 时间: 2008-4-14 17:00
标题: 我对写用例的建议
1、作需求分析，将测试的点总结出来
2、对集成部分要划逻辑流程图，标识接口信息
3、先设计功能测试用例
4、根据时间要求，编写ui测试用例或是编写ui标准文档来代替ui部分的测试用例
5、用例先执行功能测试用例，然后执行ui部分的测试

作者: zxloucy 时间: 2008-4-15 10:35
我经历了两家公司,都是按照CMMI 5流程管理项目的,关于写用例这一块,我觉得做产品软件和项目软件差别还是很大的.
按照规范流程,用例应该是在详细设计评审结束之后开始写,写完之后要进行同行评审才开始测试.
用例写完整很困难的,不过在同行评审过程中,对用例的完整和正确性,还是很重要的.
还有就是测试肯定要进行很多轮的,每一轮测试过程中,发现用例不完整的也可以补充.
针对需求变更,要及时更改用例,特别是产品软件,是长期测试的依据.

作者: zhangyundan123 时间: 2008-4-17 12:52
标题: 测试的开始
刚刚接触测试，感觉要学的真是不少啊！

作者: 无痕 时间: 2008-4-23 18:18
不错，，收藏先，再仔细看看，谢谢了

作者: lovemiya 时间: 2008-4-25 15:54
这个问题需要根据各个项目的时间来确定。
如果该项目的时间必须充裕的话应该严格地按照流程来操作，即
输入条件：Requirement & Function Spec经过评估，并且通过。
执行过程：根据Requirement & Function Spec绘制业务逻辑图，罗列测试点，参照测试点编写测试用例。
输入条件：项目小组相关成员对测试用例进行评估，并且通过。（基本条件是Requirement & Function Spec的100％的覆盖。）

如果项目的时间很紧张，则可以把正规的评估过程改为简单的走查，测试用例可以用业务逻辑图来替代。但是在一个项目周期结束之后，应该对测试用例进行整理，编写并备份入库！

另外，测试用例有一个关键地方就是测试用例的更新，因为在软件测试过程中经常使用同一个用例进行测试，软件会增加对该测试用例的”抗性“。因此，我们要对用例进行及时的更新，在一个项目周期结束之后，应该对测试用例的有效性进行评估，该评估准则是测试用例发现的BUG数量/BUG的总数量。对于用例没有发现的BUG应该添加到测试用例中，此外，用户提交的BUG是很宝贵的，也需要添加到测试用例中！

对了测试用例的管理应该纳入到项目的配置管理中！

以上是我个人的一点心得，和大家share一下！
各个公司，各个team的规定和文化的不同，流程也不一样，大家具体问题具体分析！

[ 本帖最后由 lovemiya 于 2008-4-25 16:24 编辑 ]

作者: centurystone 时间: 2008-5-3 17:17
标题: 回复 11# 的帖子
兄弟是不是华为的人啊。感觉和做过的华为项目很类似唉

作者: newlijia 时间: 2008-5-10 20:49
标题: 确定测试点
在有限的时间内写出完整的用例，是不可能的。但确定有效的和主要的测试点并且把用例写完整是可能的。
接下来的问题是如何确定测试点？
从几个方面考虑：软件将来由谁在用？
那些功能用户常用？
软件的卖点在那里？

作者: qixian 时间: 2008-6-5 15:02
标题: 回复 1# 的帖子
首先，得到该软件的需求及设计文档，理解该系统原理及功能。这实际上是熟悉系统，理解需求，找到测试的要点
其次，根据软件理解，选择恰当的测试方法，设计测试例
最后，根据测试中的理解的不断加深，增加测试用例，完善测试方法。

作者: apple煦 时间: 2008-6-8 02:26
标题: 回复 14# 的帖子
说人家落后，我看你们才是很落后呢……

作者: tangxiaoling 时间: 2008-7-30 17:37
呵,我们公司比较特别,我是根据功能规范来写测试用例的.公司根本没有需求文档,但在开发前会详细讨论功能点.形成功能规范.我就根据这个来写的.基本上是等产品开发出来,我用例早写好了,只需稍舟增,改一下,执行,结果就行了.

作者: jenvee 时间: 2009-2-13 19:29
标题: ding
zhchi

作者: 不是我，是风 时间: 2009-3-10 17:13
标题: 现实是残酷的
并不是每个公司都会给你让你满意的需求规格说明书，同时也不一定有什么check list之类得东东，举个例子，华为的手机项目测试用例是根据UI给的MMI 图来写的。所谓的MMI图其实就是一个界面布局图。上面有很少的功能描述，这些功能描述也只限于对个别不明确或是有特殊定制的功能作出的解释。
那我就有问题了，这样的情况下你如何快速，简捷，全面地挖掘这款手机的功能点？而且类似于这样的界面布局图后期变更的可能性很大。我的方法是根据MMI图画出每个模块的功能树，分出父节点和子节点。让功能点以树的形势节节细化，并且在下层的叶子节点输出用例。如果有更改就去相应模块功能树中修改，并同时修改该节点的用例。

作者: liuyanerfly 时间: 2009-3-13 17:17

原帖由 土土的豆豆 于 2008-4-11 10:51 发表
这个话题要拆分开来分析。
一、编写完整的测试用例
二、有效的测试用例
三、在有限的时间内
第一、个人认为，没有一个测试人员可以做到百分之百“完整”！何为“完整”？是测试路径覆盖率100%么？不是！即便覆盖 ...

请教“用例设计思路”？谢谢！

作者: sobani.iteyo 时间: 2009-5-28 11:51
标题: 回复 13# 的帖子
测试工作的开展最终依据的是需求，测试用例最终还是要追溯需求，根据需求写测试用例~~~
如果没有测试用例，这个测试工作该如何开展？？？
能够保证测试符合需求吗？

作者: sobani.iteyo 时间: 2009-5-28 11:55
标题: 回复 14# 的帖子
应该有这个理念，测试应及早介入；

作者: 快乐的布丁 时间: 2009-6-25 17:42
没有我啊

作者: 十期学员 时间: 2009-10-8 22:08
终于看完了每个回复，获益匪浅，谢谢各位！

作者: mklodoss 时间: 2009-10-9 14:33
学习。。。。。

作者: 8596991 时间: 2010-5-16 17:54
测试用例是否完整有效，就是看在现有的条件下，现有的需求下，能够在有限的时候之类，最大限度的解决需要解决的问题。说测试覆盖率达到100%，那是不可能的事情，只能说是最大限度的趋近完美

作者: syq8050 时间: 2010-5-22 17:24
现在面临的测试需求还没出来就单独拿个类似的产品来写测试用例确实很郁闷，对与用例100%覆盖的问题不知道有没有什么好的建议？

作者: syq8050 时间: 2010-5-22 17:24
有什么好的办法来判断用例的覆盖率呢？？

作者: syq8050 时间: 2010-5-22 17:27
标题: 回复 69# 的帖子
是的，这样的问题也是我现在面临的，写再详细的用例，功能改了岂不要大动干戈啊

作者: lmm123210 时间: 2012-1-4 17:41
回复 15# shark097

俺也是跟你一样啊

作者: blueskylcc 时间: 2012-1-12 10:40
回复 12# duola1119

说的真好，学习了。

作者: syab23ok 时间: 2012-3-5 15:55
个人觉得可以将共通的、或者是一些定性的测试用例自己写个生成工具生成下，由于时间有限，将主要的时间用在编写业务流程，特殊业务制约等用例上面。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)