测试开发与自动化测试专家的一些想法

    碰到一个在想法上不一致的面试官，有感而发。

    面试官鉴于当前研发团队人数较少，当前只有两名手工测试，因此须要一名自动化测试转发把手工测试妹子从端到端手工解放出来。短时间内，须要自动化测试把用例用coding的方式跑起来，长期目标，是指望业务也能够经过天然语言的方式实现自动化测试。面试官也有一些简单的调研，知道cucumber 和 robotframework，多是指望用这个来实现目标吧。

    先说一下什么是TDD,由于吃透了TDD的概念对下文的说明的两个框架才会有更深入的体会，我试着从本身的角度说明下TDD, 对于我本身对这样思想能有新的理解。

    什么是TDD? Test Driven Develop

    测试驱动开发，又能够根据测试类型分出不一样派别，包括UTDD(Unit Test Driven Development), ATDD(Acceptance Test Driven Development), BDD(Behavior Driven Development) 和CDCD(?)(Consumer-Driven Contracts Development)。

    能够理解为开发未动，测试先行。在充分理解需求及程序的输入输出后，就能够开始编写测试代码，意味着不管后期代码如何变化，只要需求不变，程序的输入输出没有变，同一用例能够反复进行测试，这是敏捷思想的一种实践。

    如何实践TDD? （此处引用维基百科 https://en.wikipedia.org/wiki/Test-driven_development）

    1. 写一个测试用例。

    2. 执行全部的测试用例并确认新增的测试是否失败。

    3. 开发。

    4. 执行全部测试用例。

    5. 修改代码。

    重复执行上述步骤直到产品交付。

    Kent Beck（TDD 概念提出者）同意将问题拆分红最小粒度，一次只关注一个问题，对于开发者来讲，其余问题均可以经过mock解决，"Fake it till you make it"，他是这么建议的。

    OK, 接下来要说BDD和Cucumber了。

    

    BDD( Behavior Driven Development) 行为驱动开发是在测试驱动开发（TDD）的基础上的一种升级版。cucumber 是这一模式的表明框架（之一），ruby和java都支持。

    BDD是一组实践，用于缩短团队成员对于需求的理解误差，一般进行如下描述：做为用户A, 当我得到条件A, 而后我会获得结果B，隐藏条件是，若是没有获得结果B，用例失败。经过场景描述需求。Cucumber能够说是BDD这一思想的最佳测试框架了。

    Cucumber 项目结构：

    ProjectName

    -- features  文件以 .feature 结尾，用于描述用例集合,包含了feature,scenarios和step。

    -- scenario 测试场景，这里就是用来描述测试的执行步骤及比较测试结果了。

    scenario中主要拆分红步骤：

    GIVEN XXXX ENV;

    AS A USER A;

    WHEN  DO ACTION A

    THEN DO ANCTION B

    WHEN DO ACTION C

    THEN DO ACTION D

    THEN RESULT IS SUCCESS 

    对应的每一句，能够在step_definitions(从项目结构上来讲，做为具体feature的子目录)下的对应的ruby代码 xxx.rb中，找到对应的代码执行：

    Given (/^ XXXX ENV$/) do

    Browser.goto "http://example.com"

    end

    WHEN (/^ DO ACTION A$/) do

    Browser.text (:name, " go" ).click

    end

    THEN (/^ DO ACTION B$/) do

    Browser.goto "http://example.com/go"

    end

    THEN (/^ DO ACTION C$/) do

    Browser.text (:name, " goback" ).click

    end

    THEN (/^ DO ACTION D$/) do

    Browser.goto "http://example.com/go"

    end

    参考项目以下（说明下，国内的ruby开发者较少，java开发者比较多，因此这个demo是用java写的，实际上，ruby和java均可以完成同样的功能）： 

    https://github.com/Spillage/cucumber-demo

 

    什么是TestNG?

    TestNG是一个设计用来简化普遍的的测试需求的测试框架，从单元测试到集成测试都有较完善的支持，TestNG从JUnit和NUnit发展而来，故在JUnit中经常使用的注解在TestNG中也同样的使用。只是开发经常使用JUnit做为单元测试，而TestNG多用于集成测试。TestNG支持如下几种测试，单元测试/集成测试/功能测试，这几类测试均可以经过自动化实现。小小说明一下TestNG的关注点是代码的最小单元(Method)，而TDD关注的是需求拆分后的最小粒度的问题，二者的关注点不一致。可是TestNG的通用性很高，因此对于DDD( Data Driven Development) 或是UTDD甚至其余广义TDD 均可以支持，我的认为TestNG是一个通用性较高的测试框架。

    TestNG的项目结构：

    src/test/java  这是业务测试代码，加入TestNG的各种注解，用于管理用例集及其余。

    src/resources/testng.xml 这里用于描述用例的执行顺序及测试报告管理，能够理解为灵魂文件。

    运行TestNG。

    如下是一些TestNG的概念说明：

    suite是一组用例集，由xml文件描述。它包含一个或多个测试并被定义为<suite>标签。

    test是一个用例，TestNG经过@test 寻找被标记的测试方法。test由<test>描述并包含一个或者多个TestNG类。

    TestNG类是包含至少一个TestNG annotation的Java类，由<class>标签描述并包含一个或多个测试方法。

    参考项目：https://github.com/Spillage/testng-demo

    

 

    以上的长篇大论，只是为了说明Cucumber 和 TestNG是两个在设计理念上不一致的测试框架，Cucumber侧重行为驱动，而TestNG侧重集成，两者重点各有不一样，在使用场景上也会彻底不一致。首先，cucumber 对UI自动化测试用例设计的支持，有理念上的优点，action -> result 的导向易于编写出同一feature下的用例集；而 TestNG 淡化了 action -> result的概念，改成输入——输出，故在设计自动化测试用例的时候也会出现不同的方法。

    但若是说让业务测试同窗也能写出自动化测试用例，除了在cucumber feature集中封装外，还须要对自动化测试用例设计进行高度抽象，改成 输入——action——输出——result的逻辑，在这一步，不只仅是自动化专家能作的事情，也是测试开发须要作的事情了。