持续交付4-测试策略的实现

测试策略的实现

测试策略的设计主要是识别和评估项目风险的优先级,以及决定采用哪些行动来缓解风险的一个过程.良好的测试可以赋予产品交付质量信息和交付信息,同时还可以约束开发行为,全面的自动化测试套件还可以作为产品说明文档使用,提供全局的标准.

• 业务导向且支持开发过程的测试(第二象限)

第二象限的测试通常被称为功能测试或验收测试.验收测试确保用户故事的验收条件.在开发一个用户故事之前,就应该写好验收测试,最后在部署流水线中执行该测试.

用户故事:在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。

验收测试包含系统的所有方面,包括功能,容量,易用性,安全性,可变性,可用性等,推荐通过接口方式对于业务逻辑进行验收测试.因为页面显示比较灵活,自动化不易检测页面变化,同时也会让页面僵化.而第二象限关注的是功能方面,它只是验收测试的中的功能测试,其他的属于非功能测试,它们归于第四象限.

验收测试应该运行在类生产环境中.

回归测试:是自动化测试的全集,它用来确保任何修改都不会破坏现有的功能.它是跨象限的,所以未被任何象限记录.

针对验收测试的自动化,全方位的自动化成本会很高,也并不是所有的东西都需要自动化.比如易用性测试和界面一致性测试(涉及前端页面调整的,建议人工操作).所以自动化验收测试应该仅覆盖重要的用户操作的正常执行路径.一般我们将代码覆盖率高于80%的测试视为全面的测试.

自动化覆盖率标准:取决于你替换一部分功能后,执行自动化验收测试,你是否有信心可以保证服务可以有效运行.

实际验收测试可以测试的角度包括:

1. 应用正常执行逻辑,是否满足
2. 应用由于不同初始状态,动作,会形成不同的执行逻辑,它们是否有问题
3. 以上两点造成的异常处理

正常逻辑是核心,其他另外两点是可优化测试

• 技术导向且支持开发过程的测试(第三象限)

第三象限包含了:单元测试,组件测试,部署测试.

单元测试:用于单独测试一个特定的代码段.它不应该和数据库,文件系统,外部系统等外部服务交互.目的是验证业务逻辑是否正确,并快速得到反馈.这些测试应该覆盖系统中每个代码流程路径(最少80%).是回归测试的主要部分.

组件测试:用于测试应用系统不同组件间交互的功能.它一般被称为集成测试,但是这个表述范围不清晰.所以没被使用.因为组件测试涉及更多的准备工作和I/O操作,需要连接数据库,文件系统,外部系统等外部服务,所以执行速度会比较慢.

部署测试:用于检查部署是否正常.验证应用是否被正确安装,配置,外部服务是否正常.

• 业务导向且评价项目的测试(第一象限)

第一象限都是手工测试范围,它用于探索性测试,易用性测试和演示.都是针对业务需求的确认以及扩展的范围.很多网站使用真实用户来进行beta测试,用实际用户的反馈来判断功能的价值.通常这个过程是用户无感知的.通过一些金丝雀等方式来实现.还要类似于微信,钉钉也会有有一些实验室的功能,来提前让用户体验和反馈.

• 技术导向且评价项目的测试(第四象限)

第四象限是非功能验收测试.

非功能测试:除功能之外的系统其他方面的质量.容量,易用性,安全性,可变性,可用性等.但实际上这个概念是人为增加的,依据是功能是否直接面向业务.这也造成很多时候对于非功能性测试不重视,但是缺乏合理的容量规划,服务可能会经常无法使用,没有安全性的保障,用户也可能会直接放弃选择公司产品.这些都是和业务息息相关的.但是由于这种测试需要的资源以及验证周期都比较多,一般都比较靠后执行.同时执行频率也不太高.很多情形是在遇到实际的性能问题,才开始进行这类测试.如果应用比较复杂,就应该进行非功能测试.

• 测试替身

测试替身:运行时用于替代系统中一部分的模拟对象.用于控制应用程序对外部交互的行为.要注意具体测试替身的应用场景,避免滥用造成测试的脆弱性.

解决什么问题

测试价值:

1. 加快反馈
2. 减少测试人员工作负荷
3. 让测试人员集中精力做探索性测试和高价值活动,而不是一些不断重复的测试.
4. 保障产品质量,提供修改信心
5. 可以作为实时的需求文档

怎么做

• 新项目

一开始就要写自动化验收测试.

具体流程:

1. 选择技术平台和测试工具
2. 建立简单的自动化构建
3. 指定遵守INVEST原则的用户故事及考虑其验收条件.INVEST原则:Independent独立的,Negotiable可协商的,Valuable有价值的,Estimable可估计的,Small小的,Testable可测试的.

验收测试进行流程:

1. 客户,需求和测试人员定义验收条件
2. 测试人员和开发人员一起基于验收条件实现验收测试的自动化
3. 开发人员编码满足验收条件
4. 只要有自动化测试失败,开发人员都应该把它定为高优先级并修复它

验收测试的实施需要团队的共识,以及明确的需求,从一开始,测试人员就应该参与需求的梳理过程,确保整个系统的迭代中,他们支持一致性和可维护的自动化验收测试套件.

同时验收测试会规范开发人员行为,提供更好的封装,更清晰的表达,更清楚的职责分离和更多的代码复用.

• 进行中项目

大部分验收测试都是项目中进行的,下面是自动化测试切入点

1. 选择应用中最常见,最重要且高价值的用例切入
2. 只验证正常业务逻辑流程,同时范围要稍大于验收条件范围,这样可以减少一定的人工测试
3. 如果同一个功能多次重复测试,就需要进行自动化测试了
4. 如果同一个测试结果多次不正确,要沟通一下测试否还满足需求,不满足可以去除
5. 通过测试数据脚本来保障应用当前状态,请求的设定测试目标

• 遗留系统

一般这种系统都没有自动化测试,那你首先就要创建一个.

1. 自动化测试覆盖已有核心功能,来作为冒烟测试
2. 新需求都应该进行自动化测试.

遗留系统的自动化测试只在核心功能实现即可.应用程序可以划分为两部分:功能具体代码和支撑功能的框架代码.回归缺陷往往都是框架代码引起的,所以你将框架代码进行自动化测试即可.

• 组件测试(集成测试)

组件测试环境:

1. 在与真实组件交互的环境上测试
2. 在模拟组件交互的环境上测试

新组件对接要考虑问题:

1. 测试服务是否准备好?
2. 对接方是否能有效配合对接?反馈问题,修改缺陷,满足定制化需求
3. 是否可直连它们的生产环境,以便进行容量,可用性测试
4. 技术是否匹配?
5. 是否要编写或维护现有测试服务?
6. 异常情况我们是否能正常处理

测试相关书籍推荐