1.8.2静态代码分析和Bug自动识别 1．静态代码分析 过去我们遇到了很多问题是很难通过测试发现的，但通过静态代码分析很容易发现和避免，例如： 有业务语义的时间都应该从数据库获取，不可以取本地服务器的系统时间。 从数据库获...
第五类：事情忘记做了 案例18：某渠道新增payChannelApi时忘记通知账务团队配置clearingChannelApi，导致渠道清算出错。 案例19：数据域人员在做完数据订正后，临时任务没有及时下线，导致后续任务运行冲突，引发后续ODS数据丢失，导致当日数个报...
第四类：代码容易写错 案例13：在图1-15所示的这段代码里（摘自真实的应用代码），import的是springframework的类库，但参数的顺序是按照apache的类库方式传的，于是出错了。org.apache.commons.beanutils.BeanUtils和org.springframework.beans.Be...
第三类：视觉辨识度不佳 在案例3中，我们提到要用视觉辨识度比较高的字体作为编程和文本编辑器的字体，这样有助于肉眼发现0O、1lI及半角、全角等文本问题。 过去一两年里我们还遇到了以下几例和视觉辨识度有关的防错设计案例。 案例10：新的配...
第二类：线上线下权限隔离没做好 案例7：2017年11月，线下环境的文件发送系统配置了线上SFTP，导致线下测试文件误传到线上环境。 案例8：2018年3月，案例7的问题再次发生。 案例9：数据质量团队在做线下环境清理时，调用API误删除了线上的正式...
第一类：没有第一时间校验输入值 案例1：接到业务临时需求，通过增加配置实现。在实现过程中，少了一对中括号，导致配置值格式出错，收银台无法加载渠道信息，进而导致某业务支付成功率下降。缺少一对中括号的直接原因是技术人员使用的编辑器在格式...
1.8.1防错设计 测试的最终目的是让服务在线上不出问题、少出问题。人为错误是线上问题的一个主要来源。例如，某大型云计算服务在2010—2014年最严重的10个线上故障中有4个故障和人为错误有关： 2011年9月，一个网络配置多了一个斜杠，引发大面积...
1.7.2业务覆盖率度量 如果测试可以覆盖100%的代码（包括行覆盖、分支覆盖、条件覆盖等），是不是就测全了，不会遗漏曲线了？答案显然是“不”。以下面的代码为例：public string Format(int month, int year){return string.Format("{0}/{1}", mont...
1.7提升测试的充分性 围绕把测试做得更好的目标，除了实现更高频持续执行、更高的通过率、更低的噪声、更高的有效性等，还要解决测试遗漏的问题。 过去，我们的自动化用例主要靠测试人员凭借自己的测试分析能力来列举。但随着团队规模的扩大，越...
1.6.3更多的注入类型 1．线下质量红蓝攻防 变异测试不仅可以用来度量自动化测试用例的有效性，也可以用来度量整个研发流程中所有质量保障手段的总体有效性。例如，如果我们的代码里面有一个Bug，那么发现Bug的手段可以是代码评审，可以是代码扫描...
1.6.2变异测试和Bug注入 笔者团队在比较了各种方案后，选择用变异测试（MutationTesting）来度量测试用例的有效性。 1．变异测试的原理 变异测试就是向应用代码中注入一个Bug（我们把此处的Bug叫作变异），看看测试代码能否发现这个变异，以此...
1.6提升测试的有效性 当测试团队解决了测试的通过率、稳定性、耗时和覆盖率问题以后，测试的有效性便成为下一个需要解决的问题。 1.6.1测试有效性需要面对的挑战 挑战1：“注水”的成功率和覆盖率 在推动测试的通过率和覆盖率提升的过程中...
1.5.3用完即抛 笔者在团队中一直倡导的一个测试设计原则是“测试环境是短暂的（Testenvironmentisephemeral）”。一个长期存在的测试环境不可避免地会出现各种问题，如脏数据、累积的测试数据未清理、配置的漂移（Drift）等。这些问题都会严重影响测...
1.5.2隔离 隔离指不同的测试活动（包括不同的测试运行批次）之间要尽量做到不相互影响。在有些团队里，自动化的功能回归测试和其他日常测试（例如探索性测试）都在同一个测试环境里进行，相互干扰非常大。 相比“三斧子半”里的其他几个（高频、...
1.5提升测试的稳定性 很多测试团队面临的最大难题就是自动化测试的通过率低、噪声大。在理想情况下，我们希望每个失败的测试用例都是由真正的Bug引起的。但实际情况是，自动化测试经常因为其他原因导致失败，例如，同时执行的用例之间相互影响、人对...
1.4.3缩短反馈弧的成本和投入产出比 要缩短反馈弧，就要建设持续集成。虽然持续集成的确需要投入成本，但是很多人只看到了建设持续集成的投入，没有看到回报：这个做好了，能节省多少时间。在缩短反馈弧上投入的成本是能从其他地方收回来的。 对...
1.4.2怎么才算反馈弧短 反馈弧短不短，可以从两个方面衡量。 反馈的前置等待时间。理想状态是：反馈不需要等，任何时候想要反馈都可以。 反馈本身的耗时。理想状态是：反馈本身的耗时很短，结果立等可取。 打个比方，二三十年前量血压（量...
1.4缩短反馈弧 1.4.1为什么缩短反馈弧是关键 都说“没有度量就没改进”，但这句话还不完整。度量对于改进的作用是给出反馈，但光有度量还不够，还要度量得足够频繁、度量得足够快，这样才能更有效地改进。缩短反馈弧（FeedbackLoop）的价值在生活...
1.3 理解测试的本质 代码门禁是测试团队打破困局的第一步，但远远不是全部。在进一步阐述破局的思路前，有必要先弄清楚测试的本质。 测试的本质是反馈，就是回答一个问题：代码是不是好的。这里的“好”的定义并不是一成不变的，对于不同的需求，...
1.2 建立代码门禁 笔者每次接手一个团队，要做的第一件事情都是看这个团队有没有代码门禁（Gated Checkin）。没有代码门禁的团队，虽然会在每次代码提交后触发持续集成（主要是编译代码、执行单元测试和接口级别功能测试），但结果不稳定，大部分时...
