1 前言
最近几个月都在赶个非常重要项目，基本每天或每几天都要提交CR，而因为每个CR都要附上对应的 test case, 所以这段时间写了非常多的 test case, 又在坐我旁边的 Principle Engineer 巨佬身上学到了很多有用的测试技巧，所以就想写个系列文章总结和分享我所学到的新技能。
2 Why
有个很著名的思考方式，叫黄金圈法则, 简而言之，就是对于某件事找到Why，How，What：
我为什么要做，我怎么做，做这件事的结果是什么？
所以我就先来聊聊为什么要写测试case，或者说为什么是软件开发写测试case，后续的文章再来聊聊How.
3 软件质量文化
关于软件工程师来写测试 case, 最有名的应该是Google，他们就是推崇由软件工程师来写测试case，而他们的测试文化已经成为谷歌的工程文化的重要组成部分。
Google的工程师也前后写了两本书来布道他们的测试文化/工程文化, 也非常推荐阅读:
毕业以后待过几家大公司，这几家公司的文化各有不同，但就我所供职过的部门而言，对于测试，他们都有着相同的观点： 不应该也不会有所谓的测试工程师，每个软件开发都应该为自己的代码编写测试，并保证质量.
其中微信支付基本就是在践行《Google软件测试之道》的理念，推广微信支付自己的测试文化，强调测试左称，面向测试设计等等。
Amazon 内部的测试文化也是和Google 相当类似，只是远没有Google出名.
不知道是因为Amazon的测试文化是受Google所影响, 讲究先来后到, 主客分明; 还是Amazon的开源项目或者技术影响力没有Google高，导致Amazon 工程文化没有Google出名，又或是因为Amazon工程师在血汗工厂打工，忙着赶需求，没有时间写书布道, 所以不为人所知呢.
这种文化背后，是对软件开发与质量测试密不可分的认知：
3.1 职责
首先，每个工程师，都应该为他们的代码编写测试用例， 这个工作本身就是研发流程的一部分，而质量保障又是软件开发生命周期非常关键的一步， 如果写出来的功能充满问题，这样的功能再多，开发得再快又有什么意义呢。
3.2 CI/CD
所以我现在所在S3部门而言，要求每个CR都要有对应的测试用例来保证CR代码的质量，因为代码合并到主干之后， 就会被 Continuous Deployment 自动部署上线，所以要求每个提到的CR都是 production-ready的
软件工程师自己编写测试配合CI/CD就可以更早更快地发现问题，并且由软件工程师快速完成修复, 降低反馈周期, 提高开发效率.
3.3 成本
其次，沟通是有成本的，如果存在测试工程师，软件工程师就要给测试工程师交待清楚业务功能是什么， 这次的改动要测什么功能，预期结果是什么，沟通成本就相当高，你可能还需要通过文档或者工单将测试内容呈现给测试工程师。
如果软件工程师都能把这些东西解释清楚，那为什么不自己把测试用例写完呢, 何必劳心劳力去写工单呢？
3.4 面向测试设计
虽然Test-Driven Development(TDD)的开发理念不一定所有人都认同, 但是让软件开发工程师来编写测试用例，能让软件工程师有测试先行，设计测试友好接口的认知, 反过来又会对其接口设计能力有新的要求.
3.5 敏捷开发
总结下来，让软件工程师对质量负责，自己编写测试用例, 是确保团队能敏捷开发(move fast), 又能确保软件质量的关键手段
4 总结
每个人对于测试技巧的认知并不一样，像单元测试，集成测试这类测试， 在我个人认知里，是属于每个软件工程师都需要掌握的基础技能，就不在「进阶」之列。
而像混沌测试(Chaos Monkey) 这样的测试, 自然属于进阶测试的一部分，但是因为其与公司的基础架构强耦合;
在微信支付的时候，同组的一位同事就专项负责先驱搞整个微信支付的混沌测试， 前后搞了1年半还在开发，都是和运维团队以及基础组件团队密切合作来开发混沌测试功能的， 无法用示例代码来直观呈现，所以也不会列入这个系列。
这系列文章更专注于日常开发中，每个软件工程师都有机会用上的测试技巧.
系列文章: