碰到一个在想法上不一致的面试官，有感而发。
面试官鉴于当前研发团队人数较少，当前只有两名手工测试，所以需要一名自动化测试转发把手工测试妹子从端到端手工解放出来。短期内，需要自动化测试把用例用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. 执行所有的测试用例并确认新增的测试是否失败。
4. 执行所有测试用例。
重复执行上述步骤直到产品交付。
Kent Beck（TDD 概念提出者）赞成将问题拆分成最小粒度，一次只关注一个问题，对于开发者来说，其他问题都可以通过mock解决，"Fake it till you make it"，他是这么建议的。
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的逻辑，在这一步，不仅仅是自动化专家能做的事情，也是测试开发需要做的事情了。