《测试用例设计技巧》由会员分享，可在线阅读，更多相关《测试用例设计技巧（6页珍藏版）》请在金锄头文库上搜索。
1、.浅说 测试用例 - 给测试新手的在此之前我搜集一些关于测试用例的知识，后来在我们的QQ 群里专门定了一期讨论，来探讨测试用例，毕竟这是一个很大的话题， 很难做到面面俱到，但我会尽量全面，用通俗的语言来说测试用例。-注：我们这里要说的测试用例指功能测试用例。一、什么是测试用例一、什么是测试用例. .测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。二、写测试用例有什么好处二、写测试用例有什么好处. .理清思路，防止遗漏这里是我们认为最重要的一点， 假设我们测试
2、的工程大而复杂， 我们可以把工程功能细分， 根据每一个功能通过编写用例的方式来整理我们测试系统的思路， 防止遗漏掉要测试的功能点。跟踪测试进展通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。历史参考在我们所做的工程中， 也许会有很多功能是一样或相近的， 我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。重复性我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进展测试，那么我们就需要测试用例来规和指导我们的测试行为。告诉领导，这事俺干过，不然别人怎么知道你测没测，测的全面不全面，拿测试用例给他们看呗！俺就是照着这个干活，呵呵！三、测试用例的方
3、法三、测试用例的方法好吧，咱知道啥是测试用例了，也是知道为什么要写测试用例了，那到底应该怎么写.无从下手啊。我们在写测试用例之前，先学习几种方法，它是我们写测试用例的指导思想。1. 等价类划分.v.在某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的。假设有一个输入框要求输入1-10000 个数，我们不可能用每一个数去试，我们输入5和输入 6 去验证和揭露输入框的错误可以看做是等价的。 那么这个时候我们就可以随机的抽取一些数据来进展验证。如：10 、99、7777.等价类分：有效等价类和无效等价类输入框要求输入 1-10000 的数有效等价类：可以输入1-10000
4、之间的数来验证，如：2、5、99、8495.无效等价类：可以输入1-10000 之外的任意字符验证，如： 20000、字母、下划线、特殊符号、空格、回车.2. 边界值边界值是对等价类的补充，测试工作经历告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000 之间的数。我们要测它有没有超出这个围，如：0、-1、-2、1000、10001.等等，来判定是否超出了我们的围。3. 因果图因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导
5、这我们的测试。 当然了，我们为了以免遗漏， 可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。 4. 错误推测法基于经历和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。5. 其它设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。四、测试用例的格式与要素四、测试用例的格式与要素一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。当然还可参加一些它选项，如：优先级、测试阶段.v.注：上面的格式取自微软的软件测试之道，它并不一定适合你，我只是让大家对测试格式有个了解。关于测试用例的存放管理：1.
6、 工程管理系统自带的用例管理，一般用例会与工程挂钩，有固定的格式，搜索、修改等功能，使用起来非常方便。如：禅道工程管理、QC、bugfree 等等都带的有用例管理功能。2. 通过 worldExcel 文档形式管理，这样的好处就是自己定义测试用例的格式。-测试用例例子-根底知识了解的差不多了，下面来看一个具体的测试用例。我们会有更深刻的认识。.v.注：这不是一个完整的测试用例，格式也不是固定必须这样的，你们可以根据自己的需求编写设计测试用例。=-我们还需要知道的，关于测试用例的-一、.我们在什么时候可以设计测试用例.当根据客户的需求整理出工程需求分析文档时，我们就可以根据需求文档来编写测试用例
7、了。但是，一般我们国大多小公司工程需求文档都非常“简陋，所以，很难根据需求文档设计测试用例。.v.我们只有等到工程开发人员把工程开发出来，给我们系统文档、部署环境、数据库构造如果系统牵涉到数据库的话，我们根绝这些文档来设计测试用例。二、测试用例的评审与更新我们设计的测试用例设计完成之后，是否完整.是否符合系统.符合客户要求.对用例做一个评审是必不可少。关于评审的方式，不同的公司有不同的流程。我们编写的测试用例也不是经过评审之后就不变了，随着需求的变更、功能的改良，测试用例当然也需要更新和变动。三、什么情况下不适合写测试用例文件时间如果一个功能我很快就测试完了， 而且只需要测试一遍， 但我们设计
8、测试用例时却比拟麻烦，花时间也长。这个时候就没必要编写测试用例了。需求变动大且频繁需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。工程时间不允许这一项为哪一项不太厚道的做法，如果不是急需交付客户的话，尽量不要这样做；当然了，如果只是给客户展示或试用，可以在之后进展补充和完善测试用例。不要编写不完整或别人看不懂的测试用例，那样就没有意义了。=个人闲聊容，欢送指正=四、停顿软件测试的标准。语句覆盖最低不能小于80%，测试需求覆盖率到达 100%，测试用例覆盖率到达100%，一、二级缺陷修复率到达100%，三、四级修复率到达 8
9、0%。上面一句是再网上找的，不是标准，只是个参考bug 等级：一级：非常严重的 bug二级：严重的 bug三级：一般性的 bug四级：建议性问题五、关于探索性测试.v.完全的执行测试用例时一件非常枯燥的事情， 个人在执行测试用例时会做一些， 其它的非常规性的操作， 看系统是否会有相应的处理和提示。 我的一局部 bug 就是再这种非常规操作下发现的。当然了真正的探索性测试需要对产品的深入了解， 以及软件开发技术有一定的深度和宽度。姑且把我们的探索性测试看成是瞎捣鼓吧！呵呵。六、穿插测试有木有发现，当我们第一遍测试系统时，会非常认真，但要我们测试第二遍时，我们不愿意像第一次那样认真的去测了， 这不
10、能说明我们不负责， 而是每个人都有的心理现象。 这个时候，我们可以和其它测试人员交换功能来测试，提高效率，而且更容易发现问题。七、测试的目的 1. 我们让它做的它必须会做。 2. 我们不让它做的它必须不会做。可能你会发现有附加功能的时候，就是客户没有要求，我们加了这样的功能，可能加了这点功能系统看上去会更好。这时怎么办.算问题么.作为开发人员，中规中矩的做东西最好，如果真的有非常好的功能要加的话，需要和客户沟通，然后写到需求里。毕竟多一点功能多一点风险。呵呵作为测试人员， 但凡不符合需求文档的都需要当问题点提出。 责任清楚， 以免后续麻烦。-修改： 1.测试用例的格式的要素，去掉“实际结果 2.关于测试方法“等价类划分的解释。.v.
