/catalog/2416e7f1c515497f98c8b7cb9874d41d//catalog/821d36aa8dfd499ca4af14ac5eb2b6b3//Document/282631823061061.html/Document/264572214259781.html/Document/264193141411909.html/Document/263120166727749.html/Document/262780577878085.html/Document/262434321498181.html/Document/261700928712773.html/Document/260317655674949.html/Document/259254117072965.html/Document/257842584657989.html/Document/257479171993669.html/Document/255707511132229.html/Document/255351757029445.html/Document/250725636485189.html/Document/249686534438981.html/Document/248257145659461.html

两个案例全面阐述全链路测试怎么做

首先我们先针对全链路功能测试部分进行一下讲解。去年的时候,有一家电商公司可能知道我一直在帮银行做相关的测试,就请我帮他们去做一些规划。这个平台有虚拟订单,也有实体订单,方式不太一样。


还涉及到分账分佣以及跟银行的对接,如个人通过微信朋友圈也可以进行推销,有上下级关系,不同的层级中也涉及相应的分账。整个测试过程中涉及到资金的交互以及商品是否能买卖等情况。


我们在测试的过程中发现小金额订单的结算过程中,会出现无法正常扣钱、正常退款等情况,如1毛钱、1分钱。同时在分摊分账的过程中计算出来也有一些问题。


整个过程中我们通过模拟准生产环境去跟第三方平台进行业务交互,模拟各种业务交易的场景是否能够正常处理。这个过程需要测试人员用真实的、不同的银行卡账户去买东西,用真实的手机号去注册。除了提货这个环节,其他的环节全部都是真实的。

全链路功能测试

全链路的测试过程中会涉及到不同系统的业务交互关系,我们在测试的过程中一定要将业务场景梳理出来,去进行测试,以上这部分就是全链路测试的功能性测试。

接下来我们讲一下全链路测试的非功能性的测试。前段时间我帮一个银行做的一个项目,他们是做了系统的重构,已经上线了十几天了。数据量非常大,几千万的数据量。在这基础上去做测试。


在这个系统中我不是测试人员,我是负责SQL调优的。我通过全链路的监控方式把比较慢、耗时比较高的语法定位出来,定位出来之后进行调优。


在这个系统中测试工作是由甲方的测试人员自己去做,我只是负责调优。所以在测试过程中覆盖度的高低情况我并没有去参与。


我只负责在开发和测试人员在测试、开发的过程中,通过第三方监控工具把交易耗时的时间和交易码等与相对应的语法定位出来,定位出来之后,针对SQL进行调优。是否第三方有交互我就不负责了。

全链路功能测试

全链路压测就是预判上线之后是否会出现故障,同时也是降低运维成本。如果上线之后问题比较多,开发人员和运维人员就会每天忙于运维,而没有时间去做新的功能的开发。这也是性能测试人员和全链路测试人员在企业存在的重要性和价值。


大家将来上升到测试管理人员或者性能测试管理人员的时候,如果老板对你们的价值产生质疑,那我们可以回应他,如果没有做性能测试,如果出现意外事件,你要多购买多少台硬件。


开发人员和运维人员要定位问题、还要请人去复测,这个时候成本就更高了。另外客户的体验也会很差,一个系统经常出问题,客户还会继续跟你合作吗?


我们当时在测试这个系统的时候,出现的问题是上线后第三方的外呼太多了。上线之前我们内部的系统我已经调优过了,几乎都是在毫秒级以内了。


但是在业务过程中,交易调度了三四十次。如果每次1秒,那就是三四十秒了,但是我们内部语法是毫秒级的。这里的问题就是架构设计的问题。


如果我们在全链路压测中遇到这类问题,排除SQL没问题,我们就要看看转换SQL是否有问题,就会发现是for循环一直调用,导致问题出现,这样就可以把问题定位出来了。


刚才我们讲到了性能测试中响应时间慢的问题,但是我们的全链路测试不能只靠这个指标。我们作为性能测试专家也好、性能测试支持人员也好、我们要了解业务的拆分和流量的预估。


流量的预估指的是QPS到这台服务器的流量是多少,可能每秒钟要写入100万笔,另一台服务器是1000万笔,那我们前端的并发要设置多少,均摊到不同的数据库才可以达到每秒钟我们需要的数量。这一块内容后面我们也会进行详细讲解。


在全链路测试的过程中,如果出现软、硬件不够用的情况,我们要考虑是否需要扩容集群来满足相应的指标,或者并发量少的时候要递减。


之前我帮一家公司做问卷调查,一个全国性的学生就业情况调查。当时他们担心会有问题,让我们帮忙测试调优。流量一直正常开着,成本会很大。


给他们建议,在高并发的时候通过弹性的方式无限扩容,来增加流量,提高网络的访问量,当这个问卷调查做完后,就把流量降到最低,通过这种方式来降低成本。


财务系统这类系统会涉及到跨年度的大量数据结算。之前我遇到一个系统,涉及十几年共计好几千万笔数据,好多表都通过填表的方式去核算、计算。他们问我,这个能不能帮忙调优,我说我只能部署到能正常展现出来,不让它很慢,但是没办法达到结果秒级反馈。


他们需要多少毫秒之内能出来,我说没办法,这么大的数据量,最多只能到几秒以内。十几年的数据都要去计算,建议通过跑批的方式结算出来,不能实时结算,这样才能提高效率。


我们在全链路测试的过程中,要把容量的规划也要考虑进去,才能知道有没有问题。这个系统存在问题已经十多年了,到了我这里才把这个问题处理掉。


之前他们也有做测试,在测试的过程中只是开发人员帮助测试人员构造数据,构造完成之后,就按照比例扣减,在某种环境下去压测。


我们当时很大胆地要求他们在硬盘空间充足的情况下,把原来的客户数据脱敏导出来,模拟大量计算的过程中有没有问题。出了问题之后,我们再去做调优。


全链路测试我们要把交易流、场景流、容量、硬件设施设备都要大胆的提出来,扩展进去,做不到的提出来。在测试方案提出之后,让老板知道我能做这些事情,做不到不是我能力的问题,是资源的问题。

 

接下来的文章会继续为大家介绍全链路测试的场景分析以及技术方法,欢迎大家继续关注。