1.任务估时
（都只作为参考，具体情况具体看）
- 客户端需求可参考开发估时，比如需求A两个端各估了3天，则测试时间可大概估为3天
- 有后端接口变更时，估时需要增加
- SDK或工程类需求，开发可能只需要接入所以估时会非常少，但测试时间不能少，需要开发列出测试点，根据测试点估时
- 涉及跨部门需求，考虑沟通成本，时长适当增加
- 工程类比如迁移等需求，需要大面积回归的，开发估时可能很长，但测试时长可稍微减少，因为测试过程中，每个人都可以分担一点回归的任务，无需特意测试，关注即可
2.回归
- 回归case无需包含功能所有分支，覆盖主流程即可
- 不可因为测试过程中已经走过某个case，回归时就忽略，因为在回归前开发都在改动代码，很可能一个改动影响意想不到的地方
- 回归时该迭代自己负责的需求，最好交给别人回归
3.用例
- 技术评审无特殊情况都应该参加，知道开发大概的逻辑，有利于case编写及覆盖
- case并不可能覆盖所有，但只要写了的，一定要测试
- case编写过程中，任何不确定，都一定要找PM或交互确认，不可私自做决定，不可单独和开发达成协议修改需求
- 没有接口测试的情况下，功能测试时需要详细测接口，枚举字段，每个值都需要覆盖到
4.沟通
- 提高自身能力，更深入的了解需求以及代码实现逻辑，和开发沟通起来会更高效，且能更有底气，不至于被忽悠
- bug信息全面：现象、步骤、原因(能定位到的话)；bug定级标准；避免提重复bug
- 尽量减少找开发的频次，避免造成开发时间碎片化
- 沟通时控制情绪及语言表达，换位思考，尊重对方
- 有需求、优先级争议时争取第三方介入参与，PM，开发经理等
5.风险控制
- 日常分配工作遵循交叉原则，但高风险功能需指定最熟悉功能的专人负责，编写针对性测试用例
- 高风险功能每个P1、P0的bug都要生成一个与之对应的回归用力
- 咨询高风险功能可能的回滚和恢复机制，减少过度反应
- 引入尽可能多的相关方，PM、设计师，和用户保持联系，“你使用怎么样？有没有什么问题？”
- 在测试已经尽可能覆盖完善的情况下，总是出现问题的高风险区域，需要从根本上看是否产品设计问题或者开发质量问题
6.哪些方面能提高产品质量(QA角度)
-
QA自身能力素养
a.需要足够的责任感、好奇心、耐心、洞察力、抗压性、影响力、产品意识
b.扩大知识范围结构，多了解开发内部逻辑、框架、流程(如git flow)，了解计算机网络基础知识，熟悉常见数据库，对各种专项测试如性能测试自动化等均有涉猎，熟练使用各种工具
c.提高代码能力，开发简化测试流程或辅助测试的脚本
d.从各方面保证测试用例覆盖率，如提高需求分析能力、组织PM和开发参与用例评审、参考回归用例
-
流程
a.测试尽早干预。参与技术评审并尽量提出建议，数据边界类代码可直接看，能直接进行白盒测试更佳
b.提供冒烟用例，督促开发自测
c.灰度测试
-
平台工具
a.已稳定的会用用例UI自动化
b.接口自动化回归
c.借助第三方机构
