测试工作小总结

1.任务估时

（都只作为参考，具体情况具体看）

• 客户端需求可参考开发估时，比如需求A两个端各估了3天，则测试时间可大概估为3天
• 有后端接口变更时，估时需要增加
• SDK或工程类需求，开发可能只需要接入所以估时会非常少，但测试时间不能少，需要开发列出测试点，根据测试点估时
• 涉及跨部门需求，考虑沟通成本，时长适当增加
• 工程类比如迁移等需求，需要大面积回归的，开发估时可能很长，但测试时长可稍微减少，因为测试过程中，每个人都可以分担一点回归的任务，无需特意测试，关注即可

2.回归

• 回归case无需包含功能所有分支，覆盖主流程即可
• 不可因为测试过程中已经走过某个case，回归时就忽略，因为在回归前开发都在改动代码，很可能一个改动影响意想不到的地方
• 回归时该迭代自己负责的需求，最好交给别人回归

3.用例

• 技术评审无特殊情况都应该参加，知道开发大概的逻辑，有利于case编写及覆盖
• case并不可能覆盖所有，但只要写了的，一定要测试
• case编写过程中，任何不确定，都一定要找PM或交互确认，不可私自做决定，不可单独和开发达成协议修改需求
• 没有接口测试的情况下，功能测试时需要详细测接口，枚举字段，每个值都需要覆盖到

4.沟通

• 提高自身能力，更深入的了解需求以及代码实现逻辑，和开发沟通起来会更高效，且能更有底气，不至于被忽悠
• bug信息全面：现象、步骤、原因(能定位到的话)；bug定级标准；避免提重复bug
• 尽量减少找开发的频次，避免造成开发时间碎片化
• 沟通时控制情绪及语言表达，换位思考，尊重对方
• 有需求、优先级争议时争取第三方介入参与，PM，开发经理等