软件测试学习20-设计阶段：软件测试设计

1、测试设计

测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

测试分析和设计的主要任务

评审测试依据(需求、设计、架构、规格、接口等说明)
评估测试依据和测试对象的可靠性（方案设计、数据库设计、接口设计、关键代码设计等评审）
通过对测试项、规格说明，进行测试对象行为和结果的分析
识别测试条件和确定测试用例所需的必要的测试数据
设计测试用例，并确定优先级

2、测试条件

依据在测试策略或测试计划中确定的测试技术
通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件。包含但不限于测试环境、测试方法、测试场景、测试内容等等

3、测试用例

测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。

Grenford J. Myers在《The Art of Software Testing》一书中提出：一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试，由此可见测试用例设计工作在整个测试过程中的地位，我们不能只凭借一些主观或直观的想法来设计测试用例，应该要以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例，二者相结合应该是非常完美的组合

测试用例设计依据

版本方案
功能清单（一般为测试自行梳理，形式为思维导图）
接口设计文档
数据库设计文档
开发关键设计文档
工时计划（后台、前端、客户端、测试）
风险库清单

测试用例设计框架

业务驱动设计：也可以称之为需求驱动设计、事务驱动设计、功能集成设计。该设计主要针对一个业务的完整流程进行测试，在过程中同样关注一些子需求的校验。用例之间存在强依赖关系。

优点：
1、能很快校验出业务流程是否正常
2、一个操作验证多个测试点，减少重复操作的体量，提高测试效率
3、可直接转化未自动化用例依据、门槛门槛

缺点：
1、若用例中存在太多检查点，容易出现轻重不分、校验遗漏和测试时间增加。因此建议进行量化时间控制、检查点个数控制

功能驱动设计：就是从系统功能特性出发，根据项目方案，针对每个独立功能进行验证，确定功能运行是否正常，是否和设计保持一致。一般会将功能进行分解，分为子功能、子功能的子功能，形成功能点列表，针对功能点进行测试用例设计和执行。

优点：
1、通过功能分解的方式，能做到最大程度的功能覆盖

缺点：
1、功能分解的子功能越多，执行起来就会越加困难，同时也会增加编写用例的时间
2、子功能颗粒越细，以意味着需要对该功能反复进行操作，需要对子功能颗粒大小进行控制

逻辑驱动设计：这里加入了白盒测试的理念，与开发单元测试类似，主要针对开发实现的代码逻辑进行覆盖，接口测试、渗透测试都属于该范围。此设计更加关注于"输入、输出"来核对代码的正确性。可以从开发工时计划、开发设计讨论中获需要的资源

优点：
1、可以发现除了业务、需求之外的问题，增加代码的健壮性与系统的稳定性
2、同时是输入输出，与"业务驱动设计"相比，"逻辑驱动设计"更加有针对性，可以用来剔除一些冗余用例

测试用例包含元素

前置条件：
测试步骤：
测试数据：
预期结果：
实际结果：

测试用例设计要求

需求可追踪性：具体用例必须要依据对应的需求点进行设计
用例可代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
用例可重复性：后续版本迭代时可以继续使用
结果可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
结果可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

测试用例设计方法（具体用法请查看设计方法篇）

等价类划分法：将输入数据划分为有效等价类和无效等价类，在两个子集中抽取典型数据进行测试
边界值分析法：等价类方法的补充方法，用例来自于等价类划分的子集边界值
因果图设计法：针对多种条件、结果组合的场景，通过因果图组合方法等到所有组合场景，即判定表。如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法
判定表驱动法：因果图法的补充方法，因果图的组合并不是所有都适用，需要筛选有效场景
正交实验设计法：判定表驱动法补充方法，适用于条件组合特别多的场景，需要进一步筛选从而减少用例
错误推断法：主要依赖于个人经验和项目经验，针对可能存在缺陷的条件和场景设计用例
功能图分析法：即开发人员常用的业务逻辑图
场景设计法：功能图分析法的补充方法，根据功能图梳理所有业务流程
综合策略：测试用例设计方法从来不会单独使用，请灵活使用上述和其他测试用例设计方法

PS:等价类划分法+边界值分析法：已经能发现80%的问题

测试用例的设计步骤

根据测试清单得出的基本功能测试用例；
通过边界值方法检查测试用例（边界覆盖）；
通过功能图方法检查测试用例（逻辑覆盖）；
通过错误推断法检查测试用例（经验覆盖）；
补充接口分析，决定是否要追加接口测试用例；
补充性能分析，决定是否要追加性能测试用例；
补充兼容性分析，决定是否要追加兼容性用例；

测试用例的优化方法

利用设计测试用例的8种方法不断的对测试用例进行分解与合并；
采用遗传算法理论进化测试用例；
在测试时利用发散思维构造测试用例。

测试用例设计综合策略

1.纵向切割（测试类型划分）

测试用例划分的经典方法是瀑布模型，从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。
要从更多的角度切入系统，把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性

2.横向切割（测试特性划分）

功能点切面:最常见的切面，通常认为页面上的一个按钮就是一个功能点。
根据功能的复杂程度，按每个功能进行用例的撰写。隐含切面:完整业务流程的测试;从需求、业务角度进行编写

测试用例的使用意义

业务梳理：业务拆解过程中同时也会思考业务的实现逻辑，有利于自己安排测试流程提升测试效率，并且在缺陷生产的时候能够很好的理解缺陷生产的原理提升缺陷修复效率
进度控制：根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排，否则测试进度、项目进度很难把控。
测试依据：如果不记录测试的情况，则很容易忘记自己哪些测了哪些没测。并且在缺陷回归时并不是只执行缺陷产生的用例即可，还需要判断缺陷的影响范围选取合适的用例
复盘依据：当然，再悲观一点，如果我们的项目发生了意外，上线出了问题，我们也可以通过追溯测试用例来发现自己的问题，补全自己的测试盲区。

拓展：测试用例模板案例

用例编号	模块名称	测试子项	用例名称	前置条件	测试步骤	预期结果	实际结果	备注

4、用例颗粒

1、用例设计的两种常见方式

测试用例设计的很细
- 设计用例考虑到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的
- 不依赖测试人员的责任感和能力，测试会降低风险，但是测试效率会很低，并且测试执行没有思考的空间
- 自动化用例可以按照这个模式设计
测试用例设计的很粗
- 用例设计考虑主要测试点，那么测试用例的数量较少
- 测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣
- 比较依赖测试人员的责任感和能力，风险大的多

2、测试用例颗粒度粗细的特点

测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。一下从各个角度来比较测试用例颗粒度粗细的不同点，从中可以得到如下结论：细颗粒度用例最大的风险就是可维护性，或者投入产出比不高，其他都优于粗粒度的测试用例

从用例设计角度

粗颗粒度面向宏观，面向正向的功能点、大的功能模块和整体性，体现测试用例的设计思路
细颗粒度面向微观，面对具体的一个个功能点的正向/负向逻辑，体现测试用例的细节和完备性

从测试执行人员的角度

粗颗粒度用例不容易被测试新手执行，因为很多约定成俗的操作、现象，甚至行业术语都不清楚
细颗粒度用例相对较易被测试新手执行

从覆盖度的角度

粗颗粒度覆盖度可能小于细颗粒度用例（粗颗粒度只覆盖全部正向和部分负向，细颗粒度覆盖全部正向、负向、其他等）
但还有一种可能性，就是粗细用例均覆盖全面，但是深度不同。类似下雨的降雨量不同，对农作物（产品）的意义不同

从用例可维护性的角度

毫无疑问，测试用例和需求的匹配，测试用例本身的维护是大多数团队的工作难点重点，粗颗粒度便于维护，方便和需求保持高度一致
细颗粒度用例，越细越不容易维护，维护成本过大，特别是需求频繁变更会导致不可维护，类似的概念，比如自动化测试环节，GUI不停改变导致的脚本重写类似

从用例消耗时间的角度

粗颗粒度构架和评审的时间较短，适合周期较紧的项目
细颗粒度构建和编写的时间较长，适合周期宽松或更倾向于质量的项目

从占用资源的角度

粗颗粒度占用资源较少（人力、评审、会议室等），适合小团队或同一团队多项目模式
细颗粒度占用资源较多，适合大团队或单一项目模式

从项目风险的角度

毫无疑问，粗颗粒度用例的风险是漏测，存在很大概率漏测的风险，依赖于测试人员的个人素质
细颗粒度也存在漏测，不过相对更可能是测试人员自己的想当然跳过用例不执行

3、如何选择用例的颗粒度粗细

时间因素：

时间短、项目紧、编写用例评审时间较短时，适合粗颗粒度用例
项目周期较长时，适合细颗粒度用例
- 比如规划六个月的项目，计划阶段和设计阶段有一个半月，测试前期进入，有足够的时间来进行人员培训、测试用例编写，需要细颗粒度。
- 如果项目是一个月，测试准备时间只有五个工作日，那么可能在第三天就要完成第一轮的测试用例评审，建议以粗颗粒度为主，覆盖功能和体现思路。

项目人员

测试人员中熟手多，思路和基础技能扎实，或测试人员构成责任心高时，可以采用粗颗粒度用例
测试人员新手多，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例
- 测试人员熟手和新手的区别，大家一目了然。在这里，特意把责任心作为测试用例编写粗细的一个判别标准。
- 实际上，测试人员的职业素质中，就有责任心一项，这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。

质量要求

项目质量要求一般，或项目为过渡项目，生命周期短；项目为临时项目时，可采用粗颗粒度用例。
项目质量要求高，客户或公司对质量的定位为第一位，品牌工程项目，采用细颗粒度用例。
难道不是所有的项目都是高质量高要求的么？当然不是。
- 不同国家和民族的人对质量的要求是不一样的：美国是够用就好，德国是精益求精，中国是当场不挂就行。
- 不同产业链位置的公司对质量要求是不一样的：顶级公司做完美的产品，中级公司做性价比高的产品，底层公司做廉价的产品。
- 不同定位的公司对质量的要求是不一样的：在火车站门口的饭店吃的是客流量，在市区偏远地方的饭店吃的是回头客。
- 不同目的的单子对质量的要求是不一样的：做账拉回扣的虚项目，中标后无人使用，三年后设备升级，质量就没有要求。做重点项目，质量要求苛刻等。
- 所以，肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的，顺序导出的就是不同颗粒度的测试用例。

资源配置

资源配置较少，无法实现测试用例的细化时，可以采用粗颗粒度的测试用例。
资源配置较多，可满足用例编写、评审、修订的交叉进行时，可采用细颗粒度。
- 举例：
- 如果测试人员配置较少，一共就三五个人，每人负责一个项目，彼此没有时间去做评审，甚至项目都存在临时增多的现象，就无从谈起测试用例的细化，甚至粗颗粒度都较难实现，只能拉一个测试大纲出来。
- 或者测试团队有十多个人，但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目，无法做到一个项目的全流程参与时，也很难展开测试用例评审、修订以致细化事宜。

需求变更

需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例——根据项目实际情况。
需求变更较少时，或需求变更波及较小，不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估，可对应较大的细化测试用例变更量。
举例：一个需求，粗颗粒度的用例为100条，细颗粒度的用例为10000条。此需求变更，如果要修改粗颗粒度的用例，只需要修改10条；修改细颗粒度的用例，牵扯到细化的交叉逻辑，需要审阅2000条用例并可能修改1200条。如果测试用例修改人非测试用例编写人，则修改时间还可能延长1.3倍。

项目对象

如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员，可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者，要采用细颗粒度的用例。
面对不同对象的测试侧重点：
- 面向专业人员的项目/产品，测试倾向于正向测试，一些问题或使用方式在规定、需求之外，可以在培训或规范中指定操作模式，或凭借技术人员的功底来避免问题。
- 面向非专业人员的项目/产品，无法做到培训和操作约定，各种稀奇古怪的使用方法，操作习惯，所以更倾向于细颗粒度，覆盖负向和随机操作的测试用例。

测试团队素质

团队个体素质较高，可适应粗犷、敏捷的风格时，可以采用粗颗粒度的用例。
团队处于成立初期或磨合期，需要细化的规则约定来指导时，采用细颗粒度的用例。

公司决策投入

公司对测试工作的投入，对产品质量的要求，对行业节奏的把握。具体分析，可参考项目质量部分的内容

4、如何有效度量测试用颗粒例粗细度：

代码行数

颗粒度可以跟代码行数对应：一般来说代码量越大，内部逻辑就越复杂，出现bug的的可能性也越高。对应的测试粒度也越小。

内部一致

测试团队内部对粒度达成一致，适当把握颗粒度：明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致。

业务特点

颗粒度要适合业务的需要：各公司测试用例设计的粒度不同，适合自己的需要，适合业务的需要即可，测试用例的数量统计方法，我觉得说明不了测试作得是否专业。

用例有效率

测试用例设计的覆盖率和有效性，才是说明测试是否专业的依据之一：对于进行工作量的统计还可以，不过用例还是不能简单的以数量来看，设计一个很简单的功能点的用例可能很容易，可能一天能设计十个这样的用例，但是对于一个相对复杂的功能，可能一天才能准备两个用例，光靠数量是说明不了问题的。

5、用例的文字描述的粗细

测试用例粗细的另外一个概念：用例的文字描述粗细。在写测试用例的时候你们会遇到类似的颗粒度的问题。

写给自己

第一类是写给自己，以及懂这个技术的，差不多水平的同事看的。这样只需要大致的描述核心关键点就可以。

技术一般

第二类是给技术一般的员工，但是有一定底子的人看的，这样基本的概念就不用描述，整体步骤描述清楚就可以。

不懂技术

第三类是给不懂技术，只会看图一步步操作的外行看的，这样就要详细细致的描述基本概念，步步都截图，傻瓜式的对比参照的搞过去。

举例说明，使用ping 命令

第一类写法：如果网络不通，使用ping命令测试一下网络是否通畅。
第二类写法：如果网络不通，在cmd模式下，使用ping X.X.X.X 的命令格式，测试一下网络是否通畅。
第三类写法：如果网络不通，点击开始，选择运行，然后在运行框里输入cmd，然后在弹出框里面，使用ping X.X.X.X 的命令格式，如果显示Reply from X.x.x.x bytes=32 time=3ms TTL=64，就是通畅，其他显示就是不通畅

参考文档：《测试用例设计白皮书》https://blog.csdn.net/vincetest/article/details/1475414
参考文档：https://blog.csdn.net/weixin_42176112/article/details/119190817

posted @ 2022-11-22 16:57 捕者阅读(274) 评论(0) 收藏举报

刷新页面返回顶部