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

retifax_test

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

87950461

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

by1945

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

bht2000

我顶12楼~~~~

h.guo

梦之精灵

我没有编写过测试用例,但通过跑测试用例,我觉得流程图不错,这样可以避免一些不必要的重复

Johnfu_test

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

Celery

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

zhangjinyan

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

liuhaibin

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

lijiepig

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

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

sword_zhu_1

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

huior

我的观点
http://www.51testing.com/?10851/ ... e_itemid_79249.html

derxuan

　　http://www.51testing.com/?180077/action_viewspace_itemid_79283.html

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

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

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

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

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

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

jaling

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

wldtzzming

写测试用例的前提还是要对需求有了解,对需求分析的越深,越透彻,就能写出更好的用例.
顶,以上师兄师姐的回答.

用户名密码

1.明确需求含义，确认测试要点
2.分清类别及主次关系
3.根据测试方法及测试技术编写用例，尽可能的覆盖
4.根据经验简化测试点，但实际测试过程中不能省略

wangxiang0823

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

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

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

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

jwj12402

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

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

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

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

jency_moon

我认为经验很重呀