Google软件测试之道:软件测试开发工程师
Posted 鎃鎃
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Google软件测试之道:软件测试开发工程师相关的知识,希望对你有一定的参考价值。
设计文档
项目发起人要做的第一件事情就是设计文档。
这是一个动态的文档。最早期的项目设计文档,主要包括项目的目标、背景、团队成员、系统设计。团队成员一起协同完成设计文档的不同部分。对于一些大规模的项目,需要针对主要子系统也创建相应的设计文档。在初期版本完成后,将来需要完成的工作清单也可作为项目路标。从这一点讲,设计文档必须经过相关技术负责人审核。作为SET,比较幸运的是在初期阶段加入了项目。SET在团队中有一个巨大优势,就是拥有产品方面最广阔的视野。通常代码复用和模块交互方面的设计会由SET来做,而不是SWE。
SET需要熟悉了解负责的系统设计,作为第一个审阅所有设计文档的人很了解项目整体,也有助于在在项目初期与开发工程师建立良好的工作关系。如何审阅?要点有:完整性,正确性,一致性,设计,接口与协议,测试。在SET与相应的SWE一起沟通文档的审阅结果时,关于测试工作量以及各个角色如何共同参与测试,会有个比较正式的讨论。
接口与协议
SET是第一个实现所有接口和协议的人,在系统真正搭建之前,集成测试的运行依赖于这些接口实现。为了能够尽早开始做集成测试,SET针对各个模块的依赖提供了mock或fake的实现。在任何阶段,集成测试总是依赖mock或fake,因为有了它们,一些依赖服务的期望错误场景和条件异常,比较容易产生。
自动化计划
尽早提供一个可实施的自动化计划,SWE不会被一个无所不包的设计所吸引,计划必须合情合理。规模更小且目的性更强的自动化,并存在测试框架,会吸引SWE一起参与测试。常见错误是在端到端的自动化测试上过度投入,会把你与产品特定功能设计绑定一起,这部分测试在整个产品稳定之前都不会特别有用。在google,SET用下面的方法:先把容易出错的接口隔离,针对它们创建mock和fake,控制接口之间的交互,确保良好的测试覆盖率。接下来构建一个轻量级的自动化框架,控制mock系统的创建和执行,把修改的代码提交之前运行相应的自动化测试,确保测试通过后才能被提交。SET除了自动化(mock,fake,框架)外,还要使用报表和仪表盘(dashboard)展示收集到的测试结果和测试进度。
以上是关于Google软件测试之道:软件测试开发工程师的主要内容,如果未能解决你的问题,请参考以下文章