Add new post: 测试技能进阶(一): 软件质量认知

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

@@ -0,0 +1,77 @@
++++
+title = "测试技能进阶(一): 软件质量认知"
+date = 2024-10-12T10:30:00-07:00
+lastmod = 2024-10-12T11:19:56-07:00
+tags = ["testing"]
+categories = ["testing"]
+draft = false
+toc = true
++++
+
+## <span class="section-num">1</span> 前言 {#前言}
+
+最近几个月都在赶个非常重要项目，基本每天或每几天都要提交CR，而因为每个CR都要附上对应的 test case, 所以这段时间写了非常多的 test case, 又在坐我旁边的 Principle Engineer 巨佬身上学到了很多有用的测试技巧，所以就想写个系列文章总结和分享我所学到的新技能。 <br/>
+
+
+## <span class="section-num">2</span> Why {#why}
+
+有个很著名的思考方式，叫黄金圈法则, 简而言之，就是对于某件事找到Why，How，What： <br/>
+
+我为什么要做，我怎么做，做这件事的结果是什么？ <br/>
+
+所以我就先来聊聊为什么要写测试case，或者说为什么是软件开发写测试case，后续的文章再来聊聊How. <br/>
+
+
+## <span class="section-num">3</span> 软件质量文化 {#软件质量文化}
+
+关于软件工程师来写测试 case, 最有名的应该是Google，他们就是推崇由软件工程师来写测试case，而他们的测试文化已经成为谷歌的工程文化的重要组成部分。 <br/>
+
+Google的工程师也前后写了两本书来布道他们的测试文化/工程文化, 也非常推荐阅读: <br/>
+
+-   [Google软件测试之道](https://book.douban.com/subject/25742200/) <br/>
+-   [Google软件工程](https://book.douban.com/subject/35838155/) <br/>
+
+毕业以后待过几家大公司，这几家公司的文化各有不同，但就我所供职过的部门而言，对于测试，他们都有着相同的观点： <br/>
+不应该也不会有所谓的测试工程师，每个软件开发都应该为自己的代码编写测试，并保证质量. <br/>
+
+其中微信支付基本就是在践行《Google软件测试之道》的理念，推广微信支付自己的测试文化，强调测试左称，面向测试设计等等。 <br/>
+
+Amazon 内部的测试文化也是和Google 相当类似，只是远没有Google出名. <br/>
+
+不知道是因为Amazon的测试文化是受Google所影响, 讲究先来后到, 主客分明; 还是Amazon的开源项目或者技术影响力没有Google高，导致Amazon 工程文化没有Google出名，又或是因为Amazon工程师在血汗工厂打工，忙着赶需求，没有时间写书布道, 所以不为人所知呢. <br/>
+
+这种文化背后，是对软件开发与质量测试密不可分的认知： <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/>
+
+软件工程师自己编写测试配合CI/CD就可以更早更快地发现问题，并且由软件工程师快速完成修复, 降低反馈周期, 提高开发效率. <br/>
+
+
+### <span class="section-num">3.3</span> 成本 {#成本}
+
+其次，沟通是有成本的，如果存在测试工程师，软件工程师就要给测试工程师交待清楚业务功能是什么， <br/>
+这次的改动要测什么功能，预期结果是什么，沟通成本就相当高，你可能还需要通过文档或者工单将测试内容呈现给测试工程师。 <br/>
+
+如果软件工程师都能把这些东西解释清楚，那为什么不自己把测试用例写完呢, 何必劳心劳力去写工单呢？ <br/>
+
+
+### <span class="section-num">3.4</span> 面向测试设计 {#面向测试设计}
+
+虽然Test-Driven Development(TDD)的开发理念不一定所有人都认同, 但是让软件开发工程师来编写测试用例，能让软件工程师有测试先行，设计测试友好接口的认知, 反过来又会对其接口设计能力有新的要求. <br/>
+
+
+### <span class="section-num">3.5</span> 敏捷开发 {#敏捷开发}
+
+总结下来，让软件工程师对质量负责，自己编写测试用例, 是确保团队能敏捷开发(move fast), 又能确保软件质量的关键手段 <br/>
+