2.自动化测试策略

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描述和场景设置，基本就完成了一个完整测试的定义。