测试策略的实现
测试策略的设计主要是识别和评估项目风险的优先级,以及决定采用哪些行动来缓解风险的一个过程.良好的测试可以赋予产品交付质量信息和交付信息,同时还可以约束开发行为,全面的自动化测试套件还可以作为产品说明文档使用,提供全局的标准.
- 业务导向且支持开发过程的测试(第二象限)
第二象限的测试通常被称为功能测试或验收测试.验收测试确保用户故事的验收条件.在开发一个用户故事之前,就应该写好验收测试,最后在部署流水线中执行该测试.
用户故事:在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。
验收测试包含系统的所有方面,包括功能,容量,易用性,安全性,可变性,可用性等,推荐通过接口方式对于业务逻辑进行验收测试.因为页面显示比较灵活,自动化不易检测页面变化,同时也会让页面僵化.而第二象限关注的是功能方面,它只是验收测试的中的功能测试,其他的属于非功能测试,它们归于第四象限.
验收测试应该运行在类生产环境中.
回归测试:是自动化测试的全集,它用来确保任何修改都不会破坏现有的功能.它是跨象限的,所以未被任何象限记录.
针对验收测试的自动化,全方位的自动化成本会很高,也并不是所有的东西都需要自动化.比如易用性测试和界面一致性测试(涉及前端页面调整的,建议人工操作).所以自动化验收测试应该仅覆盖重要的用户操作的正常执行路径.一般我们将代码覆盖率高于80%的测试视为全面的测试.
自动化覆盖率标准:取决于你替换一部分功能后,执行自动化验收测试,你是否有信心可以保证服务可以有效运行.
实际验收测试可以测试的角度包括:
- 应用正常执行逻辑,是否满足
- 应用由于不同初始状态,动作,会形成不同的执行逻辑,它们是否有问题
- 以上两点造成的异常处理
正常逻辑是核心,其他另外两点是可优化测试
- 技术导向且支持开发过程的测试(第三象限)
第三象限包含了:单元测试,组件测试,部署测试.
单元测试:用于单独测试一个特定的代码段.它不应该和数据库,文件系统,外部系统等外部服务交互.目的是验证业务逻辑是否正确,并快速得到反馈.这些测试应该覆盖系统中每个代码流程路径(最少80%).是回归测试的主要部分.
组件测试:用于测试应用系统不同组件间交互的功能.它一般被称为集成测试,但是这个表述范围不清晰.所以没被使用.因为组件测试涉及更多的准备工作和I/O操作,需要连接数据库,文件系统,外部系统等外部服务,所以执行速度会比较慢.
部署测试:用于检查部署是否正常.验证应用是否被正确安装,配置,外部服务是否正常.
- 业务导向且评价项目的测试(第一象限)
第一象限都是手工测试范围,它用于探索性测试,易用性测试和演示.都是针对业务需求的确认以及扩展的范围.很多网站使用真实用户来进行beta测试,用实际用户的反馈来判断功能的价值.通常这个过程是用户无感知的.通过一些金丝雀等方式来实现.还要类似于微信,钉钉也会有有一些实验室的功能,来提前让用户体验和反馈.
- 技术导向且评价项目的测试(第四象限)
第四象限是非功能验收测试.
非功能测试:除功能之外的系统其他方面的质量.容量,易用性,安全性,可变性,可用性等.但实际上这个概念是人为增加的,依据是功能是否直接面向业务.这也造成很多时候对于非功能性测试不重视,但是缺乏合理的容量规划,服务可能会经常无法使用,没有安全性的保障,用户也可能会直接放弃选择公司产品.这些都是和业务息息相关的.但是由于这种测试需要的资源以及验证周期都比较多,一般都比较靠后执行.同时执行频率也不太高.很多情形是在遇到实际的性能问题,才开始进行这类测试.如果应用比较复杂,就应该进行非功能测试.
- 测试替身
测试替身:运行时用于替代系统中一部分的模拟对象.用于控制应用程序对外部交互的行为.要注意具体测试替身的应用场景,避免滥用造成测试的脆弱性.
解决什么问题
测试价值:
- 加快反馈
- 减少测试人员工作负荷
- 让测试人员集中精力做探索性测试和高价值活动,而不是一些不断重复的测试.
- 保障产品质量,提供修改信心
- 可以作为实时的需求文档
怎么做
- 新项目
一开始就要写自动化验收测试.
具体流程:
- 选择技术平台和测试工具
- 建立简单的自动化构建
- 指定遵守INVEST原则的用户故事及考虑其验收条件.INVEST原则:Independent独立的,Negotiable可协商的,Valuable有价值的,Estimable可估计的,Small小的,Testable可测试的.
验收测试进行流程:
- 客户,需求和测试人员定义验收条件
- 测试人员和开发人员一起基于验收条件实现验收测试的自动化
- 开发人员编码满足验收条件
- 只要有自动化测试失败,开发人员都应该把它定为高优先级并修复它
验收测试的实施需要团队的共识,以及明确的需求,从一开始,测试人员就应该参与需求的梳理过程,确保整个系统的迭代中,他们支持一致性和可维护的自动化验收测试套件.
同时验收测试会规范开发人员行为,提供更好的封装,更清晰的表达,更清楚的职责分离和更多的代码复用.
- 进行中项目
大部分验收测试都是项目中进行的,下面是自动化测试切入点
- 选择应用中最常见,最重要且高价值的用例切入
- 只验证正常业务逻辑流程,同时范围要稍大于验收条件范围,这样可以减少一定的人工测试
- 如果同一个功能多次重复测试,就需要进行自动化测试了
- 如果同一个测试结果多次不正确,要沟通一下测试否还满足需求,不满足可以去除
- 通过测试数据脚本来保障应用当前状态,请求的设定测试目标
- 遗留系统
一般这种系统都没有自动化测试,那你首先就要创建一个.
- 自动化测试覆盖已有核心功能,来作为冒烟测试
- 新需求都应该进行自动化测试.
遗留系统的自动化测试只在核心功能实现即可.应用程序可以划分为两部分:功能具体代码和支撑功能的框架代码.回归缺陷往往都是框架代码引起的,所以你将框架代码进行自动化测试即可.
- 组件测试(集成测试)
组件测试环境:
- 在与真实组件交互的环境上测试
- 在模拟组件交互的环境上测试
新组件对接要考虑问题:
- 测试服务是否准备好?
- 对接方是否能有效配合对接?反馈问题,修改缺陷,满足定制化需求
- 是否可直连它们的生产环境,以便进行容量,可用性测试
- 技术是否匹配?
- 是否要编写或维护现有测试服务?
- 异常情况我们是否能正常处理