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

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

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

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

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

[table=371][tr][td=4,1,371][align=center][font=宋体][size=2][color=#ff0000]获奖名单[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#0000ff]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]获奖名单[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]奖励[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]一等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]duola1119[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]当当购物卡50元[/color][/size][/font][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=1#pid937324][align=center][font=宋体][size=2][color=#000000]12#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][tr][td=1,2][align=center][font=宋体][size=2][color=#000000]二等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]huior[/color][/size][/font][/align][/td][td=1,2][align=center][font=宋体][size=2][color=#000000]300论坛积分[/color][/size][/font][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=2#pid939765][align=center][font=宋体][size=2][color=#000000]33#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]土土的豆豆[/color][/size][/font][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=3#pid940586][align=center][font=宋体][size=2][color=#000000]45#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][tr][td=1,3][align=center][font=宋体][size=2][color=#000000]三等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]清风随雨[/color][/size][/font][/align][/td][td=1,3][align=center][size=2][color=#000000][font=宋体]100论坛积分
[/font][/color][/size][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=3#pid940686][align=center][font=宋体][size=2][color=#000000]50#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]wangxiang0823[/color][/size][/font][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=2#pid940347][align=center][font=宋体][size=2][color=#000000]38#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]lan_7366[/color][/size][/font][/align][/td][td][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110874&page=1#pid937309][align=center][font=宋体][size=2][color=#000000]11#[/color][/size][/font][/align][align=center][/url][/color][/size][/font] [/align][/td][/tr][/table]

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

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

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

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

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

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

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

如何在有限的时间写出完整有效的设计文档，可能吗？

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

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

有限的时间写出最有效的用例

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

[quote]原帖由 [i]xuwh[/i] 于 2008-4-8 09:12 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=937249&ptid=110874][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
我最近也在写测试用例，现在还有很多疑惑，导致工作一直做的都不是很满意
我认为OA系统软件的测试用例大致分为两个方向，第一是工作流测试用例，第二是功能测试用例。
问题一：在设计测试用例时，每个页面都是增删 ... [/quote]

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

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

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

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

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

回复 12# 的帖子

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

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

哎,俺们都不算测试

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

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

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

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

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

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

熟悉业务，适当的方法

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

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

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

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

新手个人见解

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

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

我顶12楼~~~~:) :handshake

:)

回复 8# 的帖子

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

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

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

如何在有限时间内编写完整有效的测试用例

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

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

[quote]原帖由 [i]retifax_test[/i] 于 2008-4-9 00:22 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=938396&ptid=110874][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
有限时间内编写完整的测试用例?这好像是不可能的.编写有效的倒有可能.
因为流程安排不完善或者紧急情况导致的实现和测试总时间短好像是国内公司经常遇到的事情.
1.拿到软件就测不是完全无用,特别是对于一个很有经验 ... [/quote]

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

回答问题

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

我的观点
[url]http://www.51testing.com/?10851/action_viewspace_itemid_79249.html[/url]

　　[url=http://www.51testing.com/?180077/action_viewspace_itemid_79283.html]http://www.51testing.com/?180077/action_viewspace_itemid_79283.html[/url]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

回复 1# 的帖子

我认为经验很重呀