2022、23年各需求提测后的总结，及典型bug缺陷

2023年

2023-12

1、建议把一些冷门的业务逻辑整理出来，整理到一个文档中，方便自己经常查看，去回忆去加固印象，防止漏测。

2、需要反思下 漏测的场景，为什么会漏测？举一反三。

• 如需求《topn》，就是拼接sql没有考虑到拼接的用户自己筛选和topn的联动。
• 如需求《超时拦截》，企微的通知上线后通知内的链接跳转到了测试环境（因为这域名是七彩石配置的，上线后开发也忘记修改这里了）
• 如需求《字典翻译》，历史已存在的看板的兼容问题，其实只要重新配置功能是生效的，但使用上不够优雅，就需去做兼容。
• 如需求《权限申请》，入口太多，只关注了prd中写的各子应用的申请入口，忘记在权限中心还有一个入口。这个确实是实实在在的漏测。
• 如需求《本地文件跨源查询》，忘记了其中一种场景下的权限继承逻辑了，本次漏测造成工单较多，回滚了。
• 【重要】怕漏测，要多进行用例评审，喊上产品、开发、和其他测试同学。

3、原来csv文件只有一个sheet。还需注意中文编码问题。

印象深刻的问题

1、（在自己认知之外的）如需求《临时指标》，纯前端操作，创建成功没有做实际的存储到db。自己测试时不好判断问题根源，就去寻求开发，才知晓可使用chrome中vue插件来排查原因。技能+1

2、针对异步的交互，子应用A调用子应用B的接口做创建（异步），子应用B再调用中间层C的接口做导入（异步），整个创建到使用的流程做了两次异步操作，测试过程中也是提出实质性的交互体验优化方案。

2023-10

1、文件上传造数据 单个256个字符，最大条数10万行，此时就得学会使用工具

• 各种在线工具，如蛙蛙工具、在线生成字符串等等
• 还得学会excel的各种函数，如单个格内容的拼接、单元格内随机数、快速生成10万行数据等等

2、FO的提测邮件中，争取让开发列出功能点，测试范围，可能影响的点。（有助于防止自己漏测）

3、与需求不符的问题，也一定要记录下了，并且bug单的标题标注好（与需求不符），凡是以prd为准，线下产品和开发对其的功能，未在群里知会的，不管，还是得记bug单（哪怕开发拒绝也要记录）。

2023-08

1、如需求《画像宽表》，分区的概念

2、如需求《DT的事件分析》，对于开发同学的技术方案、接口文档，还是要仔细的去看，不能以为本次就是功能测试，不关注技术方案，了解以上文档后，可快速的知道调用的接口是哪一个，传参是否正确，返回的参数是否正确，数据的状态是否标识正确等等。

3、如需求《行列权限》，这次测试是自己对业务不够完成透彻，导致刚测试时有点蒙圈，介入一天后才再实际中掌握了业务逻辑。【不要凭空去想，学会画图，画流程图，画demo，类似使用示例，只有自己打脑子里弄懂了，测起来才能有底气去找开发】。

印象深刻的问题

1、遇到一些bug，虽然是历史遗留 非本次需求引起的，开发同学不愿意去修改时，自己需要先评估是否影响到主流程，影响到用户常用的使用路径。若影响到了，就去battle，必须修改。若没有影响到，也需要记录bug单，备注好开发拒绝修改的原因等等。

2、脸皮要厚，当测试时，结果看起来怪怪的，又感觉不是问题，此时一定要去找第三人叙述一遍自己的疑惑，也许说着说着自己恍然大悟，不能放过任何怪怪的感觉。

2023-05

1、上线后进行测试的数据一定要是测试的，如需求《新HDFS集群配置》为了在线上进行回归，让开发用***库做测试，结果影响到了线上用户， 之后动线上数据要慎重。

2、开任何会，尽量 记录会议纪要，防止自己走神。既然参加了，就不要浪费时间。

印象深刻的问题

写接口自动化时，有些需要的接口，开发的openapi或者接口文档说明不完善，不准确，就需要在页面上找使用场景，就可以一直打开F12，看接口名称猜测可能出现的场景，点点点吧。

2023-03

1、如需求《拖拽创建视图表》，是因为自己对SQL不是太精通，怕会出现漏测情况，导致提测之前一直有所担心，但当自己把测试用例补充完整，感觉就那样吧。（勇于面对自己害怕的事，不能知难而退）

2、对于开发及产品对需求进度不上心时， 要催要催要催 群里群 私下催，尽快完成自己的测试，尽快进入到下一环节（产品验收）

印象深刻的问题

 1、有个tab的hover提示一直不消失，虽然是很小的交互问题，但非常影响使用。我又找不到稳定复现步骤，在群里反馈，试的几个人也没有复现，偏偏自己很容易就会出现这个困惑，不甘心呀。就先咨询产品该功能是哪个需求的，然后去翻相关prd，发现这个hover是有倒计时的 3s后自动消失，我就想应该和这个有关，就想是不是临界值问题，是不是不是3s，是不是功能失效，是不是倒计时被其他操作打断了，就一个一个的试，果然发现是我的一个习惯引起的倒计时被打断（我每次刷新页面后，不等页面加载完，习惯性的点几下页面，才出现的这个问题）。

2022年

2022-09

1、如需求《DM改造三期》

        上线要严格执行上线流程，开发一定要写上线步骤文档

        上线后群里开发测试一定要反馈进度

        上线后，相关开发最少要留下30min才能走

2、针对线上用户的反馈：

数据源修改密码后的影响， 自始至终都没有考虑这种场景（大概是因为实例无法登陆，也不是自己的，没有权限也没有机会修改密码，所以无法考虑到），当真是无法挣到认知水平以外的钱。

2022-08

1、提测邮件要规范，发件人尽量是需求FO。

2、需求文档放的位置有点多，表示提测阶段才发现还有一个虚拟字段 聚合指标的prd。

3、多关注小秘的输出报告，看当下用户的痛点，及常出现的问题。

4、如需求《mq权限体系》一些逻辑很多在测试时才发现没有实现或者不通，该如何避免？（需求评审、技术评审、用例评审？）

开发自测， 不能说因为造不出场景，就不自测。

2022-07

如需求《DM改造二期》

整体感觉，这一版本，大家开发的仓促。自测不充分。

2022-04

1、如需求《开放平台》临近上线，没有时间进行全量测试，开发莫要频繁动动已开发的逻辑代码。

2、如需求《DM改造一期》已提测，就不要频繁修改需求了， 用例和需求对不上，增加工作量。

3、开发的需求，有时需求对不上，若不支持，应该在需求评审、或者用例审批时提出来。

4、测试方法复杂的，一定要 当下就记录下来（文字+截图），不要怕麻烦，日后会感谢自己记录的。

印象深刻的问题

1、本需求的功能测试完成，一定要找开发 合master分支的代码到测试环境，确保代码是最全最新的，然后再过一遍核心功能。

提测阶段，要每日进行测试进度反馈：

【整体进度是否有风险，进度x%，共x个bug，未修复x个，明日测试计划，风险及建议】

针对分批提测的需求：每日测试进度中需标注好哪些已提测，哪些未提测。