测试经验总结

测试工作的一些注意要点

了解业务背景，了解为什么要做这个功能

广发同业额度需求
需求描述：没有同业额度时，可以授信
讨论：额度不足时，是否可授信？

了解业务知识

• 文档资料，如需求文档、需求调研文档、项目合同、操作手册

• 书籍，阅读对应的书籍

• 公众号、微博、视频号，关注相关的公众号、微博、视频号了解相关业务

• 搜索，遇到不了解的知识，直接百度搜索了解

• 实地了解，到行政中心时，注意看各种宣传手册、宣传流程图
  
  
  
  
  

• 政务网，访问南海、佛山、广东、国家等政务网了解业务

• 参加培训，积极参加测试部门组织的业务培训

• 向人请教，项目经理、需求人员、测试组长一般比我们更加熟悉业务，可以虚心向他们请教

• 留心平时各种运维资料
  如平时在群里让统计业务的办理量，那我们根据业务办理量就知道那些事高频业务，那些是低频业务，这对我们测试工作有指导意义。
  假如时间紧急时，我们没有那么多时间测试，但是又要上线，那么我们就侧重于高频业务的测试。

了解关联系统的功能

我们需求文档一般不会提到外围关联系统的功能，但是有些外围关联系统的功能会影响到我们测试。
如在测试IOC系统时，web后台是阿里巴巴团队做的，其中有一个功能是后台给我们分配工单。我们了解到只是有分配功能，但是操作这个系统的时候我发现web后台是可以同时向多个处置员分配工单，那我们测试的时候，就要考虑同时把一个工单分配给多个处置员，那第一个处置员处理后，其他处置员应该不能再处理了。

了解测试业务的总体流程、了解数据流向

关注兼容性测试

• 移动端测试，一定要问清楚是不是要测试安卓、苹果、鸿蒙系统
• web端测试，关注支持的操作系统、浏览器
  【ID1020236】【我的办件】ios系统手机，申请回执点击【查看下载】没有反应

问清楚开发人员如何看日志

一般问清楚日志文件的存放位置，生产和记录规则，在测试的时候tail -f 命令实时监控日志。
报错的时候，我们可以看日志，提缺陷的时候也最好把日志贴上去。

学习基础的编程知识

学习的编程语言跟项目开发人员的技术栈一致，如开发使用的是java，那你需要学习java的基础。
编程语言掌握python、java、shell、go

需求说的不一定是对的，你需要有自己的思考，有疑问就提出来

关注运维问题、用户反馈的问题

虽然运维问题、用户问题可能不会直接找上我们测试人员，但是平时留意这些问题，思考一下，如果是自己测试，自己能想到那个测试场景吗

不断总结、思考

如业务知识的积累
测试经验的积累

尽可能早参与

参与一些会议，在会议听需求、代码逻辑的确定过程，可能会得出需求文档中每天体现的测试点。

• 花一点时间，抛开测试用例，做一下探索性测试
  不要让测试用例限制住你的思维
  做探索性测试，要求你是熟悉需求，你不熟悉需求就只会根据测试用例进行测试。
  当你充分熟悉需求、了解业务，你便可能想到测试用例没有考虑到的测试点、测试场景。

文字沟通不清楚，那就直接当面沟通

千万别等

需求评审关注点

• 上传附件、图片，需求需要说清楚上次文件、图片的格式、大小、数量，异常上传时怎么提示

• 上传excel，需求需要说明是不是支持xls、xlsx后缀的文件，文件的表头不对怎么提示，其中有字段错误如何提示，多个字段错误如何提示

• 上传附件、图片临时保存
  上传后没有提交，返回上一页再进入到上传页面，原来已经上传的内容是否还存在

• 查询数据导出成文件，注意查询数据为空，是导出空表格吗

• 查询结果为空，如何提示

• 需求的完整性
  

• 多选操作
  选择部分数据符合条件，部分数据不符合条件，进行操作时如何提示

• 删除操作是否有二次提醒

• 输入框、选择框，需求需要说明默认显示、选择项

• 输入框应该有输入字段限制说明

• 页面字段如果为空、null，页面怎么显示

• 页面数据是通过接口查询，需求需要说明页面的字段是取自哪个接口哪个字段

• 涉及流程否决、驳回
  需要说明流程否决、驳回后可再次提交，测试时需要测试多次否决、多次驳回场景

• 填写表单页面，数据的临时保存

• 日期的说明
  如需求描述是“一年”，一年的具体含义是365天，还是到明年对应的年月日
  如需求描述是“7天不处理自动评价”，7天是自然日还是工作工作日

• 查询，全部条件为空的时候是否是查询全部数据

• 查询功能考虑大数据量的情况
  如刚进入页面是否查询全部
  是否限定某些条件必须输入才可查询

• 关注安全性
  如敏感数据是否脱敏
  下载的权限控制
  系统用户行为审计

• 接口要关注正常、异常返回
  社保查询需求评审，单户查询时，我提出如果单户查询出现异常，如查询没有数据，怎么提示，需求没有说明。
  需求人员看对方提供的接口，只有正常返回的约定说明，那就要向对方了解清楚异常返回的情形。

• 关注是否符合用户习惯
  社保查询需求讲解当中，提到，在输入信息后，点击左上方的按钮进行查询
  

这个交互不符合使用习惯，我在看原型图的时候就比较困惑，一般我们输入信息后，查询按钮都是放在下面，我们填写信息是从上往下，填完信息的注意点自然是在下方，这时要去左上角找按钮，非常不友好。

• 涉及调用多个接口时，要了解清楚接口调用的顺序、接口之间是否有关联传参

• 查询条件输入框，需求需要明确是精确查询，还是模糊查询

• 关注功能的具体规则与通用规则是否冲突

• 了解代码的逻辑
  THR向我反馈一个生产问题：问题跟踪管理查询页面，评级字段没有取到最新的客户评级。
  原因是取值时，仅仅是根据评级表的id最大值取出评级信息最新的评级id是最大的）。而还有一个字段，那就是评级表中还有一个状态字段，状态为0是无效，生产上id最大的评级状态为0，所以没有展示评级。

id	客户编号	评级等级	评级状态
001			0
002			1
003			0

如果测试的时候，知道评级表各个字段的信息说代表的含义，就更有可能设置出相对应的测试用例进行测试。

如何了解一个软件系统

界面了解，知道在页面如何操作，主要的业务流程
涉及哪些接口，接口的调用顺序
涉及哪些数据库表
整个系统架构

---

测试执行关注点

• 测试查询功能
  需要了解查询的逻辑，是发接口查询外围系统，还是查询数据库
  查询数据库，需要了解查询的逻辑，在页面进行查询，也在使用sql查询数据库，看查询的结果是否一致

• 一个页面有多个输入框
  测试的时候注意把所有的输入框输入满内容，观察页面是不是会错位
  

• 查询是输入#、/进行查询
  【ID1021706】【城市运行管理平台（IOC）】工单列表输入“#”查询，提示服务出错

• 测试上传附件、图片，注意测试同时选择多个附件、图片场景

• 测试的时候关注状态的变化
  如南海通app提交事项后，受理系统是可以操作办件，虽然受理系统不是我们开发的，但是我们如果能够测试的话，需要测试在受理系统进行不同操作，观察南海通app状态是否正确

• 提交、确定等操作
  测试时尝试快速多次点击，看是否会重复提交，产生相同的数据
  1022175 【城市运行管理平台（IOC）】连续快速多次点击【确定发送】，添加了多个批示

• 注意权限控制
  如IOC一个缺陷，处置员1对工单执法介入后，发现处置员2可以进行操作，这样是权限控制不对

• 注意联动测试
  如证件类型、证据号码的联动测试
  

• 关注网络
  我们做的是政府项目，涉及住建局、社保局，这两个机构的网络并不是在同一个局域网内，那数据在其中的交互就可能出现不稳定的情况。
  据说，智能柜台视频连线不稳定，就是因为内外网的网络不稳定。

• 接口新增字段，一般在后面新增字段，而不在总结新增字段
  接口的兼容性
  如果一个接口被多个系统调用，接口改动没及时通知其他系统一起改造，就可能会出错。

• 关注数据库字段对应的接口字段长度
  如接口一个字段A是存储到数据库的a字段，那数据库a字段最大长度是否大于等于接口字段的长度。

• 输入测试
  除了使用键盘输入，还要测试复制粘贴输入

• 会变动测试数据的测试
  
  如上图，测试的时候需要考虑，如果配置的内容增加、减少、修改，那下拉选项也需随之变化。

• 涉及打印功能，需要真实打印观察效果

• 一致性检查
  颜色一致性
  字体一致性
  布局一致性
  文字表达的一致性
  

• 重置功能
  默认条件下重置
  输入条件后重置