敏捷测试四象限、测试金字塔与分层自动化 | IDCF
DevOps
共 5579字,需浏览 12分钟
·
2020-09-23 14:57
来源:晨小菜 作者:陈晓鹏
一、敏捷测试象限起源
第 1 象限(Q1):面向技术、支持团队的测试 第 2 象限(Q2):面向业务、支持团队的测试 第 3 象限(Q3):面向业务、评价产品的测试 第 4 象限(Q4):面向技术、评价产品的测试
二、敏捷测试下象限介绍
主要是开发人员执行的测试 测试类型:单元测试/模块测试、集成测试 测试目标:验证单元模块被正确的实施 主要采用自动化测试的方式,例如在代码检入之前的频繁的自动化测试和重运行
主要是测试人员执行的测试 测试类型:功能测试、样例、用户故事测试、原型、模拟等 测试目标:验证一个功能或者用户故事根据验收标准被正确的实施 主要采用自动化为主,手工测试为辅的方式
主要是业务验收人员和测试人员执行的测试 测试类型:探索式测试,情景测试、可用性测试、用户验收测试、Alpha 测试及 Beta 测试等 测试目标:验证功能满足业务和终端用户需要 主要以手工测试为主,自动化测试为辅的方式
主要是测试人员执行,项目团队配合的测试 测试类型:性能/负载测试、安全性测试、其它非功能性“-ility”测试 测试目标:确定产品符合非功能性要求 很多测试需要借助测试工具来完成,主要是自动化加手工结合的方式
三、传统测试 V 模型的问题
单元测试更关注于模块内部的质量 集成测试更关注于模块之间的集成 系统测试更关注于整个系统的功能正确性以及是否满足需求文档 用户验收测试是从最终用户的角度关注是否满足最终用户的需要
一方面在敏捷中测试活动是融入到整个开发过程中而不作为单独的阶段,所以 V 模型这种按不同阶段划分的方式明显不适合敏捷测试; 另一方面在时间有限的情况 V 模型对各测试阶段需要投入多少精力并没有明确规定,所以导致有不少项目对于单元测试不重视,开发人员由于受到开发进度的压力,很多时候简单测试一下甚至是没有经过自测就提交给测试人员,从而让测试人员不得不花大量的时间来拦截缺陷,一不小心就成为“背锅侠”。
测试脆弱性:由于我们的自动化测试脚本集中在 UI 界面,而 UI 界面往往是最不稳定的部分。界面控件经常会发生变化,这对于 UI 端自动化测试脚本来说简直就是灾难。我们知道 UI 自动化测试是非常依赖 UI 界面的控件稳定,只要控件有变化,整个脚本就得重新调整和维护,否则脚本就会运行失败。所以自动化测试非常脆弱。 延迟可能性:由于我们在单元测试、集成测试做得不够充分,导致把风险留到了后面阶段,我们需要在后面的 UI 测试花大量的时间进行测试,这时发现缺陷修复缺陷的周期变得非常长而且不可控,从而大大提高了延迟的可能性。 复杂性:假如我们在单元测试、集成测试阶段没有测试充分的话,在 UI 界面测试时如果发现缺陷,那么对于缺陷的定位、诊断和分析都变得更加复杂。 成本:我们知道测试的一个定律,也就是越早发现缺陷,修复的代价越低。如果我们把一个缺陷留在后面阶段才发现的话,将会大大提升整个项目的成本。
四、测试金字塔介绍
五、分层自动化测试
六、测试自动化与自动化测试的区别?
所谓“自动化测试”,一般是指在测试执行过程中,通过自动化的工具或手段来代替人工执行的过程。它强调的是解决“测试执行过程”的效率; 而“测试自动化”,是指在测试领域中的任何方面都可以通过各种自动化的方式和手段来加快测试的效率,保证测试的质量,缩短软件交付的周期。所以它强调的范围是整个测试的过程而不仅仅是测试执行过程。比如说测试数据准备的自动化、测试环境搭建的自动化都可以包含在测试自动化这个概念里面。
七、测试自动化的目的
一是指我们如果通过机器来执行,机器不像人类一样,每天工作 8 小时。如果需要,机器可以 24 小时不间断的运行,当然也就可以利用晚上甚至是凌晨的时间来执行,而这个是人类所没办法做到的; 另一方面,随着虚拟化和容器的发展,我们可以很容易的部署多套自动化工具来进行脚本的执行。如果脚本量很大的情况下,我们可以通过容器部署更多的执行机来实现分布式执行测试,从而大大加快整个测试的速度、提升整个测试的效率。
八、增强的分层自动化
评论