写作背景：
1.最近部门新来了一位测试同事，由我负责对他讲解本组的业务知识，讲解过程中发现很多之前的业务知识点已经记不清了，还要找开发来核实，说来也很是惭愧，讲解的效率和质量也大打折扣。
知识盲区
2.人的记忆力和吸收知识的能力是有限的，想要短时间将大量的知识点一并灌输过去，大部分的人也就能消化个半成左右，那么问题随之而来，过一段时间新同事又会来问你之前已经和他说过n遍的问题。
一波操作666
3.组内没参与过本次需求的同事，而当过了n个月后这个需求又有延展性的变化需要他来负责测试时，就会向你询问之前这个需求的相关信息，但是你会发现你根本不相信这个需求之前是你测试过的，根本一点印象都没有。
我什么都不知道，别问我！
那么该如何避免？
那就是总结业务知识，将每次做过的需求加以总结，日积月累就形成了业务知识的体系网，其实之前是有总结业务知识的习惯的，后来由于做了一段时间的测试开发工作，对于业务方向关注较少，就将这些好习惯渐渐都抛弃了。
业务知识改如何总结：
1.本次需求的业务背景介绍
有些需求你可能会见名之义，但是不知道你会不会有时候看见需求名，心里默念一句WTF？
WTF
2.测试环境
有些公司的业务场景可能不同，为了提供补偿机制或者缓解压力，常常一套代码部署到两台服务器，当你兴高采烈的快要测试完成之后发现你测试的这环境竟然没部署......
笑容逐渐消失
3.本次需求涉及的功能点
本次需求所涉及的测试范围，功能点的总结一般就是需求分析的阶段，将需求的各个功能点列举出来，大致勾勒一下测试案例的设计雏形。
4.本次需求所涉及的SQL
我的建议是一个需求一个sql文件，这样能让他人清晰的了解到这次数据的存储范围，当然有些人也习惯于将本组所有的业务涉及的SQL汇总到一个文件里面，但是我觉得有时候找起来也比较麻烦。
5.需求流程图
自己动手画流程图更有利于对本次需求的场景案例设计，他人也能够一目了然的知道数据和场景的走向，多系统关联的建议可以采取泳道图。
6.测试案例
测试案例是本次需求质量的保证和依据，能通过测试案例了解需求更深层次的细节部分。
7.缺陷总结
分析缺陷的原因，避免再次掉坑。
提升效率的方法还有那些：
(1)需求文档管理
针对每一个需求建立一个单独的文件夹，文件夹里面包括本次需求的需求文档、案例集、SQL、需求分析，当然这是在公司没有类似于confluence等记录项目的测试工具的时候可以参考使用，这样将文档归类也有利于日后离职的交接工作。
(2)常用的SQL需要记下来，如果常用的SQL还需要打开文件去查找的话，会极大的浪费时间。
(3)组内定期做业务知识的分享，准备PPT还是其他文档都可以，重点是使组内成员的业务知识体系达到均衡的水平。
俗话说“前人栽树，后人乘凉”，其实不然，自己栽树也能享受到阴凉，这篇文章对于测试老鸟来说可能没有什么实质性的帮助，但是对于刚入行的小白在工作中养成良好的习惯很及其重要的。
....
网友评论