敏捷开发，基本上属于现在软件开发的主潮流。但是很多人还没有真正的理解它。敏捷开发并不是指特定某种开发模式，而是概指所有符合以下特性的任意开发模式：通过更加频繁有效的交流，更早的发现问题，解决问题。

基本上主流的敏捷方法，都是依赖于测试的质量，所以测试驱动开发（Test Driven Development）可以称为敏捷开发的基柱。TDD的思想就是通过测试活动来驱动开发活动从而达到将客户需求能够精确的反应到开发过程中，从而降低开发的成本。在这过程中，最典型的特点就是先完成测试程序，在实现能够通过测试程序验收的代码，经过反复迭代，从而使得产品顺利发布。

在TDD的进化过程中，出现了一个更加有趣的BDD分支，即行为驱动开发（Behavior. Driven Development）。在不断的迭代过程和OO思想影响下，我们会发现有很多产品的设计思路从总体来看就是一些特定对象的行为集合。我们的产品，就是不断的完善这些对象的行为。因此，TDD的真正价值就在于能够更加清晰有效的对对象的行为进行分解实现。对于拥有BA的开发团队，一般将用户的需求描述为产品的设计理念，例如UML的介入，大量的流程图和关系图的出现，将简单的需求复杂化，模块化。那么为什么不直接从真正用户如何使用产品入手呢？这样我们直接就从客户的角度考虑，如何设计产品，从而使其的行为能够符合用户的习惯（UE）和流程。BDD就是依据这一理念出现了。

BDD通过定义用户和开发团队所共同接受的“通用语言”来实现对接。从而避免双方表达不一致的出现，导致产品开发出现产品功能偏差。

而SDD（Story Driven Development）就是对BDD的一种具体的实现。使用Story来定义用户和系统行为，从而达到测试驱动开发的目的。

一般常用的story格式如下：

Story：subject                           

As a （role）

In order to （behavior）

So that （benefit）

然后通过一系列的场景来验证该story的实现。

如果我们把AC 看作test case outline，这些scenario 就等同于一个个我们要使用的test case。

一个scenario一般是如下格式：

Scenario 1： subject

Given 【上下文】

          And 【更多的上下文或步骤】

When 【要完成的事件】

Then 【期望的结果】

          And 【更多的期望结果】

场景很容易去理解，Given 和 And 给出了一些的上下文，就等同于测试用例中的precondition和steps。 When给出的就是最后要验证的系统的behavior或者要验证的操作。Then和And给出的是这个behavior或者操作的正确期望结果。

Story， As a， In order to， So that，Scenario，Given，And，When，Then这些就是我们在SDD这种模式中定义的用户和开发团队所共同接受的“通用语言”的一些关键词。SDD框架能够理解和解释这些关键词从而使得SDD得到实现。

而Cucumber就是一个实现的SDD框架。它通过feature文件来保存story和相关的scenario。使用任意支持的语言来完成scenario中的steps与自动化测试脚本的mapping。然后就可以在执行feature文件时，直接执行相关的自动化测试脚本。

性能测试数据模型
设计性能测试数据模型是一个设计数据负载分布配置文件的建模过程，也是对一个真实的用户的环境进行模拟的过程。每个配置文件一般包含了如下属性：
•	关键场景
•	并发用户数
•	请求率
•	请求模式

对于请求模式和请求率，一般是根据真实的用户环境和用户习惯进行预测。如果已经有实际的应用环境，那么分析服务器日志文件是一个更加精确的方法。通用的方法如下述各条：

那些是关键的场景？

通过分析那些会对程序性能产生影响的场景，并结合用户需求来衡量那些是关键场景。也就是说，经历程序的核心模块的那些场景

预期的最大在线用户数和并发用户数是多少？

预期的最大现在用户数一般就是预期设计的程序最大运行能力所能承受的用户数。而活跃用户数一般是分布在程序的不同场景中。而并发用户数，是指一个单一的场景所能允许的极限用户数。一般来说并发用户数占在线用户数的比例不超过五分之一。同过分析已部署的实际用户环境的服务器日志，很容易得出这些数值。

普通用户一般会执行的场景路线图是什么？

从用户角度分析，正常的用户在使用程序时都有什么样的习惯也是很重要的。通过分析用户的习惯，从而知道用户体验的关键场景在什么地方。从而有针对性的测试。例如，一个电子商务网站的最常用的场景路线图是：
•	打开主页
•	登录
•	浏览商品目录
•	选定商品加入购物车
•	提供付费，送货地址等信息。
•	提交订单


如何制定用户配置文件?

用户配置文件是为了区分不同类型的用户。每个配置文件里都包含了一种特定用户类型，以及该类型用户的特定操作组。例如，可以设计一个用户配置文件，使用该用户配置文件的用户都是属于某个特定权限组，唯一操作是浏览目录。利用这种方式就可以把各个场景的用户进行组织。

例如：
•	浏览配置文件（给只浏览的用户群使用）
•	搜索配置文件（给直接搜索的用户群使用）
•	订单配置文件（给需要完成订单的用户群使用）


每一个用户配置文件中，单一用户的操作分布是？

我们可以根据用户需求分心或者实际的用户体验（利用服务器的日志文件分析得出）来判断每个单一用户的操作分布是什么。例如对于电子商务网站来说，一个实际的订单配置文件中的用户体验如下：



对于无法从日志文件中得出分布的时候，我们可以根据用户需求分析和通常的市场分析报告来获取。例如，通过需求和市场报告我们获知，每个人在购买产品时，通常会浏览该类产品总目录一次，需要搜索指同类产品两次以做比较后进行购买。并且用户购买产品时绝大多数不少于三件产品。那么 我们的配置文件就如：



每个请求之间的平均思考时间是多少？

思考时间是指用户在两个连续的请求之间的等待时间。在次期间，用户一般在浏览上一个请求返回的信息。例如，该产品的详细信息，图片啊等等。

思考时间完全依赖于数据的复杂性。比如，登录页面的思考时间就远远小于浏览产品信息的思考时间。一般来说，思考时间都是取的所有请求的思考时间的平均值。这个时间一般都可以从通常的读速或者日志文件中获得。

用户配置的文件是如何组织的？

一般来说用户配置文件的组织结构，都是在一个给定的时间点，各个用户群体的分布来决定的。例如：



如何判断每个测试用例需要的执行时间？

测试的持续时间取决于设计的场景，数据和使用模式。以下是会经常考虑的：

用户的规模。对于一个电子商务网站来说，场景很简单，数据压力也不大，所以主要是考虑用户的使用模式。这样在考虑持续时间时，只需要做一个2-4小时即可。对于电信收费系统来说，就需要至少持续48个小时。

用户的行为。对于一个电子商务网站来说，压力最大的时候是在特定的假日期间会产生大量的订单。所以，对具体的瓶颈模块，需要更长时间的测试。比如银行付款模块，就需要能有足够大的能力来承受瞬间的强大压力，并要在最大承受能力下持续7X24小时来测试。

特殊的需求。对于一些特殊的客户需求，我们需要执行相应的测试时间。例如，电信收费系统会在每月底不断的接受强大的数据压力。为了模拟这种测试，我们就需要有个模拟的环境。例如，有一套单独的系统，独立运行中，每次压力只持续10分钟即可

-fo

压力测试

压力测试是使用高于系统承受能力的数据压力对程序进行测试。其手段是快速消耗资源从而使得程序在“零”资源情况下运转。例如，超负载的用户登录数，大量消耗处理器和内存，剥夺了其他模块获得资源的机会，使得这些模块处于“暂停”状态。

压力测试的目的是为了在高负荷条件下挖掘那些潜在的程序问题。

常见的问题有：
•	同步问题
•	资源竞争
•	内存泄漏
•	网络拥塞导致的数据丢失

和负载测试不同，压力测试是有明确针对性的测试。具有明确的性能指标，明确的测试场景，明确的数据量。负载测试往往是单一的场景测试，而压力测试往往是多个场景的复合测试。负载测试往往没有特殊的先决条件，而压力测试都是在特殊的指定测试环境下进行的。负载测试一般都是用来发现一个问题，而压力测试往往是用来复现一个问题。负载测试一般都是针对业务逻辑进行测试，而压力测试可以是一个简单的对象，例如一个指定的存储过程。

进入文档

执行压力测试的进入文档一般有如下几个：
•	程序的特性（特殊的场景）
•	潜在的问题（隐含的场景）
•	需要的压力数据的特性
•	瓶颈峰值（由负载测试得到的阀值）

步骤

进行压力测试需要的六步流程如下所示：



流程包含的步骤如下：
1.	选择测试场景。根据要测试的缺陷，选择相关的测试场景。
2.	设计测试数据。依照测试场景，和由负载测试获得的阀值，来设计所需的测试数据。
3.	指定性能指标。针对测试的缺陷，来指定在压力测试中要监察的性能指标。
4.	创建测试用例。基于测试场景，数据集和缺陷来创建针对性的测试用例。
5.	执行测试用例。在特定的测试环境中执行测试用例。
6.	分析测试结果。 对得到的结果进行分析。

步骤一 选择测试场景

进行压力测试要确定多个测试方案。每个方案都依赖于一个单一的测试场景。一般来说，只有一对一的场景测试，才能更好的发现潜在的性能问题。如下是常用选择场景的原则：
•	选择那些对整体性能有影响的场景。
•	选择那些最有可能影响性能的操作。例如，频繁的锁定操作，同步操作，长事务操作和那些磁盘密集型操作。
•	基于负载测试的结果。通过负载测试，可以探知一些系统的瓶颈。而一般围绕这些瓶颈进行压力测试是一个很好的选择。通过对瓶颈进行更大的压力测试，从而使得程序部分功能阻塞，从而揭显出那些隐藏的问题。

对一个电子商务应用来说，典型压力测试如下：
•	订单处理场景中，程序需要实时的更新产品的库存。所以，会出现数据库数据同步和假死锁的可能。
•	用户在搜索的场景中，使用了一个会返回大量值的关键词。这种搜索会占用大量的内存而使得利用率降至极低。并且很大程度上是一次无效的搜索，浪费了资源。

步骤二 设计测试数据

用于压力测试的数据负载量，首先必须超过阀值。然后，不断调整负载来观察程序的行为。

其中一个设计理念就是对负载测试的反向设计。负载测试是要保证所有影响程序性能的性能指标是处于正常运行的状态下。所以压力测试只要破坏其中任意一个性能指标就可以压垮程序。通过不断的压垮程序的压力数据集，你也可以获得对抗这种潜在的高峰压力的方法。

负载测试的持续时间一般都是有个明确的值。而压力测试的持续时间测很难判断，不但会跟测试环境相关，也跟具体的场景有关。所以，不断的更换测试环境的配置是很有必要的补充，而在负载测试中，测试环境都是要求稳定的一致。

步骤三 指定性能指标

在压力测试前，要明确每个场景存在的隐患所可能涉及到的性能指标。这些性能指标一般都是预设的性能要求或者是根据明确的用户需求推导出来的潜在需求。一般来说，这些性能指标都是和负载测试的指标相同。可以共用同一种方法来获得。例如，在代码中加入的计时器，就可以被二者共享。但是，压力测试的性能指标获得都要比负载测试的过程复杂。

例如，在提交订单这个场景中，最主要的性能指标是资源竞争。除了负载测试需要关心的基本信息，需要获得一些额外的信息：



步骤四 创建测试用例

基于以上步骤，创建所需要的压力测试用例。例如一个提交订单的测试用例如下：

触发条件：
•	十万个模拟用户
•	每秒随机两次操作
•	用户异步触发
•	持续两天

性能参数（期望值）：
•	死锁（无硬死锁）
•	接受请求数（不小于25次/秒）
•	驳回请求数（不高于50次/秒）
•	死锁率（不高于35%）
•	解除死锁率（长度不超过100个/秒）

步骤五 执行测试

可以使用手工或者自动化工具对测试用例进行执行。一般执行的时间可以分为两种：
第一种，固定时间。例如，每个模块完成集成测试后，开始执行功能测试前。
第二种，固定阶段。例如，在功能测试完成后进行。

步骤六 分析测试结果

通过分析测试结果，与负载测试的数据进行对比，从而发现那些隐藏的瓶颈的成因。为了更好的修复问题，还需要做如下的额外工作：
•	重新审读设计文档
•	重新审核源代码
•	修改架构并测试来验证结论

负载测试流程

使用负载测试来研究系统在通常数据压力下和峰值数据压力下的行为。一般是采用逐级增加数据量的方法来研究。从一个初始化环境的数据量逐级增加直到性能阀值数据量，一般是倍增的原则。例如，你设定了CPU的最高阀值是75%。那么逐级增加数据量，直到CPU的占用率接近75%。通过负载测试，你能够识别系统的瓶颈和程序的最大稳定负载能力。

进入文档

进入文档一般包含如下：
•	由性能架构决定的性能目标
•	程序的特性（测试用例）
•	工作数据流的特性
•	每个程序特性的性能指标
•	测试计划


测试步骤
如下表中描述了进行负载测试的流程：
  



负载测试流程包含了如下步骤：
1.	设定主要测试场景。从程序所包含的所有应用场景中，挑选出那些对性能影响最大的场景作为需要测试的场景。
2.	设计测试数据。根据设定好的测试场景设计相应的测试数据。
3.	审定性能指标。对每个需要测试的场景，设定具体要检测的性能指标。
4.	创建测试用例。针对每个测试场景，设计具体的测试用例，用于获得需要的性能指标。
5.	执行测试。使用设计好的测试数据执行测试用例，并搜集设定的性能指标的具体数据。
6.	分析测试结果。根据具体的性能指标的数据分析结果，对程序性能进行评估。


步骤一 设定主要测试场景

万始之初是挑选关键的测试场景。一般一条业务路径中，包含了多个场景。而关键场景，就是对你的测试目标有着直接影响的场景。一般来说关键场景就是经常被使用的场景或者是需要使用大量资源来执行的场景。

例如，对一个购物网站来说，常见的关键场景如下：
•	登录网站
•	浏览产品目录
•	搜索特定产品
•	购物车
•	信用卡验证
•	订单提交

步骤二设计测试数据

根据挑选出来的测试场景，需要有针对性的设计所需的测试数据。一般来说测试数据应该考虑到如下几个因素：
•	用户数。需要明确在线用户数和活跃用户数的需求。
•	请求频率。需要明确在单位时间内可能发生的请求数。
•	请求的模式。同样的用户集合在不同的模式下使用程序会带来不同的数据流。所以要明确用户会以何种模式来使用程序。

一般来说，我们采用数据模型的方法来创建测试数据集。 在创建了数据模型后，根据用户分布配置文件，来使用测试数据进行逐渐加压测试。在加压过程中，记录程序的行为，直到获得足够典型的性能目标数据，即可将当前的数据量作为一个数据集标准。然后逐渐加压，直到获得程序的阀值，然后就可以在数据模型中明确标识。这样，就可以勾勒出来一个明确的数据级别分布图。


步骤三审定性能指标

拥有明确的性能指标，才能在测试中获得有效的测试数据。通过这些指标，你才知道在哪里能找到用来对程序的性能进行评估的对象。只有通过这些指标，才能识别出真正的瓶颈。

而且，通过不断迭代的测试方式，你可以在任何一轮测试前根据上次的结果来修改下一轮测试需要关注的性能指标。例如在上轮测试中发现某个未监控的服务进程实际上是真正的资源消耗源头。那么在下轮测试中，就可以根据这个服务进程修改测试方法，数据和要关注的性能指标来跟踪。

如下所列的指标类型，都是用于评估程序性能的常用类型：
•	网络类指标。这类指标一般提供了网络健康指数。例如交换机，路由器和网关等的状态。
•	系统类指标。这类指标一般用于了解服务器的资源利用率情况。例如处理器，内存，磁盘的输入/输出和网络端口的输入输出状态。
•	平台类指标。这类指标一般用于监察程序相关软件的性能情况。例如，使用的公用语言运行库和私有语言运行库的性能情况。
•	程序类指标。这类指标一般使用在程序中添加获得额外的代码来获得的。例如，在登录程序中，添加一个计时器，来获得用户登录的消耗时间。
•	服务类指标。这类指标一般用于衡量整个程序的数据吞吐量和服务延迟时间。一般都会跟一些特定的业务场景相结合。例如下表所列：



在审定好性能指标后，我们需要给每个指标设定一个我们期望的基准线。这个基准线可能有多条，分别对应于不同的数据量。通过分析这些基准值和实际值，能够更加清晰的得出在不同的负载水平下的性能。举例如下：




步骤四 创建测试用例

基于步骤二设定的数据模型和步骤三设定的性能指标来制定测试用例。

例如：在数据集A的测试场景中，使用测试用例1，2，3对多个性能指标进行检测。
数据模型的数据集A为：

 

  

  
场景
  
  

  
占总用户的比例
  
  

  
用户数
  
 
 

  

  
浏览目录
  
  

  
50%
  
  

  
250
  
 
 

  

  
搜索产品
  
  

  
30%
  
  

  
150
  
 
 

  

  
提交订单
  
  

  
20%
  
  

  
100
  
 
 

  

  
总计
  
  

  
100%
  
  

  
500
  
 

审定性能指标和预设值为：
•	单位时间浏览目录数（100/秒）
•	单位时间成功提交订单数（10/秒）
•	返回查询结果平均时耗（2.5秒）
•	处理器占用率（不大于50%）
•	内存占用量（不大于320MB）

测试用例为：
•	测试用例1：每秒发送200个浏览请求。检测性能指标：单位时间浏览目录数，处理器占用率，内存占用量。
•	测试用例2：每秒发送100个查询请求。检测性能指标：返回查询结果时耗，处理器占用率，内存占用量。
•	测试用例3：每秒发送20个订单提交请求。检测性能指标：单位时间成功提交订单数，处理器占用率，内存占用量。


步骤五 执行测试

可以使用手工或者自动化工具对测试用例进行执行。一般执行的周期可以分为两种：
•	第一种，固定周期。例如，每周对测试用例执行一次。
•	第二种，固定版本数。例如，每十个版本执行一次测试用例。

步骤六 分析测试结果

根据测试获得的数据和预设值进行比较，就可以对程序的性能有一个明确的评价结果。从而明确了性能调优的目标。同时，这些数据也能帮助你得出产品的瓶颈和潜在的固有缺陷和风险。以及获得如何进行扩容的方式和方法。同时，连续的测试结果报告，有助于控制产品的性能指标，从而降低开发成本。根据测试结果，还可以帮助用户在使用程序是如何部署更加优化的运行环境。

输出文档

通过负载测试获得的常用输出文档如下：
•	更新的测试计划文档
•	在不同的负载水平下，程序的行为描述文档
•	程序的最大稳定负载能力描述文档
•	潜在的瓶颈，固有缺陷和风险的描述文档
•	推荐的部署和配置文档

 简述

性能测试用于确定应用程序在指定的输入输出条件下的响应状况。一般要使用多个独立的性能测试场景/测试用例来覆盖所有的可能性。测试时，尽可能使测试环境贴近真实环境。通过研究应用程序的模拟负载下的行为，来确定其性能指标是否满足设计目标。

性能测试是用于研究应用程序在预期数据量和最高峰值数据量下运行状态的测试方法。以便确认程序在不断增加的数据量下的具备的处理能力。如下的三种性能测试方法都可以殊途同归的实现以上的目标：

•	负载测试。使用负载测试来研究基于不同可接受的数据集合下的产品的行为。 可以很明确的获知产品是否达到了设计要求。一般通过监控响应时间，数据吞吐率，资源使用率来进行测试。而且通过这种测试可以探知应用程序在什么样的数据峰值下达到崩溃点。

•	压力测试。压力测试用于评估应用程序在数据量过载后的行为。目的是在高负荷状态下，挖掘更多的系统隐藏的内在问题。例如数据同步，资源竞争和内存泄漏这些常见的问题。通过压力测试，我们可以探知应用程序的内在缺陷，以及其会带来的风险。

•	能力测试。能力测试和负载测试相辅相成。通过其能够获知应用程序的预设的失败阀值点。这个阀值点是通过研究负载测试在各个数据量的程序行为获得的，即在崩溃点前最后一个能够维持程序稳定运行的数据量为预设的失败阀值点。通过能力测试，可以制定扩容计划。通过扩容计划，我们可以稳定的提高用户集和数据集。例如，如果想将用户集和数据集提高一倍，那么根据现有的资源。（例如处理器个数，内存容量，硬盘空间，网络带宽等等）我们就可以知道最小的扩容资源需求值。

性能测试的目标

性能测试的最大目的是来比照应用程序的实际性能和预期性能。同时还有一些其他的目的：
•	确认系统中存在的瓶颈和成因。
•	调整和优化平台的硬件配置和软件配置来达到性能最大化。
•	验证程序在压力下运行的可靠性。

只通过一种性能测试的方法是不可能获得所有的性能指标的。但是了解这些性能指标，对你进行性能测试会有很大的帮助：
•	响应时间。
•	吞吐率。
•	最大并发用户数。
•	资源利用率。
•	不同数据量对应的系统行为。
•	程序崩溃点。崩溃点一般是指程序停止响应，返回典型的503错误时的数据量值。
•	程序崩溃的原因和崩溃后的行为。
•	程序的固有缺陷。
•	负载的主要成因。例如，是用户数的增加导致负载量翻倍，还是某个操作导致数据流翻倍。

性能测试的指标

绝大多数的性能测试依赖于一组预定好的，文档化的和达成共识的性能目标。明确的目标可以提高性能测试的效率。通过测量程序的真实数据和目标进行对比从而判断程序性能的优劣。
当然你也可用通过探索的方式对产品进行性能测试来了解程序的真实情况而无需任何明确的目标。这些测试的结果也可以作为对产品性能评价的指标。

性能指标一般包含如下：
•	响应时间/延迟时间。
•	数据吞吐率。
•	资源利用率。
•	工作负载。

响应时间/延迟时间

响应时间是指发出请求后到得到相应所需的时间量。在服务器端和客户端都可以测量相应时间：

服务器端获得响应时间。这个时间段是指服务器从获得请求到完成的执行时间段。不包含客户端到服务器端的传输时间段，因为其含有网络传输消耗的时间。

客户端获得响应时间。这个时间段包含了加入请求队列的时间段，服务器处理的时间段和来回传输的网络消耗时间段。在多种测试方法中，最常用的两种方法是：TTFB，第一个字节到达客户端为终点。TTLB，最后一个字节到达客户端为终点。而且一般来说，测试时还要使用不同的网络带宽来测试从而得到更加真实的数据。

通过测试时间延迟，从而可以判断是否存在对客户端的请求响应度过低的性能问题。

数据吞吐率

数据吞吐率是指单位时间内可以被程序响应的请求数。不同的用户数和用户活动类型会产生较大的差异。例如下载的数据吞吐率就要比浏览页面的低。通常，数据吞吐率是以每秒可以响应的请求数来记录。

资源利用率

资源利用率用于确认在服务器和网络资源方面需要的资源成本。主要的资源为：
•	处理器
•	内存
•	硬盘输入/输出
•	网络输入/输出
通过性能测试，可以明确每一个流程和步骤需要的资源情况。通过优化资源利用率，降低成本。

工作负载

对于一个程序，活跃用户和并发用户往往有着巨大的差别。一般来说在活跃用户中，一般只有10%-20%的并发用户存在。

所以在性能测试中，要区别两者。在压力测试时，工作负载一般指的就是并发用户产生的数据量。