产品版本迭代过程中，回归测试是很重要的一环。
实际操作中，下面的场景很常见
- 更新了一个版本，测试问开发需要全部回归一下吗？开发说，是的。
实际对比代码变更，测试会发现开发只是增加了少许的代码。甚至有时候只改动几行。 - 开发还可能说，回归一下某某模块就行。然后你按照开发的“指示”，结果发现其它模块发现也有缺陷。然后你埋怨开发评估的回归范围不够准确，把锅甩出去。
开发为了保护自己，以后每次遇到同样的问题的时候，都是一个回答，让你全量回归。
作为测试，你的工作量开始膨胀，天天加班，却有测不完的版本。有些核心功能测了不下几百遍。
于是要怎么办？
一些没有工程经验的技术经理开始想当然地给出他的思路——用自动化解决回归用例重复执行，提效。
思路是很自然的，但是由此也引来很多问题
- 怎么做自动化？
通常的做法就是分层——单元测试，接口测试，集成测试，UI自动化测试。
每个层次的运行时常和维护成本逐步上涨。
如果我们全部包圆了把用例都用测试框架攻克各种瓶颈实现了，这个回归测试的用例集可能是比较巨大的。执行一次回归测试时间非常漫长。
一般来说单元测试的执行周期一般是 20ms-1000ms
接口测试的执行时常 200ms-5s
集成测试1s-10s
而UI测试用例可能是 5s-5min不等。
一个产品的回归用例集500-3000不等。
- 怎么维护自动化用例。
正在迭代的版本势必引起自动化测试维护成本，小到单元测试用例，大到UI用例，改动必然引起功能变更，小则引起模块关联用例失效，严重时整个层次——如UI用例——全部失效。
每次失效，进行编码改动维护。另外我们还要测试自己的测试代码。
曾经TX的某团队就提出一种所谓的“精准测试”的想法，通过测试分析来评估改动范围，再选出要进行回归的用例来测试。理论上迭代版本都是敏捷开发，一个需求一个需求的实现像堆积木一样构建产品，所以每次迭代要回归的用例就是全体用例集的一小部分而已。
测试分析——即通过理解软件的实现，代码变动来推测可能带来影响的功能，从而分析出回归范围。
这不就是一开始测试问开发的问题吗？只不过测试把这个责任揽过来了而已。
测试分析有一套所谓的方法论
比如：
-差异对比。
差异对比包括需求对比，新的需求对比运行版本的差异
代码仓库版本对比，对比已测试完的分支和新开发的分支的差异。
- 白盒测试——通过分析代码来预测风险
当然测试分析的具体方法还可以继续展开。但是说到底，很多老江湖一看，觉得没啥新东西——这不就是老子日常在做的的吗。每个版本过来，我都是先跟开发沟通改动点，确认测试范围，自己再来分支看代码，查看变更点，新增代码，然后自己写用例，确定回归范围。到了TX大厂，好了弄个好听的名字叫做——测试分析，精准测试
确实如此，大厂有些中层，不提出点什么，显得自己很没价值。
精准测试更为值得探究的是，用逆向分析技术，通过代码变更来追踪函数调用链，从而通过自动化的方法计算出来哪些用例需要被回归，并且推荐给测试人员。
做精准测试，最难顶的就是产品架构相当零乱—耦合模块太多。这个时候，如果用例预测工具做的足够好，好的代码系统应有的现象是，改动量和回归量的某个多项式关系成正比。而坏的系统，改动量正比与回归量的指数。
所以架构不好的系统，最应该做的就是重构，而不是拼命迭代功能。技术债务越欠越难还。
精准测试用例推荐的实现途径
前面说了，这是一种基于逆向分析的几乎，通过编译成二进制的文件来反向推测调用关系，计算回归用例
Doxygen + Graphviz以及clang+uml组合都能做，但是TX自己又在搞了工具——一般大厂几个月搞的工具价值很低，升职加薪之后就丢开——TX当初做精准测试系统，确实好像是内部做了逆向二进制分析工具，号称性能比Doxygen之类的开源工具功能更强，性能强10倍，听听就好。
知识库构建
既然测试分析的结果要输出自动化回归用例，那么必然我们是需要准备一个数据库供这个系统查找推荐，这个就是所谓的知识库——测试用例和代码的映射关系数据库。一般对应粒度是函数级别，即每个用例对应的代码单元是函数，也可以是类，如果产品代码是面向对象很强的语言（Java）。建立只是库，还是老办法，用调用链分析去分析，做些插桩的工作，然后运行一遍用例，找出每个用例触动了哪些函数，这样就可以拿到函数和用例的对应关系了。
一般这种结果是芜杂的，即可能多个函数对应一个用例，多个用例都和某个函数有关。
这种关系很像一种结构——叫做偶图
有了知识库，再结合调用关系分析，就可以根据代码变更计算出需要回归的用例集了。
当然，更精细一点，可以用一种叫做代码路径分析hash的方法把知识库用例具体到函数的某个路径——只是我觉得，这过于龟毛了，函数的圈复杂度要到何种级别，要把一个函数干到路径分析来区别用例的地步？
