第一章
1.本书的核心：作为一个google的测试人员究竟意味着什么，Google是如何解决软件在扩展性，复杂性和大并发方面的我问题。
2.测试这个行业，如何做测试，从而保证可以开发出可靠的值得信赖的软件，是最重要的。
3.不要招聘太多测试人员，开发提升自测能力，向测试开发工程师转变。
4.开发和测试必须同时开展，写一段代码立刻测试这段代码。
5.金丝雀版本-》开发版本-〉测试版本-》beta或者发布版本
6.要确定测试大中小型。
7. eg：自动化用例失败。系统会自动检查到最后一次代码的变更，这些内容极有可能是原因，系统会自动给代码变更的提交者发送一封邮件，并新开一个bug来记录这个问题。

第二章
1.思维方式的不同：对功能代码而言，思维模式是创建，重点在考虑用户，使用场景和数据流程上。而对于测试代码来说，主要思路是去破坏，怎样写测试代码以扰乱分离用户及其数据。
2.测试开发人员的作用：通过使用测试工具与框架帮助功能开发人员解决特定的单元测试的问题。
3.SET测试开发人员，SWE功能开发人员，TE用户开发人员 ，我们目前还处于TE的边缘，那么怎样才能一步步像SET靠近呢？
4.google在平台方面有特定的目标，就是保持简单统一。开发工作机和生产环境的机器都保持统一的LINUX发行版本，一套集中控制的通用核心库，一套统一的通用代码，构建和测试基础设施，每个核心语言只有一个编译器，与语言无关的通用打包规范，文化上对这些共享资源的维护表示尊重且有激励。
5.接口需要在项目的早期确定下来。
6.使测试人员能尽早的介入到开发流程中去，通过参与设计和代码开发的方式。
7.只有在软件产品变得重要的时候质量才显得重要。
8.第一件事：设计文档，动态文档，及时更新，类似APIcloud，所有人看到的文档一样。链接的方式
9.尽早的提供一个可实施的自动化测试计划：先把容易出错的接口隔离，并针对他们创建mock和fake，接下来构建一个轻量级的自动化框架，控制mock系统的创建和执行。
10.提交队列。
11.自动化测试：不仅仅是程序编写，还要考虑如何编译测试程序，执行，分析，存储和报告所有测试运行结果。
12.测试程序的构建文件包括测试名称，源码文件，依赖库及数据，还要指明其规模大小。
13.小型测试：验证一个代码单元的功能，单元测试。 中型测试：验证两个或多个模块应用之间的交互。大型测试：验证整个系统作为一个整体如何工作。
标记大中小的原因：调度器已经知道每个任务需要运行的时间，这样可以优化任务队列，达到合理利用的目的。
小型测试带来优秀的代码质量，良好的异常处理，优雅的错误报告。大中型测试会带来整体产品质量和数据验证。
14.重点学会思考问题的解决方案，而不是解决方案本身的实现上有多么高雅。T63

分享会：
自己写单元测试
测试用例与模块的关系
依赖图
sql注入测试

第三章
1.google的TE综合了开发者的技术能力和以用户为中心检查软件质量的能力
2.TE的工作都与分享有关：TE以对某种特定的产品最合适的方式发现软件中风险最大的地方并尝试减少或消除它。set 代码审查 测试工具
3.TE在产品定型的时候再加入
目前的情况就是，我们需要在产品一开始就开始了解产品的具体功能和细节，这样后续的功能测试工作才会比较顺利
所以我们不能照着别人学，而是了解别人的工作方式，从中找到一些可借鉴的点
4.TE加入产品的时候需要考虑的问题,不完全列表的风险概要，不需要自己去解决这些问题，但是要保证这些问题被解决掉。必须快速评估项目，代码，设计和用户的当前状态。
1.当前软件的薄弱点在哪里
2.有没有安全，隐私，性能，可靠性，可用性，兼容性，全球化，和其他方面的问题。
3.主要用户场景和功能是否正常。
4.当发生问题时，是否容易诊断问题所在。
5.TE是整个团队中全职的负责从整体角度发现产品或服务弱点的唯一角色。
6.做一个能直接指导测试的测试计划，把测试用例该怎么编写 执行描述的足够详细。
7.组件执行某种功能来满足产品的一个特质，这个活动的结果是向用户提供某种能力（可测试性）
8.什么时候加入一个产品我觉得是一个很难界定的点，比如我们现在的项目，我们现在的工作流动性很大。每次加入一个新公司，需要从头开始看，这个时候我就觉得站在整体的角度来把握确实是非常重要的，同时为退出团队做好准备，就像开发写注释一样，把文档做好注释。
9.根据模块分类测试用例。
10.做测试之前先整体考虑，除了边界值等分析方法外的考虑，例如界面，安全性，可复制粘贴？，能够提出反驳和质疑。
11.如何参与一个新项目：
首先站在用户的角度了解产品，有可能的话，作为一个用户，以自己的账户和数据去使用产品，因为一旦有自己真真实的数据在里面，你对一个产品的期待会彻底改变。
从头到尾理解一个产品，不管是整体的设计文档还是功能设计文档，只要是文档就了解。
消化文档之后，关注项目状态，特别是质量状态，去了解bug数量，问题分组形式，已经报告的bug类型，最长时间未处理的bug，最近一些bug的类型。
对每一个大一点的类，寻找关联的单元测试，并且运行，看是否有效，完整，有没有集成端到端，历史通过率，覆盖场景，边界情况，代码库的包变化情况，长时间未变更的，开发对测试文档的满意度。
评审所有自动化测试，检查代码，理解测试步骤。
了解团队的沟通方式和对测试人员的期望，帮助开发团队测试没有测试过的内容。
把应用分解为合理的功能模块，细致到可以罗列子模块的功能，排列测试优先级，风险大小。
检查bug库，按照模块对bug分组。
按照优先级顺序遍历所有模块，创建用户故事。
测试退出的标准：你有足够的信心，剩下的bug都属于使用率极低，出问题后对用户影响也较低的模块

第四章：
1.测试工程经理：负责所有的支持团队（开发，产品经理，产品发布，文档）之间的联络。需要同时具备TE和SET的功能，以及管理技能(技术 领导 协调)。
2.相关项目中最强的产品专家
假如是google浏览器测试工程经理：如何安装扩展程序，更换浏览器外观，设置同步关系，更改代理服务器设置，查看dom，查找cookie的存放位置，如何以及何时版本更新，从用户界面到后台数据中心实现。