从拍脑袋到全链路压测，阿里11.11容量规划三阶段
-
本视频来自阿里巴巴研究员蒋江伟在ArchSummit北京2016的演讲。
-
公众号后台回复关键词「双十一」下载演讲PPT。
亲历双十一
从2009年到2016年，参与了8届双十一技术备战工作。2009年的双十一，印象并不深刻，主要原因是当时整个淘宝的体量已经很大，每天的交易额已经有几亿的规模，而当时的淘宝商城双十一交易额只有5000万左右，和几亿比体量还是非常小的，所以感觉还没开始就过去了。
到了后面几年，每年都要花费好几个月的时间去精心准备，要做监控、报警的梳理，要做容量的规划，要做整个依赖的治理等等，也整理了各种各样的方法论。这是一个过程，当然在这个过程里面也沉淀出了很多非常有意义的事情。今天有人问我怎么做双十一，怎么做大促活动，我会告诉他一个非常简单的方法，就是做好容量规划，做好限流降级。
2008年，我加入淘宝，直接参与淘宝商城的研发工作。淘宝商城就是后来的天猫，当时整个淘宝商城的技术体系，和淘宝网是完全不一样的，是完全独立的体系。它的会员、商品、营销、推荐、积分、论坛，都和淘宝网没有任何的关系。两套体系是完全独立的，唯一有关系的是整个会员的数据是共享的。
2008年末启动了「五彩石项目」，把两套体系的数据打通、业务打通，最核心的点就是业务的发展变得非常灵活。这个项目的完成给淘宝商城的发展带来非常大的飞跃，后来淘宝商城也升级品牌为天猫。
另外，这个项目里还有一个很大的意义，就是比较优雅的实现了架构的扩展性、业务的扩展性和技术的扩展性。我们实现了整个服务的全部服务化，抽取了所有与电商相关的公共元素，包括会员体系、商品中心、交易中心、营销、店铺、推荐等。基于这个体系，构建后来像聚划算、电器城、航旅等的业务就非常快了。打破原来的架构，将整个公共的服务抽取出来之后，上层的业务跑得非常快，这就解决了业务扩展性的问题。第一次大规模使用中间件是在这个项目里，中间件3剑客，HSF、Notify、TDDL得到了很大的创新沉淀，并被大规模的使用。分布式带来的问题是一个系统被拆成了很多的系统，这其中也涉及到了扩展性的问题。这个项目也带来了技术的进步，从业务的发展到技术的扩展性，都达成了非常好的目标。
为什么要做容量规划？
2012年，我开始带中间件产品线和高可用架构的团队。那么为什么要做容量规划呢？双十一推动了阿里巴巴技术上非常大的创新，容量规划也是双十一在这个过程中非常好的创新。
今年做双十一的时候，老板问我今年还有什么风险？我告诉他风险肯定很多，但是最终如果系统出问题了，肯定发生在交易相关的系统里。阿里巴巴的系统分两部分：一部分系统是促进交易的，比如推荐、导购、搜索、频道等都是促进交易的，会做各种各样的营销；另外一部分系统做交易、红包、优惠等相关系统。
原因非常简单，导购类的系统留给你足够的时间去做判断，它流量的上涨不是瞬间上涨，而是一个曲线慢慢上升，它留给你30分钟做出判断。但是交易系统没有留出任何时间判断，一旦流量开始，没有给人反应时间，没有任何决策的时间，所有的行为只有系统会自动化执行。这个过程里面容量规划变的非常重要。
在早些年的时候，我们业务的自然增长本身就非常快。印象非常深刻的是，当时大家购物的时候打开的商品详情页面，有一段时间这个页面的负载比较高，公司召集了一些对于虚拟机调优、性能优化比较擅长的人来进行优化，调优了几天之后系统终于挂掉了。还好也在做一些扩容的准备，扩容完成，重启之后系统恢复了。这说明了什么？在早些年的时候，淘宝网也是一样，对容量的准备和预估是没有概念的，不知道多少容量能支撑整个系统需要的能力。
新业务不断地上线，业务运营、促销类的活动也非常频繁，记得有一次做一个促销规模非常大。会员系统非常重要，因为所有的业务基本上都会访问会员中心用户的数据，包括买家的数据还有卖家的数据。那时物理机单机缓存的能力大概在每秒处理八万请求的规模，今天来看是远远不止。但当时还没有到高峰期的时候就达到了六万，这是非常大的一个数字。
我们就把所有访问会员的系统全部拉出来，看哪些与交易无关就通知需要停掉，或者停掉一半。比如把与商家相关的，与开放相关的，与社区相关的系统停掉。在这个过程里面发生了各种各样的问题，总结来说就是我们根本不知道容量怎么去做，或者说根本就没有概念需要去做容量。所以容量规划归根结底就是：在什么时候什么样的系统需要多少服务器？需要给出有确定性，量化的数字。
容量规划的三个阶段
容量规划整个过程大概经历了七八年的时间，总共三个阶段。
第一个阶段在非常早期，我们评估的方法就是「拍脑袋」（经验判断）。根据负载的情况、系统的响应时间，各种各样的表现去拍一个数字出来。当时我问一个高管，到底怎么去判断服务器够还是不够，要支撑多少流量？他告诉我一个经验值，每台服务器支持100万的PV。
当时一天的流量曲线会有三个峰值，九点到十点，中午两、三点到五点，晚上八点到十点之间都是峰值。为什么是100万呢？这也是一个经验值，当然也有一点科学根据。我们希望做到一半的服务器停下来后能够去支撑线上的流量，同时在峰值的情况下，全部能够支撑住。实际上单机能支撑320万的PV，这是当时的经验值。
当然这个经验值当时是起作用的，原因非常简单，因为当时的系统架构简单。可以理解为把整个淘宝所有的逻辑和模块都集中在一个系统里面，所以各个模块之间的热点有时间差，通过一台服务器内部CPU的抢占或者调度在OS层面就解决了。
到了第二个阶段是线上压测阶段。因为一旦到了分布式之后，就会出现问题。举个例子，本来是会员的调用和交易的调用在一台服务器上，但是分开之后，流量比例就不清楚了。所以必须要引入一些压测机制，我们引入一些商业的压测工具来做压测。
当时有两个目的：第一个是系统上线之前要做压测，判断响应时间、负载能否达到上线的要求；第二个目的是希望能够根据线下的压测情况，准确地评估出线上大概需要多少服务器。第二个目的做起来就比较困难一些，记得当时性能压测团队还做了一个项目，叫线下线上容量之间的关系。因为线上的环境和数据与线下完全不一样，这里面没有规律可寻，没办法通过线下压测的指标反馈到线上去。这时候怎么办？首先是直接在线上压测。当时来看我们做这个决定是非常疯狂的，因为没有一家公司，包括阿里巴巴自己也没有人在线上直接做过压测。我们写了一个工具，拉取出前一天的日志直接在线上做回放。比如，根据响应时间和负载设定一个的预值，达到预值触发的时候看它QPS的多少值。
其次我们做了一个分流。因为阿里整个架构还是比较统一的，全部是基于一整套的中间件，所以通过软负载，通过调整配比，比如把线上的流量按照权重调整到一台服务器上，通过调整到应用端和服务端不断地调整到一台服务器上去，增加其权重，这时候它的负载也会上升，QPS也会上升，把这个过程记录下来。
这里已经是两种场景了，一种是模拟，回放日志。第二种是真实的流量，把做成自动化让它每天自动跑产生数据。这个事情做完之后，它从一个维度来说，替代了线下性能压测的过程。因为它可以让每个系统每天自己获得性能的表现情况。项目发布，或是日常需求的发布的性能有没有影响的指标都可以直接看出来。后来性能测试团队就解散了。
这里有个问题，它还没有基于场景化。场景化非常重要，比如我买一件衣服，平时买东西的流程可能是在购物的搜索框里面搜索，或者是在类目的导航里搜索，从搜索到购物车，再到下单这样的一个过程。双十一推的是商品的确定性，很多频道页面会把卖家比较好的促销商品直接拿出来作为一个频道页。双十二的时候推的是店铺，KPI不一样，推的东西也不一样。
双十一商品相关的服务器系统的流量会高，它所需要的服务器也会更多一些。双十二和店铺相关的系统服务器所需要也会更多一些。这与平时的流量表现是不一样的，用平时的容量去计算场景化流量，这也是不准确的。
我们也做了一件非常重要的事情：全链路压测。这是我们在2013年完成的事情，之前从没有对外讲过，这是一个核武器，它有个分界线。2009年是最顺利的一次双十一，因为没有什么流量，我们忽略不计。2010年、2011年、2012年，其实每年的双十一总是有那么一些小问题，其实心里也没底。
在2013年的时候，我们做了全链路压测这个产品之后，发生了一个本质的变化。2013年的表现非常好，2014年也非常好，这就是一个核武器的诞生。对于做营销和促销类的，它是有峰值的，在这个时间点之前峰值非常低，这个时间点之后峰值突然上去了。这就是处理这种情况非常有效的一种方法。
从线下到线上：单机压测的容量评估
重点分析一下线上压测和场景化的全链路压测。
线上压测主要是由于淘宝的业务形态多样化。分布式之后各种各样的业务都出现了，它帮助解放了生产力。以前一百多个人在做一个系统，非常糟糕，但是通过分布式改造之后，整个业务服务抽象出来之后，生产力被解放了。
其次，每个业务的机器规模非常大，每个业务应用数量非常大。我们其实是做了一个分层，根据一个系统具备的容量不断计算，最后计算出来阿里巴巴的集群容量。我们先做一个应用系统，通过分流，流量通过负载导入，把负载跑到最高之后计算。把这个APP整个集群，比如100台服务器能支撑多少量计算出来。当然数据库非常难算，数据库都是提前规划的，一般来说数据库分库分表之后，都是留了好几年的量，比较困难一些。
通过这样把整个集群的量和规模全部做出来是有问题的，为什么呢？因为系统一旦开始拆分之后一发而不可收拾，拆得越来越多。系统的依赖关系虽然是有工具能够梳理出来的，但是我们没有经历看到底哪些系统会因为这个场景下面什么原因导致整个集群出现了一个小问题。一旦出现了一个小问题，整个集群全部崩溃掉，这种问题是没法避免的。
在2013年之前都是基于这套体系去做，想想也是挺合理的，每个系统算出容量，一个个集群算出来，再算出整个大集群也是可以的，但是它还不是一个非常好的解决方案。它非常好的一点是可以自动化运行，可以每天跑出系统的容量，并且可以保证系统不腐化，日常的性能、指标不腐化。
压测平台的架构
2013年的双十一是通过这套系统做的。通过几种方式，通过模拟以及流量的复制，转发的引流，还有负载均衡的流量去实现。整个系统做成自动化，每周都会跑，根据发布前后的一天跑出来数据之后生成一个报表反馈性能有没有下降可以得出。根据计算值准备整个活动流量大概要多少。这里有一些数据，每个月有5天自动做压测，这种情况下靠人工做性能压测是做不到的，因为它是自动化的。
刚才也讲了一些缺陷，它是以点到面，通过一个点的容量评估，扩展到一条线，扩展到一个面。最大的问题是没有一个人搞得清楚整个架构到底怎么样，整个系统依赖关系里有遗漏之后会形成整体的崩溃。
为什么要做场景化的容量评估？
我们需要场景化压测的另外一个原因是因为整个背景的流量大部分用的是分流，分流意味着是用真实的流量去做的，所谓真实的流量其实是很低的，和做活动相比流量非常低，没有背景流量整个机房的网络设备和交换机的流量无法跑满，所以这些问题是没办法暴露出来的。第二个问题是场景化的确定性，每个人购物流程是不一样的，在不同的流程下面整个系统的资源必须确定下来，要用最少的服务器支撑最大的量。
基于此，当时有一套争论，要怎么做场景化压测这个事情？第一种方法，把整个淘宝网隔离出一个小的环境里面布100多个系统。整个流量引进来，把集群跑满，流量跑满。它比较好地解决了依赖关系的问题，如果依赖出现问题的时候，在这个环境是能够验证的。但是没办法解决环境的问题，那一年我们公司有一个业务，就是因为没有采用这套方案，采用了类似于小环境的流量去验证的方案，导致入口交换机的整个流量跑满。
场景化容量评估
所以需要有一个更简单可靠的评估工具，这就是基于场景化的全链路压测。2013年之后我们全部基于这套体系在做，首先要造数据，流量希望能够更接近真实的情况造出来。刚才提到临近峰值是没办法做决策的，唯一能做的是什么？能够提前模拟一次零点的峰值是什么样子的吗？我们希望把整个流量模拟出来，这是一个理想的架构，但是它也有很多困难的地方。
我们要尽可能把数据造得精确，各种场景都要模拟出来，比如优惠券如何使用，购物车里商品比例是多少，一次下单有多少商品，最后多少商品提交到支付宝等等。数据量每年越来越大，比如以2015年为例，数据量接近1T，把这1T的数据传到中心，通过中心传到压测节点上去，这就是压测集群。它是一个压测工具，但是它本身又是一个集群性的压测工具，它可以产生非常巨大的流量，与双11一模一样规模的数据。
把集群部署到CDN节点上，产生巨大的流量。这里有一些技术点，压测的工具要支持多种协议，比如HTTPS协议，需要提升性能。还要做流量的控制，根据业务场景的不同调节流量。第三点流量需要染色，右图反映了真实的流量，这些全部是在线跑的，没办法在线下模拟这个环境，否则会影响线上正常的流量，所以要把正常的流量和压测的流量完全区分开来。第四点是流量的隔离。没有流量隔离之前，我们只能在零点以后流量很低的时候，每个人都盯着自己的系统有没有出现什么问题，非常辛苦。第二年提了一个目标，希望能改善大家的幸福指数，所以我们推出了流量隔离。
流量隔离是把整个集群从原来在线的集群，比较快地通过负载均衡隔离出一个集群出来。当然隔离出的集群规模是非常大的，它可以占原来集群的从90%到10%。比如原来有10万台服务器，可以隔离到9万台服务器。因为准备做大促的时候，比如双十一的流量是平时的20倍以上，所以平时流量非常低是可以隔离出来的，并且不会影响现有的流量。
整个过程是怎么样的？以图为例，ABCD这4个系统是日常的流量，原始的场景C所需要的服务器多，但是压测之后发现B和D需要的服务器比较多。整个过程都是自动化的，如果C不需要这么多服务器，它的服务器就会被下线，这些服务器就被自动加到B和D。由于都是自动化跑，效率非常高，而且不需要到凌晨跑。最后需要把隔离出来的集群还到原来在线的集群，变成服务器的比例，就可以准备第二天的大考了。
容量评估的流程
整个容量评估的流程，从数据构造到流量环节，我们都有一个指挥部。比如我们要做一次活动，这次活动大概要5万笔每秒的交易量，输入5万笔每秒这个数字之后，整套系统开始运作，做压测、做弹性调度、做隔离，这就是整个自动化的过程。容量是可以预测的，但是没办法规划，只能做限流。我们可以非常精确地预测出双十一大概会来多少量，会来多少用户，以及当时的峰值，都可以完全精确预测出来。
但预测出来也没有太多的意义，能做的就是限流笔数，比如2016年我们做到了17.5万笔，限流的值设定到了17.2万，所有的系统先设定到这个值。这也是没办法的，因为真实的流量比这个大得多，要支持真实的流量成本会非常高。
日常占有的服务器是非常低的，在大促的时候我们基本上都采用阿里云的服务器，所以成本下降明显。所以说整个容量规划限定了一个值，比如说17万，明年可能是20万，或者25万，在这个值的基础上，通过基于场景化的全链路压测工具，然后把整个系统的容量压测出来，计算出来，把整个服务器资源占用拉平。这样做的好处是用了最少的资源做了一次最成功的活动。
场景化容量评估的表现
从2013年开始，我们通过这套技术发现了大量的问题，而且这些问题经过日常的测试，功能测试，或者一些工具的测试，是没办法发现这些问题。硬件、网络、操作系统的问题，从来没有发现的问题全部暴露出来，在大负载情况下表现出各种诡异的问题。
任何一个问题在双十一发生，可能都是灾难性的。2013年我们做完这些事情之后，回头看2012年、2011年，不出问题还怪，肯定会出问题。凡是峰值流量是平时峰值超过多少倍以上的活动肯定会出问题，因为很多的问题没办法通过一些逻辑，通过一些思考找出来的，它必须借助一个真实的环境，模拟出所有场景的流量把它营造出来。
容量评估的总结
容量规划是一个领域、一个长时间的过程。最初利用商业软件做性能压测，当时觉得这个软件应用挺好的，也能够支撑整个容量的一些计算，甚至今天很多的公司还在用类似的软件做性能的评估，它也是不断引进的过程。后来发现，其实与真实压测评估的容量还相差非常远，所以我们引入了线上的压测，引入了分流、复制流量、及日志的回放，通过一个个节点把自己的流量评估出来。
当时觉得这套系统很厉害，因为当时做了这套系统获得了整个技术部的创新大奖，所以觉得有了这套系统以后，以后做双十一就不用愁了，做任何活动就不用愁了，觉得这是非常了不起的系统。实际情况还是需要不断地发展，做了全链路压测，整个链路基于场景化的真实场景模拟，把整个集群压测出来。
回过头来看，在一个领域里面，当自己满足于当前现状的时候，比如说CSP“日常的压测平台”能够完全满足于当前现状，而且已经领先于国内很多产品的时候，其实你还是可以继续往前走一步。
我们只是做了双十一创新里容量规划这个点。阿里巴巴整个技术架构非常统一，因为做了全链路压测之后，很多的业务单元，像支付宝等等都可以采用这种方式做，它可以非常简单地复制出去，这也给我们带来了非常低的成本。从研发开始到学习，以及运维的过程，运维的产品线，带给了我们非常低的成本。所以我们整个团队人非常少，做全线路压测就4、5个人，但是它服务了整个集团100多个业务方，这也是因为整个架构的统一性。
今年双十一做完了之后，我们的CTO也给我们提出了新的挑战：双十一的整个过程可以投入更少的成本，全链路压测是对日常系统的一种验证，而不是找问题本身，同时希望我们的系统更加的自动化和智能化。我们正在思考如何实现。
——End——
< 讲师介绍 >
蒋江伟，花名小邪，阿里巴巴研究员，08年加入淘宝网，参与业务系统研发工作。12年开始负责阿里巴巴中间件技术产品和高可用架构，中间件产品是阿里巴巴电商等业务分布式架构的基础技术组件，使得各种业务系统能快速构建一套高可用的分布式架构集群。
从拍脑袋到全链路压测，阿里11.11容量规划三阶段 (qq.com)
当代码变更遇上精准测试的总结-腾讯云开发者社区-腾讯云 (tencent.com)
Martech 代码变更遇上精细化测试的总结
需求背景：
敏捷模式下迭代频繁，回归测试时总是不知道变动的范围。Devlop 有的时候也不知道他改了哪些东西，影响到哪些节点，或者是很多人改的，彼此不知道。遇到有代码洁癖的，改了别人的代码，大家都不知道。通常情况是，要么测试范围定小了，遗漏了；要么测试范围过大，付出过多代价。每次回归，测试心里总没底，生怕漏了哪里。如何才能准确定位到变更范围呢？
项目测试过程的痛点：
1.迭代更新快，人力有限
2.多分支代码合入到主干分支，修改哪个文件哪个行，测试不可控。
3.代码更新影响哪些功能无感知
4.盲测，上线风险大
5.无法更加精准监控代码质量
6.不能做到高效精准，不可衡量ROI
解决方案：精细化测试探索
1流程图：
2录制自动化测试+phpcoverage 配合落地XDEBUG文件，解析覆盖率文件，生成文件-行号/函数-用例 映射关系表【phpcover_process.py】
XDEBUG_IP服务ip_DATE日期.txt 文件如下：
3基于git diff 针对版本号之间的差异化分析.【git_diff.py】
2.1过滤相关文件（phpunit，js，test文件，vendor公共库）
2.2记录当前代码分支版本号（分支-旧版本-新版本-系统-环境）
2.3针对新版本号和旧版本号 文件中行变化的明细入库（版本号-文件-旧行号-新行号-变更类型class fun）
4生成命中的测试用例【down_accurate_case.py】
原理图：
待测json文件
5插桩-自动化测试（指定case_id顺序执行）-缺陷数量回写DB【accurate_runcase.py】
6统计精准测试效果数据统计【accurate_stat_image.py】
7.最新跑完的测试覆盖率数据新增/更新/删除 文件-用例-行/函数 覆盖率关系表，形成闭环为下次精准测试做铺垫【phpcover_process.py】
总结
·精细化测试基于自动化覆盖率到达一定量的基础上去做比较有意义。
·通过这个探索能让我们更加深入的去了解被测系统及架构，在保障质量的前提下，在不断的版本迭代过程中更加高效、可靠、自信地制定合理的测试计划和执行我们的测试工作。
·被测系统php 语言+ git代码管理，暂不包含js的精准性测试，测试解析语言：python。
精准测试的动因、概念、特性与价值-腾讯云开发者社区-腾讯云 (tencent.com)
虽然测试流程很规范，但是软件质量还是不如意
随着测试行业的发展，软件测试做得越来越规范，但大部分的测试还是基于对业务的理解，与真实业务数据还有差距，准确性难以保证，测试结果无法精确的对软件质量进行定义和判断，系统上线后，问题开始暴露出来，使用体验差，更有甚者造成巨大的经济损失。归根结底，就是因为测试不充分，没有引入精准的测试分析，仅依靠测试经验是根本无法判断的。
软件项目验收缺少好的运行检测手段，检测结果缺少技术公信力
软件是拿来使用的。虽然软件项目验收过程中验收的内容比较多，包括合同约定内容、技术协议、开发文档、产品文档、用户文档、程序代码等，但客户最关心的是他们的业务能否真的在系统中落地运行，并且运行良好，单凭投入少量人力进行业务功能的验证，抽样的检测结果不代表软件全部，可信性不具备技术公信力。
传统的手工测试，测试执行无法精准量化控制，测试效率比较低
使用传统的手工测试，采用的是基于人工评定的黑盒测试方法，打造高可靠性的软件产品需要投入大量人工成本。由于测试执行无法精准量化控制，凭主观定性评价结果为主，对人力经验依赖大，人员变动情况大，质量抖动厉害，看不到明确测试差距和量化目标。虽然在不断的执行测试，但缺陷发现率并不高，无效的测试消耗了大量的测试成本。
测试人员不能精准把握缺陷现场，与开发人员协同工作困难
缺陷处理的一般流程是：测试人员执行用例，发现缺陷就提交缺陷系统，开发人员看到缺陷，进行重现或远程调试。如果测试给开发提供的测试结果都是比较模糊的功能逻辑描述，重现缺陷需要花费大量的时间。如果测试人员采用了精准测试技术，通过执行的用例就可以找到对应执行的程序代码块，这样解决问题就会快很多，开发人员和测试人员之间的协同工作就会轻松好多。
分布式、微服务架构，软件越来越复杂，测试挑战性越来越大
采用分布式/微服务架构，使软件系统越来越复杂，测试的挑战性越来越大，采用传统的测试方法执行测试，系统质量也难以保证。
在移动互联网大力发展时代，软件开发对质量要求越来越高，而迭代开发要求项目周期越来越短，快速的版本验证面临挑战。
二、精准测试：一种可
追溯的软件测试技术
从字面理解，精准就是非常准确。非常准确需要用数字说话。
在测试领域，精准测试是一套计算机测试辅助分析系统，对测试过程的活动进行监控，将采集到的监控数据进行分析，得到精准的量化数据，使用这些量化数据进行质量评价，利用这些分析数据可以促进测试过程的不断完善，形成度量及分析闭环。精准测试是一种可追溯的软件测试技术。
三、精准测试的核心：数据与追溯
精准测试的核心思想就是使用非常精确和智能的软件来解决软件测试的问题，从根本上引领从经验型方法向技术型方法的转型。质量的评估不再靠经验，而是通过精准的数据来判定。
精准测试没有改变传统的软件测试方法，区别只在于，由软件去采集测试过程执行的代码逻辑及测试数据的过程，自动建立测试用例与程序代码之间的逻辑关系。在测试过程加入软件的采集过程，可以形成正向和逆向的追溯。
通过正向追溯，开发人员可以看到测试人员执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。
通过逆向追溯，测试人员通过修改的源代码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例，达到测试覆盖率最大化。
四、精准测试的关键特性
软件测试示波器
在功能测试过程中自动分析程序运行的一些数据指标，以波形的形式进行实时输出。示波器是一种实时的监控，实时的计算测试过程数据并展现。
用例和代码双向追溯
执行一个测试用例以后，精准测试通过程序自动的记录和显示这个测试用例执行的代码。如果测试人员关注某一些代码行，它可以追溯出哪些用例在执行过程中运行过这段代码。
智能筛选回归用例集
根据代码的变动范围来直接精确的定位需要回归的用例，这样使回归测试所需的时间更短，回归的范围更准确。
测试覆盖率精确分析
精准测试覆盖率形式多样，最高支持标准MC/DC（修订的条件/判定覆盖）的100%覆盖率要求。
软件缺陷快速定位
根据缺陷与用例的对应关系，快速找到执行用例对应的代码行。
五、精准测试体系
方案的价值和实现
根据前文所讲到的需求、概念和关键特性，我们可以设计出如下的一种精准测试体系。这也是我们的技术团队一直在客户现场采用的测试方案。
组成部分
精准测试体系主要以持续集成平台、统一测试平台和测试监控分析平台为测试能力支撑。
通过持续集成完成代码的构建编译、静态代码扫描和测试环境部署；
使用统一测试平台实现自动化测试回归；
通过测试监控分析平台，精确、详尽的记录测试用例运行的情况，提供大量原生分析性数据，进行事后的缺陷分析、追踪，建立测试用例与程序代码的关联，实现测试用例和程序代码的双向追溯，真正实现数据化的测试管理。
测试过程
精准测试的整体过程如下图所示：
精准测试需要结合持续集成、持续部署和持续测试的过程，并结合白盒测试技术和黑盒测试技术，实现代码规范、质量和安全扫描，完成单元测试及覆盖率的评测，通过自动化测试的手段实现系统的功能测试。通过测试监控分析平台，从静态测试和动态测试两个维度实现软件质量的精准化评估。
双向追溯
精准测试的核心流程就是通过测试监控分析平台实现测试用例和程序代码的双向追溯。
在测试监控分析平台的帮助下，实现测试用例和海量的代码执行信息自动关联，精确到函数级别及代码块级别。测试人员可以知道测试用例到底测试了哪些功能，覆盖了哪些代码。
上图就是测试用例到被测代码的正向追溯，通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析；通过正向追溯，可以迅速定位缺陷对应的代码执行逻辑，帮助开发人员快速修复缺陷，可追踪难复现缺陷。
相反，在测试监控分析平台的帮助下，可以实现程序代码到测试用例的反向追溯。下图就是反射追溯的一个过程展示。
通过反向追溯，我们很容易就能确定代码块对应的测试集，获取到的增量代码，通过智能用例选取算法，可以准确的确定需要回归的测试用例。精准的确定回归测试范围，避免了全量回归造成测试资源的浪费，既保证了质量又缩短了版本的迭代周期。
代码覆盖
有了精准测试，覆盖率统计不再是白盒测试的技术专利。使用精准测试技术，系统测试也可以实现程序的覆盖率分析，而且可以不需要源代码，实现运行代码的指令覆盖、分支覆盖、圈复杂度、行覆盖和方法覆盖的统计分析。
程序代码的覆盖率统计可以是单次执行的数据，也可以是多次执行的累计数据，获得一段时间内或多人测试执行的累计效果，支持在软件研发周期内整体评估测试的覆盖程度。
传统的黑盒测试技术属于经验型模糊测试，质量、进度不可视，产生的无效劳动较多，系统与人员的管理成本极高，软件质量风险高。
传统的黑盒测试大约70%的缺陷很容易发现，但之后缺陷的发现效率会急剧的下降。而传统的白盒测试技术直接面对代码测试，难度大、效率低，仅关注覆盖率，无系统性。精准测试是采用传统黑盒测试与白盒测试相结合的模式，它可以在黑盒测试过程中，通过专用软件自动采集白盒级别的运行逻辑数据，根据可视化出来的不足点和漏洞点，引导开发和测试有针对性的补充测试用例，提高缺陷发现效率。
建设理念
精准测试体系的建立也是一个系统化的工程，需要长远规划，循序渐进，并逐步完善。需要以理论为基础，以实践为准绳，持续改进，让精准测试体系使测试更加智能化，对质量评估更精准。
六、不同项目类型对
精准测试的需求程度
并非是所有的项目类型，都适用精准测试，精准测试的核心需求是来自于对软件质量的较高要求，而不同的项目类型对质量的敏感程度是不同的。
移动互联网型的产品一般需求响应快，而且产品发布成本低，采用灰度发布，使用A/B测试方法替代传统的功能测试即使用小流量测试新功能，如有问题迅速下线，对发布质量并不太敏感。
项目型的产品一般以用户为中心，需要准确把握用户的需求，需要进行系统测试，通常采用用户测试的方式对项目进行验收，对项目的上线质量比较敏感。
产品型的产品需求由自己把握，产品的研发周期相对较长，通常都有独立的测试团队，需要按照一定的规程执行测试，由开发人员进行单元测试，由测试人员进行集成测试和系统测试，而且满足一定的质量目标才允许发布，对发布质量要求较高。
七、总结
精准测试的核心是以自动化的软件对软件测试过程数据进行记录，从而实现双向的追溯：从开发到测试的正向追溯以及从测试到开发的逆向追溯。
通过双向追溯，我们可以实现软件质量的实时监控，回归用例的智能筛选，测试覆盖率的精准分析以及软件缺陷的快速定位。
但精准测试并非适用于所有的软件项目类型，互联网应用、项目级应用和产品级应用，对软件质量的需求，也就是对精准测试的要求是逐渐递增的。
精准测试的诞生，核心动因是对于软件质量的要求。无论是项目验收公信力手段、测试效率管控、测试与开发人员的协同以及复杂的分布式架构带来的挑战，无不围绕着对软件质量的需求满足。而软件质量的最终价值，是用户体验的提升。在Gartner提出数字化转型的双模式理念后，各个领域都在寻找各自业务领域里应用和实践数字化转型的方案，对精准测试的实现过程，实际上也是软件测试过程数字化的一种体现。精准测试通过提升软件质量，改善了用户体验，从而赋予企业数字化转型更可靠的软件能力。
精选提问：
问1：为啥叫示波器，不叫dashboard？
答：示波器的概念源自于一种电子测量仪器，在软件测试中用于记录软件运行状态，通过实时分析以波形曲线形式进行呈现，它是一种技术或一种方法，类似电子电路示波器、心电图，是一种类比的叫法。
问2：什么叫测试监控分析平台？这些由哪些组成呢？
答：包括插桩组件、Agent、数据传输、数据分析、报表展示等组件。
问3：这是你们普元公司自己开发的吗？
答：是的。
问4：统一测试平台也是你们普元的吗？
答：统一测试平台是普元的自动化测试平台，详情请见：移动应用的左膀右臂：持续集成与自动化测试
关于作者：王俊其，普元软件产品部统一测试平台产品经理，十余年的开发与测试工作经验，一直专注于持续集成与自动化测试领域技术的研究，带领团队成功实施多个有关金融、保险、证券等客户的持续集成与自动化测试项目，现担任普元统一测试平台产品经理，全面负责测试产品研发、售前咨询、项目实施等工作。
浙公网安备 33010602011771号