202203_GSM测试总结

• 前期没有参加需求评审

• 测试前的沟通，客户端的环境要求

• 编写测试用例，没及时发现测试用例存在问题，修改测试用例的人不反馈（lmj发现一大部分测试用例不规范，自己觉得先把缺少的功能用例先补上，不管原来只copy需求的用例），组长没有主动去了解

• 测试任务分工注意，把关联的功能分给同一个人测试

• 在不了解具体功能的情况下，如何了解执行人员的执行情况，询问细节，测试这个功能是什么，这个功能要解决什么问题，测试过程当中有没有发现什么问题，没有发现问题点开对应的页面看一下你今天测试的功能

• 观察缺陷情况，判断测试情况

• 查看测试用例执行情况，了解阻塞测试用例是否真是阻塞，有些是真的阻塞，有些是伪阻塞，是遇到阻碍，没有去了解思考证明去解决

• 向上请求协助

• 测试资产积累，把了解到的gsm与全家桶中数据助手、终端助手、设备管理器的数据关联关系搞明白，整理成文档

• 不要想当然执行者会按你的想法去做，除非你特别叮嘱，如发现非gsm系统的问题，不反馈出来，只管自己的一亩三分地，从整个公司质量情况出发，发现特别明显的问题当然应该反馈，阻碍测试时要反馈

• 跨项目沟通的难度

• 遇到问题反馈问题

• 主动发现问题，并尝试解决问题，无法解决的问题向上请求协助

• 发现组员的不足，要指出

• 不要频繁换人，让较为固定的人有一定时间熟悉系统

• 测试时间不是固定，如果实在有特别的原因，要把遇到的阻碍事情罗列出来，说明这些事情占用了自己的时间，而不是因为原来说了固定的时间，中间有各种问题，时间越来越紧，不反馈问题，而是内心抱怨，觉得公司在压榨自己的时间，赶鸭子上架

• 自己亲自执行，能够直接发现问题

• 了解测试情况，如测试执行数量、缺陷数量，领导问起时能够答上来，如果不知道就说自己要先去了解，不要随便说一个数据

• 明确说出你的要求，如这周要把进度推进到80%，发现非gsm问题证明反馈，遇到开发实现、需求文档、测试用例不一致时怎么处理

• 询问执行者如果做这个任务，他预计要化多少时间

• 发现了新的问题，影响这次测试的问题，自己解决不了，不要想着包庇，自己说明，如这次测试不全面

• 不能仅仅通过测试用例判断覆盖度

• 遇到问题，逐一分析问题。如预警管理的四个预警，每一部分测试用例的阻塞原因

• 在测试过程中中间问题，提出要求，如下一轮提测要想做需求功能讲解