1.1 测试环境搭建
在我们进行性能测试之前，通常需要搭建一个供测试用的环境，使用这个环境来录制脚本，根据在这个环境下执行测试的结果，得出最终的测试结论。
有些时候，测试环境就是生产环境，例如：一个新的项目上线前进行的性能测试，通常就是在未来的生产环境下进行的。在这种情况下，可以排除测试环境与生产环境差异带来影响，测试结果相对比较准确。
反之，如果测试环境与生产环境不是同一环境，这个时候，为了保证测试结果的准确性，需要对生产环境进行调研。在搭建测试环境时，尽量保证搭建的测试环境和生成环境保持一致（环境主体框架相同，服务器硬件配置相近，数据库数据相近等）。
另外，最好输出一个测试环境搭建方案，召集各方参加评审确认。同时，在测试方案、测试报告中，对测试环境进行必要的阐述。
1.2 并发量计算及场景设计
首先，在确定场景及并发量之前，需要对业务进行调研，调研的对象最好是业务部门，也可以通过数据库中心查询数据，进行辅助。
场景选取一般包括：登陆场景、操作频繁的核心业务场景、涉及重要信息（如：资金等）业务场景、有提出明确测试需求的业务场景、组合场景等。
每个场景的并发量，需要根据业务调研的结果进行计算。可以采用并发量计算公式：C=nL / T 进行计算（其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统））。
每个场景的思考时间，也可以通过业务调研获得。
另外，也可以采用模拟生产业务场景TPS（每秒通过事务数）的方式，来确定场景。相比上一种方式，模拟生产业务场景TPS，能更加准确模拟生产压力。本次ERP性能测试采用的就是这种方式：首先，通过调研确定业务高峰时段，各核心业务TPS量及产生业务单据量。然后，通过调整组合场景中，各单场景的Vusr（虚拟用户数）和Thinktime（思考时间），使每个场景的TPS接近业务调研所得到的TPS量，每个场景相同时间（即高峰时间段长度）通过事务数接近调研业务单据量，从而确定一个，可以模拟生成环境压力的基准场景。最后，通过成倍增加虚拟用户数，来形成2倍场景、3倍场景等。（注：在ERP性能测试组合场景调试过程中，我们发现：各个单场景TPS会受到其他场景的影响（例如：某一个单场景虚拟用户数增加，其他场景TPS就好跟着变化）。因此，建议大家在确定场景并发量时，如果场景比较复杂，最好采用第一种方式）。
最后，同样需要制定场景设计方案，召集相关部门进行评审。
1.3 测试框架搭建
在环境搭建完成、场景设计方案确定之后，下一步工作就是创建脚本。
创建脚本通常有两种方式：录制和手工编写。前一种方式相对比较容易，只需要使用测试工具，进行相关操作即可生成脚本。后一种则相对比较麻烦，需要搭建一个脚本执行的框架，编写各场景对应的代码。
首先，关于测试框架，简单来说就是一个程序运行的环境。以java语言为例：我们都知道，一个简单的java小程序，它要运行起来，我们先要安装JDK（我们可以把它看成是一组API，也可以说是一些java Class），它提供了编译Java和运行Java程序的环境。同理，我们现在想要编写测试脚本，实现特定的功能，那么首先也需要搭建一个可以让它运行起来的环境。
在搭建环境过程中，需要咨询对生产环境框架非常熟悉的工程师，了解整个环境运行的机制。测试框架搭建完成条件：测试脚本在该框架下运行，可以实现登录应用服务器，执行基本业务操作（可以通过在数据库中，查询生成数据进行验证），登出应用服务器。
具体以ERP性能测试框架为例：通过调研分析得出：
1）测试脚本执行需要使用1.4版本jdk；
2）金蝶client端程序运行，jar包调用先后顺序：sp→path→common→client ；
3）金蝶client端与应用服务器建立连接过程：获取客户端元数据（调用MetaDataLoaderFactory.setClientMetaDataPath()方法）→获取启动模块（调用SystemEntry.instance.setStartMode()方法）→初始化系统（调用SystemEntry.instance.initSystem()方法）→登陆应用（调用SystemEntry.instance.login()方法）；
4）金蝶client端登出应用服务器方法SystemEntry.instance.logout()。
根据以上几条，我们编写调试出登陆脚本，然后加入具体的业务代码之后，又顺利开发调试出某个基础资料新增脚本（因为金蝶体系固定，基础资料调试通过，代表其他业务功能也可以调试通过），这样整个框架就基本搭建完成。
具体的测试环境搭建细节，参见“ERP性能测试框架搭建”。
1.4 测试脚本开发/调试
测试框架搭建完成之后，就可以开始脚本的开发调试工作了。
首先，这部分工作需要交给，各个业务模块开发员来完成，因为每个模块的代码，只有负责的开发员最熟悉。
在脚本开发前，需要对开发员进行一个简单的培训，将我们测试的大体背景、目标等告诉他们，同时，可以规定一些脚本编写规范（如关联数据库表，核心业务代码行数等注释，为后期场景执行做准备等）。培训完之后，开发人员先在BOS里面进行开发调试，调试通过后，进行简单调整，然后复制到loadrunner中（Init和end中存放登陆、登出代码，详见“ERP性能测试框架搭建”）即可。
下面，简单讲讲脚本开发细节：
金蝶代码可以分为三种：1、客户端代码；2、服务器端代码；3、共用代码。客户端代码由UI界面发布后生成，通常它的功能是获取界面数据、对数据进行校验，增加界面控件监听（如：监听新增按钮，当其被点击后，调用远程接口，向数据库中新增数据），显示界面等。服务器端代码是实体（金蝶元数据，用于建立UI、Query等跟数据库的交互关系）发布生成的，通常可以在里面进行二次编码，实现具体业务功能，供不同客户端调用。共用代码包括接口类、值对象类、枚举类等一些服务器端、客户端需要共用的代码。
目前，ERP开发主要是进行客户端代码（*UI.java）及服务器端代码* （ControllerBean.java）二次开发，而服务端代码已经部署到服务器上，我们的测试脚本开发只需要编写客户端部分即可。当然，客户端部分可能有很多业务对应的方法，我们不是每个都必须调用，可以根据实际情况进行删选。一般情况，输入校验（insertVerify()）、核心业务（新增、修改、删除、查询监听方法）都必须写进脚本。
另外，实际业务数据是通过界面输入，我们脚本开发可以将数据写死，然后进行参数化即可。
1.5 场景调试/执行
脚本开发完成后，进入场景调试执行阶段。
场景调试执行分为：单场景执行、组合场景执行。
首先，我们在单场景执行阶段，需要对脚本进行参数化、添加事务、集合点、检查点、思考时间等操作，注意，如果想要真实模拟生成压力，需要对所有核心字段进行参数化（如出发部门、到达部门、单据编号、操作人等）。
然后，执行组合场景时，需要对各单场景，在组合场景中的执行结果进行验证，需要对数据流进行监控，保证参数化数据量充足；可以通过修改每个单场景的虚拟用户数和思考时间，来调整TPS。
最后，不论是单场景、还是组合场景，执行过程中，都会产生很多的脏数据，每次执行场景后，都需要对这些脏数据进行清理。本次ERP性能测试采用了，一种新的脏数据清理方法：数据库闪回。
数据库闪回，首先，需要对数据库进行设置，开启闪回服务，设置闪回空间大小；然后，可以通过一系列的操作，完成数据库闪回：
1）关闭数据库（srvctl stop database -d erp -o immediate）；
2）进入SqlPlus（sqlplus / as sysdba）；
3）归档模式启动数据库（startup mount）；
4）执行闪回操作（flashback database TO TIMESTAMP to_timestamp（'2012-04-12 15：10：00'，'yyyy-mm-dd hh24：mi：ss'））；
5）打开数据库（alter database open resetlogs）
1.6 性能监控分析
在场景执行过程中，可以通过使用性能监控工具，对应用服务器、数据库服务器进行监控，一般使用nmon。事务响应时间、通过率等过程记录可以使用loadrunner进行监控。数据库性能可以使用SQL脚本执行进行监控。
对于一些比较专业的性能指标，比如：本次ERP性能测试需要监控的主实例JVM情况，可以交给数据中心或者开发部门。
性能测试执行过程中，发现环境性能问题后，通常会进行一些调整，这个时候，尽可能将之前执行过的场景重新执行，并进行监控。
关于分析，原则上是需要各个部门共同参与，最好每次举行一个分析会，召集相关人员参加，并对分析结果进行讨论。
1.7 结果报告
在场景执行完成，测试分析结束后，开始进行测试报告编写。测试报告编写，要将重点内容放在最前面，要有具体的结果（目标是什么？结果是怎样？性能是否满足要求？），而不能只是分散的结果统计。
2、展望
2.1 业务调研及场景确定
现在，业务调研还存在问题：1）没有真正调研业务部门，都是通过查询数据库，或者通过各种其他途径推算；2）没有形成一个很好的调研流程及方案；场景方面，并发量、思考时间因为调研不全的等原因，无法准确的确定。这些在后期性能测试过程中，都需要去探索、总结。
2.2 场景监控与分析
目前，场景监控经常出现我们测试一个部门监控，其他部门参与不够的情况。场景结果也没有得到很好的分析。其原因，一方面，是我们的技能水平需要提高，另一方面，是如何有效的将各个部门组织参与进来。这些都是我们未来需要进行研究、提升的地方。
本文摘自51testing软件测试网
