Google软件测试之道（异步图书）James Whittaker; Jason Arbon; Jeff Carollo
序标注(黄色) - 位置 361从根本上说，如果测试人员想加入这个俱乐部，就必须具备良好的计算机科学基础和编程能力。变革标注(黄色) - 位置 367招聘具备开发能力的测试人员很难，找到懂测试的开发人员就更难，标注(黄色) - 位置 368但是维持现状更要命，我只能往前走。标注(黄色) - 位置 388我们寻找的人要兼具开发人员的技能和测试人员的思维，他们必须会编程，能实现工具、平台和测试自动化。第1章 Google软件测试介绍标注(黄色) - 1.1 质量不等于测试 > 位置 573Google能用如此少的专职测试人员的原因，就是开发对质量的负责。标注(黄色) - 1.1 质量不等于测试 > 位置 574如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个 bug的测试人员。标注(黄色) - 1.2.1 软件开发工程师（SWE） > 位置 593软件开发工程师（标注(黄色) - 1.2.2 软件测试开发工程师（SET） > 位置 600软件测试开发工程师（标注(黄色) - 1.2.3 测试工程师（TE） > 位置 612TE把用户放在第一位来思考。 TE组织整体质量实践，分析解释测试运行结果，第2章 软件测试开发工程师书签 - 位置 784标注(黄色) - 位置 787Google的 SWE是功能开发人员； Google的 SET是测试开发人员； Google的 TE是用户开发人员。标注(黄色) - 2.1.1 开发和测试流程 > 位置 864测试驱动开发”标注(黄色) - 2.1.3 项目的早期阶段 > 位置 908一个产品如果在概念上还没有完全确定成型时就去关心质量，这就是优先级混乱的表现。标注(黄色) - 2.1.14 测试运行要求 > 位置 1398每个测试和其他测试之间都是独立的，使它们就能够以任意顺序来执行。标注(黄色) - 2.1.14 测试运行要求 > 位置 1399测试不做任何数据持久化方面的工作。标注(黄色) - 2.1.14 测试运行要求 > 位置 1400在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态是一样的。标注(黄色) - 2.1.14 测试运行要求 > 位置 1404总之，“任意顺序”意味着可以并发执行用例。标注(黄色) - 2.3 SET的招聘 > 位置 1650在一些棘手的编码问题或功能的正确性上浪费时间，不如考核他们是如何看待编码和质量的。标注(黄色) - 2.3 SET的招聘 > 位置 1727测试不应是被要求了才去做的事情。标注(黄色) - 2.3 SET的招聘 > 位置 1728程序的稳定性和韧性比功能正确要重要的多。标注(黄色) - 2.4 与工具开发工程师Ted Mao的访谈 > 位置 1796要允许他们使用你无法预料的方式来使用你的工具。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1845我使用了一个被称为 DDD（译注： defect-driven development）的流程，缺陷驱动开发。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1859Chrome在使用 PyAuto，第3章 测试工程师标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1879我们说 TE是一种“用户开发者（ user-developer）”，这不是一个容易理解的概念。标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1880对于编码的敬意是公司文化中相当重要的一点。标注(黄色) - 3.2 测试工程师的工作 > 位置 1903在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定， TE通常没有太多的工作可做。标注(黄色) - 3.2 测试工程师的工作 > 位置 1904给一个项目配备多少测试人员，取决于项目风险和投资回报率。标注(黄色) - 3.2 测试工程师的工作 > 位置 1906我们需要在正确的时间，投入正确数量的 TE，并带来足够的价值。标注(黄色) - 3.2 测试工程师的工作 > 位置 1908当前软件的薄弱点在哪里？标注(黄色) - 3.2 测试工程师的工作 > 位置 1909有没有安全、隐私、性能、可靠性、可用性、标注(黄色) - 3.2 测试工程师的工作 > 位置 1910主要用户场景是否功能正常？标注(黄色) - 3.2 测试工程师的工作 > 位置 1911当发生问题的时候，是否容易诊断问题所在？标注(黄色) - 3.2 测试工程师的工作 > 位置 1914TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、标注(黄色) - 3.2 测试工程师的工作 > 位置 1921TE擅长发现需求中的模糊之处，标注(黄色) - 3.2 测试工程师的工作 > 位置 1924TE通常是团队里最出名的人，因为他们需要与各种角色标注(黄色) - 3.2 测试工程师的工作 > 位置 1938下面是我们关于 TE职责的一般性描述。测试计划和风险分析。评审需求、设计、代码和测试。探索式测试。用户场景。编写测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 1949如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的；如果软件很糟糕，人们可能就会质疑测试工作。笔记 - 3.2.1 测试计划 > 位置 1950测试背锅标注(黄色) - 3.2.1 测试计划 > 位置 1990读者可以用“ Google Test Analytics”关键词搜索到这个工具。标注(黄色) - 3.2.1 测试计划 > 位置 1991避免散漫的文字，推荐使用简明的列表。标注(黄色) - 3.2.1 测试计划 > 位置 1993不必推销。标注(黄色) - 3.2.1 测试计划 > 位置 1995简洁。标注(黄色) - 3.2.1 测试计划 > 位置 1996不要把不重要的、无法执行的东西放进测试标注(黄色) - 3.2.1 测试计划 > 位置 1998渐进式的描述（ Make it flow）。标注(黄色) - 3.2.1 测试计划 > 位置 2001最终结果应该是测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 20091. A代表特质（ Attribute）标注(黄色) - 3.2.1 测试计划 > 位置 2010在开始测试计划或做 ACC分析的时候，必须先确定该产品对用户、对业务的意义。我们为什么要开发这个东西呢？它能带来什么核心价值？它又靠什么来吸引用户？记住，标注(黄色) - 3.2.1 测试计划 > 位置 20462. C代表组件（ component）组件是系统的名词，在特质被识别之后确定。标注(黄色) - 3.2.1 测试计划 > 位置 2049组件是构成待建系统的模块，标注(黄色) - 3.2.1 测试计划 > 位置 20633. C代表能力（ capability）能力是系统的动词，代表着系统在用户指令之下完成的动作。标注(黄色) - 3.2.1 测试计划 > 位置 2095能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2098能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2100一个能力可以描述任意数量的用例。标注(黄色) - 3.2.1 测试计划 > 位置 2130用一系列能力来描述用户故事，标注(黄色) - 3.2.1 测试计划 > 位置 2142确定 Google +的特质、组件和能力。标注(黄色) - 3.2.2 风险 > 位置 2193风险无处不在——标注(黄色) - 3.2.2 风险 > 位置 2202确定风险的过程称为风险分析。标注(黄色) - 3.2.2 风险 > 位置 22021.风险分析标注(黄色) - 3.2.2 风险 > 位置 2204这些事件发生的可能性有多大？一旦发生，对公司产生多大影响？一旦发生，对客户产生多大影响？产品具备什么缓解措施？标注(黄色) - 3.2.2 风险 > 位置 2206这些缓解措施有多大可能会失败？处理这些失败的成本有哪些？恢复过程有多困难？事件是一次性问题，还是会再次发生？影响标注(黄色) - 3.2.2 风险 > 位置 2209在 Google，我们确定了两个要素：失败频率（ frequency of failure）和影响（ impact）。标注(黄色) - 3.2.2 风险 > 位置 2214风险发生频率有 4个预定义值。罕见（标注(黄色) - 3.2.2 风险 > 位置 2217少见（ seldom）：标注(黄色) - 3.2.2 风险 > 位置 2221偶尔（ occasionally）：标注(黄色) - 3.2.2 风险 > 位置 2225常见（ often）：标注(黄色) - 3.2.2 风险 > 位置 2229测试人员确定每个能力的故障发生频率。标注(黄色) - 3.2.2 风险 > 位置 2230估计风险影响的方法大致相同，也是从几种偶数取值中选标注(黄色) - 3.2.2 风险 > 位置 2231最小（ minimal）：用户甚至不会注意到的问题。标注(黄色) - 3.2.2 风险 > 位置 2234一些（ some）：可能会打扰到用户的问题。一旦发生，重试或恢复标注(黄色) - 3.2.2 风险 > 位置 2237较大（ considerable）：故障导致标注(黄色) - 3.2.2 风险 > 位置 2240最大（ maximal）：发生的故障会永久性的损害产品的声誉，并导致用户不再使用它。标注(黄色) - 3.2.2 风险 > 位置 2267风险不大可能彻底消除。驾驶有风险，但我们仍然会开车出行；旅游有风险，但我们并没有停止旅游。标注(黄色) - 3.2.2 风险 > 位置 2285在软件开发中，任何一种可以在 10分钟之内完成的事情都是微不足道的，或是本来就不值得做的。标注(黄色) - 3.2.2 风险 > 位置 2323风险分析是一个独立的领域，在许多其他行业里被严肃地对待。我们现在采用的是一个轻量级的版本，标注(黄色) - 3.2.2 风险 > 位置 2325风险管理方法），这可以作为进一步学习这一重要课题的起点。标注(黄色) - 3.2.2 风险 > 位置 2328TE有责任理解所有的风险点，并使用他或她可以利用的任何手段予以缓解。标注(黄色) - 3.2.5 TE的招聘 > 位置 2668他们只是在试图破坏软件，还是同时在验证它能正常工作？标注(黄色) - 3.2.5 TE的招聘 > 位置 2717我们需要的是愿意持续学习和成长的人。我们也需要那些带来新鲜思想和经验的人，标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3301对于一个新项目，我首先要站在用户的角度了解这个产品。有可能的话，我会作为一个用户，以自己的账户和个人数据去使用产品。我努力使自己经历完整的用户体验。一旦有自己的真实数据在里面，你对一个产品的期待会彻底改变。在具备了用户心态之后，我会做下面的一些事情。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3362遗漏到客户的 bug是一项重要指标，我希望这个数字接近 0。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3377或者用户场景无需编写、自动到位。 CRUD操作（译注： create、 read、 update、 delete）标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3385团队在推出一个产品或新功能时难免感到提心吊胆，而我能带给他们镇定和信心，这使我感到自己是一种正面、有益的力量。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3416而 Google的 SET必须写代码，这是他们的工作。这里也很难找到不会写代码的 TE。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3426Google的测试与其他公司的相同之处呢？ Apple：在测试上难以自动化的软件，很难成为好的软件。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3493不管是测试框架还是测试用例都以简单为要，随着项目的开展再迭代的设计。不要试图事先解决所有问题。要敢于扔掉过时的东西。第4章 测试工程经理标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 3989把测试推向上游，让整个团队（开发 +测试）为交付的质量负责。标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 4025从那以后，我们把配置变更也纳入质量流程中，我们开发了一套自动化测试，每次数据和配置变更时都要执行。标注(黄色) - 4.11 工程经理Brad Green访谈 > 位置 4219Google聘用的都是有极端自我驱动力的家伙。“标注(黄色) - 4.12 James Whittaker访谈 > 位置 4339先虚心学习，再在一线作出成绩，然后开始寻求创新的方法。第5章 Google软件测试改进标注(黄色) - 位置 4398Google的测试流程可以非常简练地概括为：标注(黄色) - 位置 4398让每个工程师都注重质量。标注(黄色) - 位置 4398只要大家诚实认真地这么做，质量就会提高。代码质量从一开始就能更好，标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4408可是测试并不能保证质量。质量是内建的，而不是外加的。因此，保证质量是开发者的任务，标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4409测试成了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4415保证质量不但是别人的问题，它甚至还属于另一个部门。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4416出问题的时候也很容易就把责任推卸给修前草坪的外包公司。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4426第三个致命的缺陷，是测试人员往往崇拜测试产物（ test artifact）胜过软件本身。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4430所有测试产物的价值，在于它们对代码的影响，进而通过产品来体现。标注(黄色) - 5.2 SET的未来 > 位置 4447简单来说，我们认为 SET没有未来。 SET就是开发。就这么简单。标注(黄色) - 5.2 SET的未来 > 位置 4450SET直接负责很多功能特性，如可测试性、可靠性、可调试性，