《Google软件测试之道》读后感10篇

　　《Google软件测试之道》是一本由James A. Whittaker / Jason Arbon著作，人民邮电出版社出版的平装图书，本书定价：59.00元，页数：258，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《Google软件测试之道》读后感(一)：互联网时代的软件测试

　　0、google强调在互联网时代测试的转身，并且利用测试人员很少的情况下如何做的更好。就是测试团队将能力导入开发，测试写代码逐步向开发转身，一部分测试人员向用户转身更好的测试。

　　1、小型、中型、大型比例约为 7：2：1。

　　如果是基础平台，面向数据的项目，UT比例应该更高。

　　UT带来良好的代码质量，良好的异常处理，优雅的错误报告。

　　大中型测试会带来整体产品质量和数据争取保证。

　　2、测试认证 级别1-5，设定和导入开发团队。

　　1)侧重基本准备。2）提高增量代码覆盖率。3）测试新增代码。4）测试历史遗留代码。5）更换的整体覆盖率，针对每个缺陷都增加测试用例，并要求使用已有可用的静态与动态分析检查工具。

　　3、让每个工程师都重视质量，代码质量从一开始就能更好，早期构建版本的质量会更高，系统测试可以关注与真正面向用户的问题。

　　4、测试的一些老大难问题：开发关注测试，开发和测试组织的分开，测试过于关注测试的产物bug，经过测试的产品发布后总是有问题。

　　5、google的特点，总是让资源很紧缺，负责人想办法提高效率，用到各种的工具，自动化。非常强调自动化。

　　《Google软件测试之道》读后感(二)：Google软件测试之道的一点读书体会

　　本书介绍了google中软件开发工程师swe,软件测试开发工程师set,测试工程师te三类角色的工作内容和角色定位，每一类角色都配以google人员的访谈加以拓展深化，让读者更好地理解这三类角色的分工运作，以及在google 工程项目中的作用。

　　在本书第5章google 软件测试改进中，客观分析了google流程中的致命缺陷，有三个:一是测试成了开发的拐杖，即是将测试从开发中独立出来，甚至成立专门的测试部门，会让开发倾向于不考虑测试问题，越来越不会去做测试，而且容易导致出问题时相互推卸责任。二还是开发和测试组织结构分离有关，测试人员更关注自己的角色而不是产品。三是测试人员往往崇拜测试产物胜过产品本身，但对用户来说产品才是第一位的。

　　从这三个缺陷我们也领会到Google对待测试的发现理念，开发和测试不行分离，而是应该加强合作融合，弱化两者的角色定位，以产品为第一目标协同发展，你中有我，我中有你。另外，对于te这个角色的未来，google认为测试工程师会转型为测试设计，成为像安全工程师这样的专家型角色或者变成测试管理者，而那些具体的测试活动则由其他人来完成。这点被越来越多的企业和人员所接受，而作为读者我也认同这样的发展。

　　《Google软件测试之道》读后感(三)："只有在软件产品变得重要的时候，质量才显得重要"

　　过节、带娃的间隙，看完了《Google软件测试之道》。全书其实就在讲“融合”：面向开发的测试向开发端融合，面向用户的测试向用户端融合。这种“融合”，需要“快速，有效率和效果”的工具，方法论和组织结构来完成。 其实，这也就是敏捷，DevOps运动所倡导的：快速的响应变化，以适应客户价值的不确定性和变化。

　　《Google软件测试之道》读后感(四)：向巨头学习软件测试的理想及实务

　　作为《微软的软件测试之道》的译者之一，差不多五年以后再来看这本书，是一种很有意思的体验。这本书当然写得很好，但好在哪里，可能未必人人都能说出个道道来——这很像是软件测试行业本身，充满了对这个行业的各种片面的认识，而且这些片面认识的来源往往是“一线的工作经验”。因为很久以来，软件测试的理论和实践的发展一直处于资源和人力相对不足，工作内容的边界也很模糊的状态。市场上的现有书籍的最大问题，在于站的位置不是太高就是太低。以学术口吻写就、工程人员一看就感觉与己无关者有之；以自己的实际工作经验为基础，但是并未形成有效的理论者有之；泛泛而谈的理论家凭借相当的想象写就，但是既没有实例也没有工具者有之——一言以蔽之，光说了一堆测试这件事应该怎么做，但是并没有看到测得什么优秀的产品，也没有在这个过程中发展出工具、理论和文化来，这样的软件测试图书，我以为价值是不高的。

　　但是《Google软件测试之道》——如果允许我小小地、非完全地自夸一下的话——还有《微软的软件测试之道》这样的书，则是极有价值的了。这首先在于，IT巨头已经生产出来的软件产品，其成功是妇孺皆知的。那么，以这些产品的生产过程作为软件开发生命周期中的模范，应该是不仅比较正确，而且也是更有沟通基础的，因而也是更有价值的。软件测试作为软件开发生命周期中接触点最多的一环，看一看这些IT巨头们是怎么做的——我的意思是，它们怎样设计配套的公司组织结构、怎样处理软件测试和其他生命周期环节的关系、基于怎样的思想来实施工程实务、开发了怎样的支撑环境和工程工具……这一系列的问题，看看微软和Google给出的答案，读者就可以知道，在目前的软件和硬件条件下，理想的，或者说是最高水平的软件测试已经达到了一种怎样的程度，从而在规划自己软件测试相关的团队配置和工程技术实务时，有了非常重要的参考。一般来说，能够真正达到这样的水平，是不太可能的，可是榜样和模范的力量就在于此：做一个完整版、旗舰版不可能，但是做一个精简版、定制版就总算有了一个参照可言。可以说，我本人对于测试自动化的全部概念都来自于微软的测试工程，如果不是实地看到成千上万台物理机和虚拟机在极有序、极智能地运行着各种计划任务，来测试一个小小的安全补丁在数种CPU和硬件体系结构、数十种网络条件和共存软件、数百种参数和开关组合下取得种种的功能和性能数据，并自动出具详尽的测试报告和一针见血的分析建议，光是看看教材是绝对不可能带来如此的心灵震撼的。我在之后的工作经历中，也反复地应用了这些宝贵的经验。

　　然而《Google软件测试之道》又让我看到了一些新的东西，这主要是软件交付模式从盒装变为在线带来的，因而时间特性从离散变为持续（服务从主要在客户端运行变为主要在云端运行）、空间特性从单一变为多元（对于操作系统和设备特性的假设更弱化），软件测试为了适应这些变化，必须一方面在概念上变得更灵活，另一方面却要在执行上却要变得更简单有效。这两个相互矛盾的要求，对软件测试的管理和执行人员都提出了极大的挑战。毫不意外地，我看到这本书在基础层面上与传统的盒装软件测试有着同样的测试目标：高可用性、高性能、优化的用户体验，但是在概念和技术上却发生了巨变，我诚挚地请读者们重点关注一下这本书对于测试规模的论述，以及性能测试工具的设计思想，信息量很大。另外，认真研习一下附录的两份测试计划，也会有不小的收获。这本书的问题主要是“太Google的”访谈内容有点儿多，当然这对可读性的提高有一定的贡献，但是至少现在我还没觉得这部分的价值有多大。

　　《Google软件测试之道》读后感(五)：伟大公司的“理想”测试法

　　很多时候，人们总会说某些理念或做法太过“理想化”，其实只是低头走路太久，忘记了抬头看天而已。如果我们心中没有理想，又如何可以创造出伟大的成就呢？而当下在测试领域，谷歌就是坚持理想实现了书中理念的典范。

　　12~13 小型测试、中型测试、大型测试……mock和fake……小型测试主要尝试解决的问题是“这些代码是否按照预期的方式运行”……中型测试尝试去解决的问题是，一系列临近的模块互相交互的时候，是否如我们预期的那样工作；这种端到端的使用场景以及在整体产品或服务之上的操作行为，即是大型测试关注的重点；重要的是，在Google测试人员使用统一术语来谈论他们测试的是什么，以及这些测试范围是如何划分的。

　　15 测试框架（test harnesses）、测试通用测试（test infrastructure）、模拟设施和虚拟设施（mock and fake）

　　15 对于功能代码而言，思维模式是创建，重点在于考虑用户、使用场景和数据流程上；而对于测试代码来说，主要思路是去破坏，怎样写测试代码用以扰乱分离用户及其数据。

　　17 工程师团队的交付物就是即将发布的代码。代码的组织形式、开发过程、维护是日常工作重点。

　　19 最小化对平台的依赖。所有工程师都有一台桌面工作机器，且操作系统都尽可能地与Google生产环境的操作系统保持一致。……所有对平台有依赖的代码，都会强制要求使用公共的底层库。

　　20 使用统一的运行平台和相同的代码库，持续不断地在构建系统中打包。

　　21 服务之间的接口需要在项目的早期就确定下来。……这些接口一般都不会真正实现，而只是做一个虚假的实现。

　　22 在未来可能失败的项目中投入测试资源来构造测试方面基础设施，这是一种资源浪费。

　　24 所有Google项目都有设计文档。这是一个动态的文档，随着项目的演化也在不断地保持更新。

　　29 提交队列（submit queue）的主要功能是保持“绿色”的构建，这意味着所有测试必须全部通过。这是构建系统和版本控制系统之间的最后一道防线。

　　48 检验一个项目里小型测试、中型测试和大型测试之间的比率是否健康，一个好办法是使用代码覆盖率。……Harvester……

　　51 持续集成系统使用构建系统中的构建依赖规则。

　　63 “SET的招聘” 对于候选者，最好去考察如何思索问题的解决方案，而不是解决方案本身的实现上体现得多么高雅。……只有一件事情需要去做而我正在做这个事情，这个事情就是写代码。SET不会遵循这样的世界观。我们希望先把问题搞清楚。

　　70 我认为最艰难和最有趣的挑战总是出现在设计阶段。

　　98 与其询问他们关于某个模糊概念的看法，不如拿一个明确的结论来引起辩论。

　　101 Google Test Analytics支持上述基于分类赋值（非常罕见、很少、偶尔、经常）的风险分析。……知道A比B风险大就足够了，不需要过分关心它们的具体风险值。

　　120 bug分类过程（bug triage process）……聚类算法来自动识别重复记录并确定最频繁的问题。……需要精简到10个左右主要的、共性的问题。

　　120 修复会产生一个变更列表（CL），CL排队去接受评审，一旦得到批准，就进入构建目标队伍中。

　　121 TE的招聘尤其困难，因为最好的TE不是那些基础算法、定理实现、功能实现上的牛人。……TE是稀缺个体，是技术人，关注用户，能在系统级别和端到端的视角上理解产品。他们是无情的、伟大的谈判专家，更重要的是，他们富有创造性、善于应对模糊性。

　　122 混合模型：今天，我们的面试既要考察一般的计算机科学和技术技能，也要考察候选人的测试潜力。编程知识是必需的，但只限于那些完成前述TE工作需要的水平：修改而非创建代码、设计端到端的用户使用场景的能力等。再加上TE工作本身需要的一些特定的能力，如沟通、系统级别的理解以及用户同理心。

　　124 一开始，我们考察测试资质。……我们寻找的是对于事物结构、对于变量和配置的组合的各种可能性和意义的好奇心。我们寻找的是关于事物应该如何工作的强烈感觉，以及清晰表达的能力。我们还会试图寻找很强的人格魅力。

　　127 面试时试图考察的另外一个关键特征，是TE所需要具备的处理模糊性、反驳糟糕想法的能力。……TE面试的最后一环是看候选人是否具有“Google味儿”。

　　128 Google的测试管理更多的是激励，而非强悍的管理；更多的是战略指引，而非频繁的督促检查（每天、每周等）。

　　131 TE到SET、SET到SWE是最为常见的。

　　131 OKRs（Objectives and Key Results），也即目标和关键结果。

　　134 质量机器人（Quality Bot）实验

　　143 我的反应是很Google式的：表面同意，但私底下一切照旧。

　　145 这个特性有单元测试用例，但只有bot逮住了这个问题，因为它测试的是真正的网页。

　　145 BITE代表Browser Integrated Test Environment（浏览器集成测试环境）

　　151 我们实现了一个称为Record and Playback framework（RPF）的纯Web的解决方案，是用纯Javaｓｃｒｉｐｔ实现的……在回放的时候，RPF首先查找精确匹配，在找不到的情况下查找近似匹配。……处于安全原因，某些涉及钱的场景无法通过web API自动化。

　　153 这个做法已经成功地用于众包测试，外包测试人员在安装了BITE的浏览器中执行测试，测试任务的分发通过BITE进行。

　　165~170 “Lindsay Webster的访谈” 对于一个新项目，我首先要站在用户的角度了解这个产品。……从头到尾的理解产品。……关注项目的状态，特别是质量状态。……只有熟悉了团队的全貌，才能真正有效的展开工作。……我会了解他们沟通的方式和对测试人员的期望。……询问他们对测试的期望，会帮助发现开发团队没有测试过的内容。……第一件事是把应用分解为合理的功能模块。……排列测试的优先级……再次检查Bug库……按照优先级顺序更加细致地遍历所有模块，创建用户故事……通常会编写测试用例并链接到相应模块的用户故事。……有了测试集合，我接下来会通过再次检查bug和应用来寻找覆盖度上的不足。……有了这些基础材料，我的工作通常只是维护和更新：更新测试用例，增加新特性的文档，更新变化了的模块的截屏或视频。最后，观察哪些bug遗漏到了生产环境，会告诉我们测试覆盖上的不足。……我把自己变成用户，就这么简单。……换句话说，测试要清楚地指出当做之事。……开发经常会低估我的工作，知道我们在一起工作了几个月之后，他们才会改变想法。我在完成了上述工作之后，将邀请整个团队开会，介绍一下我设定的测试流程。……当我坦诚地指出某些组件或领域的测试不应该由我负责，而应该由他们自己负责的时候，开发反而更加看重我的工作了。……这就是为什么要按照一定的优先级处理应用的各种功能和环境支持。……重要的是，要维护团队的这份信任——如果我强烈感到发布时机未到，那么这可能也是他们希望的。……当然，还是有一些不那么尊敬我的工作的SET，但他们就像有类似想法的开发人员一样，不曾与我或其他TE一起工作过。一旦发生了合作，他们的态度通常会迅速的转变。

　　174 “Apple Chow的访谈” 遵守70-20-10法则：小型的用来验证单个类或功能的单元测试占70%，中型的用来验证一个或多个应用模块之间集成的测试占20%，大型的高级别的用来验证完整应用的测试占10%。

　　178 想成为优秀的测试工程经理，第一条建议就是去了解你的产品。……第二条建议是知人善用。

　　179 不能仅仅依赖于某位明星测试人员。……必须要沉淀为可用的工具，或者总结成一套方法，这样可以帮助其他人也能走上这条成为明星的道路。

　　181 在Google，对工程师最好的褒奖就是称赞他的影响力。而对于测试工程经理来说，就是建立一支有影响力的团队。

　　183 多年来，通过不断地聆听，我发现最有力的问题就是“为什么”。

　　184 所以经验就是解决掉一些难题来赢得尊重。

　　187 我们更专注于预防bug而不是检测bug，这为我们带来了巨大收益。

　　193 目前我还是倾向于使用一种综合的方式，混合使用开发自测、脚本化测试、探索式测试、基于风险的测试、自动化功能测试等多种方法。

　　198 我们经常由于太难保证后台系统的质量而不能按时发布。后台系统不能出现差错，因为它影响太多产品线了。……在后台系统中如果仅仅使用端到端测试，要是不能发现问题，就会导致连锁反应。

　　200 一般来说，我首先会让我的团队思考，“对被测系统来说，什么是最为重要的东西？”

　　201~203 “Ashish Kumar的访谈” 整个工具集包括：源码工具；开发工具；测试基础架构；本地化工具；度量、可视化和报表。……大规模的持续集成（是我一开始不看好但最后成功的）……从小做起，不断证明其价值，然后当项目体现价值以后扩大规模。……特别重要的一件事，是要关注团队里新来的开发工程师必须使用到的开发环境。要让代码的获取、编辑、测试、运行、调试和部署都非常简单。

　　214~216 “James Whittaker访谈” 第一条，是先花一些时间来观察学习。……聆听而不是直接发言，询问而不是直接尝试。……第二条建议，“兄弟，我知道你在来Google之前已富盛名，但是在这个公司里，你还什么成就也没做出来呢。”……先虚心学习，再在一线做出成绩，然后开始寻求创新的方法。……其他公司要想仿效Google的做法，应该从这四个方面做起：技能、稀缺性、自动化和迭代集成。这就是Google测试的“秘方”。

　　219~221 “Google流程中的致命缺陷” 第一个致命的缺陷：测试成了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不去做测试。……第二个致命缺陷，还是与开发和测试的组织结构分离有关。……第三个致命的缺陷，是测试人员往往崇拜测试产物（test artifact）胜过软件本身。……最后一个致命缺陷也许是最深刻的。产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：几乎必然发现。……是谁在做测试并不重要，关键是进行了测试。……SET的角色越来越像开发，而TE的角色向着相反的方向越来越像用户。……质量需要每一个任的贡献。

　　222 测试的技能被平均地分散到各个层级的开发工程师身上，而不是集中于测试开发工程师（SET）那里。

　　223 测试工程会转型成为测试设计。……这个工作需要的是规划、组织和管理近于免费的测试资源。……测试工程师会转变成像安全工程师这样的专家型角色，或者他们会变成测试活动的管理者。

　　224 技术型的主管，将会更多地转向成为诸如杰出工程师这样的个人角色。……作为思想领袖，为维系……关系而存在……测试活动应该对人们具体工作的产品负责。

　　224 测试基础设施会最终整体迁移到云端。测试用例库，测试代码的编辑、录制和执行都将在一个网站或通过浏览器插件完成。测试编写、执行和调试需要使用与被测的应用程序本身相同的语言和环境才最为高效。

　　==========

　　徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。

　　《Google软件测试之道》读后感(六)：测试同行们都可以了解和借鉴一些google测试

　　《Google软件测试之道》

　　总的来说，这本书是我看过的所有软件测试相关书籍中，收益最大的一本。个人觉得，这本书更适合有一些测试或工具开发经验的人看。测试经验较丰富的人，看了收益较大，初学者也能领会到一些基本的东西。

　　这本书主要通过对测试开发工程师（SET）、测试工程师（TE）和测试工程经理三种角色及其各自负责的工作的介绍，将Google测试的整体概况和部分细节（2012年前的情况）介绍给读者。

　　小型测试（fake环境） -> 中型测试（fake或真实环境） -> 大型测试（真实环境）

　　mock：对外面依赖系统的模拟，一般可以动态地设置返回值；fake：一种虚假的实现，只返回固定的结果；stub：和mock意思接近，但它一般不知道是否被call过。我自己觉得这3者差别也是太大，偶尔大家都混用（如全都叫“mock”）。个人感觉是，一般是测试方写的mock/stub，提供方在没完成功能前提供fake；另外，mock/stub一般可以工具直接生产，而fake一般是手写的。

　　强调小型、中型测试的自动化覆盖率；在端到端自动化测试上投入过多，常常会和特定功能设计绑定在一起。

　　小型、中型、大型测试的比例：7:2:1

　　测试认证级别，根据测试覆盖率、分层测试情况、继续集成、缺陷和测试用例的关系，将团队分为5个级别。 Level 5 最高，做的做好。

　　ET主要负责mock/stub、API测试、测试工具、CI工具，更偏向于代码开发；2.3节 SET的照片写的不错。

　　TE是面向用户的测试，具备测试代码开发和用户为中心测试的双重能力。

　　TE完成测试整个过程，风险评估、测试计划、测试执行、探索式测试、用户反馈。

　　3.2.4节 bug的生命周期、bug的要素等，也是值得借鉴的。Google feedback 一个极简的用户提交bug的方式。

　　3.2.5节 TE的招聘，SET和TE的区别，面试TE的问题和各种回答的分析，都非常精彩。

　　测试工程经理，把TE和SET联系起来，需要足够的技术能力，需要足够了解产品，也需要知人善用的能力。

　　Google的原则是：ship early and often, fail fast.

　　Google测试的秘方：技能、稀缺、自动化、迭代集成。

　　第5章 关于软件测试的未来的论述也不错，不过里面描述的那个未来估计至少10年之后才会明朗起来，20年后估计才能普及吧。

　　测试工程师和测试经理分散到各个项目团队中去，更少关注测试流程，更多关注产品本身；测试开发工程师成为开发工程师。技术型测试主管，更多地成为资深工程师。

　　《Google软件测试之道》读后感(七)：前期不能测，后期不用测，中期外包测

　　1. 自动化测试，说起来容易做起来难，有google能做到不代表所有公司都能做到。况且google自己就做到了么？ 自动化测试占前期测试方案的百分之多少？

　　2. 书中推崇自动化，却缺乏一般性方法，只举特例，特例又只举成功的，例如某某花了20%时间做了个啥啥，然后大获成功，那没成功的项目花的时间怎么算？描述成功的例子时用大量形容词，几乎从不涉及具体百分比数字

　　3. 看完本书，我觉得google真NB，但是怎么样才能让我们也向google一样NB呢？就不告诉你，因为里面的方法都是针对特定的google产品的。

　　4. 书中提到一个成功的工具或者方法，就说目前有“许多”小组都在用，“许多”是多少？占全部小组比例的百分之多少？究竟把百分之多少的测试用例自动化了？

　　5. google的测试人员少，因为项目前期有风险，不测。后期产品成熟了，不测。中期把一大部分交给外包测，确实是好点子。

　　《Google软件测试之道》读后感(八)：初识测试

　　工作的部门负责开发内部管理程序，原来没有测试，开发员自己测试，写测试报告，很原始，写输入输出数据，发生错误，当然最后都是更正了的。最近赶工项目多，用户反映体验差，领导也觉得很多是初级错误，搞个测试岗把把关。我对测试的认识就是开发测试，在慕课学了一次软件测试和质量，图书馆借了４本测试书看，这本ｇｏｏｇｌｅ是第一本，速览花了一周。

　　上了一次慕课，对软件测试了解大概，黑盒技术白盒技术，测试工具，软件特性说明，测试图表介绍等等。这本ｇｏｏｇｌｅ读后感到超出预期。首先这本书的副标题应该是自动测试之道。慕课上介绍的更多是传统测试技术，捎带了１０分钟的自动测试工具介绍，就是录制脚本回放。这本ｇｏｏｇｌｅ没有枯燥的技术工具介绍，而是从作者个人在ｇｏｏｇｌｅ测试多个项目经历的概要介绍及访谈，说明了ｇｏｏｇｌｅ的测试文化，测试岗位，测试发展等等。由于ｇｏｏｇｌｅ是世界最大的软件公司之一，这本书有很强的借鉴意义，好象去这家公司调研了一番。自动测试是未来发展方向和目标。就国情而言，大多软件公司人员规模不大，测试人员开发技术能力弱，商业测试工具不成熟，但只有善用自动测试，有效组织测试工作，最终达到提高开发效率的目的，测试人员才有尊重和地位可言。简单的模拟测试和手工测试，只是低价值的劳力付出。这本书提及的记录的测试属性，可以拿来现用。这本书值得再次阅读。

　　《Google软件测试之道》读后感(九)：Key：ACC

　　本书颠覆了我对测试之前的了解

　　本书有两点核心。

　　一是角色（SWE,SET,TE，最终是开发测试极度融合，相互辅助前行）

　　二是ACC理念。（A,C）坐标定义的区域，有两个输出，一个是C(能力，就是test plan)，一个是风险热图（risk heat map）。测试的出发和落脚点是A(attribute)，也是本书提到的，不懂产品的人，根本无法真正的进行测试。

　　技术分享时，整理了ppt和sample

　　《Google软件测试之道》读后感(十)：工程师思维

　　Google的软件测试之道，参考意义首先跟之前看的一篇文章一样，互联网并不缺前端，也不缺测试，我们真正缺少的是工程师思维，是创造性的提出和解决问题的想象力，站在用户角度思考的产品的能力。

　　我们学习Google软件测试，只能学其道而没有必要，也不可能去他们的术。如《看板方法》一书所说，对于新组建的团队，尤其初创公司，能力建设才是唯一的问题，业务成功是压倒一切的目标，而且业务本身充满风险和变化，并没有空间去发明太多轮子，何况google这个轮子，直接就是selenium、webdriver这个级别的测试工具，并非一般工程师能做到的。

　　最终软件行业真正寻找的既不是前端，也不是后端，也不是测试，唯有工程师思维，充满好奇心和创造力的头脑，在自由的环境下，发挥创造力这样一个理想状态。

　　回到测试本身，无论测试计划也好，需求分析也好，核心在于谁来看，如果写的时间超过看的时间，而且找不到目标受众，其实也就没有必要。

　　测试金字塔也是一个重要的实践，在自动化everything的理念下，测试又回到了纸带卡片的时代，需要合理的权衡测试的规模和代价。

　　核心其实不在于文档，也不在工具，核心还是思考和创造数据，站在用户的角度思考产品的意义。至于编写测试的工具，发明轮子在做好测试，只是理所当然。

　　至于te和测试总监，其实跟开发一样，只有高质量的有趣的项目，才能吸引更多的测试人员投入，如果测试人员都抛弃的项目，估计被用户抛弃也就不奇怪了。测试总监只需要招聘最合适的人，然后创造条件去激发创新，就可以了