敏捷开发模式下测试策略-敏捷测试

jun · 发表于 2016-11-15 17:51:59

本帖最后由 jun 于 2016-11-15 19:45 编辑

敏捷开发模式下测试策略

持续交付，.......进行频繁的交付周期【2~5周】带来了更迅速的对产品的反馈和改善建议，以快速适应市场变化，主要分为自动化测试、持续集成，自动化部署组成... 3

敏捷测试模型... 4

Automation TESTING.. 5

敏捷测试原则

综述

在敏捷开发模式，往往传统以功能测试为主的测试难以适应新的角色，而敏捷团队也面临着产品质量和快速市场的压力，需要通过快速的迭代抢占市场，但另外一方面质量的问题，又可能导致市场丢弃，这时，测试应尝试调整测试的重心和方法，目标是做到敏捷测试，测试与开发并行，测试的重心更应移到后台的业务逻辑测试，并建立起新的测试模型，特别后端接口的自动化测试，有了自动化测试，我们所说的持续交付才有可能真正实现，在开展敏捷测试时，可以在各敏捷小组之上增加量个角色以保证产品质量和迭代的效率，一个测试开发角色，负责团队基础测试技术如性能测试，安全测试，负责测试工具、测试平台开发，测试实验室的建立；而另一个过程管理角色，则负责提升整个敏捷流程效率，梳理各环节的问题，对产品、开发、测试、运维的工作成果进行审计，促进设计、开发、测试、运维等角色密切协作，倡导3C【Card、Conversation、Confirmation】。

总的来说，敏捷测试的终极目的是为了持续交付，快速向市场交付可靠的产品；在敏捷开发模式下，迭代使得代码量逐步累加，越靠后的迭代我们所面临的整合测试压力、测试任务就越大；敏捷测试需要测试人员能够随时启动自动化回归测试对发布的迭代代码进行快速验证，以确保开发人员在进行新功能开发同时，未对已有的功能进行破坏。

过程管理角色

· 具备组织能力和过程管理

主导流程梳理与改进活动，进行流程审计，确保公司业务过程的先进合理性

· 具备较好的沟通能力和一定的洞察力

收集过程改进意见，识别业务流程中的问题并提出改进意见，定期审视现有业务流程，识别研发管理体系的改进机会，并策划和实施改进活动；促进设计、开发、测试、运维等角色密切协作

· 具备一定的审计及其稽核能力

针对产品、开发、测试、运维的工作成果进行审计和稽核

测试开发角色

· 具备独立性测试能力
独立分析业务需求，独立配置测试环境，独立编写测试脚本，独立开发测试工具，可以安排到敏捷团队进行敏捷测试，覆盖到整个测试范围。

· 具备较好编程能力和较好的学习能力
需要一定编程知识，不仅仅是脚本Python\ruby，要需要懂代码编程方面的基础，如Java，即会看代码，也会写代码，同时具备对一些常用测试工具的使用和学习能力

· 具备测试能力
要求基本的测试理论知识，熟悉相应的测试用例设计原则、方法

持续交付

持续交付，是在产品开发过程，从原始需求识别到最终产品部署到生产环境的各个环节，需求以小批量形式在团队的各个角色间流动，能够以较短地周期完成需求的小粒度频繁交付；频繁的交付周期【2~5周】带来了更迅速的对产品的反馈和改善建议，以快速适应市场变化，主要分为自动化测试、持续集成，自动化部署组成

· 自动化测试

如何能够保证我们写出来的代码既能准确实现我们的新功能，又能够不破坏已有的功能？而当我们开始追求频繁地甚至是持续地部署的时候，自动化测试是唯一的能够让我们持续反复地验证软件的方法。如果一个产品具有完备的自动化测试用例，那么任何一次对软件的修改都能够得到自动化地回归验证，如果验证通过，我们就具备了将这些修改部署到生产环境中的信心；自动化测试的质量直接决定了我们能否具有持续部署的信心

· 持续集成

一旦实现自动化测试脚本，则可以逐步实现持续集成，GIT、SVN上服务端代码的任何变化，都可以自动启动接口自动化测试，对于任何错误都即时通知相关人员，以尽早地发现集成错误；如果测试通过，则自动和前端【WEB、APP】进行集成测试。如果条件允许的话可以考虑Daily Build.

· 自动化部署

有了自动化测试和持续集成这两个作为前提，特别是靠自动化测试建立信心，借用各种工具实现高效自动化部署，就可以达到持续交付。

敏捷测试模型

敏捷测试应把接口，集成测试作为一个重点进行测试，以提升产品的稳定性和健壮性，并开展自动化测试；总体而言，各测试阶段都是相辅相成，增加底层测试覆盖面，尽可能减少上层测试量，降低整合后的测试压力，并做到尽早测试。

· UITESTING/OTHER
界面测试，即GUI 测试，基于表现层进行功能测试，理应重在页面展现的BUG，兼容性BUG，用例设计要主要典型用户场景的覆盖;OTHER主要是产品稳定后所进行的性能测试，安全测试，浏览器兼容性测试，机型兼容性测试等

· INTEGRATION/SYSTEM TESTING

针对后端API与前端页面，APP集成所开展的集成测试，用于发现集成的BUG，系统层面可以以此展开。

· API TESTING/UNITTESTING
接口测试。目前较多的是HTTP RESTFUL API，提供给前端APP或是页面进行集成，HTTP RESTFUL API涉及到所有的后端逻辑，接口用例编写从单接口道组合接口基本上可以覆盖所有的后端逻辑；UNIT TESTING一般应覆盖到核心业务，考量现在现在各模块的依赖，有些UNITTESTING难以执行，这层可以把测试的重心放在API级别的测试，如果有MOCK支持，对这两部分会有很大的帮助，再者，这两块测试相对稳定，适合自动化测试

Automation TESTING

主要是针对后端HTTP RESETFUL API开展自动化测试，辅之前端APP兼容性测试、稳定性测试，WEB的冒烟自动化测试，建议基于Xunit + FIT实现自动化测试，通过构建公司自有的测试平台，实现自动化测试用例的管理，测试报告收集，自动化测试执行。设计上要实现测试用例与测试代码的分离，测数数据与业务逻辑分离，提高自动化的可维护性、可扩展性，支持多种测试用例或数据的导入如EXCEL,WIKI,HTML TABLE，降低自动化使用门槛。

· 测试用例设计原则
自动化测试用例的设计思路主要体现在以正向的路径覆盖尽可能多业务场景，具体原则如下：

n 原子性、可复用，即每条用例都是可单独执行的最小单元，尽量减少用例间的依赖，依赖关系或是组合的测试用例尽可能归类

n 正向性，主要设计正向的测试用例，考量到ROI,因尽量少设计NEGATIVE的测试用例

n 可重复执行，回到原点，即每一套测试集【testsuite】都是可重复反复执行，如登录与登出归到同一个测试集，自动化测试运行完毕必须回到当前执行前的场景，并不产生脏数据

n 不需要每个点进行校验，通过某一关键词、正则的部分校验来校验整个的测试结果

n 测试用例本身的可读，易于大家理解和维护，同时测试用例本身也要逐渐的完善

· 测试代码、脚本
测试人员要学习脚本语言，进行测试开发编程，特别是自动化测试人员，整个测试团队需要逐渐参与自动化测试中，提升整个团队测试水平和测试技术。

· 测试集（Test Suite）的编写要满足不同测试类型的需要，如SMOKE TESTING、REGRESSION TESTING等等。

· 测试开员和开发人员进行深度沟通、互相学习
Automation TESTING不仅仅是测试团队开展测试。开发人员也应当借助于自动化测试，来切实提升拟交付测试的API接口的质量。

需要强调是，自动化测试不是一朝一日的功夫，关键是要建立起一套可以持续维护的自化测试体系；不然就走一批换一种自动化测试技术或工具，没有任何自动化的积累最终导致自动化测试的失败，早期的自动化投入也打水漂了。

敏捷测试原则

尽早测试是通过尽早暴露和发现系统存在的质量风险，来加快项目进度，减少全局测试成本，尽早测试又不仅仅限于代码级测试（单元测试和静态代码扫描），还包含未编码前的测试怎么做？对需求，架构和设计文档的测试，由于当前测试基本上偏黑盒、手工测试，这导致了很多架构层面的问题delay后期解决，极大增加产品的重工的成本，也是为什么后期很多敏捷团队重视应用架构和系统架构的原因，其本身也有缺少有质量的敏捷测试人员有关，或是没有意识到敏捷测试，另外因一线黑盒测试人员往往对需求或产品产品设计有较好的理解，但是因介入比较晚，往往是到代码测试阶段才发现需求阶段的产品或是设计上的BUG，具体原则如下：

· TestingEarly原则
尽早配置环境，尽早集成，尽早测试，开展代码级别的测试，如借助于findbug, checkstyle等工具做静态代码扫描

· Testingoften原则
经常进行迭代集成测试，这时候自动化测试的成本效益优势就体现出来了。

· Testingenough原则

从产品设计、需求分析开始，一直到线上运营、用户反馈，随时开展测试，收集测试问题或是用户反馈信息，制定相应的产品方案，确定个测试阶段的主要测试内容。