精准测试探索
前情提要：由Jacoco到精准测试的相关内容见《测试有效性探索之测试执行与代码覆盖率》
# 1 概念
# 1.1 非精准测试的局限性
传统测试存在以下6个方面的局限性，我们不展开讲述了：
- 虽然测试流程很规范，但软件质量还是不如意；
- 软件项目验收缺少好的运行检测手段，检测结果缺少技术公信力；
- 传统的手工测试，测试执行无法精准量化控制，测试效率比较低；
- 测试人员不能精准把握缺陷现场，与开发人员协同工作困难；
- 分布式、微服务架构，软件越来越复杂，测试挑战性越来越大。
# 1.2 精准测试的核心
精准测试的定义：一种可以追溯的软件测试技术。
从字面理解，精准就是非常准确，非常准确需要用数字说话。
在测试领域，精准测试是一套计算机测试辅助分析系统，对测试过程的活动进行监控，讲采集到的监控数据进行分析，得到精准测试的量化数据，使用这些量化数据进行质量评价，利用这些分析数据可以崔进测试过程不断完善，形成度量及分析闭环。
精准测试的核心就是“数据与追溯”
精准测试的核心思想就是使用非常精确和智能的软件来解决软件测试的问题，从根本上引领从经验型方法向技术型方法的转型------质量的评估不再靠经验，而是通过精准的数据来判定。
精准测试没有改变传统的软件测试方法，区别只在于，由软件去采集测试执行触发的代码逻辑及测试数据的过程，自动建立测试用例与程序代码之间的逻辑关系。在测试过程中加入软件的采集过程，可以形成正向和逆向的追溯。
通过正向追溯，开发人员可以看到测试人员执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。
通过逆向追溯，测试人员通过修改的源码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例，达到测试覆盖率最大化。
# 2 设想新的道路
期望通过引入精准测试技术，解决我们当前测试面临的两大困难：
- 应该测什么
- 测得怎么样
假设我们已经在测试工作中引入了精准测试的技术，我们的测试工作应该会发生以下改变。
# 2.1 新版本要测什么我很清楚
# 2.1.1 曾经的故事
项目经理：小马，明天我们要提测新版本，修复了上一轮提出的一些bug，完成了这个迭代的3个新需求。
测试负责人：好的，我们的测试方案和测试用例都准备好了，评审通过了。
第二天一早，测试负责人收到提测邮件，本次提测的内容简简单单四五句话，下载好安装包，release-note内容就更少了，根据对新需求了解的结果和JIRA上的bug单以及测试方案和测试用例来测试吧......
安装完成，先来一轮回归测试，哎哎哎？为什么A功能回归失败了，这不属于新需求也不是bug修复的内容啊，定位下问题，一通排查，日志中也没发现问题（可能日志记录不够合理），找开发沟通下吧。
测试工程师：刘哥，这个版本没改动A功能吧，回归测试时，A功能出错了，日志也没找到原因，你看，报错这个样子的......
开发工程师：不可能啊，我们都没改这里，改了就写到提测邮件了，你再看看你们的测试环境部署是不是有问题.......
一个上午的bug定位开始了，过了好久终于找到问题修复好，再次提测已经是午休以后了，再熟悉不过的场景了。
# 2.1.2 如果这样该多好
项目经理：小马，明天我们要提测新版本，修复了上一轮提出的一些bug，完成了这个迭代的3个新需求。
测试负责人：好的，我们的测试方案和测试用例都准备好了，评审通过了，按照精准测试的规范，提测邮件记得提供下本次提测的Git代码分支和commit id。
第二天一早，测试负责人收到提测邮件，本次提测的内容简简单单四五句话，下载好安装包，release-note内容就更少了，先用精准测试的代码差分和用例推荐功能检查下。
打开精准测试平台，填入上一版本的Git代码分支和本次提测的Git代码分支，点击“比对分析”按钮进行自动差异分析，查看本次提测修改变动的方法函数（修改/删除/新增），查看变动的方法关联的测试用例清单，对照下提测说明和release-note，发现有个A模块代码有改动，但提测邮件和release-note都没有提及，这有风险。
此处需要一张效果图
测试工程师：刘哥，我们进行版本代码差异分析时发现这个A模块改动了，不在本次提测内容范围内啊，改了什么内容啊？
开发工程师：啊，这个啊，我看这个代码比较冗余，我就重构了下，逻辑没改动，没什么影响的，我们就没写到提测内容里，你正常测试就行。
安装完成，先来一轮回归测试，很巧啊，A功能的测试用例没通过，截图、日志打包发给开发工程师。
测试工程师：刘哥，不巧，A功能的代码重构应该有些问题，具体是这几个方法的代码，你看看这是报错截图和日志，麻烦你们排查定位下。
第一轮测试打回，1小时后研发修复问题，重新提测。
# 2.2 测得怎么样我可以用数据说话
# 2.2.1 曾经的苦恼
经过1个月的工作，我们终于通过了新版的测试，整个测试过程的测试方案和测试用例都经过测试和开发的一致评审，计划提测需求达成率100%，提测需求通过率100%，重要缺陷和中等缺陷全部修复，轻微缺陷修复90%以上，测试报告得到大家的认可，产品可以发布上线了。
上线2周过后，客户反馈说Z功能在某筛选条件下点击就报错......，Z功能属于核心功能，测试团队和开发团队紧急联系现场进行问题定位分析，最终发现是一个bug。这个bug是由于最后一个迭代优化业务功能时新增的一个逻辑，测试用例评审时遗漏了导致的，属于漏测。
事后回顾开展AAR，测试团队和开发团队达成一致意见，要把功能改动及时告知，文档写清楚......
大家都知道，这种问题很难避免，代码一些微小的改动，无法度量无法洞察，从黑盒测试的角度解决不了这个矛盾，只能寄希望于开发和测试都足够细心，足够负责，足够有经验，但这似乎大家都没有信心。
# 2.2.2 用数据和事实来说话
经过3个周的测试，缺陷逐步收敛，最后一个迭代测试通过我们就可以上线了，大家都卯足了劲工作，根据迭代改动内容，完善、修改、评审新迭代的测试方案、测试用例。
提测后测试工程师使用精准测试平台进行版本间代码差分比对，发现核心模块Z功能的代码有改动，但提测内容没有提及，于是测试工程师找开发沟通，完善新增了相关测试用例。
测试执行完成后，测试工程师打开精准测试平台，查看本迭代的代码覆盖率，发现有个核心模块Z功能部分代码分支没有覆盖到，与开发工程师交流后发现新增的测试用例考虑的条件有遗漏，导致部分代码分支逻辑未覆盖，于是补充测试用例重新测试，再次度量代码覆盖率，最终核心功能代码覆盖率达标。
补充效果图
经过1个月的工作，我们终于通过了新版的测试，整个测试过程的测试方案和测试用例都经过测试和开发的一致评审，计划提测需求达成率100%，提测需求通过率100%，重要缺陷和中等缺陷全部修复，轻微缺陷修复90%以上，测试报告得到大家的认可，产品可以发布上线了。
上线2个月，没有出现重要问题，大家对自己的产品质量充满了信心。
# 3 如何实现
# 3.1 精准测试工作流程和要点概览
# 3.2 原理实现概览图
# 3.3 测试用例与代码方法双向追溯关系构建思路
# 3.3.1 双向追溯实现效果
# 3.3.1.1 字节码方法信息表
# 3.3.1.2 源代码方法信息表
# 3.3.1.3 测试用例关联方法数量
# 3.3.1.4 测试用例关联代码方法信息详情
