回顾测试入行以来的一些感受，浅谈对测试管理方面一些见解

　　测试入行以来算算也有几年了，总体的感受有以下几点：

1.基础设施建设，这些包含：

　　测试流程，设计流程，评审流程，变更流程，沟通渠道，人员技术基础，业务基础，辅助工具开发，开源框架引入，跟着高效平台引用，团队氛围管理，测试环境的管理等各个方面。

　　为啥都把这些归类为基础设施建设呢，因为这些是后续测试开展的基础，你会发现基础设施的建设直接影响到后续工作的开展。

　　首先测试流程的管理与建设：很多人认为测试就是点点点，按照需求，设计文档来验证功能就可以了，这个是比较肤浅的，一般性的功能测试确实是这样的，但是测试的价值不只是这些，测试是需要贯穿整个质量保证体系的，打个比方，你设计一个产品，测试需要在需求阶段就对产品的一些需求进行明确，而不是产品生产出来去验证产品与需求文档是否一致，这时候产品已经定型，针对产品的改进，都需要从头再来了。

　　测试流程贯穿整个产品需求设计阶段的好处是管理整体的流程，一个好的流程是一个好的产品产出的重要保证，没有一个好的流程，产品生产出来好只能是个概率性的问题，而不是个必然的结果，跟闭眼赌博没啥区别，产品好只能说人品好，对于后期的维护，升级都只能向苍天祈求你的团队不解散，业务一直稳定增长。客户不提新的需求，等等。

　　所以前边的这几个流程可以都归类为基础设施建设，是需要一直存在且严格执行的，对于产品的回溯，问题的定位，文档的管理是要有严格要求，测试标准有明确的定义，限定条件有明确的声明，各项指标都有明确的声明，现阶段我所经历的大部分都是有个需求文档就开始开发了，到测试手里的时候产品基本已经定型，这种基本测试就是去个验证的职务，产品开发的各个环节要是每一个人都是按照需求做的话，那产品的可维护性，易用性，可扩展性基本就无从谈起了，肯定是都做最基本的功能，因为这样是最快的开发周期。变更流程沟通不及时也会导致软件漏测，误报等问题。

　　体会深的就是我第一份工作，每年入冬之前需要给管道做保温，不然三九天你会站在凛冽的寒风中去拿蒸汽去吹冻住的管子。基础工作在前边做好了，到了关键时刻，只需要在几个关键点对数据流程进行把控，既能及时向上游反馈问题，也能保证问题不传到下个环境，成本的减少是可预见的。

　　人才技术基础，这个就是技术债的问题，产品开发需要哪些技术栈，这些技术栈对产品的重要性有多大，需要有个前瞻性，提前内部培养或者外部招聘，内部培养的好处是贴近业务，不用招个新人来对业务不熟悉或者不喜欢业务造成人员流失。人员技术培养中设计到，培训的过程可视化，效果落地，知识的积累，存留，公共知识库的建立，与业务的结合等等方面。同时业务的基础也是这个思路，每次来一个新人，都需要业务流程的梳理，本身就是一种投入，如果有相对完整的业务流程介绍，可视化的讲解，本身就是一种省钱的办法，因为招一个人来，要安排一个人来带，明显就会占用一个人的精力，算下来不是人力增加，至少在新人能承担业务之前，人力投入时减少的。

　　辅助工具开发，这些就是增强性的范畴，业务的开展用人堆当然可以，但是有自动化的工具，框架相对来说会解放一部分人，有更多的精力投入到产品的设计，维护，问题反馈环节，提升产品的品质，这些都是投资长见效慢的活，需要注意，如何落地，如何与业务沟通，是关键。

　　另外对于测试环境的管理也是一大痛点，测试过程的并行，会极大的提高效率，串行肯定是要消耗大量的时间，把各个新功能分布到不同的测试环境中并行测试，并最后进行集成测试肯定是要比把所有的功能集成到一个环境测试要高效的多。测试环境多以后，堆测试环境的管理也会成为一个关键点，数据库是否及时的更新为生产数据库同样字段，所有环境的配置文件是否一致，这些都是需要定期检查及更新管理的，不然会因为这些配置造成一些不必要的误报bug问题，及与开发的沟通问题。

　　另外就是整体这些基础设施建设的根基，软件，技术的公共文档库的建立，我了解的情况是，有些公司是对外网访问及个人网盘U盘，硬盘管理是不友好的，那就需要提供公共的开发软件库，知识库，业务流程库，这些都方便人员迅速上手，避免在软件的安装，知识的获取阶段花费过长的时间，来适应公司的管理。另外也可以考虑进行内网访问设置权限，内部资料外传设置权限的方法，把外网访问权限全开的方式，来管理公司的安全涉密资料。

　　以上就是个人这些年的一些感受和总结，有后续的问题会再补充。谢谢