| 了解业务的重要性 | 系统业务应该熟悉到什么程度 |
| 1、功能测试的前提 2、可以更好的设计测试用例 3、可以快速定位线上问题 4、可以发现设计缺陷 5、协助开发做业务梳理 6、提高测试地位 7、缩短测试工期 8、有助于和产品及研发的沟通 9、站在用户的角度考虑问题 |
1、系统的业务流、设计流、；数据流走向； 2、上下游的接口； 3、缓存、MQ、库表结构等； 4、配置、降级开关、ump监控、日志等； 5、架构部署（都部署在了哪些机房，有多少个实例等）； 6、系统的关键点实现细节要了解； |
| 不熟悉系统业务的原因 | 解决办法 |
| 懒惰； 时间久了，业务线多忘了； 没时间总结文档或文档较旧； |
个人问题，勤看文档，及时更新文档 |
| 产品人员的需求文档模糊 | 和产品进行有效的沟通，挖掘产品的真实想法； |
| 功能及需求变动后，没通知到测试或者只有少部分测试知道； | 沟通解决、测试之间同步 |
| 测试人员前期未参与和测试介入晚； 设计评审不叫测试； |
与相关人员沟通解决（勤问着点这个业务项目的动向） |
| 与开发沟通不顺畅； 测试代码能力不强； |
提高自身沟通能力及代码能力； |
| 新人不知道自己不了解 | 自身解决，多去沟通，了解该了解系统的什么 |
| 没需求文档； 敏捷开发过程中没有文档产出； |
规范流程（领导解决） |
| 熟悉被测系统的方法 |
| 看系统相关文档 |
| 亲自体验被测系统 |
| 和了解系统业务的人沟通 |
| 看代码（前提是看的懂） |
| 参与评审（需求评审、设计评审、用例评审等） |
| 业务分享 |
从不熟悉系统业务的原因和熟悉被测系统的方法中，可以看到：
1、熟悉被测系统业务主要靠文档；
2、不熟悉的原因主要是文档较旧或者没有文档；
所以将我们熟悉的业务传递下去最好的方法就是文档
希望大家能将文档及时更新及时总结，这样才不会叫“后人”遇到和我们一样的境遇