一点耳濡目染的总结
测试的方法有很多，分类也很丰富。
一、按开发阶段划分
1.单元测试（Unit Testing）
2.集成测试（Integration Testing）
3.系统测试（System Testing）
4.验收测试（Acceptance Testing）
二、按是否查看代码划分
1.黑盒测试（Black-box Testing）
2.白盒测试（White-box Testing）
三、按是否运行划分
1.静态测试（Static testing）
2.动态测试（Dynamic testing）
四、按测试对象和目的划分
1.性能测试
2.安全测试
3.兼容性测试
4.文档测试
5.易用性测试（用户体验测试）
6.业务测试
7.界面测试
8.安装测试
五、按是否手工执行划分
1.手工测试（Manual testing）
2.自动化测试（Automation Testing）
从用户需求、需求文档和以往经验进行测试需求分析，包括沟通、梳理功能点，分解出测试点、测试项
深度参与需求评审，拆分测试需求，从上到下逐层梳理功能目录项，根据目录项做思维导图梳理设计待测功能项
根据客户需求、产品设计；核心业务场景+高风险功能点，挖掘客户场景，梳理设计探测性待测功能项
耳熟能详的设计用例方法：等价类划分法、边界值分析法、因果图法、流程图法、猜错法
思维导图和流程图可以帮你完成80%的思考工作
测试经理如何制定测试策略，如何把控测试风险
3W1H方法制定测试策略：
WHY 深刻理解项目的目标是什么，这决定着我们测试策略的粒度、方法、范围
WHAT 根据PRD，推荐使用Xmind梳理出项目范围和P0级关键模块，做测试范围思维导图。根据测试对象和目的梳理出需要做的测试类型
WHEN 测试阶段的拆分，范围时间的制定
HOW 在测试策略中，推荐梳理P0级关键模块的测试办法和测试全流程（包含上下游系统的检测）
梳理最关键的功能清单P0级别，做重点跟踪，重点管理（核心业务、业务入口、与金钱相关等）
产品、研发、测试三方联动的用例评审，校验用例质量。
高频风险点：
1)软件需求不清楚，开发商对产品需求特性理解不准确。
2) 需求变更风险。
3) 测试人员，开发人员的能动性。
4) 测试环境，和测试数据不准确
每日站会帮助梳理、上报、解决风险
通过测试人员评估以及测试难题分析，尽早发现风险点并将其影响降到最低
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
