google软件测试之道 摘录

1.如果测试人员想加入google这个俱乐部,必须具备良好的计算机科学基础和编程能力。

  1. 一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责,包括产品,开发,测试等。最好方式是测试人员有能力将测试变成代码库的一个实际功能。能够实现测试功能的技能,也是开发人员需要具备的技能。
  2. google测试团队组织叫工程生产力(engineering productivity)团队。
  3. STE(software engineer in test软件测试开发工程师);TE(test engineer)
  4. GTAC(google test Automation conference)
  5. 谈论开发测试比例就如同讨论太阳表面的空气质量一样没有任何意义。如果职位头衔上有测试的字样,你的任务就是怎样使得头衔上没有测试的人可以更好的去做测试。----协调多方共同参与,保证产品质量
  6. 质量不等于测试。把开发过程和测试放到一起,就像在搅拌机里混合搅拌那样,直到不能区分彼此,就得到了质量。写一段代码就立刻测试这段代码,完成更多的代码就做更多的测试。如果某个产品出了问题,第一个责任人肯定是对应的开发人员,而非遗漏bug的测试人员。所以质量更像是一种预防行为,而不是检测。质量是开发过程的问题,而不是测试问题。
  7. you build it ,you break it ,you fix it。测试人员的存在是让开发人员的工作更有效率。
  8. SET写代码的目的是可以让SWE测试自己的功能,目标用户是SWE。TE把用户放第一位思考,组织整体质量实践,分析解释测试运行结果,驱动测试执行,构建端到端的自动化测试。
  9. 产品发布,优先考虑的是功能完整性和易用性,很少考虑质量。同一个团队,测试总是为开发让路。google生产力团队,测试人员是借调模式,可以涉及多个产品,了解更多专业技术。
  10. 爬,走,跑===》各个版本,包括金丝雀版本,开发版本,测试版本,β/发布版本
  11. 小型测试涵盖单一代码段,一般运行在fake,mock环境;中型测试涵盖多个模块,重点关注模块交互,运行在fake或者真实环境;大型测试涵盖任意多个模块,运行在真实环境,使用真实用户数据和资源。
  12. 编写功能代码(考虑实现),编写测试代码(考虑破坏功能)
  13. TE,不需要过早介入,在产品需求不明确,未立项情况下,TE介入并无太多实际作用。而starting in the middle,说明TE必须保持足够的灵活,迅速融入产品。
  14. 测试计划是最早出现,最先被遗忘的测试产物。ACC(attribute component capability),特质、组件、能力,测试计划的替代方法。能力处于特质和组件的交点,组件执行某种功能满足产品特质,这个活动的结果就是向用户提供某种能力。
  15. 追求数量而非质量,是一种低效的工作方式。所以设计测试用例需要先分析需求,不能一猛子扎进去开始设计测试用例
  16. 对自己工作的评估
  17. 释放时间用于自动化,高优先级的测试或者探索式测试
  18. 测试活动是最重要的,而不是测试用例,bug,测试计划等。
  19. 测试工程师会转变为安全工程师这样的专家型角色,或者管理者,具体的测试活动由其他人完成。

猜你喜欢

转载自blog.csdn.net/Trival_dreamy/article/details/81905194
今日推荐