《Google软件测试之道》的原文摘录
-
在测试上难以自动化的软件，很难成为好的软件。 (查看原文)
-
除此之外，安排好优先级，寻找小成本大回报的自动化项目。一定要记住自动化并不能解决所有问题，尤其是前端项目和设备测试。 (查看原文)
-
我首先会让我的团队思考，“对被测系统来说，什么是最为重要的东西？”对搜索来说是性能，对新闻来说是时效性，对地图来说是综合性和完整性。每个应用都有其最重要的属性。类似的，对系统基础架构来说，数据完整性对存储最为重要，可扩展性对网络系统最为重要，利用率对任务管理系统最为关键。当你分清了你要测试的特定产品的关键因素以后，就要把你的大部分精力集中在检验系统的核心能力是不是能够满足这些关键属性要求上。
当这些重要的事情搞定以后，再去关心那些简单的事情（用户界面这些锦上添花的东西）。还要关注那些核心的不容易改动的方面（如性能设计），而不对那些很容易修改的方面花费太多精力。如果你过早报告关于字体的bug，我就会担心你是不是没有搞清楚事情的优先次序。 (查看原文)
-
质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量 (查看原文)
-
SET写代码的目的是可以让SWE测试自己的性能 (查看原文)
-
HGTS：Flash占据了YouTube内容和UI的一大部分，它怎样测试的呢？你们是否有某种通过Selenium测试Flash的秘籍？
Apple：不幸的是，没有。有的只是大量的艰苦劳动。Selenium在某些方面有帮助，因为我们的JavaScript API是暴露的，可以利用Selenium来进行调用测试。我们使用了一个图像比较工具pdiff来测试缩略图、最后一屏（end of screen）的渲染。我们还使用了大量的HTTP流代理来监听流量，这样就可以了解页面变化的更多信息。我们使用As3Unit和FlexUnit来加载播放器来播放不同的视频，以及触发播放器事件。关于验证，我们可以使用这些框架来验证软件的各种状态、完成图像对比。我想说这就象变戏法一样，但实际上是大量代码铺就的。 (查看原文)
-
我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。 (查看原文)
-
你可能是一个TE (查看原文)
-
如果能够自动化，并不需要人脑的睿智与直觉来判断，那就应该以自动化的方式实现 (查看原文)
-
通过使用定位点击的验证方式、录制技术等可以把一些手动测试转变成自动化测试，这些自动化测试在每次建立之后都会重复地回归运行，而手动测试更倾向于关注于新功能。 (查看原文)
-
mock对象是指对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望的结果。fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只能返回特定的结果。 (查看原文)
-
开发团队在寻求测试帮助的时候，有义务让测试人员相信他们的产品是令人兴奋且并充满希望的。在Chrome OS的开发总监给我们介绍他们项目、进度和发布计划时，我们也要求提供当前已有的测试状态、期望的单元测试覆盖率水平、以及明确在发布过程中各自承担的责任。 (查看原文)
-
TE面试的最后一环是看候选人是否具有“Google味儿”。 (查看原文)
-
工程师只要在当前的项目工作了18个月以上就可以自由离开，而不需要获得当前经理和未来经理的许可
负面因素是有经验的员工也可能转到其他团队。这对测试工程经理提出的要求是不能过于依赖于某些成员。不能仅仅依赖于某位明星测试人员，那些促成这位测试人员成为明星的东西，必须要沉淀成可用的工具，或者总结成一套方式，这样就可以帮助其他人也能走上这条成为明星的道路。 (查看原文)
-
Google测试成功的关键是什么？不要招聘太多的测试人员，写代码的开发人员也承担了质量的重任。
开发和测试并肩齐驱。
Google能用如此少的专职人员的原因，就是开发对质量负责。这意味着质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。 (查看原文)
-
SET编写代码，通过这些代码提供的功能让SWE能够自己测试他们的功能。多数测试代码是由SWE完成，SET存在的目的就是保证这些功能模块具有可测试性，并且响应的SWE还可以积极的参与到测试代码的编写中。 (查看原文)
