一、背景
我们的测试工作经历了以下四个阶段。
第一阶段,产品需求评审完成,开发团队实现功能开发,然后草草提测,不写单元测试。测试人员进行人工测试,没有工具或系统做辅助,测试用例编写是在excel或脑图中呈现。这个阶段只对业务熟悉,开发只关注功能实现。
第二阶段,产品需求评审完成,开发团队实现功能开发,写自身功能相关的单元测试,组长review组内代码。测试方面,依然处于人工检测功能测试阶段,但开始有一些相关的小工具辅助测试。在两轮或多轮测试情况下,回归一直是一个问题,还有分支测试完成,主干回归的过程,测试环境、预发布环境、灰度环境、线上环境等测试回归效率很低,人工测试在这方面的不足格外明显。
第三阶段,随着业务的发展产品功能需要快速上线,同时系统技术不断迭代,质量也面临着从未有过的挑战,人肉战术不是长久之计。在此阶段部门做了很多改进,引入和开发了很多测试辅助工具,如项目管理工具、测试用例管理工具、BUG管理工具、自动发布系统、自动打包等。
- 搭建测试用例管理工具,方便编写及后期跟踪用例。一轮二轮测试人员如何分配;用例状态的管理是通过、挂起还是失败,一目了然。
- BUG管理工具,主要是给开发和测试人员使用,通过文字和图片结合的方式描述功能问题,减少了开发和测试的沟通成本。
- 项目方面也开发出项目管理工具,方便查看项目状态和人力资源情况,在项目中做到很好的呈现。
- 在此阶段我们开始研发UI自动化测试工具,直观的想法是减少人工测试成本,提高测试效率。
- 自动化部署系统让开发环境、测试环境、灰度环境和线上环境做到很好的隔离,每个阶段更清晰,避免相互干扰引起的问题。
- APP方面结合Jenkins可以实现自动打包,测试起来做到了开发和测试都以版本控制系统为主。
第四阶段,因为测试往往是最后一个环节,风险较大,“怎么实现降低风险提高人效,测试用例可以复用”变成了我们这个阶段的主要工作。之前的流程是开发完成提测,做一次冒烟。因为我们的产品是互联 金融APP,APP有服务端开发和前端开发,像web、wap、anroid、IOS等渠道,在研发过程中经常会出现以下场景:
- 需求只是项目中的一小部分,测试问产品要不要全量测担心这次需求的研发会影响到其他部分,就要求全量测试,于是测试的工期会拉得很长,拉长了需求的整个工期。
- 测试抱怨开发的BUG多,还有阻塞流程的BUG,需要等待开发解决BUG后才能继续测试,导致整个测试工期加长。
- 手工测试偶有疏忽造成漏测试的点,需求上线后,客户反馈BUG。
产品上线时间有deadline;测试时间长,挤占开发时间;测试人手不够;测试的准确性达不到要求…要解决这些问题,必然要做自动化测试方案。
针对业务和测试开发同事的特点,我们从单元测试、接口测试、UI自动化测试三个方面做了有效衔接和可持续使用的自动化测试方案。
服务端开发完成,接口测试开始介入。接口测试前期使用一些小工具,会在小工具里写一些脚本,来方便测试过程中的功能多次回归检验,是否有更好的方式来做这件事,于是我们搭建了接口自动化系统。之前测试是只对UI界面做功能测试,我们现在还实现了单元测试、UI自动化测试、接口自动化测试。
第五阶段,测试团队全部人员转型测开,部分成员处在人工测试和自动化测试的边界上,实际上我们一直在做内训,让团队整体能更快地转型成为一个测试开发团队。这个阶段对成员要求相对较高,主要技术语言是python,还要对基础的系统架构及运维知识有更多了解,团队内部正在开发测试项目看板、重写用例管理工具、升级接口自动化工具等,后期计划实现APP多设备管理及测试。还有一些测试没有提到,但也包括在主流程中,比如安全测试、兼容性测试、分辩率测试等。
目前项目的整体流程是这样的:
- 产品通过DM上传PRD,参与人员熟悉需求。
- 开需求分析会议,确定需求最终版。
- 需求定稿后,开发人员抽象基础功能、编写UI部分,测试人员通过testlink写测试用例。
- 测试用例编写完需要产品、开发、测试人员做测试用例评审。
- 开发人员根据测试用例,编写自己具体业务的单元测试用例。前端人员和自动化测试人员制定UI自动化测试点,定义好断言字典和模拟用户行为的方法名称,自动化测试人员编写自动化测试case。
- 开发人员开发的同时,接口测试人员根据接口文档,编写接口测试用例。
- 所有编码工作完成,开发人员单元测试通过后,进行接口测试验证,再进行UI自动化测试验证。UI自动化测试既要测试当前需求点,也要回归以往的case。
- 验证都通过后,手工测试人员介入。
- 手工测试完毕,自动化CASE反复测试通过的情况下,进行上线。
接下来分别介绍团队在单元测试、服务层自动化测试、UI层自动化测试的具体技术实现。
二、单元测试
单元测试是对代码实现逻辑做测试,整体项目环节比较靠前,所以成本最小也最有效,但对开发人员的综合能力要求较高。
前端代码中,用户交互的部分交给UI自动化测试,而作为业务基础的类和方法,适用单元测试,我们项目使用测试库mocha和断言库chai,配合开发工具WEBSTORM,可以非常方便地检测代码通过性。比如我们开发的公用方法叫tools.js,使用mocha来测试它的文件是tools.test.js,如下图:
进入页面的时候,会有
[外链图片转存失败(img-fXzL2lEV-1568690614341)(http://college.creditease.cn/resources/upload/image/20190916/1568603429155044977.png)]
测试工具抓取到riskPage,说明进入到了风险测评页。当用户勾选完选项提交问卷后,如果接口返回正确,前端代码如下:
3.2 技术选型
1)web框架:Flask
简述:Flask是一个使用Python编写的轻量级Web应用框架。
优点:
- 轻巧,相较于大型框架Django,flask更适合小型web项目。
- 简洁,不需要复杂的分层和逻辑,框架内建了很多功能。
- 入门简单,即便没有多少web开发经验,也能很快做出 站。
2)分布式任务队列:Celery
简述:Celery 是一个分布式队列的管理工具, 可以用Celery提供的接口快速实现并管理一个分布式的任务队列。
优点:
- 简单,熟悉了celery的工作流程后,配置和使用还是比较简单的。
- 高可用,当任务执行失败或执行过程中发生连接中断,celery会自动尝试重新执行任务。
- 快速,一个单进程的celery每分钟可处理上百万个任务。
- 灵活,几乎celery的各个组件都可以被扩展及自定制。
3)测试框架:Robot Framework
简述:Robot Framework是一个基于Python的、可扩展的关键字驱动的测试自动化框架,用于端到端验收测试和验收测试驱动开发。
优点:
- 门槛低,通过使用关键字驱动测试(KDT)方法简化了自动化测试过程,方便测试人员创建易读的测试。
- 易于扩展,可以自定义测试库。
- 功能全面,支持WEB测试、SSH、telnet、API接口多种测试方式。
4)UI测试库:SeleniumLibrary
简述:SeleniumLibrary是针对Robot Framework开发的Selenium库,它也是Robot Framework下最流行的库之一,主要用于编写Web UI自动化测试。
优点:
- 多浏览器支持,包括Firefox、Chrome、IE、Opera、Safari。
- 多平台支持,包括Linux 、windows、Mac。
- 多语言支持,包括Java、Python、ruby、PHP、C#、JavaScript。
3.3 平台架构图
[外链图片转存失败(img-0Uz6MkiF-1568690614366)(http://college.creditease.cn/resources/upload/image/20190916/1568603516316016410.png)]
[外链图片转存失败(img-rm7R5JHV-1568690614367)(http://college.creditease.cn/resources/upload/image/20190916/1568603528766035680.png)]
脚本中使用的关键字分为两种:引用的Library和resource。library为第三方库,resource为自定义关键字集合。Resource关键字给我们提供的是一种类似于“函数”概念的用户自定义机制。我们可以将一些通用的业务过程封装为一个关键字。在编写测试用例时直接调用。一旦业务过程发生变化,我们只需要更改关键字中的业务逻辑即可,而不必更改每个测试用例。编写自定义关键字需要考虑它的健壮性、合理性,所以在任务的分配过程中这部分的编写都是由具有一定编程思想的测试人员实现的。
[外链图片转存失败(img-csuituqi-1568690614369)(http://college.creditease.cn/resources/upload/image/20190916/1568603541487037375.png)]
4)UI测试脚本运行
测试执行需要选择脚本、测试环境和Mock地址(可选)。运行过程中可以实时查看任务队列中的执行状态和历史任务的测试 告。
四、接口测试
接口测试主要的作用是提前降低风险,不至于等到APP端开发完成才发现问题,越往后时间成本和开发成本越高,风险越大。在多团队协作项目工期紧张的情况下,发现较大问题再调整产品需求几乎是不可能的,此类问题很消耗团队士气,团队被突如其来的问题影响,很容易被打乱节奏。在服务端开发完成提测,服务端测试可以有效拦截到一半左右的问题,很大程度降低风险,提高人效。
在我们的项目中具体实施步骤如下:
- 产品通过DM上传PRD,参与人员熟悉需求。
- 开需求分析会议,确定需求最终版。
- 需求定稿后,开发人员抽象基础功能、编写UI部分,测试人员测试用例。
- 测试用例编写完需要产品、开发、测试人员做测试用例评审。
- 开发人员根据测试用例,编写自己具体业务的单元测试用例。前端人员和自动化测试人员制定UI自动化测试点,定义好断言字典和模拟用户行为的方法名称。自动化测试人员编写自动化测试case。
- 开发人员开发的同时,接口测试人员根据接口文档,编写接口测试用例。
- 所有编码工作完成,开发人员单元测试通过后,进行接口测试验证,再进行UI自动化测试验证。UI自动化测试既要测试当前需求点,也要回归以往的case。
- 验证都通过后,手工测试人员介入。
- 手工测试完毕,自动化CASE反复测试通过的情况下,进行上线。
同样接口自动化测试也实现了web平台化,支持自动化测试全流程,覆盖测试环境管理、测试项目管理、测试脚本开发、测试执行、测试 告生成等流程。平台具有良好的扩展性、易维护性,支持异步执行、定时任务,能与企业邮件系统集成发送测试 告,同时在项目不断迭代的过程中,测试用例能弹性调整和复用。
4.1 技术选型
1)web框架:Django
简述:最流行的python web框架,采用了MVC的框架模式,提供全套的web开发解决方案。
优点:
- 功能完善,自带大量的常用工具,可以快速开发。
- 开源框架,有完美的文档支持。
- 自带后台管理系统,只需要几行配置和代码就可以实现一个完整的后台管理系统。
- 路由映射,具有完整强大的路由映射功能,使用正则表达式使路由配置更加灵活、简洁。
- App设计理念,App是可插拔的,不需要了可以直接删除,对系统整体影响不大。
2)分布式任务队列:Celery
简述:Celery 是一个分布式队列的管理工具, 可以用Celery提供的接口快速实现并管理一个分布式的任务队列。
优点:
- 简单,熟悉了celery的工作流程后,配置和使用还是比较简单的。
- 高可用,当任务执行失败或执行过程中发生连接中断,celery会自动尝试重新执行任务。
- 快速,一个单进程的celery每分钟可处理上百万个任务。
- 灵活,几乎celery的各个组件都可以被扩展及自定制。
3)测试框架:HttpRunner2.0
简述:HttpRunner是一款面向 HTTP(S) 协议的通用测试框架,只需编写维护一份YAML/JSON脚本,即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。
优点:
- 继承Requests的全部特性,轻松实现HTTP(S)的各种测试需求。
- 采用YAML/JSON的形式描述测试场景,保障测试用例描述的统一性和可维护性。
- 借助辅助函数,在测试脚本中轻松实现复杂的动态计算逻辑。
- 支持完善的测试用例分层机制,充分实现测试用例的复用。
- 结合Locust框架,无需额外的工作即可实现分布式性能测试。
- 极强的可扩展性,轻松实现二次开发和Web平台化。
4.2 接口自动化平台架构图
2)模块管理
按照待测接口所属功能模块进行创建,支持模块的增、删、改、查。创建模块必须指定所属的项目,在模块列表页面可以选择单个或多个模块运行。
[外链图片转存失败(img-iqmLgRFo-1568690614379)(http://college.creditease.cn/resources/upload/image/20190916/1568603688608085073.png)]
[外链图片转存失败(img-AF5aXSs7-1568690614380)(http://college.creditease.cn/resources/upload/image/20190916/1568603702408005066.png)]
4)配置管理
配置内可定义全局变量和全局hook,支持配置的增、删、改、查。
5)测试套件
通过测试套件,将服务于同一个测试目的或同一运行环境下的一系列测试用例有机的组合起来。支持测试套件的增、删、改、查。
7) 告管理
支持测试 告的可持久化存储,可以在线查看、下载和删除。 告基于extentreport实现。
[外链图片转存失败(img-gMFBaPJc-1568690614385)(http://college.creditease.cn/resources/upload/image/20190916/1568603794342018013.png)]
9)用例执行
执行方式分为同步和异步两种,可以按照项目、模块、用例和测试套件执行。手动触发需要选择运行环境和执行方式,定时任务执行支持添加项目级别和模块集合,遵循crontab表达式。

[外链图片转存失败(img-QwBRMD0e-1568690614390)(http://college.creditease.cn/resources/upload/image/20190916/1568618589426068167.jpeg)]
4.4 接口自动化测试架构图(引自官方文档)
[外链图片转存失败(img-mhIP7syS-1568690614391)(http://college.creditease.cn/resources/upload/image/20190916/1568603887832051288.png)]
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!