[你问我来答第20期]：如何编写好的测试用例？(已结束)

霸王别妖

能不能不回复用引用啊，看到了回复就得上前面看问的内容。
我还在上学，正好有软件测试这门课，我想知道我们有没有必要去深究一下？毕竟多余时间可以用来练习其他代码

zbl0531

庄家也不回答俺的问题，伤心了，走了

楠族开心果

回复 103# zbl0531


    十分的抱歉，最近事情挺多。所以回答的速度比较慢。问题我都会在这月回答的，放心吧

baby-julie

我现在在通信行业公司中做测试，涉及到手机终端软件例如米聊，飞信这种软件的测试，还有类似于淘宝这种电子商务网站的测试，我想请教专家一下问题：
1、对于米聊，飞信这种软件如何设计好的测试用例才能保证没有功能遗漏，这种软件如何做性能方面的测试？
2、对于类似于手机版淘宝这种软件，它拥有客户端，服务器端还有一个后台管理系统类似于进销存管理系统，我如何设计测试用例才能保证功能的完全覆盖？他们之间的交互如何设计测试用例？
谢谢

妖娆小妖

刚刚加入黑盒测试的行列，测试计划和测试用例应该怎么部署？测试用例是不是就是自己在测试过程中用到的实例或步骤呢？

月上百合

记不得多久没来论坛了，在首页上一眼看出来个熟悉的影子，就被吸引进来了，给我们庄姐捧捧场。

楠族开心果

回复 25# 德尔惠

黑盒测试前途？
    黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的

德尔惠

其实自动化测试就是用一个软件去测试另一个软件，编写脚本的时候也就是在开发一个软件的过程。回复 108# 楠族开心果

楠族开心果

回复 28# woainini

问,在测试资源不足的前提下, 是否可以用 粗颗粒度的用例+测试人员跑场景流程过程的中的经验 来取代大量的用例?
(例如: 用例只有一个,但是跑的过程中利用测试者的观察力与经验,顺带的间接检查其他功能点.)

测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。

测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”

如果外部环境参数较多，并且互相矛盾，比如团队新手多，但测试项目对质量要求很高，并且项目周期短时，如何构建测试用例的颗粒度，就更需要测试管理人员的平衡。

楠族开心果

回复 30# jimao
对于产品的测试，每次更新版本的功能都不一样，而每次都要进行旧功能的测试，怕新增加的功能影响到周边的功能，这样怎样设计用例更加全面咧。。。

这是最常见的形式。可以分成新功能测试和老功能回归两块。新功能测试不讲了，你也清楚，老功能回归这块需要一个回归测试，视测试自动化的程度来定，自动化程度低，那就需要制定详细的回归策略，和开发讨论清楚新增、修改功能的影响范围，来定回归测试用例；自动化程度高的，那就直接全面回归就行了。

楠族开心果

什么样的用例才是好的用例呢？
Olivia_keke 发表于 2012-3-2 22:38

我觉得做好以下三点就是一个好的用例。
    第一：依据分明
    众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。
    假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么ok，我们就要写5000以上个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。
    第二：目的明确
    用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。
    第三：便于统计
    测试用例对整个测试过程的质量控制和评估有很重要的意义。
    一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。
    二，做用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多。那么你做的用例成功率还有什么意义？
    你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。
    三，做缺陷分析。用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候，这几个测试点也有回归，有些可能与缺陷毫无关系的测试点，都被你回归了。

楠族开心果

请教一下:

1)易用性的测试用例在编写有什么技巧?从网上看过类似的易用性用例,但是感觉这方面的用例写得太 ...
marysnow 发表于 2012-3-3 14:08

易用性用例涉及的测试点通常都未在需求文档中明确定义。但由于其本身与普通的功能/UI用例的结构没有明显区别。故较为常见的两种处理方法如下：
A．在设计用例阶段，将此部分用例标记并在用例评审中进行讨论和澄清。确认其用例预计输出后，再将其放入相应的功能/UI用例组中
B．在测试执行阶段，出现此类用例时，tester与RD争执较小的部分，两个部门单独沟通即可；而当tester与RD无法独立达成共识，申请PM一起评审此部分用例的预期结果，以达成共识。
小结：易用性用例在设计阶段通常不需要额外划分。
功能性测试用例,在编写前有明确的测试策略和测试方法,但是在实际编写中每个人写的情况不一样,有的写的细,覆盖全,有的则比较粗.不知道你们是如何来解决这类问题的. (我们内部会有评审)
此问题主要涉及当个测试团队的测试策略，通常来说，一个测试团队在测试单个项目时，测试策略不会作大幅改动。所以，测试用例的粒度在某一段时间内通常固定为一个范围。
测试用例的粒度取决于多个测试环境因素：测试用例设计水平，执行测试测试技能水平，项目测试周期和资源分布，项目出场标准要求… 而作为测试领导者，应根据实际测试的环境，制定合适的测试用例粒度。如，项目周期长且测试资源充足，则尽量将用例粒度细化，以求达到对测试过程活动的充分控制（理想状态，标准跨国型企业使用较多）；项目周期短且测试资源匮乏，则将用例设计中心放在测试检查点引导，以少量测试用例结合自由测试的方式，达到对重要的项目风险点的控制，而降低甚至放弃低优先级测试点的风险控制。
所以，不同公司，不同测试团队，不同测试项目，其用例粒度可能不同，但是，若相同公司，相同测试团队，相同测试项目，用例粒度不同，则可能就需要检讨测试团队的用例设计规则是否合理，各个tester是否清晰了解公司用例设计理念。（一句话，该培训的就培训，该检讨的就检讨改正。如果用例评审后还出现此类问题，多半这个团队的测试主管就该“背背书”了）
在编写用例时,组内是否会规定用例编写的顺序,比如先写控件,再写功能,再写接口的.
这个问题与上一个问题其实基本相同。用例设计规范需要先行于实际用例设计。
备注：测试的领域中，没有绝对的正确和错误，只有适合与不适合。
用例的优先级,你们是如何来评定的.
用例的优先级规范都大同小异，把握2个出发点即可
1.产品的核心
2.客户的需求
由于项目产品不同，优先级有一些差异，以下列举一个用例优先级排序，供参考：
1.第1优先级为主功能实现用例和客户特殊要求的功能实现用例
2.第2优先级为子功能实现用例和1~2级交互用例
3.第3优先级为3~N级交互用例和NFT用例组
呵呵,说实话,虽然我们组的人都知道常用的黑盒方法,但是在项目紧的情况下,最常用的也就是等价类和边界值了.毕竟用例设计也是需要时间的.不知道你们在编写用例方面有哪些技巧和方法,能否分享一下.

不同的企业采用不同的方式来节约用例设计和用例执行的资源，以下几项可酌情参考：
1.建议基础用例库与测试资源库，用例与测试需要的环境均从库中调用后更新，降低用例设计周期和测试环境搭建周期，并在一定程度上保证不同水平的tester能设计出质量差不多的用例组
2.根据用例的实际使用环境，运用多种用例格式设计用例。如，UI用例组使用流程图代替；交互用例组使用判定表代替。
3.用例设计前期可只依靠需求文档和基础设计方法（等价+边界）完成，其他标准用例设计方法则作为评审标准或手段引入。以保证基础用例组的快速开发。

chaoyue0662

手机测试，在没有任何需求文档的情况下，如何把用例写好？

zhangnan080923

来晚了，但是最近一直有个问题困扰，CS的测试用例怎么样编写才是规范的，

xullnscc

if(a>0||b<20&&c>30)测试用例的总数？
我是新手，最好把分析过程写得详细些，非常感谢

忠冉佼

支持一下吧！

jia8162

回复 116# xullnscc
大致是这样的


a > 0 true or false
b < 20 true or false
c > 30 true or false

(a = 0) = false
(a = 1) = true
(b = 20) = false
(b = 19) = true
(c = 30) = false
(c = 31) = true

(b < 20 && c > 30) true or false

(b = 20 and c = 30) = false
(b = 19 and c = 30) = false
(b = 20 and c = 31) = false
(b = 19 and c = 31) = true

(a > 0 || b < 20 && c > 30) true or false

a = 0 or (b = 20 and c = 30) = false
a = 0 or (b = 19 and c = 30) = false
a = 0 or (b = 20 and c = 31) = false  
a = 0 or (b = 19 and c = 31) = true
a = 1 or (b = 20 and c = 30) = true
a = 1 or (b = 19 and c = 30) = true
a = 1 or (b = 20 and c = 31) = true
a = 1 or (b = 19 and c = 31) = true

楠族开心果

能否分享一下，对于用例写作质量如何进行评价、如何进行度量？
在做测试执行策略时，好多朋友也在问，对于 ...
wangjian790213 发表于 2012-3-3 23:43

   

编写用例之前，定义好用例的编写规范。根据用例 的要素，裁剪出我们需要的。求同存异，上下一致达到共识。有利于预审、评审时每个参加的人能够很快熟悉用例编写者的格式。

测试用例内部评审：
当一个QA完成了手头的测试用例之后，可以让相关的开发人员、攥写需求文档的人员和相对senior或者有专业知识背景的测试人员一起对测试用例做一个review，在review过程当中一般会发现测试用例的不足和需要改进的地方。这些用例的不足之处以及需要改进的地方可以从一个侧面反映出用例的质量。具体的衡量标准由管理人员制定（有些时候测试用例的不足是由于需求文档本身的问题造成的，这就不应该算作是测试用例质量的问题）。

外部评审：
如果公司开发的软件比较大的话，一般会有partnerr或者咨询公司为软件做代理或者实施。这些partner和咨询公司在实施公司新版本软件之前自己一般会做一些测试（他们自己会有自己的测试用例）。公司可以考虑将收集这些合作商的测试用，然后和QA所写用例比较，以作为对测试用例的评价或考核。当然公司也可以反过来作，即把公司的测试用例拿出去让合作伙伴评审（这样做的我看到的不多）。
按客户反馈评审：
当软件发布后，客户使用一段时间一定会发现有问题，或者在设计方面不符合他们的要求。我们可以将客户报告的BUG收集起来加以分析（严重性，BUG类型，复杂程度），并和通过测试用例发现的BUG作个比较，从而评定测试用例的质量。

楠族开心果

初学者  接触测试用例 好头疼 怎么写好 几种方法怎么融合 每种方法适合哪种模块 求救
wuqinqing 发表于 2012-3-4 22:37

先了解什么是测试用例：

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

再了解如何设计测试用例：

1.等价类划分

　　(1)划分等价类。

　　①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

　　②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

　　③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

　　④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

　　⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

　　⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

　　(2)确定测试用例。

　　①为每一个等价类编号。

　　②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。

　　③设计一个测试用例，使其只覆盖一个不合理等价类。

　　2.边界值分析

　　使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

　　(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。

　　(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。　　(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况

　　由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。

　　(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。

　　3.错误推测

　　在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。

　　4.因果图

　　等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。

　　5.综合策略

　　每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。

测试用例设计误区

　　·能发现到目前为止没有发现的缺陷的用例是好的用例；

　　首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&AMp;V”的活动，测试 需要保证以下两点：

　　程序做了它应该做的事情

　　程序没有做它不该做的事情

　　因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

　　·测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

　　不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实 现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

　　在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个ProjECt，也需要在 给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

　　除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

　　·测试用例设计是一劳永逸的事情；

　　这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。

　　这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

　　·测试用例不应该包含实际的数据；

　　测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software TeST》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

　　·测试用例中不需要明显的验证手段；

我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？ 显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

最后进行编制和评审

lsekfe

开心果写的很详细嘛！