51Testing软件测试论坛

标题: 测试工程师不能不懂的迭代复盘之敏捷测试 [打印本页]

作者: lsekfe 时间: 2023-1-31 13:08
标题: 测试工程师不能不懂的迭代复盘之敏捷测试
随着这几年敏捷概念和方法的流行，越来越多的组织和项目选择了敏捷开发模式。那么对于测试人员来说，究竟敏捷测试与传统测试有什么区别？测试人员在一个敏捷项目中需要如何改变才能适应当前这种流行的测试模式呢？
　　一、敏捷测试的定义
　　1.什么是敏捷测试
　　“敏捷测试”既不是一种测试方法，也不是一种测试方式，而是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付，涵盖所需的、正确的价值观、思维方式、测试流程、一系列优秀的测试实践和更合适的测试环境、自动化测试框架和工具。
　　敏捷测试可以采用目前已有的各种测试方式、方法，包括手工探索式测试方式，接口自动化测试方式、UI自动化测试方式、边界值/等价类划分方法、组合测试方法等等。与传统测试相比，侧重点有所不同，主要的差别是在价值观、测试思维方式、流程和实践上。
　　2.敏捷测试宣言
　　与开发协作测试胜于测试分工与测试工具；
　　可运行的测试脚本胜于写在纸上的测试用例；
　　从客户角度来理解测试需求胜于从已定义的需求来判定测试结果；
　　基于上下文及时调整测试策略胜于遵守测试计划。
　　二、敏捷测试的特点
　　1.敏捷测试流程
　　（1）测试需求分析与定义
　　（2）测试计划
　　（3）测试设计
　　（4）BVT：版本验证测试
　　（5）持续测试
　　（6）版本验收测试
　　（7）测试交付与反思

图1：敏捷测试流程图

　　2.敏捷测试四象限
　　（1）第一象限：开发最熟悉
　　（2）第二象限：面向用户测试
　　（3）第三象限：面向业务，评价产品
　　（4）第四象限：跨功能性需求测试
　　（应该在开发周期的每一步都要考虑评价产品的面向技术的测试，而不是留到最后。不然，可能会太迟而不能修正这些问题。在很多情况下，这些测试甚至应该在功能测试之前进行，比如性能指标的不同，会驱动出不同的技术解决方案。）

图2：敏捷测试四象限图

　　三、为什么要敏捷测试
　　一个很直接的原因是如果整个项目都在采用敏捷开发模式，比如两周一个迭代，你还在跟项目谈传统的各个测试阶段，就好像两个不同转速的齿轮，根本无法结合。试问，两周时间能完成得了所有的测试阶段吗？所以必须要有新的测试实践来取代原有的模式，才能更好的适应敏捷小步快跑的特点。当然，除了适应开发的节奏外，敏捷测试还是有其特有的价值：
　　①缩短价值交付
　　周期通过采用敏捷测试这种模式，可以契合整个敏捷开发周期，使得整个敏捷开发按照相同而快速的迭代速率和周期交付，让最终用户尽快获取到业务价值；
　　②更早发现测试风险
　　敏捷测试使得测试人员尽早开始进行测试，尽早的发现系统缺陷或存在的问题，避免所有的问题都堆积在最后的测试阶段形成“Big-bang”的结果，降低整体系统风险；
　　③强调质量属于大家
　　质量是构建出来的，而不是测出来的。敏捷测试一直强调质量属于每一个人的责任，除了测试之外，开发、产品经理等都有义务对自己的交付件质量负责，这样才能确保项目的整体质量；
　　④化繁为简节省成本
　　敏捷测试没有要求需要详细的测试计划和测试文档，也没有定义繁复的测试流程及缺陷流程，这种轻量级的管理模式为测试人员减少不必要的负担，节省了工作量及成本。
　　四、如何测试才能更敏捷
　　1、需要敏捷测试的思维方式
　　（1) 成长性思维
　　测试人员需要具备成长性思维，相信我们自身的能力是可以通过培养不断成长的；面对挑战是拥抱而不是躲避；面对失败不是责备自己、同事，而是需要搞清楚为什么失败以及如何避免再次失败；要内心充满力量、充满自信。
　　（2) 团队对质量负责的思维
　　测试守护质量，提供质量信息，甚至帮助团队改善质量，自然是很有价值的，但是如果依赖测试来保证质量，那么其实是很难保证质量的，而且成本很高。应该让整个团队关注质量，从需求开始尽可能一次把事情做对，从而构建出高质量的产品，这对企业来讲更有价值——效率更高，成本更低。
　　（3) 上下文驱动思维
　　上下文驱动的思维是要认识到上下文是一直在变的，测试的策略和方法也要更具上下文及时调整、不断优化，尽可能达到更有效、更高效的测试状态。上下文可以简单地理解为项目所处的环境，以及所要满足的条件等，包括项目人员、风险变化、研发状态、质量标准等。
　　（4) 用户思维
　　用户思维的意思是要做对客户有价值的事情。
　　2、需要构建强大的敏捷测试基础设施
　　测试基础设施是支持测试运行、测试开发、测试管理，以及与研发环境集成的综合性平台。敏捷的目标就是要做到持续交付，尽快向用户交付满足需要的、有价值的软件，那么敏捷测试就离不开稳定、高效、准确的基础设施，以满足对于持续交付的需要。而要做到持续交付，需要做到持续运维、持续部署、持续测试、测试集成、测试构建。
　　● 持续构建，包括代码的编译、测试、打包等活动
　　● 持续集成，关注的是让代码能够工作在一起，以便开展进一步的测试。
　　● 持续测试，不等于自动化测试，一次迭代中的新功能特性的测试采用手工（探索式）测试更高效，回归测试尽量用自动化的方式持续验证新的代码和功能。
　　● 持续部署，就是按需部署，通过技术手段随时随地、快速地将软件包部署到各类环境（包括测试环境、准生产环境、生产环境）中，并确保系统可以正常工作。
　　● 持续运维，要实现全自动的监控、告警、故障定位和自愈，以及自动的数据收集、分析和处理。
　　● 持续交付，是一种能力，也就是说，能够以可持续方式，安全、快速地把代码变更部署到生产环境，让用户使用。
　　3、需要测试左移
　　测试左移是指让测试尽早开始，把测试活动左移到需求分析阶段，目的是及时发现研发前期的错误，避免将错误带到后面的研发活动中。测试左移通过持续地对产品需求和设计进行评审，及时发现需求定义和设计中的问题，加强单元测试、持续集成等。
　　4、需要测试右移
　　测试右移是指在生产环境中对软件进行测试，即把测试活动延伸到了运维阶段，包括在线性能测试，在线监控告警，安全性监控等。
　　五、传统测试与敏捷测试的区别

　　1. 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
　　2. 传统测试具有明显的阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告，一个阶段一个阶段往前推进，但敏捷测试更强调持续测试、持续的质量反馈，没有明确的阶段性界限。
　　3. 传统测试强调测试的计划性，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
　　4. 传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。
　　5. 传统测试关注测试文档，包括测试计划、测试用例、缺陷报告和测试报告等，要求严格遵守文档模板，强调测试文档评审的流程与执行等，而敏捷测试更关注产品本身，关注可以交付的客户价值。敏捷测试中，强调面对面的沟通、协作，强调持续质量反馈、缺陷预防。
　　6. 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

作者: oliver.tang 时间: 2023-2-28 10:16
敏捷是思路，不是流程

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)