fix img

2025-11-16 22:23:45 +08:00 · 2022-09-06 22:30:37 +08:00
parent 66970f3e38
commit 3d6528675a
796 changed files with 3382 additions and 3382 deletions
--- a/开篇词既往不恋，当下不杂，未来不迎.md.html
+++ b/开篇词既往不恋，当下不杂，未来不迎.md.html
@@ -164,8 +164,8 @@ function hide_canvas() {
 <p>也有很多测试从业者认识到了互联网的核心是各种类型的微服务，而且服务端承载了业务的核心逻辑和用户价值，所以他们选择了服务端测试工程师职业方向。思路和切入点很好，但是对于微服务架构下的服务端应该如何测试，网络上大多是关于接口测试自动化及框架之类的资料，很难让他们建立一个整体的认知，并因此容易误会为——服务端测试只能通过接口测试来进行。</p>
 <p>其实，服务端测试是一套全方位的测试保障体系，除了保证对外提供的接口符合要求，在业务广度和技术深度方面都需要有良好的覆盖率，并且要求有一系列的流程规范、方法、工具等做支撑。而软件测试人员需要根据技术架构和测试对象的特点，相应地调整自己的测试策略和思路，积累和总结测试方法和技能，进而沉淀出体系化的保障体系。</p>
 <p>此外，各大互联网公司也都在积极招募服务端测试高级工程师、服务端测试开发工程师等服务端测试岗位，薪资非常具有竞争优势：</p>
-<p><img src="assets/Ciqc1F8VK_6AQpYjAABA-cWN2mI917.png" alt="image" /></p>
-<p><img src="assets/Ciqc1F8VLASAEQ8CAABrZtOY7vE525.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8VK_6AQpYjAABA-cWN2mI917.png" alt="png" /></p>
+<p><img src="assets/Ciqc1F8VLASAEQ8CAABrZtOY7vE525.png" alt="png" /></p>
 <p>从招聘需求中可以看到，与很多测试从业者对服务端测试的认知和技能还停留在传统的<strong>服务端测试</strong>阶段不同，大厂已经明确要求服务端测试工程师参与<strong>服务端质量保障体系</strong>的建设。而即使熟悉服务端质量保障体系的测试人才，也因为微服务的盛行面临新的挑战。他们需要针对微服务的特点、所在项目的环境情况做进一步的分析，对质量保障体系做合理裁剪，才能真正落地应用。</p>
 <h3>服务端质量（保障）体系的重要性</h3>
 <p>这里我们有必要先厘清两个概念：<strong>测试</strong>更多指具体的测试活动，而<strong>质量保障</strong>是一个全面的体系化的内容，测试只是其中的一个环节或方面。</p>
--- a/微服务架构有哪些特点？.md.html
+++ b/微服务架构有哪些特点？.md.html
@@ -158,9 +158,9 @@ function hide_canvas() {
 <p>首先，我以我自身的两份工作经历，来让你感受下什么是微服务，以及微服务架构的优缺点。这样有利于你理解后面的课时内容，同时更加有代入感。</p>
 <h3>单体应用架构下的服务特性</h3>
 <p>我第一份工作是网络游戏的测试保障工作，在功能测试之外做了很多服务端相关的工作，如编译后分发、配置、部署、发布等。那时候的服务端应用程序是几个独立的几十兆、上百兆的文件。<strong>每个文件是一个可执行文件，包含一个系统的所有功能，这些功能被打包成一体化的文件，几乎没有外部依赖，可以独立部署在装有 Linux 系统的硬件服务器上。</strong> 这种应用程序通常被称为单体应用，单体应用的架构方法论，就是单体应用架构（Monolithic Architecture）。单体应用架构下，一个服务中包含了与用户交互的部分、业务逻辑处理层和数据访问层。如果存在数据库交互则与数据库直连，如下图所示。</p>
-<p><img src="assets/Ciqc1F8VMbWADRXPAABfysmIcFg665.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/Ciqc1F8VMbWADRXPAABfysmIcFg665.png" alt="png" /></p>
 <p>单体应用架构下，一个服务中，两个业务模块作为该服务的一部分存在同一进程中，它们通过方法调用的方式进行通信，如下图所示。</p>
-<p><img src="assets/Ciqc1F8VMb6AFe-pAAAxKvxK3wA298.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/Ciqc1F8VMb6AFe-pAAAxKvxK3wA298.png" alt="png" /></p>
 <p>通过在单体应用架构下，不同阶段的服务端相关工作，可以感知到<strong>单体应用的特性。</strong></p>
 <h4>1. 日常研发测试阶段</h4>
 <ul>
@@ -178,10 +178,10 @@ function hide_canvas() {
 <p>现在应用程序日益复杂化，项目对于迭代速度的要求也越来越高，上述的不足会暴露得更加明显，在这种时代背景下，微服务架构开始在企业生根发芽。</p>
 <h3>微服务架构下的服务特性</h3>
 <p>后来我转到了互联网公司工作，所在项目的服务架构与过去经历过的单体应用架构下的服务差异巨大。同等规模的研发团队，服务的个数竟然有近百个，虽然数量众多，但<strong>每个服务都只负责一小块儿具体的业务功能，能独立地部署到环境中，服务间边界相对清晰，相互间通过轻量级的接口调用或消息队列进行通信，为用户提供最终价值。这样的服务称为微服务（Microservice）。</strong> 从本质上来说，微服务是一种架构模式，是面向服务型架构（SOA）的一种变体，如下图所示。</p>
-<p><img src="assets/Ciqc1F8VMgmAbQ0RAACD0qeLHMs761.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/Ciqc1F8VMgmAbQ0RAACD0qeLHMs761.png" alt="png" /></p>
 <p>上图所示，微服务架构下，业务逻辑层被分拆成不同的微服务，其中不需要与数据库交互的服务将不再与数据库连接，需要与数据库交互的服务则直接与数据库连接。</p>
 <p>微服务架构下，因为两个服务分别在自己的进程中，所以它们不能通过方法调用进行通信，而是通过远程调用的方式进行通信，如下图所示。</p>
-<p><img src="assets/Ciqc1F8VMhGAIS2iAAAyeIWdJZ4810.png" alt="Drawing 6.png" /></p>
+<p><img src="assets/Ciqc1F8VMhGAIS2iAAAyeIWdJZ4810.png" alt="png" /></p>
 <p>同样，通过在微服务架构下，不同阶段的服务端相关工作，可以感知到微服务的特性。</p>
 <h4>1. 日常研发测试阶段</h4>
 <p>因为微服务数量众多，研发和测试团队都有诉求构建一个良好的基础建设。如搭建持续交付工具，通过持续交付工具拉取某微服务代码，再进行编译、分发、部署到测试环境的机器上。再加上，微服务应用程序本身并不大，部署耗时短、影响范围小、风险低，整个编译分发部署的过程在几分钟之内就可以搞定，且几乎是自动完成，因此部署频率可以做到很高。</p>
@@ -192,7 +192,7 @@ function hide_canvas() {
 <h4>4. 其他阶段</h4>
 <p>架构设计方面，微服务可以使用不同的语言，采用不同的架构，部署到不同的环境。同时可以采用适合微服务业务场景的技术，来构建合理的微服务模块。</p>
 <p>由此可见，微服务的确解决了单体应用架构下服务的诸多短板。单体应用与微服务对比总结如下。</p>
-<p><img src="assets/CgqCHl8VMjCAeWiUAAB11eN264M629.png" alt="Drawing 8.png" /></p>
+<p><img src="assets/CgqCHl8VMjCAeWiUAAB11eN264M629.png" alt="png" /></p>
 <h4>微服务的缺点</h4>
 <p>当然，<strong>事物都有两面性，任何一项技术都不可能十全十美，在解决一定问题的同时，也会引入新的问题。</strong> 那么，微服务架构下服务有哪些缺点呢？</p>
 <p>从微服务架构设计角度来看。</p>
--- a/微服务架构下的测试策略.md.html
+++ b/微服务架构下的测试策略.md.html
@@ -166,24 +166,24 @@ function hide_canvas() {
 <li>测试需要分层，每一层的测试颗粒度有所不同；</li>
 <li>不同层次的测试比重有差异，通常来说，层次越高，测试比重应越少。</li>
 </ul>
-<p><img src="assets/CgqCHl8ZQp2AA2yKAADyJvMVUks187.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl8ZQp2AA2yKAADyJvMVUks187.png" alt="png" /></p>
 <p>需要说明的是，传统意义下的测试金字塔，在微服务架构下不再完全奏效。因为微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，这一点值得特别注意。</p>
 <p>因此，<strong>针对微服务架构，常见的测试策略模型</strong>有如下几种。</p>
 <p>（1） <strong>微服务“测试金字塔”</strong></p>
 <p>基于微服务架构的特点和测试金字塔的原理，Toby Clemson 有一篇关于<a href="https://www.martinfowler.com/articles/microservice-testing/">“微服务架构下的测试策略”</a>的文章，其中通过分析阐述了微服务架构下的通用测试策略。</p>
-<p><img src="assets/Ciqc1F8ZQrSACTc9AAB65lA45vc729.png" alt="Drawing 1.png" /></p>
+<p><img src="assets/Ciqc1F8ZQrSACTc9AAB65lA45vc729.png" alt="png" /></p>
 <p>如图，该策略模型依然是金字塔形状，从下到上依次为单元测试、集成测试、组件测试、端到端测试、探索式测试。</p>
 <p>（2） <strong>微服务“测试蜂巢”</strong></p>
 <p>这种策略模型是蜂巢形状，它强调重点关注服务间的集成测试，而单元测试和端到端测试的占比较少。</p>
-<p><img src="assets/CgqCHl8ZQsGAZti7AABGRbBNFY8164.png" alt="Drawing 3.png" /></p>
+<p><img src="assets/CgqCHl8ZQsGAZti7AABGRbBNFY8164.png" alt="png" /></p>
 <p>（3） <strong>微服务“测试钻石”</strong></p>
 <p>这种策略模型是钻石形状的，组件测试和契约测试是重点，单元测试比率减少，另外增加了安全和性能等非功能的测试类型。</p>
-<p><img src="assets/CgqCHl8ZQs-AByNAAACgJaZwyyU241.png" alt="Drawing 5.png" /></p>
+<p><img src="assets/CgqCHl8ZQs-AByNAAACgJaZwyyU241.png" alt="png" /></p>
 <p>我想，有多少个基于微服务架构的测试团队大概就有多少个测试策略模型吧。<strong>“测试金字塔”是一种测试策略模型和抽象框架</strong>，当技术架构、系统特点、质量痛点、团队阶段不同时，每种测试的比例也不尽相同，而且最关键的，并不一定必须是金字塔结构。</p>
 <p>理解了测试策略模型的思考框架，我们看下应如何保障测试活动的全面性和有效性。</p>
 <h4>全面性</h4>
 <p>微服务架构下，既需要保障各服务内部每个模块的完整性，又需要关注模块间、服务间的交互。只有这样才能提升测试覆盖率和全面性，因此，可以通过如下的分层测试来保证微服务的全面性。</p>
-<p><img src="assets/CgqCHl8ZSrqAVjqcAAVCHyjoRMg887.png" alt="Drawing 7.png" /></p>
+<p><img src="assets/CgqCHl8ZSrqAVjqcAAVCHyjoRMg887.png" alt="png" /></p>
 <ul>
 <li>单元测试（Unit Test） ：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。</li>
 <li>集成测试（Integration Test）：验证当前服务与外部模块之间的通信方式或者交互符合预期，以便测试出接口缺陷。</li>
@@ -198,7 +198,7 @@ function hide_canvas() {
 <p>测试策略如同测试技术、技术架构一样，并不是一成不变，它会随着业务或项目所处的阶段，以及基于此的其他影响因素的变化而不断演进。但归根结底，还是要从质量保障的目标出发，制定出适合当时的测试策略，并阶段性地对策略进行评估和度量，进而不断改进和优化测试策略。因此，<strong>选取测试策略一定要基于现实情况的痛点出发，结果导向，通过调整测试策略来解决痛点。</strong></p>
 <p>比如，在项目早期阶段或某 MVP 项目中，业务的诉求是尽快发布到线上，对功能的质量要求不太高，但对发布的时间节点要求非常严格。那这种情况下快速地用端到端这种能模拟用户真实价值的测试方法保障项目质量也未尝不可；随着项目逐渐趋于平稳后，时间要求渐渐有了节奏，对功能的质量要求会逐渐变高，那么这时候可以再根据实际情况引入其他测试方法，如契约测试或组件测试等。</p>
 <p>你要永远记住，<strong>适合自身项目阶段和团队的测试策略才是“完美”的策略。</strong></p>
-<p><img src="assets/CgqCHl8ZSvOAK06pAAVCHyjoRMg396.png" alt="Drawing 7.png" /></p>
+<p><img src="assets/CgqCHl8ZSvOAK06pAAVCHyjoRMg396.png" alt="png" /></p>
 <h3>如何建立质量保障体系？</h3>
 <p>上述分层的测试策略只是尽可能地对微服务进行全面的测试，确保系统的所有层次都被覆盖到，它更多体现在测试活动本身的全面性和有效性方面。要想将质量保障内化为企业的组织能力，就需要通过技术和管理手段形成系统化、标准化和规范化的机制，这就需要建设质量保障体系。</p>
 <p><strong>质量保障体系：通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。</strong> 同时，还需要相应的度量、运营手段以及组织能力的保障。</p>
--- a/单元测试：怎样提升最小可测试单元的质量？.md.html
+++ b/单元测试：怎样提升最小可测试单元的质量？.md.html
@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>单元测试的价值</h3>
 <p>单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成，目的是验证软件代码中的每个单元（方法或类等）是否符合预期，即<strong>尽早</strong>在<strong>尽量小的范围内</strong>暴露问题。</p>
 <p>我们都知道，问题发现得越早，修复的代价越小。毫无疑问，在开发阶段进行正确的单元测试可以极大地节省时间和金钱。如果跳过单元测试，会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。</p>
-<p><img src="assets/Ciqc1F8f7cWAVsrMAABFwThSg-U472.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/Ciqc1F8f7cWAVsrMAABFwThSg-U472.png" alt="png" /></p>
 <p>如图，假如有一个只包含两个单元 A 和 B 的程序，且只执行端到端测试，如果在测试过程中发现了缺陷，则可能有如下多种原因：</p>
 <ul>
 <li>该缺陷由单元 A 中的缺陷引起；</li>
@@ -185,10 +185,10 @@ function hide_canvas() {
 <p>就像之前课程所说：<strong>微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，服务与服务之间常常互相调用以实现更多更复杂的功能。</strong></p>
 <p>举个例子，我们需要测试的是订单类（Order）中的获取总价方法（getTotalPrice()），而在该方法中除了自有的一些代码逻辑外，通常需要去调用其他类的方法。比如这里调用的是用户类（User）的优惠等级方法（reductionLevel ()）和商品类（Goods）中的商品价格方法（getUnitPrice()）。很显然，优惠等级方法或商品价格方法，只要一方有错误，就会导致订单类获取总价方法的测试失败。基于这种情况，可以有两种单元测试类型。</p>
 <h4>1. 社交型单元测试（Sociable Unit Testing）</h4>
-<p><img src="assets/CgqCHl8f7e6AKMwnAABnkatxrFM928.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/CgqCHl8f7e6AKMwnAABnkatxrFM928.png" alt="png" /></p>
 <p>如图，测试订单类的获取总价方法（Order.getTotalPrice()）时会真实调用用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）。将被测试单元视为黑盒子，直接对其进行测试，这种单元测试称之为<strong>社交型单元测试（Sociable Unit Testing）</strong>。</p>
 <h4>2. 孤立型单元测试（Solitary Unit Testing）</h4>
-<p><img src="assets/Ciqc1F8f7h-AU6TmAAC372KA44g862.png" alt="Lark20200728-165448.png" /></p>
+<p><img src="assets/Ciqc1F8f7h-AU6TmAAC372KA44g862.png" alt="png" /></p>
 <p>如图，如果测试订单类的获取总价方法（Order.getTotalPrice()）时，使用测试替身 <strong>（test doubles）</strong> 技术来替代用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）的效果。对象及其依赖项之间的交互和协作被<strong>测试替身</strong>代替，这种单元测试称之为<strong>孤立型单元测试（Solitary Unit Testing）</strong>。</p>
 <p>另外，上述提到的测试替身是一种在测试中使用对象代替实际对象的技术，常用的技术如下。</p>
 <ul>
@@ -196,9 +196,9 @@ function hide_canvas() {
 <li><strong>模拟代码（Mocks）</strong>：模拟代码跟桩代码类似，它除了代替真实代码的能力之外，更强调是否使用了特定的参数调用了特定方法，因此，这种对象成为我们测试结果的基础。</li>
 </ul>
 <p>根据被测单元是否与其交互者隔离，会产生以上两种单元测试类型，这两种类型的单元测试在微服务测试中都起着重要作用，它们用来解决不同的测试问题。</p>
-<p><img src="assets/CgqCHl8f7kiAI3ksAAFYtUA3syQ407.png" alt="Drawing 5.png" /></p>
+<p><img src="assets/CgqCHl8f7kiAI3ksAAFYtUA3syQ407.png" alt="png" /></p>
 <p><strong>由上图可知，在微服务架构中，不同组成使用的单元测试类型不同：</strong></p>
-<p><img src="assets/CgqCHl8f7lqAYCVuAACnpSlf1e4918.png" alt="Drawing 6.png" /></p>
+<p><img src="assets/CgqCHl8f7lqAYCVuAACnpSlf1e4918.png" alt="png" /></p>
 <p>特别注意：当微服务的（网关+仓库+资源+服务层）与（域逻辑）之比相对较大时，单元测试可能收益不大。常见的情况有小型服务或某些几乎只包含了网关+仓库+资源+服务层等内容的服务，例如适配服务等。</p>
 <h3>如何开展单元测试？</h3>
 <p>在实际项目过程当中，应该怎样开展单元测试呢？通常来说，可以通过如下四个步骤来进行。</p>
@@ -216,7 +216,7 @@ function hide_canvas() {
 <p>只单纯地看单元测试的执行通过率还比较单一，为了更全面地看到测试的覆盖情况，可以借助代码覆盖率工具和技术。在 Java 语言里，常用覆盖率工具有 Jacoco、Emma 和 Cobertura，个人推荐使用 Jacoco。</p>
 <h4>4. 接入持续集成工具</h4>
 <p>接入持续集成工具是为了形成工具链，将单元测试、代码覆盖率统计集成在一起，使得代码有提交时便自动触发单元测试用例的执行，并伴随有代码覆盖率的统计，最后可以看到单元测试报告的数据（用例通过情况和代码层面各个维度的覆盖数据）。接着可以判断是否需要修改代码，这便形成了一个代码质量的反馈环，如下图所示。</p>
-<p><img src="assets/CgqCHl8f7peAZGzxAABmknW8jXs450.png" alt="Drawing 7.png" /></p>
+<p><img src="assets/CgqCHl8f7peAZGzxAABmknW8jXs450.png" alt="png" /></p>
 <p>后续的文章还会讲解到代码覆盖率工具和持续集成工具。</p>
 <h3>单元测试最佳实践</h3>
 <p>了解了如何开展单元测试，那么如何做到最好呢？我们都知道，代码产生错误无非是对一个业务逻辑或代码逻辑没有实现、实现不充分、实现错误或过分实现，所以无论是拆解业务逻辑还是拆解逻辑控制时都要做到 <strong>MECE 原则</strong>（全称 Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”，即日常沟通中常说的“不重不漏”）。</p>
--- a/集成测试：如何进行微服务的集成测试？.md.html
+++ b/集成测试：如何进行微服务的集成测试？.md.html
@@ -164,7 +164,7 @@ function hide_canvas() {
 <p>微服务架构下也需要集成测试，<strong>需要针对不同服务的不同方法之间的通信情况进行相关测试。</strong> 因为在对微服务进行单元测试时，单元测试用例只会验证被测单元的内部逻辑，并不验证其依赖的模块。即使对于服务 A 和服务 B 的单元测试分别通过，并不能说明服务 A 和服务 B 的交互是正常的。</p>
 <p>对于微服务架构来说，<strong>集成测试通常关注于验证那些与外部组件（例如数据存储或其他微服务）通信的子系统或模块。</strong> 目标是验证这些子系统或模块是否可以正确地与外部组件进行通信，而不是测试外部组件是否正常工作。因此，微服务架构下的集成测试，应该验证要集成的子系统之间与外部组件之间的基本通信路径，包括正确路径和错误路径。</p>
 <h3>微服务架构下的集成测试</h3>
-<p><img src="assets/CgqCHl8iem-AFErwAAUV3BnSpVE692.png" alt="image" /></p>
+<p><img src="assets/CgqCHl8iem-AFErwAAUV3BnSpVE692.png" alt="png" /></p>
 <p>微服务结构图与集成测试边界</p>
 <p>如上图所示，网关组件层（Gateways+Http Client+External Service）包含了访问外部服务的逻辑，通常包含一个 HTTP/S 的客户端，客户端会连接到系统中另一个微服务或外部服务。数据持久层（Date Mappers/ORM）用于连接外部数据存储。</p>
 <p>即，微服务架构下的集成测试主要包括两部分：</p>
@@ -175,7 +175,7 @@ function hide_canvas() {
 <p>这里请注意，因为需要测试微服务下子系统之间的通信和外部服务的通信是否正确，所以<strong>理想情况下不应该对外部组件使用测试替身（Test Double）。</strong></p>
 <p>下面我们逐一来看这两部分是如何进行集成测试的：</p>
 <h4>（1）网关组件层集成测试</h4>
-<p><img src="assets/CgqCHl8ieoeAGpreAABlJ9Cf-_M925.png" alt="image" /></p>
+<p><img src="assets/CgqCHl8ieoeAGpreAABlJ9Cf-_M925.png" alt="png" /></p>
 <p>假设有个登录服务，该服务需要知道当前时间，而时间是由一个外部的<a href="http://worldclockapi.com/">时间服务</a>提供的。当向<a href="http://worldclockapi.com/api/json/cet/now"> /api/json/cet/now </a>发出 GET 请求时，状态码为 200，并返回如下完整的时间信息。</p>
 <pre><code>{
 $id: &quot;1&quot;,
@@ -203,7 +203,7 @@ serviceResponse: null,
 <li>进行相关的测试；</li>
 <li>循环上述这个过程。</li>
 </ol>
-<p><img src="assets/Ciqc1F8ieqeAa4YoAABZtUlBe2M988.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8ieqeAa4YoAABZtUlBe2M988.png" alt="png" /></p>
 <h3>常见问题及解决策略</h3>
 <p>然而，有很多时候外部服务不可用（服务尚未开发完成、服务有 block 级别的缺陷未修复），或其异常行为（如外部组件的超时、响应变慢等）很难去验证。外部组件不能使用测试替身，外部服务又不可用或异常场景难构造，看似无解，实际上都是有替代方案的。</p>
 <h4>服务不可用</h4>
--- a/组件测试：如何保证单服务的质量？.md.html
+++ b/组件测试：如何保证单服务的质量？.md.html
@@ -159,7 +159,7 @@ function hide_canvas() {
 <p><strong>组件（Component）通常指大型系统中任何封装良好、连贯且可独立替换的中间子系统，在微服务架构中，一般代表单个微服务，因而组件测试（Component Testing）就是对单个服务的测试。</strong></p>
 <p>在一个典型的微服务应用程序中，会有许多微服务，且它们之间存在相互调用关系。因此，要想高效地对单个微服务进行测试，需要将其依赖的其他微服务和数据存储模块进行模拟（mock）。</p>
 <p>比如，使用测试替身（Test Double）工具隔离掉单个微服务依赖的其他微服务和数据存储，避免测试过程中受到依赖服务或数据存储模块的各类影响（如服务不可用、服务缺陷、数据库连接断开等）而出现阻塞测试过程、测试无效等情况。</p>
-<p><img src="assets/CgqCHl8pBgqANMbHAABddoBq1dc448.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl8pBgqANMbHAABddoBq1dc448.png" alt="png" /></p>
 <p>从某种意义上来说，组件测试的本质上是将一个微服务与其依赖的所有其他服务和数据存储模块等隔离开，对该服务进行的功能验收测试。</p>
 <p>基于组件测试的隔离特性，它有如下优势：</p>
 <ul>
@@ -170,7 +170,7 @@ function hide_canvas() {
 <p>根据组件测试调用其依赖模块的方式，以及测试替身位于被测服务所在进程的内部或外部，可以有两种方式：进程内组件测试和进程外组件测试。</p>
 <h3>进程内组件测试</h3>
 <p>进程内组件测试是将测试替身注入所测服务所在的进程中，这样对服务的依赖调用通过方法调用的方式实现，不再需要使用网络。</p>
-<p><img src="assets/CgqCHl8pBhmAIvbCAAYUsJRZIuE903.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/CgqCHl8pBhmAIvbCAAYUsJRZIuE903.png" alt="png" /></p>
 <p>进程内组件测试示意图</p>
 <p>如图所示，进程内组件测试有如下变化：</p>
 <ul>
@@ -183,14 +183,14 @@ function hide_canvas() {
 <h3>进程外组件测试</h3>
 <p>进程外组件测试则是将测试替身置于被测服务所在进程之外，因而被测服务需要通过实际网络调用与模拟的外部服务进行交互。</p>
 <p>如下图所示，只用模拟的外部服务（Stub Service）替代了真实的外部服务（External Service），所以模拟的外部服务和被测服务都以单独的进程运行，而对于数据库、消息代理等基础设施模块则直接使用真实的。因此，被测服务和模拟的外部服务存在于不同的进程中，这就是“进程外（out-of-process）”的具体表现。除了对功能逻辑有所验证外，进程外组件测试还验证了微服务具有正确的网络配置并能够处理网络请求。</p>
-<p><img src="assets/CgqCHl8pBlWAB4TKAAaCogpYuQQ495.png" alt="Drawing 3.png" /></p>
+<p><img src="assets/CgqCHl8pBlWAB4TKAAaCogpYuQQ495.png" alt="png" /></p>
 <p>进程外组件测试示意图</p>
 <p>关于外部服务模拟，也有不同的类型，常见的有使用事先构造好的静态数据、通过传参方式动态调用API、使用<strong>录制回放技术</strong>（record-replay mechanism），你可以根据自己的需求选取模拟类型，如果依赖的服务仅提供少数几个固定的功能，并且返回结果较为固定，可以使用静态数据来模拟；如果依赖的服务功能较为单一，但是返回结果有一定的规律，可以使用动态调用 API 的方式来模拟；如果依赖的服务功能丰富多样，那么推荐使用录制回放技术来模拟。</p>
 <p>在实际微服务项目中，进程外的组件测试非常常见，一般使用服务虚拟化工具对依赖的服务进行模拟。上一课时给出了 Wiremock 模拟服务通信的例子，在进行组件测试时，依然可以用Wiremock，但与集成测试不同的是，组件测试需要更加深入：<strong>验证被测服务的功能或行为是否符合预期、返回结果的格式是否符合预期、对服务超时、异常返回等异常行为是否具有容错能力，等等。</strong></p>
 <p>用 Wiremock 模拟服务的具体步骤如下：</p>
 <p>1.下载 <a href="https://repo1.maven.org/maven2/com/github/tomakehurst/wiremock-jre8-standalone/2.27.0/wiremock-jre8-standalone-2.27.0.jar">Wiremock 独立版本</a>（wiremock-jre8-standalone-2.27.0.jar）;
 2.作为独立版本运行，效果如下：</p>
-<p><img src="assets/CgqCHl8pBmaAcHr_AADb2quOzVs534.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/CgqCHl8pBmaAcHr_AADb2quOzVs534.png" alt="png" /></p>
 <p>启动后，Wiremock 会在本地启动一个监听指定端口的 web 服务，端口可以用 --port和 --https-port 来分别指定 http 协议和指定 https 协议端口。之后发到指定端口的请求，就会由 WireMock 来完成响应，从而达到接口 Mock 的目的。</p>
 <p>这时，在本地运行目录下会看到自动生成 __files 和 mappings 两个目录。这两个目录中存放的是 Mock 模拟的接口匹配内容。其中 __files 存放接口响应中会用到的一些文件资源，mappings 存放接口响应匹配规则。匹配文件以 json 格式存放在 mappings 目录下，WireMock 会在启动后自动加载该目录下所有符合格式的文件作为匹配规则使用。</p>
 <p>3.编辑匹配规则文件 tq.json，放到 mappings 目录下，内容如下：</p>
@@ -209,7 +209,7 @@ function hide_canvas() {
 }
 </code></pre>
 <p>注意：body 中的内容为 Json 格式时，需要对其中出现的双引号进行转义，否则启动 Wiremock 时将报错。</p>
-<p><img src="assets/Ciqc1F8pBomAKzePAAI6xPBo8Uo976.png" alt="Drawing 5.png" /></p>
+<p><img src="assets/Ciqc1F8pBomAKzePAAI6xPBo8Uo976.png" alt="png" /></p>
 <p>4.重新启动 Wiremock，访问模拟服务的对应接口（ <a href="http://localhost:8080/api/json/est/now">http://localhost:8080/api/json/est/now</a>），返回如下：</p>
 <pre><code>{
 $id: &quot;1&quot;,
@@ -292,7 +292,7 @@ serviceResponse: null,
 <p>Wiremock 的模拟能力远远不止这些，足够你用它来模拟被测服务，感兴趣的话可以自行探索和学习。</p>
 <h3>“进程内” VS “进程外”</h3>
 <p>如上可知，两种测试方法各有优劣，如下是示意图，方便查看它们的异同：</p>
-<p><img src="assets/CgqCHl8pByGARk8eAAgwMHVWdTI199.png" alt="Drawing 6.png" /></p>
+<p><img src="assets/CgqCHl8pByGARk8eAAgwMHVWdTI199.png" alt="png" /></p>
 <p>两种测试方法的示意图对比</p>
 <p>两种测试类型的优缺点对比：</p>
 <table>
--- a/契约测试：如何进行消费者驱动的契约测试？.md.html
+++ b/契约测试：如何进行消费者驱动的契约测试？.md.html
@@ -159,11 +159,11 @@ function hide_canvas() {
 <p>在介绍契约测试之前，首先来看下什么是契约。现实世界中，契约是一种书面的约定，比如租房时需要跟房东签房屋租赁合同、买房时需要签署购房合同、换工作时你要跟公司签署劳动合同等。在信息世界中，契约也有很多使用场景，像 TCP/IP 协议簇、HTTP 协议等，只是这些协议已经成为一种技术标准，我们只需要按标准方式接入就可以实现特定的功能。</p>
 <p>具体到业务场景中，契约是研发人员在技术设计时达成的约定，它规定了服务提供者和服务消费者的交互内容。可见，无论是物理世界还是信息世界，<strong>契约是双方或多方共识的一种约定，需要协同方共同遵守。</strong></p>
 <p>在微服务架构中，服务与服务之间的交互内容更需要约定好。因为一个微服务可能与其他 N 个微服务进行交互，只有对交互内容达成共识并保持功能实现上的协同，才能实现业务功能。我们来看一个极简场景，比如我们要测试服务 A 的功能，然而需要服务 A 调用服务 B 才能完成，如图：</p>
-<p><img src="assets/CgqCHl8rwdWARQ7JAAAlzqKNM8A650.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl8rwdWARQ7JAAAlzqKNM8A650.png" alt="png" /></p>
 <p>服务 A 所属的研发测试团队在测试时，太难保证服务 B 是足够稳定的，而服务 B 的不稳定会导致测试服务 A 时效率下降、测试稳定性降低。因为，当服务 B 有阻塞性的缺陷或者干脆宕机时，你需要判断是环境问题还是功能缺陷导致的，这些情况在微服务的测试过程中属于常见的痛点问题。因此，为了提升测试效率和测试稳定性，我们会通过<strong>服务虚拟化技术</strong>来模拟外部服务，如图：</p>
-<p><img src="assets/CgqCHl8rwd2AHsPJAAAqXjJCb3o139.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/CgqCHl8rwd2AHsPJAAAqXjJCb3o139.png" alt="png" /></p>
 <p>需要特别注意的是，如果此时你针对内部系统的测试用例都执行通过了，可以说明你针对服务 A的测试是通过的吗？答案是否定的。因为这里面有个<strong>特别重要的假设是</strong>，服务虚拟化出来的Mock B 服务与真实的 B 服务是相等的。而事实是，它们可能只在你最初进行服务虚拟化时是相等的，随着时间的推移，它们很难保持相等。</p>
-<p><img src="assets/CgqCHl8rweeAaDkdAABVWLFzSS8274.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/CgqCHl8rweeAaDkdAABVWLFzSS8274.png" alt="png" /></p>
 <p>可能你会说，保持相等不就是个信息同步的工作嘛，有那么难吗？事实上，说起来容易做起来真的挺难：在实际的研发场景下，一个研发团队需要维护若干（a）个服务，每个服务又有数十（b）个接口，每个接口又被多（c）个团队的服务所调用，可见信息同步的工作量是巨大的（a<em>b</em>c）。</p>
 <p>所以在微服务团队中，如下情况极为常见，每一项都会导致信息不同步：服务 B 的开发团队认为某次修改对服务 A 无影响，所以没告诉服务 A 的开发团队，而实际上是有影响的；服务 B 的开发团队认为某次修改对服务 A 有影响，而服务 A 的开发团队认为无影响；服务 B 的开发团队忘记把某次修改同步到服务 A 的开发团队。</p>
 <p>所以，比较好的方式就是<strong>通过“契约”来降低服务 A 和服务 B 的依赖</strong>。具体指导原则为：</p>
@@ -171,7 +171,7 @@ function hide_canvas() {
 <li>根据服务 A 和服务 B 的交互生成一份“契约”，且契约内容的变化可以及时感知到，并生成模拟服务；</li>
 <li>将服务之间的集成测试，变成两个测试，即真实的服务 A 和模拟服务 B 之间的测试和模拟的服务 A 和真实服务 B 之间的测试。</li>
 </ul>
-<p><img src="assets/Ciqc1F8rwi2AD_NcAABULdvxmSY140.png" alt="Drawing 6.png" /></p>
+<p><img src="assets/Ciqc1F8rwi2AD_NcAABULdvxmSY140.png" alt="png" /></p>
 <p>契约测试示意图</p>
 <p>理解了契约测试产生的背景，我们来讲解下微服务架构下契约测试的具体含义。</p>
 <h3>契约测试介绍</h3>
--- a/端到端测试：站在用户视角验证整个系统.md.html
+++ b/端到端测试：站在用户视角验证整个系统.md.html
@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>端到端测试详解</h3>
 <h4>定义</h4>
 <p><strong>端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。</strong> 它模拟用户真实的使用场景，通过用户界面测试应用程序，如图所示：</p>
-<p><img src="assets/CgqCHl8yTcSAeDftAAB83pJdFxE154.png" alt="image" /></p>
+<p><img src="assets/CgqCHl8yTcSAeDftAAB83pJdFxE154.png" alt="png" /></p>
 <p>与其他类型的测试相反，<strong>端到端测试是面向业务的</strong>，其目的是验证应用程序系统整体上是否符合业务目标。为了实现这一目标，该系统通常被视为<strong>黑盒子</strong>：尽可能完整地部署系统中的微服务，并主要通过 GUI 和 API 等公共接口对其进行操作。</p>
 <blockquote>
 <p>GUI：Graphical User Interface，又称图形用户界面或图形用户接口。它是采用图形方式显示的计算机操作用户界面，是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其他一些日常任务。</p>
@@ -170,7 +170,7 @@ function hide_canvas() {
 <p><img src="assets/Ciqc1F8yTdSAPYvnAAVCHyjoRMg047.png" alt="分层测试策略-示例2.png" /></p>
 <p>分层测试策略-测试范围</p>
 <p>绝大多数情况下，微服务应用系统会依赖一个或多个由外部管理的微服务。通常，这些外部服务包含在端到端测试范围内。 但是，在极少数情况下，也可以主动排除它们。因为如果外部服务由第三方管理，可能会经常出现稳定性和可靠性问题，这会导致端到端测试因不可控的原因而失败。</p>
-<p><img src="assets/Ciqc1F8yTduAWInrAABovfUmzPk447.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8yTduAWInrAABovfUmzPk447.png" alt="png" /></p>
 <p>微服务应用的典型示例</p>
 <p>比如，某个应用程序系统依赖公安部门的背景审查服务，通过调用该服务来查询用户是否有过违法前科。首先这样的服务通常会按调用次数付费（每次 5-10 元），具有较高的测试成本，其次背景审查服务不总是稳定可用的。在这种情况下，通过服务虚拟化技术模拟背景审查服务是个不错的选择，这虽然多少会降低端到端测试的信心，但增加了测试用例套件的稳定性。</p>
 <h4>测试入口</h4>
--- a/微服务架构下的质量保障体系全景概览.md.html
+++ b/微服务架构下的质量保障体系全景概览.md.html
@@ -163,7 +163,7 @@ function hide_canvas() {
 </ul>
 <p>通常情况下，对业务发展来说，<strong>质量保障体系是企业内部系统的技术和管理手段，是有计划的、系统的企业活动，目的是满足业务发展需要，生产出满足质量目标的产品。</strong></p>
 <p>对应到微服务架构下，说得更接地气一点就是为了共同的目标，一群人在一块儿做事。总结如下：</p>
-<p><img src="assets/CgqCHl80zsuAPVCCAACB146hwsY972.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl80zsuAPVCCAACB146hwsY972.png" alt="png" /></p>
 <p>所以，质量保障体系是通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。同时，还需要相应的度量、运营手段以及组织能力的保障。</p>
 <ul>
 <li><strong>体系的定义</strong></li>
@@ -195,7 +195,7 @@ function hide_canvas() {
 </ul>
 <h3>微服务架构质量保障体系的全景概览</h3>
 <p>基于上述分析，通用的微服务质量保障体系如下：</p>
-<p><img src="assets/CgqCHl80zuWAM40oAAC1foc5qII387.png" alt="Drawing 1.png" /></p>
+<p><img src="assets/CgqCHl80zuWAM40oAAC1foc5qII387.png" alt="png" /></p>
 <p>如下是质量保障体系的关键方面，后续课程也将按如下内容展开讲解。</p>
 <ul>
 <li><strong>项目管理和流程规范</strong>：每个业务所做的事情都是把战略规划拆解成大的业务目标，再进一步拆解成产品需求。产品需求又经历了产品研发、运营&amp;运维、售后服务这样的业务价值全流程。没有规矩不成方圆，在这个过程中，无论项目管理还是流程规范，都是保障质量中非常关键的一环，只有建立起闭环、分工明确、易执行的流程规范，才能保证其可落地，从而形成业务价值过程的正循环。</li>
--- a/流程规范篇：高速迭代的研发过程需要怎样的规范？.md.html
+++ b/流程规范篇：高速迭代的研发过程需要怎样的规范？.md.html
@@ -163,7 +163,7 @@ function hide_canvas() {
 <li>售后服务阶段。它主要由客服人员或售后工程师主导，包括解答或解决用户在使用产品后产生的疑问和投诉等。</li>
 </ul>
 <p>产品研发阶段是指需求产生到需求上线的过程，这阶段是测试人员的“主战场”。但这三个阶段共同组成了整个业务流程，要做到全流程质量保障，需要具有全局思维。即<strong>积极影响产品研发阶段</strong>，推动流程规范的制定、建设和完善；<strong>对日常运营/运维阶段和售后服务阶段保持关注</strong>，定期收集这两个阶段中遇到的问题，做好协同和配合，思考在产品研发阶段如何预防或闭环解决这类问题。</p>
-<p><img src="assets/CgqCHl87m3iAXfC1AACy09bRN3E695.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl87m3iAXfC1AACy09bRN3E695.png" alt="png" /></p>
 <p>关注圈&amp;影响圈</p>
 <h3>产品研发流程规范要点</h3>
 <p>好的流程规范（Process specification) 能够保障业务稳步进行，使各部门各司其职。要想使产品研发阶段能够有条不紊地进行，就需要制定和执行流程规范。产品研发流程大体分为需求阶段、研发阶段、测试阶段、发布阶段等，每个阶段都需要有相应的流程规范，从而把需求变成软件产品并发布到线上。</p>
@@ -205,7 +205,7 @@ function hide_canvas() {
 <p>当然，规范的制定与落地，还需要结合人员配备情况、工具建设情况协同来看。</p>
 <h4>规范如何呈现？</h4>
 <p>流程规范涉及多方协作，其呈现形式的第一要点应为<strong>通俗易懂</strong>，一图胜千言，建议采用流程图的方式来展现，比如使用泳道图。</p>
-<p><img src="assets/CgqCHl87m6-AB5XhAAw01YGdoL8801.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/CgqCHl87m6-AB5XhAAw01YGdoL8801.png" alt="png" /></p>
 <p>泳道图示意图</p>
 <blockquote>
 <p>泳道图，一种 UML 活动图，能够清晰体现出某个动作发生在哪个部门，常见工具有 StarUML、Rose、Visio 等。泳道图在纵向上是部门职能，横向是岗位（有时候横向上不区分岗位）。绘图元素与传统流程图类似，但在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位来。</p>
@@ -214,7 +214,7 @@ function hide_canvas() {
 <p>基于此，产品研发阶段的流程可以包含如下内容：</p>
 <h3>产品研发阶段</h3>
 <p>产品研发阶段又进一步分为需求阶段、研发阶段、测试阶段、发布阶段等。</p>
-<p><img src="assets/CgqCHl87m92AUVrRAAC28aNzBao783.png" alt="image" /></p>
+<p><img src="assets/CgqCHl87m92AUVrRAAC28aNzBao783.png" alt="png" /></p>
 <h4>（1）需求阶段：产品需求评审</h4>
 <p>产品需求评审是产品研发阶段中非常重要的环节，通过它可以确保需求表述上没有歧义。需求文档通常的表现形式是产品需求文档（PRD）或市场需求文档（MRD），它们也是技术设计文档和测试设计文档的重要输入，所以这一环节是后续所有工作的基础。</p>
 <p><strong>评审要点</strong></p>
@@ -229,7 +229,7 @@ function hide_canvas() {
 <p>常见的需求表述问题有“同线上逻辑”“同已有逻辑”，或者一句话的概况描述，如“每种状态都需要处理”，却不说明一共有几种状态，这些都非常容易产生理解上的偏差，应该予以杜绝。</p>
 <p>其中，<strong>测试人员尤其要重视需求的可测性。</strong> 早期提出可测试性方面的问题和风险，可以及早应对，从而降低项目风险。否则，到了后续的环节才发现需求不可测，这可能会导致需求变更或技术实现方案的变更，这对质量和效率的影响就太大了。</p>
 <p><strong>测试人员如何参与需求评审？</strong></p>
-<p><img src="assets/CgqCHl87m7qAQWKQAAE2Bwd7NNk811.png" alt="Drawing 3.png" /></p>
+<p><img src="assets/CgqCHl87m7qAQWKQAAE2Bwd7NNk811.png" alt="png" /></p>
 <p>对于测试人员来说，在要进行需求评审或技术设计评审时，通常情况下还在另外一个需求的测试执行过程当中。测试执行过程通常需要投入较高的专注度，所以很多测试人员最最容易出现的情况是，<strong>弱化需求评审或技术设计评审环节，投入度较低，等其他需求测试完成了再花精力去熟悉它。</strong> 殊不知，这就造成了长期的恶性循环。<strong>正确的做法是，强化需求评审或技术设计评审环节，投入较多的精力，前置思考好一个需求中的重点、难点、风险点，提前应对</strong>。如果与测试执行时间有一定的冲突，则可以优先投入更多的个人时间来化解，同时在后续的测试执行过程中留有一定的 buffer，几个需求过后，你就会进入一个良性循环。对其他关键的评审环节，如技术设计评审也同样适用。</p>
 <h4>（2）研发阶段：技术设计评审</h4>
 <p>技术设计主要评审是否满足业务需求的功能和非功能质量属性，以及发布方案是否完备。</p>
@@ -256,7 +256,7 @@ function hide_canvas() {
 <p>如果前面的阶段完成得较好，测试执行阶段和发布阶段就会轻松很多。在这两个阶段，只需要按计划执行，出现风险时要及时并充分地暴露出来。</p>
 <p>其中，测试执行阶段会涉及缺陷管理、测试总结与分析、测试报告编写等工作，这些是测试人员的看家本领，此处不再赘述。发布阶段需要前置准备发布内容、采用既定的发布策略，发布完成后实时观察线上日志、并进行线上回归。发布过程如果出现问题，切忌不要在线上解决问题，应立即回滚。线上回归完毕后，需持续关注监控指标，对告警进行及时响应。</p>
 <p>这里给出了产品研发的流程图，从该图中可以看出来各个职能角色的关键活动和活动状态流转。其中，所有的“菱形”环节都是需要 PM、RD、QA 三方参与的。</p>
-<p><img src="assets/Ciqc1F87m_yAVZrZAAEicbx-lP4999.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/Ciqc1F87m_yAVZrZAAEicbx-lP4999.png" alt="png" /></p>
 <p>产品研发阶段流程规范</p>
 <h3>实践经验和认知</h3>
 <p>好的流程规范能够保障业务稳步进行，使各部门各司其职。但它也不是万能的，这里给出一些实践经验和认知，供你参考：</p>
--- a/测试技术篇：测试技术这么多，我该如何选型？.md.html
+++ b/测试技术篇：测试技术这么多，我该如何选型？.md.html
@@ -243,9 +243,9 @@ function hide_canvas() {
 <p>在换工作时通常会出现这样的情况：有不止一份工作机会，但也没有哪份工作有着特别明显的优势能够让你快速做出判断。出现这种情况时比较愁人，虽然最终还是在艰难中做出了选择，但更好的方式是建立起对工作机会打分的判断逻辑，大体步骤如下：</p>
 <p>1.列举出你选择工作岗位时最看重的几个特征，比如是个人发展、工作强度、上班距离、薪资待遇和其他。
 2.对上述特征进行权重设置，使其总分为100，比如权重设置如下：</p>
-<p><img src="assets/Ciqc1F8-PM6AF1J4AAAo8nt74JY978.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8-PM6AF1J4AAAo8nt74JY978.png" alt="png" /></p>
 <p>3.把你候选的工作，按上述特征进行打分，并计算最终得分。比如，个人发展特征的满分是40，这三家公司在个人发展方面的优势差异明显，公司C&gt;公司A&gt;公司B，最终各项得分如下，其他特征也依次打分：</p>
-<p><img src="assets/Ciqc1F8-PN6AYHxDAABJ7vA_stw401.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8-PN6AYHxDAABJ7vA_stw401.png" alt="png" /></p>
 <p>4.通过上述你就可以知道这三份工作最终的得分情况。</p>
 <p>由上可知，通过评测打分机制，要比你完全不进行量化更容易做决策。其中，对一家工作关注的指标和权重可以随着你职业发展的阶段进行调整，比如有的测试人员找工作时只看个人发展，其他都是浮云，那么就可以把特征设置为“个人发展+其他”，个人发展的权重可以设置为一个比较大的值，比如 90，其他的权重为 10。如果还会考虑其他特征，也可以补充进去并设置权重，所以，这个评测逻辑可以做到以不变应万变。</p>
 <p>从找工作的例子中可以做下“映射”，在建设评测机制时，可以进行如下步骤。</p>
--- a/测试技术篇：如何提升测试效率？.md.html
+++ b/测试技术篇：如何提升测试效率？.md.html
@@ -204,7 +204,7 @@ TCPCopy 是国内各大互联网公司广泛应用 XCopy 系列工具之一，XC
 <blockquote>
 <p>Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎。Jenkins 是一款开源 CI&amp;CD 软件，用于自动化各种任务，包括构建、测试和部署软件。Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序。</p>
 </blockquote>
-<p><img src="assets/CgqCHl9EwKKAZnW6AAWgEd90r1M546.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9EwKKAZnW6AAWgEd90r1M546.png" alt="png" /></p>
 <p>CI/CD 示意图</p>
 <p>由上图可知，在研发人员提交代码后，CI 服务根据指定分支自动执行“编译-打包-部署”，之后执行一系列的自动化测试，每一个阶段的测试结果都反馈给开发人员，这样就可以实现“快速反馈、快速解决”的效果，提升研发和测试效率。可见，<strong>自动化测试技术可以在持续集成中应用起来。</strong></p>
 <h3>认知</h3>
--- a/测试技术篇：专项测试技术解决了哪些专项问题？.md.html
+++ b/测试技术篇：专项测试技术解决了哪些专项问题？.md.html
@@ -169,7 +169,7 @@ function hide_canvas() {
 <p>对于微服务架构来说，非功能测试有很多，常见的有如下几类。</p>
 <h4>如何找出系统性能瓶颈？——全链路压力测试</h4>
 <p>对于服务端来说，性能测试尤为重要。通常情况下，会通过单接口性能测试来发现其性能问题并优化解决。常见的工具有 Apache Benchmark、Jmeter、LoadRunner 等。微服务架构下，单接口性能测试很难模拟出接近生产环境的场景和数据规模，因为**整个集群和系统的性能取决于接口的短板效应（如图短板效应）。**而短板的接口，在正常的流量下，是不会显现出来的。</p>
-<p><img src="assets/Ciqc1F9HhYKAbfm5AAH1tS8KaYw978.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/Ciqc1F9HhYKAbfm5AAH1tS8KaYw978.png" alt="png" /></p>
 <p>短板效应</p>
 <p>微服务架构下，系统及接口不是独立存在的，它们的相互调用关系复杂。当业务流量暴涨时，从网关接入层到各级后端服务都将面临巨大的请求压力，而且还受到公共资源的制约，如 CDN、网络带宽、消息队列、缓存、各类中间件、数据存储等，最终会体现为某个服务的处理能力出现瓶颈，引发宕机。当某个单点服务出现性能问题时，这种问题会快速累积放大，进而成为系统性问题，如果不及时解决，会造成雪崩效应，进一步引发整个系统集群的瘫痪。</p>
 <p>这样的情况下，可以引入全链路压测，它是基于生产环境的业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。通过压测确定系统的基准吞吐量，找到集群的短板，快速找到特定场景下的集群服务器配比和每个系统支撑该场景所需服务器的数量。因此，全链路压测起到了两层作用，一来可以发现整个系统的服务能力瓶颈，进行针对性地优化；二来可以获取合理的服务器数量配比，针对短板服务增加机器配置或数量，用容量来换取性能，极大地节省成本。</p>
@@ -193,10 +193,10 @@ function hide_canvas() {
 <p>相关的工具有 Chaos Monkey 和 ChaosBlade。Chaos Monkey 是 Netflix 开发的开源工具，它可以在生产环境随机选择并关闭服务。ChaosBlade 是阿里巴巴开源的一款混沌工程工具，可实现底层故障的注入和丰富的故障场景实现，从而帮助分布式系统提升容错性和可恢复性。</p>
 <h3>对专项测试技术的看法</h3>
 <p>作为测试人员，不要小看非功能性测试或专项测试。在招聘网站中也很常见，一些专项测试会设置固定的岗位，薪资可观，可见其稀缺性，且如果把它们做到高精尖，可以作为你职业发展路上的核心竞争力。</p>
-<p><img src="assets/Ciqc1F9HhZSABW9YAALI_I0DAAM161.png" alt="Drawing 1.png" />
-<img src="assets/Ciqc1F9HhZqANSByAADUhWjtQW0820.png" alt="Drawing 2.png" />
-<img src="assets/CgqCHl9HhZ-ANH89AADTLTRX-AM118.png" alt="Drawing 3.png" />
-<img src="assets/Ciqc1F9HhaOAJd84AAEuEQvaf-I032.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/Ciqc1F9HhZSABW9YAALI_I0DAAM161.png" alt="png" />
+<img src="assets/Ciqc1F9HhZqANSByAADUhWjtQW0820.png" alt="png" />
+<img src="assets/CgqCHl9HhZ-ANH89AADTLTRX-AM118.png" alt="png" />
+<img src="assets/Ciqc1F9HhaOAJd84AAEuEQvaf-I032.png" alt="png" /></p>
 <h3>总结</h3>
 <p>本课时我讲解了微服务架构除了具有功能的质量属性，还具有很多非功能的质量属性，如可靠性、可测性、可用性、可扩展性等，而要验证这些属性，需要引入专项测试（非功能测试）技术。常见的专项测试技术如下：</p>
 <ul>
--- a/篇：如何更好地利用多个“测试”环境？.md.html
+++ b/篇：如何更好地利用多个“测试”环境？.md.html
@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>CI/CD &amp; “测试”环境</h3>
 <p><strong>CI/CD</strong></p>
 <p>缩略词 CI/CD 具有几个不同的含义，CI/CD 中的“CI”始终指<strong>持续集成</strong>（Continuous Integration），它代表研发人员工作的自动化流程，<strong>目的是让正在开发的软件始终处于可工作状态，</strong> 它主要关注代码是否可以编译成功，以及是否可通过单元测试和验收测试等。即，每次当开发人员提交了新代码，CI服务器会自动对这些代码的所属服务进行构建，并对其执行全面的自动化测试。根据测试的结果，可以确定新提交的代码和原有代码是否正确地集成在一起了。如果整个过程中出现了构建失败或测试失败，也需要立即让开发人员知道并修复。如此重复这个过程，就可以确保新代码能够持续地与原有代码正确地集成。</p>
-<p><img src="assets/CgqCHl9OBxOAOKByAAPwRmhK4Dg635.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl9OBxOAOKByAAPwRmhK4Dg635.png" alt="png" /></p>
 <p>持续集成示意图</p>
 <p>而“CD”的含义却有两种：持续交付（Continuous Delivery）、持续部署（Continuous Deployment）。持续部署和持续交付是两个特别容易混淆的概念，它们之间最为本质的区别是：<strong>持续部署是一个技术操作，而持续交付则是一个业务行为。</strong></p>
 <p>我这边具体展开来说下它们两者的区别。</p>
@@ -167,20 +167,20 @@ function hide_canvas() {
 </ul>
 <p>持续交付是指所有开发人员始终让 Master 分支（也叫做主干分支或发布分支）保持可随时发布的状态，根据实际需要来判断是否进行一键式地发布。</p>
 <p>持续交付主要通过如下方式来实现：开发人员在特性分支（Feature分支）上工作，这些分支存在比较短暂的时间，进行过相应的功能测试后，则可以合并到 Master 分支。如果发现引入了其他错误类型（包括缺陷、性能问题、安全问题、可用性问题等）则将测试结果反馈给开发人员，开发人员立即对问题进行解决，使主干始终处于可部署状态，如下图所示。</p>
-<p><img src="assets/Ciqc1F9OByCADkrgAAd1WJT6DX0767.png" alt="Drawing 1.png" /></p>
+<p><img src="assets/Ciqc1F9OByCADkrgAAd1WJT6DX0767.png" alt="png" /></p>
 <p>持续交付示意图</p>
 <ul>
 <li>持续部署</li>
 </ul>
 <p>持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式地向生产环境部署优质的构建版本，甚至每当开发人员提交代码变更时，就触发自动化部署到生产环境。<strong>可见，持续交付是持续部署的前提，就像持续集成是持续交付的前提条件一样。</strong> 如下图所示。</p>
-<p><img src="assets/CgqCHl9OByaAPz2NAAFRgHQ4La4072.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/CgqCHl9OByaAPz2NAAFRgHQ4La4072.png" alt="png" /></p>
 <p>持续部署示意图</p>
 <p>由上图可知，无论 CD 是持续部署还是持续交付，<strong>CI/CD 都是将重复的、手工的工作用自动化的方式来代替</strong>。因为这样可以减少不同阶段之间等待的时间成本、降低手工操作的出错率、快速收到反馈并修改。久而久之，最终整个产品的交付周期就缩短了。下面，本课时中的 CD 统一表示持续交付。</p>
 <p><strong>“测试”环境</strong></p>
 <p>文章标题提到的“测试”环境，并非代表我们日常所说的测试环境（Test 环境），而是产品交付过程中的各种环境。因为在产品交付过程中，不同的环境有着不同的特性和作用，需要在其中进行不同类型、针对不同对象的测试，所以它们都能起到“支撑测试活动”的作用。</p>
 <p>如上述的<strong>持续部署示意图</strong>或<strong>持续交付示意图</strong>所示，在产品交付过程中，从代码提交到发布到生产环境，会经历多个环境，如 Test 环境、Staging 环境和 Prod 环境等，这些环境在 CI/CD 方面发挥着“价值传递”的作用。</p>
 <p>例如，某个业务有一个名叫 Order 的微服务，研发人员对其进行开发后，需要先将代码提交到代码仓库。然后 CI 服务器从代码仓库中将代码拉取到 CI 服务器的特定目录，再通过提前配置好的编译命令对该服务进行编译，并将结果部署到 Test 环境中。如果 Test 环境测试通过，则会进一步部署到 Staging 环境中，Staging 环境测试通过后会以自动化或手工触发的方式在生产环境中部署。由此可见，<strong>Test、Staging、Prod 三个环境对要发布的微服务进行着构建和测试，每前进一步，该微服务就离交付更近一步，离实现业务价值就更近一步。</strong></p>
-<p><img src="assets/Ciqc1F9OBzOABTF9AATo-qaOITQ554.png" alt="Drawing 3.png" /></p>
+<p><img src="assets/Ciqc1F9OBzOABTF9AATo-qaOITQ554.png" alt="png" /></p>
 <p>多环境实现价值传递</p>
 <p>我们知道，CI/CD 的本质是产品价值的传递。因此，当代码提交后会经历编译、部署，最终形成二进制包，这些软件包会流经不同的环境进行测试。可见，<strong>环境是产品交付过程中价值传递的载体。</strong></p>
 <p>为了快速交付产品价值，需要及时地在不同环境对产品进行测试，这不仅需要各自环境足够稳定，还需要在各种环境中进行各种类型的自动化测试。测试通过后，产品发布到线上，测试不通过，则快速将结果反馈给开发人员。这样便实现了**“快速响应，快速反馈”**的效果。这也是 CI/CD 的精髓。</p>
@@ -195,15 +195,15 @@ function hide_canvas() {
 <ul>
 <li><strong>整个测试团队共用一套测试环境</strong>：微服务架构下，当一个服务被多个服务依赖时，如果该服务不稳定，那么会影响其他大量服务无法测试。如图，当服务 B 不可用时，依赖服务 B 的其他服务也无法使用。</li>
 </ul>
-<p><img src="assets/CgqCHl9OB0OAMuxiAABf6EuumI0144.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/CgqCHl9OB0OAMuxiAABf6EuumI0144.png" alt="png" /></p>
 <ul>
 <li><strong>每个测试人员一套完整的测试环境</strong>：这种情况下虽然可以解决环境依赖问题，但软硬件成本高，环境维护成本比较高，服务器资源利用率比较低。比如，业务系统包含 40 个微服务，测试团队有 10 人，那么就需要 40*10=400 台服务器来管理测试环境。现如今，虚拟化技术盛行，虽然可以从一定程度上减少资源成本，但维护成本依然不容忽视。</li>
 </ul>
-<p><img src="assets/Ciqc1F9OB1SARKn1AACBPT1nKJM083.png" alt="Drawing 6.png" /></p>
+<p><img src="assets/Ciqc1F9OB1SARKn1AACBPT1nKJM083.png" alt="png" /></p>
 <ul>
 <li><strong>服务级复用的虚拟化技术，基于消息路由的控制，实现集群中部分服务的复用。</strong> 像阿里的“公共基础环境+特性环境”，美团的“骨干链路+泳道链路”、有赞的“基础环境（Default Service Chain）+SC 环境（Service-Chain）”都是在此方向上的有效尝试。</li>
 </ul>
-<p><img src="assets/CgqCHl9OB1-AJu65AACHP4QdVqU442.png" alt="Drawing 8.png" /></p>
+<p><img src="assets/CgqCHl9OB1-AJu65AACHP4QdVqU442.png" alt="png" /></p>
 <p>服务链路隔离和复用</p>
 <p><strong>测试环境的测试关注点</strong></p>
 <p>测试人员将在该环境进行新功能测试、回归验证 Bug等内容，这包含了微服务架构下的分层测试策略（集成测试、组件测试、契约测试、端到端测试），以及一些非功能类型的测试。</p>
@@ -218,7 +218,7 @@ function hide_canvas() {
 </ul>
 <p>如果预发布环境使用生产环境的数据库备份，则需要进行不定期的数据库同步，保持和生产环境的设置、数据一致性。</p>
 <p>通常来讲，微服务架构下，数据库有许多库表且数据存储量大，所以以备份数据库方式的预发布环境比较少。如下图所示，两种预发布环境的区别在于使用数据库的方式。</p>
-<p><img src="assets/CgqCHl9OB2-AcVl6AAB34w7trfU945.png" alt="Drawing 10.png" /></p>
+<p><img src="assets/CgqCHl9OB2-AcVl6AAB34w7trfU945.png" alt="png" /></p>
 <p>预发布环境连接的数据库有所不同</p>
 <p><strong>Staging 环境的特点</strong></p>
 <p>Staging 环境的特点是高度仿真，它是正式发布前的最后一个环境，数据库同生产环境。对于“数据库同生产环境”这一特点来说，需要特别注意的是，对于同一条用户数据，应避免同时在预发布环境和生产环境对其进行变更。因为数据库缓存存在这两套环境中，可能会产生数据不一致等问题，且难以定位和修复。</p>
@@ -237,7 +237,7 @@ function hide_canvas() {
 </ul>
 </li>
 </ul>
-<p><img src="assets/CgqCHl9OB3-AFaigAACcuc533fA687.png" alt="Drawing 12.png" /></p>
+<p><img src="assets/CgqCHl9OB3-AFaigAACcuc533fA687.png" alt="png" /></p>
 <ul>
 <li>回归测试：在该环境进行回归测试，应尽量避免造成脏数据。发布过程需要流量来验证，建议采用 UI 层面的端到端自动化测试。</li>
 <li>特殊内容测试：测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。</li>
@@ -280,7 +280,7 @@ function hide_canvas() {
 </ul>
 <p>UAT(User Acceptance Test)，用户接受度测试，即验收测试，所以 UAT 环境主要是用来作为客户体验的环境。这个阶段可以收集客户的体验反馈，对于出现的问题可反哺到研发交付过程中。</p>
 <h4>各环境关系</h4>
-<p><img src="assets/Ciqc1F9OCA-AJ3ldAACj9CaQBck366.png" alt="11.png" /></p>
+<p><img src="assets/Ciqc1F9OCA-AJ3ldAACj9CaQBck366.png" alt="png" /></p>
 <p>生产环境之外的环境，都是对生产环境的仿真。仿真程度不同，能做的测试类型和深度是不同的。而生产环境，因为它的特殊性，能做的测试也是有限的，所以需要配合使用。几个环境最大的好处就是各司其职，既不会影响开发，也不会影响测试工作。</p>
 <h3>总结</h3>
 <p>本节课我讲解了 CI/CD 的基本概念，和“测试”环境。CI/CD 是持续集成和持续交付的意思，“测试”环境指的是产品交付过程中的各类环境，在 CI/CD 中的起到了产品价值传递的重要作用。</p>
--- a/篇：如何构建持续交付工具链？.md.html
+++ b/篇：如何构建持续交付工具链？.md.html
@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>持续交付工具链</h3>
 <p>持续交付在上一篇文章中已经提到，它是指所有开发人员始终让 Master 分支保持可随时发布的状态，根据实际需要来判断是否进行一键式发布。而工具链（Tool Chain）通常是指一系列工具，它们按照一定的逻辑顺序运行，最终完成一件比较复杂的事情。</p>
 <p>因此，持续交付工具链是帮助我们把持续交付进行落地的工具集合或自动化平台，它可以固化产品交付过程中的各个环节，实现自动化地构建、部署、测试、输出报告等工作。如下图所示。</p>
-<p><img src="assets/CgqCHl9QjxSAYZYgAAd1WJT6DX0137.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/CgqCHl9QjxSAYZYgAAd1WJT6DX0137.png" alt="png" /></p>
 <p>持续交付示意图</p>
 <p><strong>构建持续交付工具链需要考虑哪些内容？</strong></p>
 <p>通过上面的描述，不难看出，构建持续交付工具链涉及如下工作。</p>
@@ -214,7 +214,7 @@ function hide_canvas() {
 <p>只是通知还不够，很多时候一些不太好的数据需要持续的运营。比如，部署环境总是失败，阻塞了工具链的执行；提测后自动化用例执行失败较多，需要进一步查看是自动化用例稳定性问题、环境稳定性问题还是代码质量问题；这些内容都需要有量化的数据才有利于改进。</p>
 <h3>工具的整合</h3>
 <p>用于持续交付的工具有很多，这里不一一列举，借用<a href="http://www.jamesbowman.me/">James Bowman</a>的一张图：</p>
-<p><img src="assets/CgqCHl9Qj3iAKWw_ABiFJEg8CSU454.png" alt="Drawing 1.png" /></p>
+<p><img src="assets/CgqCHl9Qj3iAKWw_ABiFJEg8CSU454.png" alt="png" /></p>
 <p>除了图片中的工具，还有很多在持续交付过程中发挥作用的工具：</p>
 <ul>
 <li>服务发现和全局配置存储，例如 ZooKeeper 等；</li>
@@ -256,7 +256,7 @@ pipeline {
 }
 </code></pre>
 <p>Jenkins Pipeline 可以轻松实现如下所示的持续交付效果：</p>
-<p><img src="assets/Ciqc1F9Qj4uADoy1AAHSlw_w0bw987.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/Ciqc1F9Qj4uADoy1AAHSlw_w0bw987.png" alt="png" /></p>
 <h3>总结</h3>
 <p>本节课我首先讲解了持续交付工具链，它是帮助我们把持续交付进行落地的工具集合或自动化平台，用于固化产品交付过程中的各个环节，实现自动化地构建、部署、测试、输出报告等工作。然后讲解了构建持续交付工具链需要进行基础设施盘点、组织支持、关键过程自动化、工具的整合。</p>
 <p>接着我讲解了持续交付全流程中的关键过程，如下所述。</p>
--- a/度量与运营篇：如何做好质量和效率的度量与运营？.md.html
+++ b/度量与运营篇：如何做好质量和效率的度量与运营？.md.html
@@ -183,23 +183,23 @@ function hide_canvas() {
 引领性指标：与滞后性指标相反，是一个前置指标。</p>
 </blockquote>
 <p>滞后性指标只能告诉你目标是否达成，不会告诉你怎么样达成这个目标（即过程）。而引领性指标，对结果可预见，过程可控制。所以，在软件交付过程中，要从关注滞后性指标改为关注并改善引领性指标。交付过程中的过程质量则是引领性指标，按照交付阶段，产品交付过程又分为需求阶段、开发阶段、测试阶段、发布阶段，因此质量度量可以进一步细分为按如下核心指标。</p>
-<p><img src="assets/Ciqc1F9XTPCAdI9TAABgnhBkp1o742.png" alt="Drawing 0.png" /></p>
+<p><img src="assets/Ciqc1F9XTPCAdI9TAABgnhBkp1o742.png" alt="png" /></p>
 <h4>(1) 交付质量</h4>
 <p>对于微服务来说，线上质量可以通过如下维度来度量。</p>
-<p><img src="assets/Ciqc1F9XTPqAHeMfAACXA5zxpjc791.png" alt="Drawing 1.png" /></p>
+<p><img src="assets/Ciqc1F9XTPqAHeMfAACXA5zxpjc791.png" alt="png" /></p>
 <p>从上述指标不难看出，保障交付质量是要努力减少线上故障和线上缺陷，降低故障级别。微服务架构线上故障几乎不可避免，那么就需要最大限度地降低线上故障的影响，比如降低线上故障的恢复时长，减少对生产环境真实用户的影响。</p>
 <h4>(2) 过程质量之需求质量</h4>
 <p>在产品交付过程中，需求的规划和评审是起点，所以规划质量和内容质量会间接影响到代码质量和测试质量。需求质量通常有两层理解，一是需求所涉及的研发项目的质量，这种理解比较接近整个需求开发的过程质量，二是该需求所对应的 PRD 的规划质量和内容质量，本文指的是第二种。</p>
 <p>PRD 的质量可以用如下指标来衡量。</p>
-<p><img src="assets/Ciqc1F9XTQSAXRjrAADpKrcd9Vk328.png" alt="Drawing 2.png" /></p>
+<p><img src="assets/Ciqc1F9XTQSAXRjrAADpKrcd9Vk328.png" alt="png" /></p>
 <p>一般来说，需求质量 Bug 数应该占总 Bug 数的 5% 左右。需求评审打回的标准可以是发现 5 个逻辑类的问题。需求评审打回、需求变更、需求插入等情况，对软件过程的健康度和质量有较大危害，建议制定相对严苛的流程规范，并结合质量运营手段来应对此类情况，以减少此类情况发生。比如需求评审不通过时，需求文档的作者需要向相关人员发送重新评审的申请邮件，并针对当次打回情况做改进分析。</p>
 <h4>(3) 过程质量之开发质量</h4>
 <p>我们在工作中，经常会反馈开发质量差的问题，但是有多差、差在哪里，又很难说清楚。常见的开发质量指标有：</p>
-<p><img src="assets/Ciqc1F9XTRGADTSXAACS3HW8brk250.png" alt="Drawing 3.png" /></p>
+<p><img src="assets/Ciqc1F9XTRGADTSXAACS3HW8brk250.png" alt="png" /></p>
 <p>一般情况下，提测质量等于 1 才符合预期，即 15/15、12/12 等，因为只要有 1 条冒烟用例执行不通过，则可以进行提测打回。你可能会好奇，既然有 1 条执行不通过就提测打回，那么是不是就不用执行后续用例了，直接记录提测打回数为 1 不是更好吗？这是因为，即使提测打回的情况下，比如提测质量是 1/15 还是 13/15，还是有很大区别的，这也是为了后续更好地进行质量分析和运营。</p>
 <h4>(4) 过程质量之测试质量</h4>
 <p>质量度量过程中，测试团队和人员自身的测试质量也需要额外重视，常见的指标有：</p>
-<p><img src="assets/Ciqc1F9XTSSAALWnAACwR0t2U00021.png" alt="Drawing 4.png" /></p>
+<p><img src="assets/Ciqc1F9XTSSAALWnAACwR0t2U00021.png" alt="png" /></p>
 <h4>(5) 过程质量之发布质量</h4>
 <p>发布环节直接操作线上环境，是非常关键的一个环节，它的质量不容忽视。所以，需要特别留意发布类的相关指标，常见的有：</p>
 <ul>
@@ -239,7 +239,7 @@ function hide_canvas() {
 <p>通常来说，初创业务或成长期业务下，业务变化快，质量保障建设薄弱，质量痛点问题多，质量目标难以确定，这时候以质量痛点驱动为主。随着业务逐渐成熟和稳定，质量在业务中的重要性更为凸显，对质量目标的要求越来越高，这时候以质量目标驱动为主，质量痛点驱动为辅。</p>
 <h4>D（Do）：实施落地计划</h4>
 <p>无论采取怎样的质量改进思路，质量运营都是一个持续运转和迭代的过程，运营周期不同，目的和关注点也有较多不同，具体如下：</p>
-<p><img src="assets/Ciqc1F9XTTyAX-g9AAB1ACo7eeA340.png" alt="Drawing 5.png" /></p>
+<p><img src="assets/Ciqc1F9XTTyAX-g9AAB1ACo7eeA340.png" alt="png" /></p>
 <p><strong>数据收集和聚合</strong></p>
 <p>有了质量度量体系，还需要针对这些指标所对应的数据进行收集和聚合，这就需要在产品研发过程的关键环节进行”埋点“，对关键过程数据和结果数据进行存储。因此，建议利用成熟的项目过程管理工具，如 Jira、TAPD 等。随着度量指标的丰富，可能还需要进行二次开发或者自建平台。</p>
 <h4>C（Check）：复盘和反馈</h4>
--- a/度量与运营篇：如何度量与运营效率和价值？.md.html
+++ b/度量与运营篇：如何度量与运营效率和价值？.md.html
@@ -162,7 +162,7 @@ function hide_canvas() {
 <p>因为交付效率有非常强的相对属性，所以，去度量某一个团队或阶段的效率似乎没有太大意义，投入产出比很低，不如采用相对的方式查看不同团队或阶段的相对效率。因此，可以通过如下维度进行度量。</p>
 <h5>1. 交付周期比、工时比</h5>
 <p>交付周期指一个需求从想法提出到发布到线上的周期跨度，这其中，按阶段又可以分为需求阶段、开发阶段、测试阶段，等等，它们属于交付周期的子集。通常使用周期比、工时比两个指标来衡量效率。其中，周期比是指交付周期中日期的实际跨度（排除节假日），工时比是指实际投入的工时，一般以 PD（Person Day 即人日）为单位。</p>
-<p><img src="assets/Ciqc1F9aBdqAbxgcAAByrfGDeno440.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBdqAbxgcAAByrfGDeno440.png" alt="png" /></p>
 <p>如上图，需求阶段从想法提出、产出需求文档到完成需求评审共跨越了 10 天，因此周期为 10 天。而在这 10 天时间里，共投入了 15 PD。随后，研发人员开始进行技术设计和评审、编码、联调、自测等环节，共跨越 15 天，总投入 60 PD。与此同时，测试人员开始进行测试设计，投入 2 PD。研发人员提交测试后，测试人员开始测试执行，跨越了 5 天，投入 10 PD人力。需要特别注意的是，测试设计阶段的周期是 0 天，这是因为测试设计阶段的周期在开发阶段的周期内，从交付视角看，测试设计并没有占用额外的周期。</p>
 <p>所以，对于这个需求来说，三个阶段的总周期是 10+15+5=30 天，工时投入是 15+60+2+10=87 PD。从周期上看，需求阶段、开发阶段、测试阶段的周期比为 10:15:5，从工时比维度看，需求阶段、开发阶段、测试阶段的人日比为 15:60:12。</p>
 <p>通过上面的数据还可以知道，如果每个阶段只有 1 个人力投入到项目中，那么该阶段的周期数应等于工时数。周期数大于工时数时，意味着在项目交付过程中有挂起或等待的时候。工时数大于周期数，意味着利用周期内的节假日进行了赶工（也就是加班）。无论是等待还是加班，都属于非正常情况，需要深入分析，使项目交付过程正常化。同样，每个阶段有多人投入的情况也是如此，只不过涉及多人时，需要弄清楚在每个阶段，多个人是如何参与和协同的，分析复杂度也将有所提高。</p>
@@ -171,7 +171,7 @@ function hide_canvas() {
 <blockquote>
 <p>累积流量图由精益思想的创始人 Don Reinertsen 和 David Anderson 引入。它是一个综合的价值流度量方法，通过它可以得到不同维度的信息，反应 WIP 的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。它是追踪和预测敏捷项目的重要工具。它从不同方面描述工作：总范围、进行中和已完成的。</p>
 </blockquote>
-<p><img src="assets/CgqCHl9aBeSAGULSAABY0WhIW08217.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBeSAGULSAABY0WhIW08217.png" alt="png" /></p>
 <p>如上图，黑线代表不同时间点，需求评审完成进入开发阶段的需求个数；红线代表不同时间点，开发人员提交给测试人员进行测试的需求个数；绿线代表测试人员完成测试，等待发布到生产环境的需求个数。同一时刻，黑线和红线的差值表示待开发任务的“堆积”，红线和绿线的差值表示待测试任务的“堆积”，反映了交付过程中的开发和测试效率瓶颈。</p>
 <h5>2. 吞吐率</h5>
 <p>吞吐率是单个阶段的效率衡量，它表示单位时间内，团队能够交付多少产出。产出这个词听起来比较“虚”，软件产品交付不是计件工作制，因此很难完全标准化。比如，同一个人，一天时间编写了 500 行代码，第二天编写了 300 行代码，那么它哪一天的效率更高？两个人，一天的时间分别编写了 500 行代码和 300 行代码，哪个人的效率更高？很难判断。</p>
@@ -206,21 +206,21 @@ function hide_canvas() {
 <li>测试团队视角</li>
 </ul>
 <p>测试团队视角主要查看团队人数、团队内分工、测试技术建设和测试团队的需求吞吐率等信息。</p>
-<p><img src="assets/Ciqc1F9aBfmACNNeAABebK14DKQ976.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBfmACNNeAABebK14DKQ976.png" alt="png" /></p>
 <ul>
 <li>测试人员视角</li>
 </ul>
 <p>测试人员视角主要查看测试人员本身的问题。</p>
-<p><img src="assets/CgqCHl9aBgOABXVLAACFQBPPpf4829.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBgOABXVLAACFQBPPpf4829.png" alt="png" /></p>
 <h5>3. 项目组视角</h5>
 <p>分析了测试人员的效率瓶颈外，还可以扩大关注圈到产品交付过程视角，针对每个阶段进行区别分析。因为测试阶段之前的阶段出现问题，会导致测试团队花更多的力气去调整和适应，且更容易在过程中出现各种各样的非预期问题，遗患无穷。</p>
-<p><img src="assets/Ciqc1F9aBg2AP2suAACqSl_5IF8597.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBg2AP2suAACqSl_5IF8597.png" alt="png" /></p>
 <p>这里说一下我自己的经历，我分析过比较多的反馈测试人员资源不足类的实例，最后发现根本问题有两个：一是测试人员的效率的确可以再提升，二是由于项目规划导致，项目规划时没有把测试人员当作是一种必备资源进行整体考虑和预排期，而是直接按顺序排时间，等到了测试人员排期时才发现不符合预期，于是想当然地产生了“测试人员人再多一些就好了”“测试人员效率再高一些就好了”的诉求。当然，每个项目和团队的问题总是千差万别，建立起分析框架，遇到问题时多维度分析，以不变应万变。</p>
 <h3>价值度量与运营</h3>
 <p>无论是保障质量还是提升交付效率，都是在“如何正确地进行产品交付”这个维度上，那么如何确保产品本身是正确的呢？即，产品本身传递了正确的价值，这就需要对价值进行度量。</p>
 <h4>价值度量指标</h4>
 <p>无论产品形态是怎样的，产品价值不外乎是业务层面的价值体现和技术方面的价值体现，如图所示：</p>
-<p><img src="assets/CgqCHl9aBhuAZAG1AAFF3SLG8Pg504.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBhuAZAG1AAFF3SLG8Pg504.png" alt="png" /></p>
 <p>产品价值度量指标</p>
 <p>这些指标不难理解，这里不再赘述具体含义。</p>
 <h4>价值闭环运营</h4>
--- a/组织保障篇：质量是设计出来的.md.html
+++ b/组织保障篇：质量是设计出来的.md.html
@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>协同方角色</h3>
 <p>我在第 10 课时“流程规范篇：高速迭代的研发过程需要怎样的规范？”中有提到，产品研发是为业务服务的。业务流程分为 3 个阶段：产品研发阶段、日常运营/运维阶段、售后服务阶段。这三个阶段涉及许多部门角色的协作，包含但不限于产品经理、研发人员、质量保障人员、客服人员、SRE、业务运营人员、法务人员、商务人员、财务人员等。</p>
 <p>下面将对在业务流程中与质量保障人员打交道最多的角色及职责进行讲解。</p>
-<p><img src="assets/Ciqc1F9ggL2ACmL7AABQHv6ZJkU208.png" alt="image.png" /></p>
+<p><img src="assets/Ciqc1F9ggL2ACmL7AABQHv6ZJkU208.png" alt="png" /></p>
 <h4>（1）PM： 产品经理</h4>
 <p>通常来说，需求分为业务需求和技术需求，业务需求由产品经理负责，技术需求由研发人员负责，技术需求占比较少，一般不超过 30%，所以产品经理是主要的需求负责方。</p>
 <p><strong>角色职责</strong></p>
@@ -187,7 +187,7 @@ function hide_canvas() {
 <p><strong>常见问题：协同项目易出问题</strong></p>
 <p>研发涉及多个方向的需求或项目，比较容易出现各种各样的问题。比如多方需求理解不一致、项目排期未对齐、技术方案实现有误、因依赖服务问题导致测试阻塞，等等。上述这些问题的主要原因是，各方向的产品研发测试等人员都只明确负责所在方向的交付内容，对于需求关联处和需要协同的部分，看似都负责，实际上<strong>多人同时负责等同于没有人负责。</strong></p>
 <p>这种情况比较推荐的做法是借鉴 RASCI 工具的思想。比如，有且仅有一个人为整个项目的完成负责，在各子方向需求的产品经理、研发人员、测试人员中也推选一个主 R，职责是在该职责角色内起到横向主导作用。在整个项目过程中，分职能主 R 向项目主 R 虚线汇报，如下为相应的 RASCI 矩阵：</p>
-<p><img src="assets/CgqCHl9ggNOAK7HQAABwTzbiGic297.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9ggNOAK7HQAABwTzbiGic297.png" alt="png" /></p>
 <blockquote>
 <p>RASCI 是一套用来确定责任的表格，RASCI 是指负责、批准、支持、咨询和知情。</p>
 <blockquote>
@@ -273,7 +273,7 @@ I：知情（Informed）需要了解项目相关情况的人。</p>
 </ul>
 <h3>结语</h3>
 <p>本课时我讲解了业务流程过程中主要协同方的角色、职责、常见问题与对策，总结如下：</p>
-<p><img src="assets/CgqCHl9gmzSAdxWhAADU7UHdHwc646.png" alt="Lark20200915-184359.png" /></p>
+<p><img src="assets/CgqCHl9gmzSAdxWhAADU7UHdHwc646.png" alt="png" /></p>
 <p>其次还讲解了质量文化建设相关内容，文化不是纸面上写了什么，喊了什么口号，而是大家信仰什么，比如日常如何思考、如何做事儿。质量文化的价值在于组织成员能够主动、自发地思考质量保障，做好手头的事情。另外，通过领导层重视质量、建立激励制度、质量文化触达等多种方式推行质量文化建设。</p>
 <p>下一课时，我将针对软件测试新趋势进行探讨。</p>
 <blockquote>
--- a/软件测试新趋势探讨.md.html
+++ b/软件测试新趋势探讨.md.html
@@ -157,7 +157,7 @@ function hide_canvas() {
 <p>现如今，新业务形态和新技术层出不穷，它们将从方方面面影响到软件测试的趋势。今天我们就探讨下软件测试的新趋势，以及基于这些发展趋势，软件测试人员应如何打造自身的核心竞争力，提前布局和播种，为以后的职业发展添砖加瓦。</p>
 <h3>软件测试趋势受哪些因素影响？</h3>
 <p>在众多影响软件测试的因素中，如下几个因素比较关键。</p>
-<p><img src="assets/CgqCHl9jKKyAXxf0AAIyWmteaKc220.png" alt="1.png" /></p>
+<p><img src="assets/CgqCHl9jKKyAXxf0AAIyWmteaKc220.png" alt="png" /></p>
 <p>从上表中也可以看到，前两个属于大环境带来的外部因素，后两个是测试领域的内部因素。本课时将通过以上几个方面来探讨下软件测试的变化和趋势。</p>
 <h3>1. 新型业务形态和传统行业互联网化</h3>
 <p>互联网的发展越来越快速，相信你通过自身的生活和工作经历不难发现，近几年不断兴起和蓬勃发展的行业有新零售、短视频、直播、区块链、物联网等，加之 2020 年的新冠疫情，使得在线教育、远程办公等业务出现了新的生机。基于这些业务发展，将会催生出许多软件业务和技术团队，相应的软件测试需求也大大增加。</p>
@@ -219,7 +219,7 @@ Github 地址：<a href="https://github.com/alibaba/intelligent-test-platform">h
 <p>另外，上述新趋势的测试人才的需求日益凸显，他们需要能够搭建新技术的测试基础建设，参与完善质量保障体系。</p>
 <h3>总结</h3>
 <p>本篇文章从影响软件测试趋势的四个因素入手，分析了未来软件测试的新趋势。具体包含如下内容。</p>
-<p><img src="assets/Ciqc1F9jKMGATKwNAAGUKBx0ZZo390.png" alt="2.png" /></p>
+<p><img src="assets/Ciqc1F9jKMGATKwNAAGUKBx0ZZo390.png" alt="png" /></p>
 <p>虽然有这么多的测试新趋势，但结合到每个测试从业者身上，不可能把所有的趋势和机会都抓住，能赶上一两个趋势和机会，沉淀出最核心的竞争力就很不错了，贪多，反而样样不精。</p>
 </div>
                    </div>