敏捷(Agile)是一种软件开发模式,用限制时间段的方式,滚动周期地交付可用的软件,旨在灵活地应对改变,包括需求的改变、依赖的改变、计划的改变、团队的改变等等。敏捷开发模式相较于传统的瀑布模式而言,具有更高的灵活性,以交付价值驱动开发,而不是传统瀑布模式的以计划驱动开发。
在敏捷开发模式下工作的团队我们称之为敏捷团队,敏捷团队中测试人员和开发人员联系紧密,通常是同步工作的,注重即时沟通和质量内建,保证交付质量是每个人的责任。面对软件的缺陷,敏捷团队抱有更开放的态度。
敏捷测试
由于团队的工作模式和业务交付模式都不同,敏捷开发模式下的软件测试与传统软件开发模式下的测试也有所不同。
敏捷测试的核心是质量内建,简而言之就是软件的质量不是测试人员测出来的,而是全团队共同创建出来的。所以在软件开发的全过程都应该有提高质量的思想和行动,包括在需求阶段和生产阶段,都需要质量内建的思想。
测试在软件开发前期的介入叫测试左移,包括对需求的评审、预IPM、IPM,甚至单元测试、集成测试等。
测试在生产阶段的介入叫做测试右移,也叫做生产环境的QA(QA in Production),主要包括三个方面:生产环境的测试、监控告警、用户反馈。
将测试左移、敏捷测试、测试右移结合,并在软件开发过程中,注重测试人员与开发人员的沟通协作,合理管理缺陷,就是DevOps,也是全程软件测试(朱少民老师的《全程软件测试》)。
测试分层
分层测试体系也叫做测试金字塔,一共将测试分为三层,每一程的面积代表了建议该种测试的量。
最底层,也是建议最大量来做的是单元测试。由于单元测试的运行速度快,修复成本低,在CI中单元测试是代码合并强有力的质量保障关卡,所以单元测试的覆盖率越高,越能把多数缺陷扼杀在最初,用最低的成本修复。
中层,服务测试。“服务测试”这个名称不太表意,测试金字塔的中层目前有很多人进行了各个方面的解读,最常见的是说中层包含了集成API测试、web API测试等。中层的测试种类非常多,界定也不用太纠结,往往根据软件系统的需要,将需要团队较大量来维护的测试放在这一层。
上层,包含UI测试、探索性测试或手动测试。目前UI测试工具发展已经可以做到UI测试的持续维护,所以也有很多人不认同UI测试继续处于测试金字塔顶层。金字塔顶层主要是指发现缺陷修复成本高、测试执行慢、结果反馈慢以及大多数需要手动操作的测试。敏捷测试建议尽量减少这种测试,依靠增加底层和中层的测试来减小缺陷的修复成本,加快测试反馈时间。
敏捷测试四象限
Q1: 包含单元测试、组件测试、集成测试等。一般要求采用自动化方式,并且根据测试分层的理念,应该是要覆盖面最广,运行频率最高。
Q2: 包含功能测试、用户故事测试等。主要基于实例,并且采用手动+自动的方式,保证迭代交付业务的功能运行正常。
Q3: 包含探索性测试、可用性测试,以及用户验收测试等。主要采用手动的方式,关注产品在交付功能之外的其他表现,注重产品是否完成了业务价值的交付。
Q4: 包含性能测试、安全测试以及其他的“非功能性”测试。一般需要采用专业的工具,对产品的功能性之外的方方面面进行评估,根据不同的产品有不同的要求。
Q1和Q4对执行人员的技术能力要求比较高,需要一定的代码能力、计算机网络知识和底层实现理解。
Q2和Q3对软件所交付的业务价值比较关注,也是软件的Owner关注比较多的部分。
需要注意的是。敏捷测试的四象限并不是按照时间来排序的,并不是说软件交付的前期Q1的测试比较多,后期Q4的测试比较多,而是根据产品的性质和需求,在软件开发的各个阶段都按需进行。比如有一些产品的性能需求非常高,像一些电商网站,在支付、下单等业务上,软件的性能表现直接影响到功能、业务,具有非常大的影响力,所以在开发早期就要关注Q4的测试。
根据敏捷测试四象限制定测试策略
制定测试策略是测试人员职业生涯需要一直学习与精进的技术,需要质量维护、缺陷检查、保障功能交付和凝聚团队能力等等各方面的大局观。
一般来说,测试策略主要围绕三个问题:what、how、why。即:
1、测什么
2、怎么测
3、为什么测
其中what和how,即测什么和怎么测这两个问题,会在测试策略中被重点关注。
敏捷测试的测试策略可以根据测试分层体系和测试四象限的指导来制定,测试人员可以借测试策略在产品开发之初跟团队约定质量内建的团队公约,由此来提高团队的质量内建意识,提高软件交付质量。
简单的测试策略中应包括以下测试级别:
1、单元测试(完成人、使用工具、覆盖面要求、运行频率要求)
2、接口测试(完成人、使用工具、覆盖面要求)
3、回归测试(完成人、运行时间、运行频率、回归测试列表维护)
4、探索性测试(完成人、运行环境、测试时间、覆盖范围)
5、验收测试(完成人、测试时间、通过标准)
6、性能测试(完成人、性能指标、工具、测试频率)
7、冒烟测试(完成人、测试运行时长、通过标准、测试内容)