十二、无招胜有招
1、回顾之要义整理
第一式：差异化
目的：破全面回归。保证质量的前提下，少测提效。
要旨：需求差异要明了，技术实现差异更要明了
第二式：技术治理
目的：破耦合。耦合影响内容不能漏测，也不能多测。能够快速准确的分析出耦合影响，人工精准就基本达成了。
要旨：快速准确的分析耦合影响。
第三式：度量及分析闭环
目的：破差异化后的度量。代码覆盖率不仅仅可作为质量的一个度量维度，更可以作为测试分析精准与否的一个度量手段。
要旨：代码覆盖率分析结果，是精准测试质量的重要依据。
第四式：知识库
目的：破函数和用例映射。精准测分核心是分析变更函数及影响到的用例（含新增），如有一库在手，任何变更来了，都可以分析的又快又准。
要旨：函数和用例关系库建设。
第五式：用例预分析
目的：破人工分析变更影响用例。变更函数有了，知识库也有了，自动分析影响用例还远吗？
要旨：函数变更自动分析出影响用例。
第六式：知识库优化
目的：破函数用例关联冗余。同一个函数内覆盖相同分支路径的用例去重。
要旨：函数和用例关联，细化到函数内分支级别。
第七式：用例预分析消振
目的：破推荐影响用例冗余。变更分析也细化到分支级别。
要旨：差异化分析细化到函数分支级别。
第八式：精准测试执行手段
目的：破系统应用。精准测分系统完成之后，人工和自动化的配合。
要旨：人工和自动的取舍。
第九式：质量评估
目的：破精准之后的质量评估。从“你来决策发不发“角度，来全面阐述质量评估维度。
要旨：决策侧重
2、无招胜有招
完美的情况是，每一个需求来，都用精准测分的流程走一遍，质量和效率都没的说。但实际情况是纷繁复杂的，不同的需求、不同的时间要求、不同的测试参与阶段，都极有可能发生。如果非要在每一种情况面前都走全套的精准测分，很可能客观条件不允许。那如何灵活应对呢？最高境界：无招胜有招！
一：单个需求测分的破解思路：前提质量标准不降低，整体思路以下4步
1、什么类型的需求？ -- 为了得到需要精准测分的力度要多大。
从质量保障分层部署的角度：
从其他维度：
新需求：
可能技术方案难易程度
需求变更风险大小
增量需求：
技术变更影响大小
可供快速测分参考的工具或资料是否完善
2、项目对测试时长的期望？
测试敏捷的突破重点，就是测试角色在整个项目周期中独占的一段时间（测试独占时长）
具体到标记性的动作上：
测试独占时长的开始标志；最后一个需求提测时间
测试独占时长的结束标志：测试报告发出时间
* 测试独占时长 = 单人黑盒测试时长 / 黑盒测试总人数 = （CaseNum * 回归次数 * 每个用例执行时长 + BugNum * Bug回归验证时长）/ PersonNu
降低独占时长，可多渠道入手：
* 降低CaseNum （黑盒测试用例数），可通过精准测分缩减测试内容，从而降低测试用例数；可通过分批今早测试，在开发阶段测试掉一部分用例
* 降低回归次数，可通过精准测分降低回归次数，如通过分析是否环境无关来降低，也可通过设计稳定可靠的自动化来降低
* 降低BugNum（未解决的bug），可通过白盒测试手段达到在开发阶段发现问题，从而减少测试独占时长内的bug数；更可通过测试早起参与，给团队各角色的质量风险把关，从而降低后期bug数
* 降低bug回归验证时长
3、谁来负责这个需求的测分？
-- 深入分析什么人合适，主要考察的是人的精准测分成熟程度，可从以下3个维度剖析
1）人的精准测分成熟程度
模块级 --》文件级 --》代码级 --》函数级 --》架构级
模块级意指：人在进行技术实现分析的时候，只能分析到模块级别，还不能分析出这个实现由哪些文件、哪些代码、哪些函数，函数的逻辑又是怎样的。后面级别以此类推。
特提架构级，为什么架构级在函数级之后呢？因为现实测分通过分析代码实现来发现架构级别的问题，难度是较大的。当然架构级别的问题，应该在技术方案评审阶段就分析发现出来，也是对测分人代码能力的较高考察点。
2）人的业务熟悉程度
面对熟悉业务，接手同类业务时，上手速度更快。
面对全新的业务，要考察这个人对业务的快速分析建模能力。这个能力考察的核心可以白哦先在黑盒测试设计的速度和质量上。
3）人的整体质量效率把控程度
人的整体质量把控能力，在精准测分团队中，体现以下维度：
1）质量指标的落地程度（版本质量外发指标、发布前过程质量监控指标、发布后质量监控指标）
2）需求技术评审能力
3）代码线控制能力、风险评估能力
4）版本变更控制能力、风险把控能力
5）测试策略能力，主要体现在不同阶段部署不同的测试手段能力，比如在开发阶段进行框架代码测分、静态代码检查、持续集成和自动化分层验证部署、测试用例全面有效。
6）发布策略等闲把控能力
7）外发后质量监控
人的整体质量把控能力，在流程控制上，体现以下维度：
1）迭代节奏把控能力，单周、双周，或者单需求的节奏把控
2）文件升级流程把控
3）大版本全流程节奏把控，体现下面完整流程的质量和效率节奏影响力：onepage需求评审 --》需求评审 --》技术评审 --》开发实现阶段 --》提测阶段 --》测试阶段 --》外发阶段
4、如何把控质量和进度风险？
风险把控的主要途径是实时的质量看板（产品质量指标值、过程质量监控值、发布后质量监控值），从这个看板里，审核人可以一目了然看到某个项目的产品质量现状、项目进度风险。
二：团队测分能力提升建设的破解思路
从正式员工经理投入角度破局：
（1）现状
正式员工100%精力进行业务测试。固定人员负责固定的业务测试，双人交叉备份。
（2）人工精准测分阶段
正式员工80%精力进行日常的业务测试，另外20%精力进行测试分析建设和提升上。
正式员工20%的测试分析工作，可从以下阶段产出成果：
1）拿到代码权限，可以开展代码测分
2）分析出整个团队所有代码编译出来的所有模块全景图
3）根据业务变更优先级，来排这些模块的优先级，对模块进行代码层次的梳理，得=--、该模块的整体架构、分功能的代码实现、核心逻辑实现等。
4）增量需求的变更代码测分
（3）精准测分平台建设阶段
正式员工60%精力跟进日常的业务测试工作，领30%进行测试分析，还有10%进行平台的建设工作。（平台建设思路和实现可参照四五六七式，也可根据自己项目的实际代码实现特点，实际测分痛点，来建设自己的平台）
（4）高效团队阶段
正式员工40%精力跟进日常业务测试，并督促各角色承担起质量保证工作，另40%进行测试分析，20%进行平台和工具建设
从无到有建设测试团队思路：
1）找到合适的人
2）寻找业务痛点，重点突破
3）精准测分流程走起来，平台建设起来
4）建立行业影响力（及时感知行业需求变化，做出反应和改变）
3、后记
1）一夜回到解放前：较高的质量风险和解决用户的燃眉之急相比，有些风险是可以接受的。
2）探索，永无止境
测试左移（bug左移和测试内容左移）：测试从研发流程的后端，走入前端，要承担生产力建设的责任，不再单纯做对质量兜底的工作
EP（工程生产力）团队：依赖测试团队技术能力的提升，依赖开发团队承担质量责任的文化建设
