需求测试之测试经验分析法

前言

需求评审、用例设计，这两个是测试工作当中非常关键的技能，却可能被忽略。

需求评审是源头，如果需求评审的工作没有做好，那用例设计就难免出现缺漏甚至错误。需求评审没做好，就等于拿着一个不是圆形的形状却想去度量出圆形，结果可想而知。

那到底怎么才能做好需求测试呢？为什么不同的人看一份同样的需求，有人能够提出各种问题，有人看完觉得没有什么问题。我想原因很多吧，如对需求的熟悉程度、有没有掌握需求测试方法、测试经验的积累。

需求测试方法，有测试类型分析法、业务继承分析法、功能交互分析法、测试经验分析法，光看这些方法的概念，看完之后其实你还是不知道怎么进行需求测试。那需求测试是不是真的只可意会不可言传，并不是，我觉得测试经验分析法可以有一定的传承性，我认为可以把需求测试的一些经验总结出来，对一些新人还是会有一定的借鉴作用。

经过思考，我认为可以把需求的功能归纳为一些模块，如流程、查询功能、导入导出、上传下载等，总结每一个模块常见的需求问题，那在进行需求测试时，就可以进行参考。

本文只能起到抛砖引玉的作用，每一个人都可以根据自身的测试经验，去修改补充完善属于自己的需求测试经验。

测试类型分析法，依据产品的六大质量特性（功能性、可靠性、易用性、效率、可移植性、可维护性）及行业特点，将软件测试划分成一系列不同的测试类型，来覆盖产品的标准规范、功能和非功能性的用户需求。

业务继承分析法，针对产品项目需求分析的对象有新增功能、修改功能和功能变更后的功能影响部分（功能影响的范围由开发人员协助划分）。测试负责人在明确了需求后，根据需求特点，以测试需求分析步骤为指导，采用测试类型分析法完成测试需求分析。

功能交互分析法，针对业务需求，分析业务模块的功能界面、业务流程、用户场景与数据规则，验证功能场景交互的过程流转与数据校验的正确性，结合功能场景交互应用采用测试类型分析法。

测试经验分析法，该方法是将具有代表性的测试积累形成经验库，以方便重用，如果经验有代表性，可并入测试类型分析法。

需求测试经验

流程

• 既要有正常流程的描述，也要有异常流程的描述

• 不同流程状态的可操作项
  如在审核状态下，提交流程的人只可查看流程信息，不可编辑流程信息

• 流程不同岗位的信息查阅权限
  如流程节点a——b——c，b、c可以填写流程审批意见，可能因为a是外部客户，但是c审核的一些具体内容不希望被a看到，如审批信用卡，a看到一些具体信息可能会想办法去规避，所以流程控制a只能得知最终结果，看不到具体审批意见，而b是内部人员，可以看到c的审批意见。

• 历史存量流程的处理
  如果修改已有流程的节点，那么原来已经发起的在途流程，是按新的流程处理还是按旧流程处理

• 流程是否可以再被否决、驳回后可再次提交

• 已结束流程的查看与编辑
  一般已结束流程的信息是不会改变，也不能再编辑。但可能因为流程中的一些字段信息是获取某些会发生变化的数据，如利率、汇率，那利率、汇率发生变化后，已结束流程的数据是需要保持当时时点的数据。

• 在途流程数据的取值规则
  在途流程中的一些数据，如果这些数据会发生变化（因为流程审批需要时间），如利率、汇率，那利率、汇率发生变化后，在途流程的数据是取最新的还是流程发起时点的

• 流程多人审批问题
  如一个流程同时提交到a、b、c（同级别），3个人都可以审批流程，那谁先审批，其他人便不能在审批，如a审批后，b、c在待办任务中看不到此流程
  如一个流程同时提交到a、b、c（同级别），a、b都打开了流程审阅信息，a先审批，然后又审批，如何处理

• 审批前流程被撤回如何处理
  如一个流程提交到a，a已经打开流程查看信息，但还没有审批，这时候发起人撤回流程，a再审批流程，怎么处理

权限、角色

• 需求是否明确不同权限、角色可以进行的操作

• 新增权限、角色时，权限、角色的初始化，是脚本初始化，还是手动配置

• 修改权限、角色时，原来已经绑定这个权限、角色的用户怎么处理

• 明确权限大小规则，如有a、b两个权限，a的权限更大，用户同时配置a、b权限，是以哪个权限为准

数据

• 历史数据的处理
  功能改造会响应数据，那么已存在的数据如何处理

• 数据初始化
  新增一些标识，那原来没有这个标识的数据是否进行初始化。如证件类型原来有一个“其他”类别并标识了一些数据，现在证件类型“其他”类别拆分为“其他”、“港澳台身份证”

• 数据定义是否清晰
  如社保通系统的统计分析功能，原来提交审核数量、满足购房条件、不满足购房条件的数据定义不明确，原来没有说明“以生成凭证的为准”
  

• 数据来源是否说明清楚
  如数据来源与接口，需要明确是哪个接口哪个字段

• 数据的异常展示
  如表单当中文本超长时是否换行展示，
  如展示的长度是否有限制（测试不动产计算器发现开发限制了计算结果的长度，输入框是限制输入13位数字，结果开发实现显示框也只展示13位，而需求并没有说明这一点）
  通过计算得到的数据的展示，如除不尽时怎么展示
  数据为空时，页面如何展示

• 数据覆盖取值规则
  如一个流程，人员a把流程提交给人员b，人员b可以驳回流程，人员a可填写提交意见再次提交，需求要求是人员b需要看到人员a的提交意见，如果多次驳回提交，是取最新的提交意见吗

• 数据删除是物理删除还是逻辑删除
  物理删除，直接从数据库把数据删除掉
  逻辑删除，一般是把数据置为无效状态，还是保留在数据库当中

查询

• 是否自动触发查询
  有时候为了方便，会在进入页面就按默认条件进行查询

• 是否有默认的查询条件

• 全部查询条件为空时是查询全部数据吗

• 查询无数据时如何提示

• 是精确查询，还是模糊查询

输入

• 输入的长度、字符类型是否明确

• 异常输入时如何处理
  是直接限制输入，还是输入后进行提示，是什么时候进行提示（输入后就进行提示还是进行确认后再提示）

• 是否必输项

• 复制粘贴异常输入会怎样

• 是否可换行输入，单行输入框、多行输入框

提示语

• 需求是否明确了提示语
  有时候需求文档描述就提了一下什么情况下要进行提示，但是没有把提示语写出来，要在需求文档明确提示语

• 提示语是足够精确
  是否针对每一种情况，都有相对应的提示语，而不是把所有提示语都写成一条，有时候是多种异常情况，需求只写了一条提示语
  提示语是否足够明确，有时候需求说提示语直接取接口的内容，那要明确是哪个接口哪个字段，如果提示语出现不友好的情况是否要进行转译

• 提示语与功能是否对应
  如明明是选择框，没有选择时提示“请输入XXX”
  如字段是“手机号码”，没有输入时提示“请输入电话号码”

• 删除时是否进行二次确认

• 是否有默认提示语

上传、下载

• 上传文件的格式、大小、数量是否明确
  txt一般是不给上传，txt有可能上传脚本，会有安全性问题

• 是否区分小写、大写后缀

• 格式说明是否足够明确
  如word文档是有doc、docx两种后缀，是都可以上传吗

• 是否能够同时选中多个文件上传

• 上传图片，是既可以直接拍照上传，也可以上传本地图片

• 格式限制，是前端直接过滤还是选择上传不支持格式文件再进行提示
  前端直接过滤，如假设限制只可上传doc文件，那选择文件时只能看到doc文件，或者非doc文件全部置灰无法选择

• 上传达到数量限制后，是无法再上传还是上传时进行提示

• 可同时选择多个文件上传，选中多个文件其中有文件超大如何处理

导入、导出功能

• 是否提供导入模板
  明确定义导入模板的字段、字段类型、长度

• 导入文件格式说明
  要足够具体，只是说支持导入word文件还不够，word文件有两种后缀

• 导入数量的说明
  是否一次可以导入多个，还是只能单个导入
  导入excel表格，行数是否有限制

• 导入空文件处理

• 重复导入，是否是以最后一次导入数据为准

• 导入文件中必填字段的限制，哪些字段是必填的

• 导入文件中字段内容的长度、字符类型的限制

• 异常导入

1. 导入非法格式的文件
2. 导入文件表头字段错误
3. 导入文件的表头字段缺失，如删除了一列
4. 导入文件必填字段缺失，能够提示出哪个字段缺失吗，如果是一行一行导入，前面99行导入没问题，100行必填字段有问题此时如何处理
5. 必填字段中空格、换行
6. 导入文件中数量超出限制
7. 模板中列的顺序不对

• 导入数据中去重规则-模板之内数据重复
  如一个excel表格中有两条相同的数据
  判断数据重复的规则

• 导入数据与系统现有数据重复处理规则

• 取消导入

• 导入规则校验时间点
  是在导入时就直接提示
  导入进去后，进行操作时才提示

• 导入后数据的展示
  是按照导入文件的顺序进行展示
  是否分页展示

• 导入数据后是否可以删除

• 导入数据后是否可修改

• 导入数据后数据的展示，分页展示还是展示在一页

• 导入数据后，数据的保存逻辑
  是导入完毕，就把数据存到数据库当中，还是只是暂存在序列当中，要相关操作后才保存在数据库当中

• 导出模板
  需求需要提供导出模板

• 如果需要选中才可导出，那没有选中任何数据点击导出，是怎么处理

• 导出是否跟数据状态有关
  某种状态下数据才可以导出，那是直接过滤数据，如果不是过滤，选择有不可导出状态的数据如何处理

接口

• 接口的异常返回
  社保查询需求评审，单户查询功能，我提出如果单户查询出现异常，如查询没有数据，怎么提示，需求没有说明。
  外围系统提供的接口文档，只有正常返回的约定说明，那就要向对方了解清楚异常返回的情形。

• 接口调用顺序
  涉及调用多个接口时，是否清楚说明接口调用的顺序

• 接口入参是否说明清楚
  接口入参的必填字段、字段的类型与长度
  接口之间是否有关联传参

• 修改接口字段，下游系统影响评估
  如一个接口是a系统与b、c、d系统交互的接口，修改这个接口（如增加字段、删除字段）对下游系统有什么影响

• 调用接口的时间点
  是进入页面就调用接口，还是需要用户点击再调用接口

文件归档、数据保存

• 文件归档的频率，归档文件的命名规则，归档文件的放置路径，归档文件大小限制是否明确

• 数据的临时保存
  如填写表单时，退出页面后再回到页面原来填写的信息、上传的文件是否保存

日志

• 发生异常、错误时是否保存日志

• 保存日志的规则

日期、时间

• 如需求描述是“一年时间”，一年的具体含义是365天，还是到明年对应的年月日

• 区分自然日、工作日，描述是“7天不处理自动评价”，7天是自然日还是工作工作日

• 时间点的说明，如需求描述是“一天”，是需要24小时才是一天，还是过了晚上12点就是一天

页面跳转

• 业务办理完毕返回到什么页面

• 提交失败后返回到什么页面
  

状态

• 状态流转是完整且闭环的

• 每种状态下的流程的可操作项
  如什么状态下可以查看、什么状态下可以编辑

安全性

• 敏感数据是否脱敏

• 下载、导出的数据的权限控制

• 系统用户行为记录
  可能会只在后台记录

• 密码是否可以复制粘贴

• 密码是不是可以通过F12查看到

兼容性

• 移动端支持的操作系统

• PC端支持的操作系统、浏览器

性能

• 大数据量查询

• 上传文件
  如可以上传10个文件，每个文件限制100M，假如同时上传10个100M的文件，那速度会很慢不

拓展性

• 后台数据的记录
  如一些数据可能前端不需要记录，但是之后可能要这些数据，如点击量、办理量，那应该后台记录这些数据

一致性检查

• 需求是否前后矛盾
  

• 需求文档与原型图是否一致

• 用词的一致性，如有些地方用“确定”，有些地方又用“确认”

• 需求修改，是否修改了全部地方
  有时候需求变更时，需求人员只改了一部分需求文档的描述
  
  前面改成了“本次赠与人预计税局申报纳税日期”，土地增值税计算公式中描述是”赠与人税局申报纳税日期“，描述前后一致，增加理解成本

• 关注功能的具体规则与通用规则是否冲突
  看到过功能具体规则的手机号码输入规则与通过规则相矛盾的情况

• 功能与提示语是否一致
  如下面需求描述，既有默认值，又有提示语
  

完整性检查

• 如有不同状态，但是需求只是对某些状态进行了说明
  

准确性检查

• 错别字

• 国家法律、行政法规的专业词语，行业标准词语不能任意更改

常识性检查

按照你的理解，看出需求是否有问题。

• 在测试不动产税费计算器时，看到需求如下描述：
  
  读起来感觉是描述反了，“直系亲属”应该是“指配偶、子女、父母、祖父母、外祖父母。”，“赡养人及抚养人”是“指承担直接赡养或抚养义务的人。”

• 之前所在项目，需求描述股东的比例数值不能大于100%，没有描述全部股东比例加起来也不能超过100%，结果开发实现功能后全部股东比例加起来大于100%。

• 需求当中的概念是否定义清楚
  

关注是否符合用户习惯

社保查询需求讲解当中，提到在输入信息后，点击左上方的按钮进行查询，如下图：

这个交互不符合使用习惯，般我们输入信息后，查询按钮都是放在下面，我们填写信息是从上往下，填完信息的注意点自然是在下方，这时要去左上角找按钮，感觉非常奇怪。

关于需求测试的一些建议

• 不是需求说什么就是什么，你可以有自己的思考，也应该有自己的思考

• 需求不完善，抱怨是没有用的，尽自己的能力，能推动多少就推动多少

• 自己多思考与总结，形成自己的经验

• 敢于提出问题，不要因为觉得是小问题就不提出来

• 需求测试需要一定的想象力，你想象自己是用户时，会有什么场景，这些情况需求都描述清楚了吗