Tips：此文为阅读Bob大叔的《代码整洁之道》一书的摘抄小记，谨慎“食用”
一、验收测试
- 重视沟通，专业开发人员既要做好开发也要做好沟通。“输入糟糕，输出也会糟糕”，职业程序员需要重视与团队及业务部门的沟通，确保这种沟通准确、流畅
- 过早精细化，做业务的人和写程序的人都容易陷入一个陷阱，即过早精细化，业务还没启动项目，就要精确知道最后能得到什么；开发还没评估整个项目，就希望精确知道要交付什么，双方都贪求不现实的精确性
- 不确定原则，东西画在纸上和真正做出来是不一样的，在我们阶段演示成果后，业务方关于要什么会冒出更好的想法，他们查看演示成果的时候，获得了比之前更多的信息，这些信息会影响他们对整个系统的看法，所以要接受不确定原则
- 预估焦虑，即使拥有全面准确的信息，评估也通常会存在巨大变数，因为不确定原则的存在，不可能经过反复推敲实现早期的精确性，需求一定会变化，所以追求那种精确性是徒劳的
- 专业开发人员和业务方必须确认，需求中没有任何不确定因素，但这很难，目前只有一种办法可以解决，即：验收测试
- 验收测试，在本书中，验收测试定义为：业务方和开发方合作编写的测试，其目的在于确定需求已完成。验收测试的目的是沟通、澄清、精确化
- 验收测试应该自动化，在开发周期中，确实有时候需要手动测试，但验收测试不应该手动进行，因为要考虑成本，自动化测试成本低，实现自动化测试是程序员的责任
- 身为开发人员，与编写测试的人协商并改进测试是你的职责，绝不能被动接受测试，更不能对自己说：“噢，测试是这么要求的，我就这么办”
二、测试策略
- QA的任务之一便是和业务人员一起创建自动化验收测试，业务人员编写针对正确功能的测试，QA编写针对极端情况、边界状态和各类异常场景的测试
- 自动化测试金字塔
- 单元测试，由程序员使用与系统开发相同的语言编写，供程序员自己使用，目的是在最底层次上来定义系统，这些单元测试将作为持续集成的一部分来运行，用以确保程序员的代码意图没有遭到破坏
- 组件测试，是验收测试中的一种，通常由QA和业务人员正对系统的各个组件而编写，系统的组件封装了业务规则，对组件进行测试便是对业务规则的验收测试
- 集成测试，针对组件很多的较大型系统才有意义，将组件装配成组，测试他们彼此之间是否能正常通信，集成测试是编排性测试，不会测试业务规则，而主要测试组件装配在一起时是否协调
- 系统测试，针对整个集成完毕的系统，来运行的自动化测试。是最终的集成测试，在这个层次，应该要包含吞吐率测试和性能测试
- 人工探索式测试，这是需要人工介入、敲击键盘、钉牢屏幕的测试，意图是要在验证预期行为的时候，探索系统预期之外的行为
