2.1 自动化测试的工作方式
功能自动化测试：
通过软件工具（测试脚本）模拟用户实际的鼠标、键盘、触屏等操作，实现自动化执行和操作被测对象的预期功能。
性能测试：
通过软件工具（测试脚本）模拟多个虚拟用户并发请求，来检验服务器的性能行为是否满足系统要求。
自动化测试的基本工作流程：
自动化测试用例设计->编写自动化测试脚本->执行自动化测试脚本->收集自动化测试报告->分析测试结果
自动化测试框架成熟后，最主要的工作是自动化测试用例的设计和自动化测试脚本的编写，相当于一个测试人员的测试思想和测试能力。
2.2 如何在项目中引入自动化测试
在项目中引入自动化测试，需要评估：
该项目是否适合做自动化测试？是否有合适的人力和时间去做自动化测试？
以上问题答案都为是的条件下，可以将自动化测试列为一个项目。前期需要搭建自动化测试框架，然后分析自动化测试的需求，自动化测试任务排期，自动化测试脚本验收、提交、执行，继而是自动化测试的迭代。
2.3 BDD及TDD思想在自动化测试中的应用
TDD - Test-Driven Development，即测试驱动开发：它是一种测试先于编写代码的思想用于指导软件开发。测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。
TDD的原理：在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
BDD - Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作，是对TDD的理念进行了扩展。
TDD侧重点偏向开发，通过测试用例来规范约束开发者编写出质量更高、bug更少的代码。而BDD更加侧重设计，其要求在设计测试用例的时候对系统进行定义，倡导使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。
BDD描述的行为就像一个个的故事(Story)，系统业务专家、开发者、测试人员一起合作，分析软件的需求，然后将这些需求写成一个个的故事。开发者负责填充这些故事的内容，测试者负责检验这些故事的结果。通常，会使用一个故事的模板来对故事进行描述。
BDD的通用语言是一种近乎自然语言的描述软件的形式。基于这种通用语言形式可以尽可能的避免客户和开发者在沟通上的障碍，实现客户和开发者同时定义系统的需求。避免了因为理解需求不充分而带来的不必必要的工作量。
Story：
As a 角色
I want 特征
so that 利益
As a标识出这个系统行为是为哪一个角色而定义的。
I want和so that则指明了该角色想做的事， 以及想达到的目的。这三个断句定义了这个系统行为的参与者、范围。
同样的一个Story，可能会有不同的场景。通过上面的模板描述了故事之后，再通过下面的模板对不同场景进行描述
Scenario:
Given [上下文]
And [更多的上下文]
When [事件]
Then [结果]
And [其他结果]
这些场景中的Given…When…Then…实际上就是设定该场景的状态、适用的事件，以及场景的执行结果。
其实通过这样的Story描述和场景设置，基本就完成了一个完整测试的定义。