敏捷开发（TWIST）
简介
原文地址：http://blog.csdn.net/Sherry_Pei/article/details/4233356
Twist（http://studios.thoughtworks.com/twist-agile-test-automation）是Thoughtworks Studio（http://studios.thoughtworks.com/）开发的又一款敏捷开发相关的产品。这是一个功能测试（Functional Tests，FT）的集成开发环境，将FT的自动录制，开发，维护，报表功能集中到同一个平台上。
一、自动化测试的痛处（Pain Point）
自动化测试将测试人员从无意义的重复劳动中解救出来。但是目前，功能测试自动化普遍遇到两个问题：
- 测试层次难把握
自动化测试，基本上是技术人员，也就是Dev们在开发。他们的确对技术十分精通，但往往陷入技术细节。如果进行功能自动化测试的开发，他们往往不能准确把握“功能测试”这个层次。而真正理解并掌握业务逻辑的，是Analysts，是BA们和QA们，他们更知道功能测试应该涵盖的范畴，他们往往更能够设计出更有价值的功能测试。但是，很遗憾，他们的开发功力往往不够。
- 测试代码难维护
我们为每个用户故事或功能点书写测试用例（Test Cases）和验收标准（AC，Acceptance
Criteria），依靠自动化测试和手工测试共同来验证这些用例和标准是否通过。在自动化测试中，很难将测试代码集与书写好的文档相关联，在代码注释中加入测试用例ID或AC标号显然是下下策。 - 测试涵义不好懂
即便敏捷Dev们将测试代码重构到极致，我们也无法将测试代码做为与客户业务人员交流的媒介。
二、Twist的着眼点
Twist和它的开发者认为：合作产生高效；测试是资产。
合作产生高效。Twist使Analyst们和Dev们合作开发功能自动化测试成为可能。精通业务逻辑的Analyst们掌握测试层次，精通技术的Dev们掌握开发细节，Twist给他们提供的高效的交流、合作开发的平台。它抚平了自动化测试的痛处1。
测试是资产。资产只能在有效的组织下才能发挥更大价值。Twist管理和组织下的测试，就是一组分类了的、简明易懂的且可执行的文档。这种管理结构下的测试代码，是团队中的任何成员都可读懂的，是易于与客户交流的，所以，也是价值最大化了的。它抚平了自动化测试的痛处2和3。
概念篇
原文地址：http://blog.csdn.net/sherry_pei/article/details/4283501
Twist用“测试情节”（Scenario）来组织和管理测试。每个测试情节中，包含一个或多个“业务工作流”（Business work flow）和“业务规则表”（Business rule table），这些“业务工作流”和“业务规则表”共享“测试上下文”（Context）。测试情节是可运行的，运行一个测试情节时，Twist将会把测试情节中所有的业务工作流或业务规则表顺序执行一遍。
一、Business work flow
业务工作流由名称（Name）和步骤（Steps）组成。从业务层面上讲，名称用以标识测试意图；步骤则类似于测试步骤说明，不同之处在于，业务工作流的步骤是可运行的。从技术层面上讲，Twist的代码转换器会将每个业务工作流转换为唯一的一个JAVA类，业务工作流的名称即为类名，而每个步骤则被映射为该类的公有函数。业务工作流被运行时，Twist的任务运行器（Task-Runner）会按照步骤的顺序去调用相应的函数。当任何一个步骤出错时，将终止整个业务工作流的执行。
例如，测试一个图书管理系统正常借书功能：
work flow 名: Borrow a book
work flowo的步骤：
- Login with username "User1" and password "123"
- Search a book named "Agile"
- borrow the book
- Logoff
则代码转换器会生成一个名为BorrowABook的类。该类会具有公有函数
- loginWithUsernameAndPassword(string username, String password)
- SearchABookNamed(String bookname)
- BorrowTheBook()
- Logoff()
运行时，任务运行期会自动依次调用这四个函数，并将写在Business work中的参数传给相应的函数。
二、Business rule table
业务规则表由名称和表格组成。表格由若干个参数列和若干个断言列（Assertion Column）组成。该表格每一行的数据表述的业务意义为：当给定参数列所限定的条件时，期望的是断言列所描述的结果。Twist的代码转化器会将业务规则表转换为一个单独的JAVA类；并在这个类中，给每个参数列生成一个私有成员变量及其公有的set函数，以每个断言列的列名生成一个公有函数。当业务规则表被运行时，Twist的任务运行器会逐行执行表格内容：给当前行生成一个类实例，调用当前行的每个参数列的set函数，将对应单元格内的值赋给相应的成员变量，执行每个以断言列名来命名的公有函数，并将返回值与当前行对应列的单元格的值向比较。无论比较结果是否相等（即每行测试是否通过），业务规则表都会从第一行执行到最后一行。
例如，测试一个小学生的算术加法练习系统
rule table名：AddSystem Msg Test
参数列：augend，addend，sum
断言列：resultMsg，MsgColor
则代码转换器会生辰类AddSystemMsgTest，该类具有私有成员变量augend，addend，sum，以及公有的setAugend(Int augend)，setAddend(Int addend)，setSum(Int sum)，和公有的函数String resultMsg()，以及String msgColor()。
给表添加两行：
augend addend sum resultMsg MsgColor
1 2 3 Right #00ff00
1 2 4 Wrong #ff0000
任务运行器将会首先创建类AddSystemMsgTest的实例，再将1，2，3分别赋值给augend，addend，sum，之后调用String resultMsg()函数并将返回值与“Right”相比较，调用String msgColor()并将返回值与#00ff00相比较。
对第二行，做相同的事情。
三、Business work flow 和 Business rule table的比较
业务工作流和业务规则表都会被代码转换器转换成JAVA类，所不同的是，前者的每个step可以是不同的JAVA函数，而后者的不同行之间，是反复执行同一组函数；前者执行到出错的step时，会终止运行，而后者则一定会执行到最后一行。
四、Scenario
按照需要，一个Scenario中可以包含一到多个Business work flow或者Business rule table，允许同时包含二者。Scenario只是Business work flow和Business rule table的容器，或者称为，场景。它完全是业务层面的东西。Scenario中的Business work flow或Business rule table可以在技术上毫不相关，但是，它们应该是业务上相关联的。
在Twist的测试组织架构中，Scenario是可运行的最小单元，所生成的测试报告也是针对Scenario的，所以，将多于一个的Business work flow或者Business rule table放在一个Scenario，前提是它们的业务相关性较强。
五、Context
有些测试需要在一定的背景下完成。例如，编辑profile，借书，论坛发帖，都需要先登录。那么，登录就称为编辑profile，借书，论坛发帖等的Context，或称为，上下文。
仍以借书为例，如果有了用户登录这个上下文，那么，business work flow就只需要包含两个步骤了
- Search a book named "Agile"
- borrow the book
给这个业务工作流所在的场景添加上下文UserLogin，并在生成的类中，在其setUp和tearDown中分别实现用户登录和登出，那么用户登录和登出会在业务工作流所有步骤执行之前和之后被自动调用。
其他的Scenario可以共享这个上下文。
六、Tag
Tag标签，用于给Scenario分组。例如，可以设置Functional Test、Smoke Test、Regression Test等标签，将不同的Scenario分组执行和管理。