当前位置:网站首页>《Google软件测试之道》 第一章google软件测试介绍

《Google软件测试之道》 第一章google软件测试介绍

2020-11-06 01:15:05 --D

前段时间比较迷茫,没有明确的学习方向和内容。不过有一点应该是可以肯定的:迷茫的时候就把空闲的时间用来看书吧!

这本书,目前只是比较粗略的看了一遍,感触很大。以下是个人所作的笔记,与原文会有出入的地方。建议感兴趣的伙伴阅读原文书籍!

 

一、质量不等于测试

质量不是被测出来的:未经测试也不可能开发出有质量的软件。

保证质量:

  测试开发同时开展:google目标。

  开发对质量的责任:写一段代码后立刻测试,完成了更多的代码就做更多的测试;质量像是预防行为(质量是开发过程的问题,不是测试问题)。

       测试:线上bug重重,就会回滚版本;判断预防工作做得怎么样(开发的测试,能不能确保不会出现回滚级别的bug发生)。

 

二、角色

1、软件开发工程师SWE

实现最终用户所使用的功能代码:

  创建设计文档、选择最优的数据结构和整体架构、代码实现和代码审核。

编写测试代码:

  测试驱动的设计、单元测试、参与构建各种大小规模的测试。

增加功能性代码或是提高性能的代码。

质量责任:

  对他们编写、修复以及修改的代码承担质量责任(容错设计、故障恢复、测试驱动设计、单元测试)。

2、软件测试开发工程师SET

工作重心:

  保证SWE开发的功能模块具有可测试性:参与设计评审,观察代码质量与风险;可能会重构代码,编写单元测试框架和自动化测试框架。

  通用测试基础框架。

负责提供测试支持:

       有个测试框架:可以把新开发的代码隔离,通过模拟真实的工作运行环境和代码提交队列来管理代码的提交。

关注:质量提升和测试覆盖率的增加。

写代码的目的:可以让SWE测试自己的功能。

3、测试工程师TE

专注用户角度的测试:

       花大量时间模拟用户的使用场景和自动化脚本或代码的编写上。

       是否满足性能期望,在安全性、国际化、访问权限等方面是否满足用户的要求。

工作:

  组织整体质量实践(把SWE和SET编写的测试分类组织起来),分析解释测试运行结果,驱动测试执行,构建端到端的自动化测试。

 

三、组织结构

大多数公司:

       资深管理者一般来自产品经理或开发经理,而不是来自测试团队。

       产品发布时,优先考虑的是功能是否完整和易用性方面是否足够简单,很少考虑质量。

       作为同一个团队,测试总是在为开发让路:“行业充斥着各种有缺陷、早产的产品”的问题所在;质量不行就再发布一个补丁包。

Google组织汇报关系:

       划分不同的专注领域:客户端、地理、广告等(开发工作汇报给这些专注领域的管理者)。

       测试是独立存在的部门:工程生产力团队

  • 以租借的方式进入产品团队:

1)      做提高质量的相关工作,或者公开一些不可接受的缺陷率数据;

2)      不是直接向产品团队进行汇报,不能因项目急需发布就能通过测试(可以事先协商。有自己选择决定的优先级,在可靠性、安全性上的问题不会妥协);

3)      可以让SET和TE保持新鲜感和忙碌,一个好的想法可以快速在公司内部蔓延

  • 会根据不同产品团队的优先级、复杂度,并与其他产品实际比较之后,再来分配测试人员(可能会搞错,但总体上来说会保持实际需求与不明确需求之间的某种平衡)。

 

    四、爬走跑

1、Google产品经常在最初版本里只包含最基本的可用功能

在后续的快速迭代中得到内部和外部用户的反馈。

每次迭代都非常注重质量。

产品发布前,会经历金丝雀、开发、测试、beta或正式发布版本。

2、金丝雀版本

每日要构建的版本(核心开发团队成员都会安装):

       这个版本可能无法使用应有的基本功能;

       安装了错误代码,手机甚至无法使用基本功能;

用来排除过滤明显不适宜的版本:

       构建失败,意味着流程可能出现严重问题

3、开发版本

每周发布,该版本有一定功能并通过一系列测试:产品相关工程师会安装。

不能满足日常真实工作需求,会打回金丝雀版本:工程团队会花时间重新评估。

4、测试版本

通过了持续测试,近一月里的最佳版本。

有持续的优良表现,会作为beta测试的候选版本。

5、beta或发布版本

对外发布的第一个版本:经历了内部使用和通过所有质量考核。

 

五、测试类型

使用称谓:小型测试、中型测试、大型测试。

强调测试的范畴规模而非形式;规模越小,越可能被实现成自动化的测试。

1、小型测试

验证一个单独函数或独立功能模块的代码是否按预期工作。

一般是自动化实现:

       几秒或更短的时间就能运行完毕。

       SWE实现,也会有少量SET参与。

使用mock,在fake(虚假实现)环境中运行。

2、中型测试

验证功能模块间的交互和彼此调用时的功能是否正确。

通常也是自动化实现:

       独立模块开发完后,SET会驱动这些测试的实现及运行,SWE会深度参与,一起编码、调试维护这些测试。

       运行失败,SWE会自觉去查看分析原因。

       开发后期,TE会通过手动的方式或自动化执行这些用例。

一般运行在虚假实现(fake)环境或真实环境中。

3、大型测试

涵盖多个模块,关注所有模块的集成,倾向于结果驱动,验证软件是否满足最终用户的需求。

或是通过自动化,或探索式测试:三种工程师都会参与;需要消耗数个小时或更长时间。

一般运行在真实环境中,并使用真正的用户数据和资源

版权声明
本文为[--D]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/mind18/p/13901104.html