从测试到项目质量

        从有开发的第一天起，就有测试了。

 

       最早阶段的测试是指定预先设置好的参数，手动运行程序，然后看程序是否符合预期结果。这个阶段最典型的特点是手动，以项目为单位，业务场景检验为主，阶段清晰。

 

       随着使用互联网的人越来越多，系统压力越来越大，如何检验一个系统是否能够抗住高峰期的压力，于是引入了压力测试，也叫性能测试，因为性能测试需要编码和理解系统交互的协议，对测试人员的要求有了进一步的提升，更多相关工具也出现了，帮助降低测试的门槛和提交测试效率。这个阶段的特点是从手工测试转换到机器的测试，同时伴随着大量测试工具，如load runner, jmeter, grinder 还有专门测试前端的yslow 和dynaTrace。

       

        发展到压力测试后，从测试的根本方法上没有很明确变化，更多是从工程的角度，做过提升，这也和高速迭代的互联网有着密切的关系。项目开发高速迭代，系统越分越细，要保证这些迭代不出问题，测试也要做到高速迭代，这个阶段最大的问题是很难评估迭代对整个系统的影响面，那么只能全部做回归测试，为了减少大量大频次的回归测试带来了资源消耗，测试也开始引入工程的思想，建立公共用例库，编写测试校验代码，每次修改的时候我跑一下以前的用例就行，你开发一个新功能，我写一版新用例库。这个阶段的最典型的特点是测试引入工程思想，进行开发领域，上线一个功能，测试的代码量通常比开发人员的代码量还要多，同时为了避免运行时出现问题，还有大量的代码埋点和监控，也就从这个环节开始测试就已经不是单纯的测试了，已经是项目质量的保证者了。

 

        随着微服务的兴起，工程大都按照领域去划分，系统分的更细，更散，单个应用可用，并不代表整个系统可用，所以要额外关注，系统和系统之间可能出现的问题，于是编写具有系统上下文的测试程序成了必不可少一个环节。同时为了保证整个系统不出问题，还会有关键的链路场景定时校验，如果交易系统的下单支付环节。大量的全链路测试，全链路压测也搞的红红火火，测试人员甚至做不过来这么多质量保障工作，devops的概念的引入，让开发人员也要开始重视项目质量，关注项目生命周期的各个环节。

     

        为了更快的发现和定位问题，很多公司打造出一套自己公司专属的测试平台和运维平台，集项目管理，开发流程，发布流程，测试流程，上线流程，监控配置，流程审批，图形化报表为一体的大型系统。

 

        大数据的兴起也出现了这一专门针对数据的数据质量领域，数据质量关注数据的准确，及时，一致和完整，同时关注数据在各个数据处理节点的流畅性，要做到这些保障，需要编写大量的大数据脚本以及自动化的流程。

 

        所有前面的这一些都是需要人工来确定测试范围和测试方法，有没有让机器自己感知系统系统变化或者数据变化来自己保证数据质量的呢？机器学习的火热让这个方向再次得到各大公司的青睐，通过模型训练和大量的聚类分析已经有出现类似的产品了, 这也是很多大公司在研究的方向。

 

       从来没有简单的事情，只有简单的想法，和不想做更好的简单想法。