上周我们探讨了敏捷开发模式的质量管理模型，敏捷开发其最大特点就是高度迭代，有周期性。在敏捷开发模式下，作为一名测试人员，如何去理解敏捷模式呢？又如何从传统开发模式迁移到敏捷模式呢？面对敏捷模式下快节奏的迭代，测试人员也要不断学习，不断思考，如何能更好的把控产品质量，踩准项目节奏？
敏捷测试不是具体的测试方法，不是黑盒、白盒、自动化测试，而是在测试人员具有一定测试技能的基础上，并对项目特点和业务背景有深入的了解后，得出来的一整套项目测试解决方案，由此形成一个特定的测试流程。
正如一百个观众眼中有一百个哈姆雷特，一百个人看敏捷测试就会有一百种看法。根据项目的不同，敏捷测试的方法也不尽相同。
在一个敏捷项目的sprint中，测试人员的工作内容主要分五个部分：需求评审、user story 分析、测试用例设计、新功能测试执行、回归测试。
敏捷项目每次迭代的新功能中，如何提高测试效率呢？
测试人员在敏捷测试中应该更积极主动的参与到PRD评审中去。与传统的开发模式不同，敏捷开发由于迭代周期短，产品PRD可能写的并不是很详尽，测试人员需要在PRD评审会前先浏览PRD，理解需求，将有疑问的需求及时记录下来，在PRD评审会上提出。对于认为不合理的需求也要和产品进行沟通。
敏捷的一个重要特点就是变化，作为测试人员也要积极拥抱变化。在项目中遇到需求变化，需要以积极的心态去面对，及时评估影响，提出潜在风险。测试人员对于需求变化需要做好记录，同时对测试工作进行相应的调整。
敏捷测试是不断确认用户需求得以圆满实现，因此，对于需求的分析和理解要一直持续下去，发现有偏差及时与产品讨论。
对于story的分析，如果发现story有遗漏或者和PRD中不同时，也要及时提出。
Story的拆分要遵循独立性、可协商、有价值、可评估、短小和可测试的原则，测试人员在story分析过程中用这个原则来检查story颗粒度，如有疑问，应及时提出。
我们约定测试人员需要给每个story添加提测的冒烟测试用例，冒烟测试用例通过才能达到提测标准，以此来提高提测质量。
与传统的项目模式不同，快速迭代及变化的项目模式，留给测试人员的测试用例开发时间不多了。
敏捷测试中，根据迭代具体情况的不同，测试用例的设计可以不拘泥于形式。在保证各个功能点被覆盖的前提下，测试用例可以通过思维导图、测试要点描述等方式实现。
对于功能简单的story，可以在验证功能的基础上进行探索性测试；对于流程逻辑复杂的story可以先梳理出流程图，根据整理出的流程路径设计测试案例。
敏捷方法中，往往将一个大的系统开发分解成多个小的模块，这样集成测试和端到端测试就会显得更为重要。
在完成本次迭代模块功能点全覆盖测试后，需要加强对系统的流程性测试及场景测试，尽可能把精力集中到模拟用户的真实操作上来，实施更多的探索性测试、组合交互性测试和用户场景测试，更有效地发现埋藏较深的缺陷。
测试执行阶段，不只是测试用例的执行还有测试反馈，测试人员可以通过每日的站立会了解开发进度，汇报沟通测试进度和bug情况。遇到bug不收敛或者重复打开的情况，需要及时提出，以督促开发查找原因。考虑到整体的质量，需要对开发在单元测试上提出一定要求，以保证功能的可测试性。
回归测试是敏捷测试中需要面对的难点。
经过十几次、甚至几十次的功能迭代，产品功能可能已经非常多，版本的整体回归也会变的非常大，而回归测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试。
以计费项目为例，计费项目的最主要功能是计费，在计费账单正确的基础上实现运营、财务的功能。对于计费项目来说，正确快速的生成账单是基础。对于这样的模块，理所应当的考虑自动化实现，此功能测试的难点在于前期数据的铺设。不过好在铺设的数据可以重复使用，这就为自动化实现此模块的功能提供了极大的便利。在实际应用中，目前我们实现了95%的产品的计费覆盖，并备份了数据，新产品也会在功能测试完成后立即补充，大大减少了测试成本。
如果在全量回归测试不能实现的情况下，如何确认回归范围呢？
测试人员可以从以下几个方面考虑：
通过code Diff了解代码变更的内容，关联分析修改代码涉及的功能模块，调用情况等确定回归范围；
评估本次迭代的功能，对其他无关联功能只做主流程回归以减少回归测试的工作量，节省时间。
如何在敏捷测试中做得更好、走的更远呢？我们可以在实现测试自动化的基础上进行持续集成。
代码集成通过自动化构建，在构建过程中要尽快检测集成错误，避免开发代码集成的冲突；在正确构建完成后，自动运行回归测试自动化脚本，以确保新功能的代码提交没有影响到原有的功能实现，极大程度上提高新代码的可测性。另外可引入测试覆盖率的统计，从类覆盖率，行覆盖率等方面统计测试覆盖程度，补充和完善测试用例，确保测试执行的广度和深度。
每个迭代对于需求，进度，成本的目标和策略是不同的，敏捷测试人员应该根据各迭代版本的情况合理安排测试计划，确定测试范围，编写合适颗粒度的测试用例，评估测试范围，并把沟通反馈时刻灌输在整个项目迭代之中，在每个版本后持续改进测试方法，保证每个迭代的质量。
长按左侧二维码关注
关于“零道书院”
我们是来自于中国平安集团旗下前海征信的fintech先锋团队。定期分享互联网金融的前沿技术，探讨热点专题。有料！有态度！欢迎关注。
（部分图片来源于网络）
信用·让你我更好互联
看你靠不靠谱，点击阅读原文测分
