• 测试用例的基本要素
• 测试用例的设计方法
• 基于需求的设计方法

• 测试用例的有效性
• 测试用例的粒度和评价

测试用例的基本要素

回顾测试用例的概念：
测试用例 (Test Case) 是为了实施测试而向被测试的系统提供的一组集合， 这组集合包含： 测试环境、操作步骤、测试数据、预期结果等要素。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

• 评价测试用例的标准：对比好坏用例的评价标准
• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高。

测试用例的给我们带来的好处

测试执行者的依据
使得工作可重复， 自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
使用中带来困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题
不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗 余测试影响测试效率

测试用例的设计方法

基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正 确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测 试点或者测试项，然后根据每一个测试点进行测试用例的设计；
在分析测试需求时，一般分为功能测试需求和非功能测试需求

功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以 下，通常包括以下几个方面。
(1)系统各个功能界面的验证
(2)借助业务把功能串起来进行测试
(3)功能的一致性，交互性(多功能互操作)的测试
(4)系统的不同输入，结果输出的业务数据测试。
(5)功能的错误操作，异常操作的测试(属于负面测试)
(6)功能实现用到的算法验证，有时需要用运代码评审
(7)用户操作的易用性，用户体验，往往结合功能测试同时验证。
针对具体的需求，可以根据业务分类，用户角色(餐厅的会员系统)或者用户操作区域等将系统的功能 分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分 是最常见的做法。
下面对一个简单的日历系统的需求进行分析

也可以采用思维导图的方式，更为方便，有效，只管的呈现测试需求的分析结果，可以更好的支持测试
分析思路的连贯性。
下面以我们常用的百度云盘手机端为例进行分析功能

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用 例。例如我们可以再想象以下场景：
1、用户激活后再次点击邮件激活链接r> 2、已注册用户再次注册r>

2个原因中有一个为真时，结果就为真。

• 画判定表：有3个条件,输出有2个取值，所以表的列数为2x2x2=8



5、增补测试用例
姓名、邮箱、密码、确认密码、验证码都不填写

什么样的测试用例是一个好的测试用例h1>

什么是测试用例的有效性h1>

测试用例对应的功能已删除，不可操作了

微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。

执行一条测试用例未发现BUG，实际该处有BUG

苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹 果7微信小程序扫码开锁。

执行一条测试用例发现了BUG

苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现

执行一条测试用例未发现BUG，实际该处BUG已修改

苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁

测试用例的粒度和评价

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

粒度：指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内 容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用 的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数 据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。
(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外， 测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进 行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测 试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理 解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将 影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测 试用例。
主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

但是不管用例怎么简化，都不应该省略
测试用例的评价
测试用例设计出来了，如何提高测试用例设计的质量软件产品需要通过各种手段来保证质量一 样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

• 同行评审
• 用户检查
• 项目组评审

(1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的 同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价 值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单， 测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是 存在局限性。因此需要一起设计测试用例。
(2)除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏 捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试， 如果测试是对产品的批判，则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家)； 如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！