以前一直从开发的角度来看待测试，看完这本书以后感觉错了，难怪之前公司的测试一直搭建不起来
1.开发人员，开发测试人员，测试人员
* 开发人员负责开发
* 开发测试人员近距离接触代码，负责编写测试用例，模拟运行环境，使不同模块的测试可以进行自动化，提供给开发人员测试框架，方便编写中小型测试
* 测试人员主要是面对用户，也可以跟开发测试人员进行交流
在我们实际开发过程中，很难去区分开发人员，开发测试人员，因为不好招人，所以实际上开发人员和开发测试人员是不区分的，这个就是测试驱动开发，开发人员也要承担一部分测试的责任
2. 把非手动的测试记录下来，并且思考如何进行自动测试
以前开发的时候一直觉得麻烦，所以一旦涉及到复杂逻辑的时候，就开发交给测试人员，这个思路是错误的，实际上越复杂的逻辑越需要通过自动化测试，这样后续的修改才能更好得进行，而且能够编写手动测试的代码可维护性和模块化会比不好写测试的高很多，这个也是测试驱动开发的逻辑
3. 区分大型测试，中型测试，小型测试
* 小型测试就是单元测试，即可以单独测试的模块，关注点在模块是否能完成我们的需求测试，小型测试的时候，外部服务必须通过fake或者mock来实现
* 中型测试是指2个模块交互的代码，关注点在模块的交互上
* 大型测试是指多个某块交互的代码，关注所有模块的集成，倾向于结果驱动，验证软件是否满足用户最终需求
在我们工作过程里面，因为业务的关系，很难做到这么完美，毕竟人手和时间是需要考虑的问题，在开发过程里面，大型测试，中型测试时比较容易进行的，但是大型测试比较考虑编写代码的模块独立，在编写代码的时候需要注意
4. 测试人员需要独立，有地位，不做杂活
可惜在国内一直很不重视测试这一块
5. 软件开始只发布核心功能，然后根据用户进行反馈
这点说得有道理，这个也是我们过去软件开发一个常见的问题，就是一开始就想把软件做全，做好，特别在人手不够的时候还很喜欢这样做，所以在软件开发的时候应该把优先级给定义好
6. 工程师提交的代码即使即将发布的代码，测试时由整个团队来负责的
7. 使用持续构建工具，当有失败的时候通知开发者
8. google有一个测试百科全书，里面对于测试所需要的东西多有提到过
9.测试认证级别
等级1:
* 使用测试覆盖率工具
* 使用持续集成
* 测试分为小型，中型，大型
* 明确标记哪些测试时非确定性测试(结果不确定的测试)
* 创建冒烟测试集合
等级2：
* 如果有测试运行结果失败，就不会发布
* 每次提交代码前都需要通过冒烟测试
* 各类型的测试整体覆盖率要大于50%
* 小型测试的增量覆盖率要大于10%
* 每一个功能特性至少有一个与之对应的集成测试
等级3：
* 所有重要代码都需要经过测试
* 小型测试的增量覆盖率要大于50%
* 新增的重要功能都要经过集成测试的验证
等级4：
* 在提交任何代码前都进行冒烟测试
* 冒烟测试必须在30分钟内运行完成
* 没有不确定性测试
* 总体测试覆盖率不效率40%
* 小型测试的代码覆盖率不小于25%
* 所有重要的功能都应该被集成测试验证到
等级5：
* 对每一个重要的缺陷修复都要增加一个测试用例与之对应
* 积极使用可用的代码分析工具
* 总体测试覆盖率不低于60%
* 小型测试的代码覆盖率应该不小于40%
测试认证可用让大家知道哪个团队对测试工作做得比较好，有利于大家学习
10. 测试工程师是连接业务和用户的人
11. 测试计划的特性
* 及时地更新
* 描述了软件的目标和卖点
* 描述了软件的结构，各个组件和功能特性的名称
* 描述了软件的功能和操作简介
* 不必花过多的时间去撰写，必须随时可以修改
* 应该描述必测点
* 在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足
12. google test analytics
* 避免散漫的文字
* 不必推销
* 不要把不重要的，无法执行的东西放进测试计划
* 渐进式的描述
* 指导计划者的思路
* 最终结果应该是测试用例
13. ACC指导
1.A代表特质Attribute
* 开始测试计划或做ACC分析的时候，必须确定该产品对用户，对业务的意义，比如chrome的要求是快速，安全
* 特质必须在几小时内描述完整
2.C代表组件(component)
* 组件是系统的名字，在特质被识别确定以后，组件是构成系统的模块，比如在线商店的购物车和结账系统，word处理器的格式化和打印功能等等，这些正式测试人员需要测试的对象
3.C代表能力(capability)
* 比如从一个购物车里面进行增加和删除商品
实际上这部分是一直细分下去的，比如先确定特质，google里面有社交功能，再确定社交功能的子功能，比如个人资料，再确定个人资料的子功能，比如联系人，设置，头像等等，通过逐级的划分去逐渐增加测试用例
ACC是很有意思的区分，实际上在做软件的时候应该按照这个来编写测试计划
14. 将测试计划的编写限定在10分钟之内
这一点在项目赶的时候很有用，只针对游泳的编写代码
15. 软件尽早交付，经常交付，尽快失败
16. 渐进式迭代测试，不然chrome，早先测试结果是页面级别的，后来提升到元素级别
在我们实际的开发项目里面，人手不足导致单元测试用例落后的时候，这个对于软件集成很有帮助
17. 只有熟悉了团队的全貌，才能更好的展开工作，而不是只熟悉开发或者测试