一个项目的自动化测试实践-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

一个项目的自动化测试实践

技术小菜鸟 2016-06-21 11:03:45 4033
项目上线,有时间总结一下当前的项目,对自己而言,一直是一个学习的过程。本篇总结我们的测试实践。本文分5部分,分别是:项目背景、系统架构与模块划分、我们的测试实践、自动化测试在项 目中的价值与对自动化测试的进一步思考。


  一、项目背景


  所有对项目的介绍一定是从客户开始。


  客户:我们的客户是一家全球领先的时尚内容提供商,通过遍布全球的员工,客户每天获取大量关于时装发布、产品设计、街边流行、城市热点等信息,这些信息的绝大部分以图片的形式上传到 公司服务器,然后由专职编辑对这些图片进行整理和归类(打标签),最后再由设计人员根据这些信息书写分析报表。


  关键内容:分类细致的海量高清图片和具有前瞻性的分析报表。


  商业模式:网站,行业内用户订阅-付费。


  客户面临的问题:同质化竞争、客户流失。


  新系统的关键词:CMS、更精确的内容分类、更好的全文检索、更好的用户体验(更有表现力的内容展现)、更快的内容发布。


  二、系统架构与模块划分


  1、REST的架构风格


  系统采用了Sling作为WEB框架,JCR作为了底层内容存储框架。


  系统的特点:


  URI唯一标识资源


  通过URI能够直接映射到JCR节点,例如http://localhost:80/content/section/news.html能够映射到JCR里的/content/section/news节点


  GET/POST/DELETE标准方法对资源进行操作


  支持标准方法对资源的直接操作


  资源的多重表述


  服务器端的无状态


  通过JS获取当前用户信息并缓存在客户端。


  2、系统分层


  系统分为四层:JS、Servlet、Domain Model和JCR。


  因为JCR提供了一套节点模型,所以Domain Model是在节点模型上的行为增强,例如所有对图片节点的操作我们封装在Asset领域模型里。





  3、程序划分


  程序分为两个大的模块:Migration和Bundles。为什么叫Bundles?因为Sling使用了OSGI框架Felix。


  Migration负责导入客户的遗留数据到新系统。之前客户的CMS运行已有10多年的时间,积累有大量数据。主要是各种类型的报表和图片。


  Bundles实现系统功能。主要包括了定义报表模板、定义报表各种所见即所得的展现组件、实现对图片的管理、搜索(包括基于图片的可视化搜索)和其他七七八八。


  三、测试实践


  1、Migration的测试


  自动化测试


  对Migration,我们采用了TDD的方式。


  输入是客户实际提供的xml文件,输出是JCR里的节点。测试环境的搭建主要是在本地建立起Jackrabbit实例。我们的工作方式是这样:每天早上领到一张migration故事卡,然后先写一个xml到jcr 节点的集成测试描述出该类型报表的功能需求,接下来就是让这个测试通过。经过开始阶段的熟悉过程,我们的速度保持在一对Pair一天一种报表类型的导入。


  手工测试


  将xml文件内容正常解析并导入JCR只是第一步,第二步我们需要在Bundles里为该类型的报表编写模板使之正常展现。由于涉及到报表样式,这个测试我们采用手工测试,这个工作也是QA工作的重 要一部分。


  在最开始的开发中,我们没有导入所有报表数据进行测试。这带来了问题,由于客户遗留数据跨越10多年,各种数据形式都可能存在(特别是04年以前数据,给 UI带来了很大挑战),而最开始的开 发中,我们只是使用了部分数据(09、10年数据)进行测试,这个导致了建立UAT环境时程序的很多返工以及QA的测试压力。


  2、Bundles的测试


  自动化测试


  对领域模型,我们采用了TDD的方式进行单元测试;在本地Jackrabbit实例里建立数据,领域模型封装数据测试行为。


  对servlet,我们采用了TDD的方式进行集成测试(同时测试了servlet和领域模型),在测试中对request和response进行mock; 对JS,我们使用数据驱动的selenium功能测试进行覆盖。





       我们最后的自动化测试结构:






  手工测试


  手工测试内容主要是功能测试。


  自动化测试价值低的部分我们采用手工测试,这部分内容包括报表模板,相对独立,内容不多,一次测试处处通过;


  自动化测试成本高的部分我们采用手工测试,这部分内容包括报表展现组件的编辑功能,因为采用了Ext JS,所以自动化测试困难;


  无法自动化的测试:报表在线生成PDF,报表样式,WEBDEV批量上传图片等;


  我们与QA的约定:


  每完成一个用户故事,我们会与QA、BA一起mini showcase;


  QA验收完成后编写功能测试用例;


  我们对QA编写的功能测试用例进行自动化,共同维护一个功能测试列表;


  对于不能自动化或自动化价值不高的测试用例QA继续使用手工测试。


  四、我们感受到的自动化测试价值


  1、通过自动化功能测试,我们使得需求对客户可视化;


  2、QA的回归测试成本降低,尽管目前频繁的向客户实际使用环境部署,但QA每次部署只需要做一些简单的冒烟测试;


  3、测试即需求,这点在TDD的开发过程中感觉非常明显,今天开发的目的就是使这个测试通过,避免了频繁部署到应用中进行测试,最快的电梯不是速度最快的电梯,而是中间停的楼层最少的电 梯;


  4、与持续集成一起,及时反馈。这点在进行JS代码编写时,心理上都非常依赖于selenium测试,对于没有测试覆盖的地方,没有安全感;


  5、足够的单元、集成测试保证了频繁重构,没有人愿意引入BUG,没有足够的测试,没人愿意重构;


  6、测试即文档,良好的测试和命名,使得新加入的成员非常容易理解当前代码的功能。


  五、思考和讨论


  1、自动化功能测试做到多少才合适?


  当然是越多越合适,问题在于自动化功能测试成本要大大高于单元测试和集成测试,这些成本反映在测试环境的搭建、数据的准备,需要准备其他很多关联数据例如用户信息和权限信息、自动化 功能测试的运行时间长、稳定性(随机成功/失败)、编写等等,需要权衡成本与收益。


  个人认为,自动化功能测试需要考虑的着重点包括:页面是否包含大量功能交互性JS(与展现性JS相对)?当前功能是否与其他功能共享一些代码?即独立性,独立性越低越需要着重覆盖(这里又涉及 到另外一个问题,即从各个模块里重构出共用代码是否总是合适?)。QA每次冒烟测试时是否需要重复回归(重复回归次数越多,自动化越有价值)?经常失败的测试一定比不失败的测试价值更高?或者从 未失败过的测试就没有价值?


  2、单元测试?功能单元测试?


  TDD的测试粒度多大才合适?从我个人而言,几乎天然的反对mock,为了满足测试覆盖率的追求,强制将两个联系很紧密的类分开,做出各式各样mock,这真让人气馁;stub也不是什么好东西,在一 个曾经的spring项目里,在测试目录里,一堆一堆的测试xml配置文件让人有种呕吐的感觉。那就做集成测试吧,两个类关系很好,那么就整体测试它们的输入和输出,看起来很不错,功能实现了,测 试也没多写,也不用准备太多其他东西,但是打开实现代码,你就发现那个丑陋,到处是复制和粘贴,是啊,不管黑猫白猫抓住老鼠就是好猫,只关注了当前结果,完全失去了TDD驱动简单设计的好处


  3、测试的重点是测试用例的设计,它反映出对需求的理解


  那么结论就很明显,我们如果连需求就没有理解,如何进行实现,所以测试驱动是很自然的。


云效平台官网地址:http://yunxiao.aliyun.com/


(本文来源:领测软件测试网)
XML JavaScript 数据可视化 Java BI 测试技术 持续交付 数据格式 网络架构 Spring
分享到
取消 提交回答
全部回答(1)
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

推荐文章
相似问题
推荐课程