测试点编写（2020-09-10）

测试点编写（功能测试）

为什么需要写测试点

个人感觉测试和人的成长其实有点类似。获取到需求文档、UI稿其实等同于这个功能获取到生命；我们开始编写测试点相当于这个功能开始学走路； 编写测试用例等同于学习奔跑；或许比喻不是特别恰当，但是能理解就好。

既然如此，没理由我们在没学会走之前就去尝试奔跑，因为这样操作，后续会发现测试用例会有很多坑（缺少测试用例）。也就是你会在奔跑的时候不断的摔倒（漏测）。

当然编写测试还有更重要的原因

1、测试点是需求文档测试要点的提取文档，先编写测试点可以有效防止直接编写测试用例造成测试场景缺失、需求理解不到位的这些情况发生；
2、可以解决迭代周期较快、同期新增需求功能较多、人力资源不足情况下，测试团队不能快速介入、高效测试和输出等问题
3、团队内部可以高效同步当前需求的主要逻辑和交互详情，理解新增需求的功能和效果

黑盒测试常用的测试方法

测试点以及测试用例编写方法都有比较多，但是其实其中一部分使用不是很多；关于编写功能测试点，个人感觉以下几种方法结合就可以达到基本目标了。

1、等价类划分
2、边界值分析
3、场景法
4、错误分析法/错误猜测

当然还有其他的因果、正交等方法。不过不太常用，但是作为测试人员也是需要了解一下的～

测试方法详细介绍

等价类划分

一般等价类划分主要分为两个大集合：

1、有效等价类：对程序规格说明来说是合理并且有意义的数据
2、无效等价类：对程序规格说明来说是不合理、没有意义的数据

其次等价类划分多应用于有数据输入的地方，比如搜索、登陆注册、用户名称设置、信息发送；总而言之看见各类类型可手动输入数据的位置大部分都适用等价类划分的方法进行测试和检查。

比方说腾讯会议登录界面

腾讯会议登录界面就很典型有两个可以输入数据的input。然后我们来看一下需求，节选“人人都是产品经理”网站的需求文档里面逻辑说明其中一个路径：

新用户注册：点击”注册/登录“选项，点击”新用户注册“选项，输入手机号，点击”获取验证码“选项，系统判断手机号是否合法，不合法给予提示，满足条件可发送验证码（60S后可重新发送验证码、单条验证码10分钟内有效），验证码匹配正确后可进入首页，点击”登录“选项，系统判断手机号是否合法、是否注册以及密码是否正确。满足条件后，填写会议姓名及密码，完成后可进入首页

（主要针对两个input分析）需求内提及：
1、系统判断手机号是否合法（中国手机号是一个很典型分析例子，网上也有很多详细的分析）

• 首先我们可以先划分大类型：
  有效等价类：数字「0-9」
  无效等价类：中英文、字符、空格、emoji、各类型文字（这个可以基本不考虑）…

• 第二步在有效等价类内进行划分（因为有一些组合也是属于无效范围的）
  有效等价类：首位为1且二位不为0/1/2/6/9
  无效等价类：首位非1或二位为0、1、2、6、9

这样看下来有效等价类

2、验证码匹配正确

其实验证码匹配和手机话第一步的划分也是一样的，不同之处为第二步。因为验证码一般为乱序的数字，所以没有像手机号一样有严格格式规定。因此第二步主要是
1、输入与验证码一致的数字可正常提交
2、输入与验证码不一致的数字会提示错误（大部分产品会刷新/更换验证码）
3、验证码使用后是否正常失效

最后，关于发送消息的input、搜索、筛选、用户名称等划分也是类似上述步骤进行。不过需要根据不同的需求说明进行划分，比方用户名可输入中英文，不可输入数字。那反过来数字在这个input就变为

边界值

边界值一般都和等价类划分结合使用，因此使用的场景也相对较多是有数据输入的位置。边界值主要关注四个值：最大值，最小值，小于最小值，大于最大值

依旧用上面的手机号和验证码为例子：
因为手机号确定为11个数字因此边界值为：10、11、12；一般这里我会再加一个考虑为空的状态

这里要测的就很简单了，输入少于11位/输入超11位表现是否正常。不过结合等价类之后可测的用例就会变得多很多了。并且大部分错误都可以通过边界值测试验证查出。

场景法

场景法主要是要求测试人员将自己想象为最终的用户，然后基于一些测试方法模拟用户使用的场景。

这个部分能动性相对较高。但主要常规操作方向是：
1、正确按照系统提示进行操作，验证App/系统功能实现是否和需求一致，并观察是否有需优化位置（比如缺少引导/提示）
2、模拟用户操作失误/误操作等场景，验证异常场景App/系统处理能力

这个部分最主要是需要了解需求的主要逻辑和功能实现。能完整理解需求的流程后，如果场景相对比较复杂可编写流程图辅助测试：

基本流程+备选流程

比如加入视频会议：

基本流程：

• 用户登录 - 点击链接 - 进入视频会议 - 退出视频会议

备选流程：

• 用户登录验证不通过（密码错误/账号错误）-返回登陆界面
• 用户账号不存在-返回登陆界面
• 点击链接无响应-提示错误
• 点击链接用户无权限进入-提示权限错误
• 多次点击链接后系统响应
• 加入视频会议后网络不稳定-弱网提示
• 进入会议后，摄像头/麦克风无权限
• 加入视频会议后麦克风启动失败
• 加入视频会议后摄像头启动失败
• 加入会议后被主持人踢出
• 会议过程，会议房间被关闭
  …

错误分析法

根据测试人员经验和猜测列举的测试点/用例，从而有针对性地设计测试点/用例方法；通常是属于编写测试点最后阶段根据测试人员个人能力发散考虑的测试范围；考虑方向可包含以下方向：

1、根据跟进的开发人员编写代码习惯推测可能出现错误位置；
2、模块交互、关联影响较高部分；
3、需求文档明确标注不允许的范围；

编写测试点/测试用例的原则和逻辑

有一定的测试方法理论知识后可以尝试通过分析需求文档、UI稿后结合编写方法提取相关测试点了；

流程： 拿到测试需求 -> 分析需求（画思维导图） -> 编写用例/测试点 -> 划分用例优先级

编写原则

编写测试点/测试用例一般遵循一些基本原则，这样可以很好的降低投入成本和支持测试点/用例的持续输出；

1、单个测试点覆盖最小化

• 含义：

  • Camera包含A、B、C三种子功能，测试点覆盖是最好是Camera A、Camera B、Camera C进行测试，不直接Camera A-B-C这样长路径测试；

• 原因：

  • 若A/B功能出现问题后，后续的测试点/测试用例就难以执行。
  • 连续测试定位Bug相对较为复杂和浪费时间。甚至有时候因为涉及路径较为复杂无法定位Bug，以至于需要和多名开发确认Bug归属位置。
  • 步骤多多手工测试点/测试用例增加了不确定性；

• 优点：

  • 测试用例的覆盖边界定义更清晰
  • 测试结果对产品问题的指向性更强
  • 测试用例间的耦合度最低，彼此之间的干扰也就越低
  • 只验证所需要验证的，这样可减少测试执行阶段的负担和风险

2、尽量减少操作难度

• 减少测试点/测试用例的操作难读可以大幅度提升测试时间
• 常规路径质量可得到保证

3、制定匹配的重要性和优先级

• 区分重要性及优先级，以便在实际项目测试中进行选择。
• 可突出内部验收范围、以及主要逻辑的覆盖范围
• 便于后续更新和管理

4、一次性完成测试点/测试用例

• 含义：
  • 测试点最好一次性设计完成，之后不断修改和完善；根据需求文档完成主要逻辑和重点功能点编写
• 优点：
  • 减少逻辑不连贯、不系统问题

编写逻辑

点阶段是项目测试前期执行中的最小单元，这个阶段测试点的设计及执行有几个要求：

1、测试点设计要简单、独立、明确、减少与其它点的交叉；
2、测试点设计的范围局限于单个模块内部；
3、测试点设计以功能验证为主，性能指标、可靠性、可用性等暂不涉及；
4、测试点设计以正向测验为主，异常测试及复杂场景模拟先不考虑；
5、测试点执行时的策略：优先选择简单、执行难度小、功能最核心的指标，尽早暴露问题；
6、项目前期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部基本功能测试；

面阶段是项目测试中期执行中的单元，这个阶段测试点的设计及执行有几个特点：

1、测试点设计要稍微复杂些，考虑单模块内部的异常和复杂场景；
2、测试点设计的范围不仅包括单模块的复杂设计要求，还包括模块间的接口测试；（功能阶段仅考虑模块之间数据、连接、切换是否正常）
3、测试点设计以功能验证为主，单模块及模块间的性能指标、可靠性、可用性可以涉及；
4、测试点设计以正向测验为主、异常测试及复杂场景模拟为辅；
5、测试点执行时的策略：优先选择功能最核心的指标，必要的性能和异常场景，尽早暴露问题；
6、项目中期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部高级功能和性能测试，模块间的接口测试；

以“体”为主；系统、性能和异常模拟：

1、测试点设计要复杂些，考虑被测系统多模块/全模块内部的功能（性能、稳定性、可用性、可靠性等指标）的测试；
2、测试点设计的范围不仅包括被测系统多模块/全模块级别的测试，还包括系统与外界环境的兼容性、真实场景模拟等；
3、测试点设计以被测系统多模块/全模块功能验证为主，其次是性能指标，最后是可靠性、可用性、可升级性等指标；
4、测试点设计以被测系统多模块/全模块的正向测验，功能性能全部通过之后是异常测试及复杂场景模拟；
5、测试点执行时的策略：优先选择被测系统多模块/全模块的功能、性能最核心测试指标，必要的可靠性和异常场景模拟，尽早暴露问题；
6、项目后期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是被测系统多模块/全模块的功能和性能测试，各种稳定性、可靠性测试等；

最后：测试点在编写的过程中，一定要考虑真实使用场景，这会非常的高效，场景模拟本来就是测试点编写的重要方法之一

回顾审核测试点

前提： 参与评审人员对需求以及逻辑均熟悉
链接: 评审.
评审要求：跳出编写人的基础逻辑，审核人应该从更高角度查看测试点/测试用例的完整性

1、模块划分合理性：要包含所有要测试的对象，但不能重复
2、逻辑链路流畅性：流程是流畅的，没有阻隔
3、子属关系正确性：主类、子，并行关系、从属关系区分清晰，不在同一级并列展现
4、需求覆盖完整性：显性需求100%包含；尽量挖掘隐形需求
5、类型覆盖的全面性：前后端、UI、功能、性能、兼容等
6、描述定位准确性：位置以及功能描述简洁准确

实用技巧总结

• 从用户角度出发，编写测试用例
• 多考虑意外情况，异常用例
• 关注关联/复用模块，功能相互影响位置
• 新增需求对原有各项功能的影响
• 编写测试点/测试用例方向固定从上到下，左到右
• 类型覆盖的全面性：前后端、UI、功能、性能、兼容…(等)
• 参考市场主流App、爆红App、新星App同类型功能使用和本身的用户体验

测试点逻辑学习来源：https://blog.youkuaiyun.com/zimingzim/article/details/89405997