XPY：买单侠性能测试之道
2017-11-13 19:52:35 来源: 财经新闻网
Chapter 1: 性能测试之道
1.1 性能测试是一剂疫苗，更是妙手回春的神医
测试，在早期的互联网创业公司中往往处于不尴不尬的地位。
在当今精益创业盛行和竞争空前激烈的快餐式创业时代，时间已不仅仅是金钱，几乎变身生死脉搏。
测试，则因此经常成为被忽视的那一环，而这，也常常为互联网初创企业埋下了长久的隐患。
严重者，将犹如童年阴影般长久的伴随企业的成长历程。
而之于性能测试，此现象尤甚。
当企业终于渡过服务器数量大于客户数的婴儿时期后，性能瓶颈开始浮现，并渐渐如梦魇般伴随左右，甚至可能吞噬还不太成熟的胜利果实。
机智的企业往往先人一步，未雨绸缪。
注射一剂优质的疫苗有百利而无一害。
阻碍早期企业执行有效性能测试的借口往往是过高的成本，而不得不承认，专业的性能测试要求之苛刻确实伴随很高的成本。
但更应意识到的是，性能测试执行的越早，其成本越低，执行的越晚，不单其本身的成本水涨船高，由于性能瓶颈带来的生产效率下降甚至严重生产事故的发生，更远远超出性能测试成本本身的讨论范畴了。
性能测试的意义实际远超疫苗的隐喻，专业到极致的性能测试被形容为妙手回春的神医更为恰当。
性能测试的终极目标是通过定位系统的问题，源源不断的给出技术咨询，并改进以致创新生产线的整体架构。
也就是说，好的性能测试可以成为系统架构不断进化的发动机，不但可以保障系统的健康，更能使其变得健壮。
简言之，性能测试必须做，且越早越好。
1.2 性能测试从不简单
上文已提到，专业的性能测试要求甚高。
比如，被测系统要求跟生产线上系统一模一样，从硬件设施到软件配置，从网络条件到数据库性能。
而实际上，最好的性能测试就是直接在生产线上进行，像双十一那样，然而这在当前现实世界中几乎是不可能的。
同样看起来不可能实现的还有很多：
比如，系统中对接的第三方系统，如果你的合作伙伴没有提供类似线上的性能测试环境（往往没有），那么这部分系统就只能通过Mock方式来模拟实现。
测试客户端同样要求跟线上一模一样。
而光单单模拟网络环境就已经是几乎不可能，即便你有足够多的成本去从全国甚至全球各地来模仿客户的真实行为。
而对于像秦苍科技这样极其倚重风控系统的金融科技公司，在保证不泄露任何客户隐私信息的前提下，如何模拟上百万真实客户的信息来为系统施压，也是近乎无法解决的现实难题。
此外，实际的业务过程中，客户流量所呈现的行为模型往往不尽相同。
性能测试中的28原则和Spike压测也不能充分覆盖特定业务领域的所有流量模型。
问题永远存在，答案往往不止一个。
Chapter 2: 秦苍的性能测试解决方案：XPY的前世今生
专业性能测试要求测试环境与线上服务端的完全一致。
而之于性能测试，容器(Docker)技术几乎是革命性的解决方案。
容器云的使用几乎可以保证生产和测试环境两者的完全一致，而差别仅仅是体现在规模上。
目前，秦苍科技正走在微服务和容器化道路上，本公众号也会适时推出秦苍微服务和容器化的实践和心路历程。
所以目前对于秦苍性能组而言，核心精力放在了测试客户端的优化上。
而在客户端面临的诸多问题里，首当其冲的便是性能测试效率的提升。
这也就有了XPY的诞生记。
2.1 传统性能测试解决方案
传统性能测试场景大致如下：
首先，下载安装一个测试客户端，比如全球市场占有率长期稳居第一的HP LoadRunner。
然而，工作还没开始，问题就已经来了。
费尽周折，装好LR，开始准备测试。
撰写测试用的测试脚本。
配置要监控的远程机器信息。
配置要监控的机器指标。
配置测试场景。
终于在复杂繁琐的GUI上一番大动干戈以后，
部署完成，测试准备阶段结束。开始测试！
测试过程中，客户端要监控测试日志，可能还要登录到服务器上监控服务端测试日志，各种Cat,Tail, 编辑器命令，又是一番折腾。
终于测试完成！然而，真正的工作才刚刚开始。
面对大量测试数据，手动拷贝，整理，分析，画图，撰写测试报告。
这还没完，测试报告写完可能还要做DEMO，这样整个一轮性能测试才算完成。
生活很艰难，而这样的性能测试让生活变得异常艰难。
大量人工操作，反复无意义，且极易出错。
相信很多测试工程师都有过当次测试报告里出现以前或者过期测试数据的糟糕经历。
人，总会犯错；而机器则不然。
我们经历过这些，所以秦苍性能组有了新目标：
开发一键从测试设计到测试报告生成的全自动性能测试平台。
2.2 XPY诞生记
自动化测试是自动性能测试的基础。
SPY是秦苍第一版基于C#的自动化测试平台。
而基于SPY和C#，秦苍有了第一版的半自动化性能测试平台。
在性能测试强度和频度要求都日益迫切, 而传统解决方案烦杂低效的背景下，XPY诞生了。
XPY的名字来源于SPY自动化测试平台。
XPY的设计原则：
一键从测试设计到报告生成。
XPY的技术核心：
1.模块微服务化。
2.服务容器化。
3.使用开源软件。
下图便是XPY第一版的架构图。
在微服务方面，我们选择了更轻量级的Embedding Jetty作为Web Service服务端，而没有使用相对耗费资源更多的Spring框架。
当然，我们保留在未来使用Spring框架的可能性，毕竟其是已经被市场验证过的相当成熟的微服务框架。
而在容器方面，我们使用了当前最成熟的Docker技术。
通过Docker Compose技术一键即可部署整个测试平台。
在开源软件方面,我们:
采用Ansible做配置管理。
SSH+Dstat监控机器信息。
Jmeter为默认测试端。
ELK做日志收集管理。
Apache Velocity做模板引擎，MatPlotLib生成监控图片，LaTeX生成PDF版本测试报告。
系统整个工作流程很简练，前端页面是测试设计入口。
输入测试设计信息，比如各服务的域名端口，测试线程数，时间等等，提交，测试开始。
后端Controller模块接收测试设计，自动生成Jmeter测试脚本，并分发测试配置，而后调度Jmeter Cases和Monitor模块开始测试和监控。
测试结束以后，Jmeter Cases和Monitor输出的csv文件分别作为Plot模块的输入生成相应的业务或机器指标图片。
与此同时，TexGen模块使用模板引擎生成LaTeX的输入文件，tex文档。
最后tex文档和Plot模块生成的图片，通过调用XeLaTeX服务编译生成最终版本的PDF测试报告。
前端页面的测试设计是整个测试过程中唯一的手动输入过程。
2.3 XPY带来的收益与思考
自动化极大提升了测试效率。
测试环境的一键部署，测试脚本的自动生成，测试数据的自动填充和测试报告的一键生成都极大的提升了秦苍性能测试的效率。
而自动化最大的优点就是在重复工作中，最大限度的降低了出错概率，这是机器所擅长的事情。
微服务极大的提升了开发效率，降低了维护成本。
1.随时重构，比如Controller和Monitor模块，都经历过在一周之内从Shell脚本到Python编程的重构过程
2.每个模块都可作为独立服务来使用，比如监控服务，可以通过调用REST接口实时监控任何一台被赋予了相应权限的机器的健康状况。
3.微服务带来的松耦合使得后期的Debug和维护也变得异常清晰和简单。
容器技术带来了一系列便捷效应。
1.Docker Compose一键搭建测试平台，使环境部署变得轻而易举。
2.Docker的特性让微服务的开发部署发布前所未有的迅速高效优质。
最后，开源技术给予了开发人员更多自由和选择。
开源，是我们的信仰。
而我们的XPY在版本稳定以后，也将择时开源。
Chapter 3: XPY的未来
XPY的设计初衷是因为遇到了LoadRunner和MsTest性能测试的弊端和瓶颈， 要做一个针锋相对的服务化的性能测试软件，即SAAS。
然而，随着业务的发展和更多的思考，我们开始重新审视这个设计初衷并最终决定将XPY升级为更为广泛适用的PAAS。
不再仅仅是一个软件。
升级版的XPY，将加入MongoDB存储测试数据，K8S编排后端容器服务，ReactJS前端展示数据和测试报告。
目前工作中，我们会为每个业务组搭建一套单独的测试平台，使各业务组以SAAS的方式来使用XPY。
而未来的XPY将是一个真正的测试平台，各业务组将以独立用户的形式随时接入XPY平台，执行性能测试，获取测试报告，查看历史数据等等。
不远的将来，XPY会做为一个全链路压测的PAAS平台，为秦苍的产品线保驾护航。
作者介绍
于国庆
浙江大学数字媒体技术本科，新加坡国立大学硕士。目前就职于上海秦苍科技，专注于性能测试，曾先后为公司搭建了业务自动化测试平台和半自动化性能测试平台。
目前负责研发基于Docker的全自动化性能测试平台XPY。持续交付和DevOps文化的拥趸。
狂热的区块链布道师，偏执的坚信区块链技术会像互联网一样再次更新这个世界和所有人的世界观。2014年IBM裁人浪潮中，决然离开无聊的传统行业，杀赴互联网。2015年在比特币中国见证了比特币的疯狂和区块链的迷人。