增加系列文章的相互引用.

content/zh/post/2024/测试技能进阶一_软件质量认知.md

@@ -1,7 +1,7 @@
 +++
 title = "测试技能进阶(一): 软件质量认知"
 date = 2024-10-12T10:30:00-07:00
-lastmod = 2024-10-12T11:19:56-07:00
+lastmod = 2024-10-14T15:11:52-07:00
 tags = ["testing"]
 categories = ["testing"]
 draft = false
@@ -10,68 +10,90 @@ toc = true
 
 ## <span class="section-num">1</span> 前言 {#前言}
 
-最近几个月都在赶个非常重要项目，基本每天或每几天都要提交CR，而因为每个CR都要附上对应的 test case, 所以这段时间写了非常多的 test case, 又在坐我旁边的 Principle Engineer 巨佬身上学到了很多有用的测试技巧，所以就想写个系列文章总结和分享我所学到的新技能。 <br/>
+最近几个月都在赶个非常重要项目，基本每天或每几天都要提交CR，而因为每个CR都要附上对应的 test case, 所以这段时间写了非常多的 test case, 又在坐我旁边的 Principle Engineer 巨佬身上学到了很多有用的测试技巧，所以就想写个系列文章总结和分享我所学到的新技能。
 
 
 ## <span class="section-num">2</span> Why {#why}
 
-有个很著名的思考方式，叫黄金圈法则, 简而言之，就是对于某件事找到Why，How，What： <br/>
+有个很著名的思考方式，叫黄金圈法则, 简而言之，就是对于某件事找到Why，How，What：
 
-我为什么要做，我怎么做，做这件事的结果是什么？ <br/>
+我为什么要做，我怎么做，做这件事的结果是什么？
 
-所以我就先来聊聊为什么要写测试case，或者说为什么是软件开发写测试case，后续的文章再来聊聊How. <br/>
+所以我就先来聊聊为什么要写测试case，或者说为什么是软件开发写测试case，后续的文章再来聊聊How.
 
 
 ## <span class="section-num">3</span> 软件质量文化 {#软件质量文化}
 
-关于软件工程师来写测试 case, 最有名的应该是Google，他们就是推崇由软件工程师来写测试case，而他们的测试文化已经成为谷歌的工程文化的重要组成部分。 <br/>
+关于软件工程师来写测试 case, 最有名的应该是Google，他们就是推崇由软件工程师来写测试case，而他们的测试文化已经成为谷歌的工程文化的重要组成部分。
 
-Google的工程师也前后写了两本书来布道他们的测试文化/工程文化, 也非常推荐阅读: <br/>
+Google的工程师也前后写了两本书来布道他们的测试文化/工程文化, 也非常推荐阅读:
 
--   [Google软件测试之道](https://book.douban.com/subject/25742200/) <br/>
--   [Google软件工程](https://book.douban.com/subject/35838155/) <br/>
+-   [Google软件测试之道](https://book.douban.com/subject/25742200/)&nbsp;[^fn:1]
+-   [Google软件工程](https://book.douban.com/subject/35838155/)&nbsp;[^fn:2]
 
-毕业以后待过几家大公司，这几家公司的文化各有不同，但就我所供职过的部门而言，对于测试，他们都有着相同的观点： <br/>
-不应该也不会有所谓的测试工程师，每个软件开发都应该为自己的代码编写测试，并保证质量. <br/>
+毕业以后待过几家大公司，这几家公司的文化各有不同，但就我所供职过的部门而言，对于测试，他们都有着相同的观点：
+不应该也不会有所谓的测试工程师，每个软件开发都应该为自己的代码编写测试，并保证质量.
 
-其中微信支付基本就是在践行《Google软件测试之道》的理念，推广微信支付自己的测试文化，强调测试左称，面向测试设计等等。 <br/>
+其中微信支付基本就是在践行《Google软件测试之道》的理念，推广微信支付自己的测试文化，强调测试左称，面向测试设计等等。
 
-Amazon 内部的测试文化也是和Google 相当类似，只是远没有Google出名. <br/>
+Amazon 内部的测试文化也是和Google 相当类似，只是远没有Google出名.
 
-不知道是因为Amazon的测试文化是受Google所影响, 讲究先来后到, 主客分明; 还是Amazon的开源项目或者技术影响力没有Google高，导致Amazon 工程文化没有Google出名，又或是因为Amazon工程师在血汗工厂打工，忙着赶需求，没有时间写书布道, 所以不为人所知呢. <br/>
+不知道是因为Amazon的测试文化是受Google所影响, 讲究先来后到, 主客分明; 还是Amazon的开源项目或者技术影响力没有Google高，导致Amazon 工程文化没有Google出名，又或是因为Amazon工程师在血汗工厂打工，忙着赶需求，没有时间写书布道, 所以不为人所知呢.
 
-这种文化背后，是对软件开发与质量测试密不可分的认知： <br/>
+这种文化背后，是对软件开发与质量测试密不可分的认知：
 
 
 ### <span class="section-num">3.1</span> 职责 {#职责}
 
-首先，每个工程师，都应该为他们的代码编写测试用例， <br/>
-这个工作本身就是研发流程的一部分，而质量保障又是软件开发生命周期非常关键的一步， <br/>
-如果写出来的功能充满问题，这样的功能再多，开发得再快又有什么意义呢。 <br/>
+首先，每个工程师，都应该为他们的代码编写测试用例，
+这个工作本身就是研发流程的一部分，而质量保障又是软件开发生命周期非常关键的一步，
+如果写出来的功能充满问题，这样的功能再多，开发得再快又有什么意义呢。
 
 
 ### <span class="section-num">3.2</span> CI/CD {#ci-cd}
 
-所以我现在所在S3部门而言，要求每个CR都要有对应的测试用例来保证CR代码的质量，因为代码合并到主干之后， <br/>
-就会被 Continuous Deployment 自动部署上线，所以要求每个提到的CR都是 production-ready的 <br/>
+所以我现在所在S3部门而言，要求每个CR都要有对应的测试用例来保证CR代码的质量，因为代码合并到主干之后，
+就会被 Continuous Deployment 自动部署上线，所以要求每个提到的CR都是 production-ready的
 
-软件工程师自己编写测试配合CI/CD就可以更早更快地发现问题，并且由软件工程师快速完成修复, 降低反馈周期, 提高开发效率. <br/>
+软件工程师自己编写测试配合CI/CD就可以更早更快地发现问题，并且由软件工程师快速完成修复, 降低反馈周期, 提高开发效率.
 
 
 ### <span class="section-num">3.3</span> 成本 {#成本}
 
-其次，沟通是有成本的，如果存在测试工程师，软件工程师就要给测试工程师交待清楚业务功能是什么， <br/>
-这次的改动要测什么功能，预期结果是什么，沟通成本就相当高，你可能还需要通过文档或者工单将测试内容呈现给测试工程师。 <br/>
+其次，沟通是有成本的，如果存在测试工程师，软件工程师就要给测试工程师交待清楚业务功能是什么，
+这次的改动要测什么功能，预期结果是什么，沟通成本就相当高，你可能还需要通过文档或者工单将测试内容呈现给测试工程师。
 
-如果软件工程师都能把这些东西解释清楚，那为什么不自己把测试用例写完呢, 何必劳心劳力去写工单呢？ <br/>
+如果软件工程师都能把这些东西解释清楚，那为什么不自己把测试用例写完呢, 何必劳心劳力去写工单呢？
 
 
 ### <span class="section-num">3.4</span> 面向测试设计 {#面向测试设计}
 
-虽然Test-Driven Development(TDD)的开发理念不一定所有人都认同, 但是让软件开发工程师来编写测试用例，能让软件工程师有测试先行，设计测试友好接口的认知, 反过来又会对其接口设计能力有新的要求. <br/>
+虽然Test-Driven Development(TDD)的开发理念不一定所有人都认同, 但是让软件开发工程师来编写测试用例，能让软件工程师有测试先行，设计测试友好接口的认知, 反过来又会对其接口设计能力有新的要求.
 
 
 ### <span class="section-num">3.5</span> 敏捷开发 {#敏捷开发}
 
-总结下来，让软件工程师对质量负责，自己编写测试用例, 是确保团队能敏捷开发(move fast), 又能确保软件质量的关键手段 <br/>
+总结下来，让软件工程师对质量负责，自己编写测试用例, 是确保团队能敏捷开发(move fast), 又能确保软件质量的关键手段
 
+
+## <span class="section-num">4</span> 总结 {#总结}
+
+每个人对于测试技巧的认知并不一样，像单元测试，集成测试这类测试，
+在我个人认知里，是属于每个软件工程师都需要掌握的基础技能，就不在「进阶」之列。
+
+而像混沌测试(Chaos Monkey) 这样的测试, 自然属于进阶测试的一部分，但是因为其与公司的基础架构强耦合;
+
+在微信支付的时候，同组的一位同事就专项负责先驱搞整个微信支付的混沌测试，
+前后搞了1年半还在开发，都是和运维团队以及基础组件团队密切合作来开发混沌测试功能的，
+无法用示例代码来直观呈现，所以也不会列入这个系列。
+
+这系列文章更专注于日常开发中，每个软件工程师都有机会用上的测试技巧.
+
+系列文章:
+
+-   [测试技能进阶(一): 软件质量认知](https://ramsayleung.github.io/zh/post/2024/%E6%B5%8B%E8%AF%95%E6%8A%80%E8%83%BD%E8%BF%9B%E9%98%B6%E4%B8%80_%E8%BD%AF%E4%BB%B6%E8%B4%A8%E9%87%8F%E8%AE%A4%E7%9F%A5/)
+-   [测试技能进阶(二): Parameterized Tests](https://ramsayleung.github.io/zh/post/2024/%E6%B5%8B%E8%AF%95%E6%8A%80%E8%83%BD%E8%BF%9B%E9%98%B6%E4%BA%8C_parameterized_tests/)
+-   [测试技能进阶(三): Property Based Testing](https://ramsayleung.github.io/zh/post/2024/%E6%B5%8B%E8%AF%95%E6%8A%80%E8%83%BD%E8%BF%9B%E9%98%B6%E4%B8%89_property_based_testing/)
+
+[^fn:1]: <https://book.douban.com/subject/25742200/>
+[^fn:2]: <https://book.douban.com/subject/35838155/>