写在前面
2019年初，公司信息系统由单体架构向微服务架构改造，同时还面临开发-测试-运维各阶段相对独立模式向Devops开发运维一体化模式的转型。作为一个干了十多年测试的老家伙，面对各种新名词、新技术像浪潮一样一波一波涌过来，最初我也是懵懵懂懂，甚至怀疑Devops是否将是测试的终结者。于是我翻CSDN、翻简书、翻技术大牛的博客，理论结合自己这一年半做微服务架构系统测试的实践，得到的结论恰恰相反，即微服务架构改造对测试的需求比单体架构更多，Devops也不是测试的终结者，而是对测试提出了新的定位、对测试角色提出了新的要求。
所谓新定位，是指测试不再作为独立的阶段，而是跟开发紧密融合在一起，即开发中有测试、测试中有开发，开发测试持续集成密不可分。而对测试角色的新要求，套用现在最流行的描述叫做具有测试思维的开发或者具有开发技能的测试。关于这一点业界有一些不同的声音，其中不乏大牛，他们认为测试和开发是两个平行空间的事件如果强行搓揉到一起会引起时空错乱。我是不认同这个观点的，我认为不管是具有测试思维的开发还是具有开发技能的测试，其实是对个人能力的更高要求，这种能力是综合的，包括业务能力、技术能力、以及将技术灵活运用于业务测试的能力。随着Devops模式的普及，纯粹的开发或者纯粹的测试将不可避免的被开发测试/测试开发的角色替代。
在我翻阅资料的过程中，我发现大多数文章对于微服务框架下的测试描述，不是泛泛而谈测试理论（纯测试思维）、就是抛开了测试背景谈技术实现（纯开发思维）、再不就是介绍看着不错但是要收费才能深入阅读……基于以上原因，我决定重拾笔墨记录下自己对于微服务框架下的测试实践和思考，希望分享出来供同道中人借鉴，同时也作为自己所学所思的回顾和总结。
关于微服务框架下的测试实践和思考，我会做成一个系列，每部分都会围绕“做什么”“为什么这么做”“怎么做”来展开。“做什么”定义做什么测试以及采用什么技术做，“为什么这么做”从测试和开发两个层面解释这样做的原因，“怎么做”将描述具体的技术实现细节。
这个系列包括多少部分以及多久能完成我还不确定，依赖于项目的进度和我实践的所得，并且由于可参考的现成例子很少，这可能是个比较漫长的过程。也许几个月、也许几年、也许十几年，有心得了有成果了就写两笔，不求速效，用冯唐的话，在对的事儿上投入时间和精力，持之以恒没准就不朽了呢。
