测试平台对持续集成的支持(之三)——测试代码编写(二)

       前面讨论了测试代码编写的前三个环节：需求审阅，测试分析，用例编写。这一节简单讨论一下测试代码的编辑。


       提到测试代码的编辑，我们不得不先提自动化的分层测试。自动化分层测试的出现最早产生于传统行业，在互联网行业是近几年新起并实施的，业内分层形式也不止一种，目前基本的方法是分为三层：单元测试，接口测试，UI测试。每一层的测试相互独立，各有侧重，但测试覆盖面又相互重合。


       分层测试是必要的，每一层测试都有可轻易测出别的层难以测出的一些方面的问题。所以相信今后一段时间内，单元测试、接口测试、UI测试都会因为各自所在的投入产出比优势领域而继续存在。但同时分层测试在各自的覆盖面上又会有相当大的重合，比如某一层(UI)的测试做到极致，从扫除缺陷的角度，几乎就可以取代其他层的测试。所以在笔者看来，决定分层测试中的各个层的测试在项目实际测试中所占的比重固然有纵多的因素，但投入产出比应当是一个主要的考虑因素。从测试平台来看，未来哪一层的测试工具或框架能大幅提高这一层测试的效率和投入产出比，则这一层的测试比重相对于其他层测试而言将占有优势地位。那种仅仅因为持续集成的某一些开发模式而认为将来单元测试将会占据测试主流地位的观点笔者不敢苟同。


      也正是基于上述的原因，测试平台将立足于各种分层测试工具或框架的全面改造而不仅限于一种，并且测试平台将与这些工具尽最大可能的集成以突破单个孤立工具框架所遇到的效率瓶颈。各分层测试工具框架自由竞争，各线开发和测试人员可以结合自身产品线的不同而自主决定分层测试的比重。(需要说明一点，各种分层的测试工具或框架并不仅用于测试代码的编辑，还涵盖了测试代码的调试，执行甚至于维护，所以在后续谈到这些环节中还会涉及各种分层的测试工具或框架)。


      再回到各个分层测试中的测试代码的编辑：


      1. UI：UI的测试工具有很多，比如watir，selenium已经普及数年，但由于编写的工作量大且不宜维护为人所诟病，尽管业内有不少公司在其上做了许多封装和改进，但本质没有变。要希望UI测试能继续在分层测试中占有一席之地甚至于处于优势，就必须抛弃原有的框架的设计思路，做根本性的改变，比如页面录制就是一个方向，说起页面录制，业内就会提起QTP，QTP的问题很多，比如难以维护，但笔者认为这是QTP的问题而不是页面录制的错，采用页面录制的新思路却仍然用录制生成代码的老设计模式是捡了芝麻丢了西瓜，必须采用配套的新思路。目前云效平台已突破技术难点，开发出针对UI测试的页面录制，以及辅助的自动化测试代码维护，版本管理等众多重要的功能，在若干条产品线的测试人员中进行试用，效果不错。有望于在此领域大幅提效。


      2. 接口：目前云效平台已开发出辅助接口测试代码半自动生成的功能。已取得初步成效，在较大范围内的接口测试编写工作中能提效近一倍。但是能否进一步在技术上有根本性的突破，仍然在摸索中。


      3. 单元：目前测试平台对于单元测试的代码编辑提效仍处于初步接触期。


      除了上述分层测试代码的编辑之外，还有一些特殊测试需求所需要的测试方式也面临着提效问题，比如多浏览器测试，图片对比等等。尤其是图片对比，据笔者了解，已有一些兄弟公司开发出一些很不错的自动识别工具。


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