测试点编写（2023 保险黄金十点怎么写

测试点编写（功能测试） 为什么需要写测试点

个人感觉测试和人的成长其实有点类似。获取到需求文档、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/系统处理能力

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

基本流程+备选流程

比如加入视频会议：

基本流程：

用户登录 - 点击