课程连接：
https://time.geekbang.org/column/intro/103
开篇
从知识体系上看，你需要有比开发人员更全面的计算机基础知识，还需要了解互联网的基础架构、安全攻击、软件性能、用户体验和常见缺陷等知识。
“如何把手工测试步骤用自动化脚本实现”变成了“如何构建低维护成本，可以灵活组装的自动化脚本”
基础
登录界面
但是作为测试工程师，你的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以你需要考虑的测试用例就需要更多、更全面。
但是，一个质量过硬的软件系统，除了显式功能性需求以外，其他的非功能性需求即隐式功能性需求也是极其关键的。
但是，在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。
设计好的用例
“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
整体完备性， 等价划分准备， 等价集合完备。
等价类划分方法
与之对应的还有非有效等价
边界值分析
通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
错误推测方法
单元测试
打桩测试
https://martinfowler.com/articles/mocksArentStubs.html
自动化
提高效率，节省测试成本
覆盖率
实际项目中，无论覆盖率多高，没有根据需求正确的写assert其实也是无法利用测试用例发现bug，提高代码质量，在实际的测试用例中，正向的case一般比较容易写，难得是测试error handling和模拟各种异常情况下的代码行为
缺陷报告
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。
应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前置条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、根原因分析，以及附件这几大部分、
如何做好测试
测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测什么后测什么”和“如何来测”；测试资源需要明确“谁来测”和“在哪里测”；测试进度是需要明确各类测试的开始时间，所需工作量和预计完成时间；测试风险预估是需要明确如何有效应对各种潜在的变化。
核心竞争力
为什么开发很少讨论自己的核心竞争力，我想是因为开发的学习线路图和发展路线比较清晰，而测试，其实大家都是在迷茫中摸着石头过河。
个人认为，如果是从功能测试入门进来，则很容易迷茫。因为入门很容易，而想要更深一步去走的话，像作者列出来的这几条能力，也是很难量化的，都是需要在实践中摸爬滚打，再加上不断总结经验教训，才能有一点感悟。很难说要怎样“学”会，或者怎样“教”会后来者。
要学什么
做好软件产品的测试工作，软件测试工程师需要掌握非常多的非测试专业知识，包括：网站架构、容器技术、云计算技术、DevOps 思维，以及前端开发技术的核心知识以及实践。
