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

发表于:2015-03-31来源:uml.org.cn作者:ronghao点击数: 标签:自动化测试
我们最后的自动化测试结构: 手工测试 手工测试内容主要是功能测试。 自动化测试价值低的部分我们采用手工测试,这部分内容包括报表模板,相对独立

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

  手工测试

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

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

  自动化测试成本高的部分我们采用手工测试,这部分内容包括报表展现组件的编辑功能,因为采用了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://www.uml.org.cn/Test/201006281.asp

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)