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