摘 要：本文主要是面向性能测试的工程师，从实际项目中总结经验、教训，并且提出一些改善的建议，希望大家能在以后的性能测试的项目中吸取和借鉴，本文尤其在性能测试的前期数据准备方面给出了解决方案。
关键词：测试用例；性能测试；测试流程
项目介绍
该项目为两年前的一个项目，目前该系统的性能在一定的条件下速度极慢，当用户量达到一定程度时，整个程序会无法响应，所以需要对该项目进行性能测试，找到系统的瓶颈，为以后的系统升级做充分的准备。
项目延期的原因
XXX项目已经结束，在整个项目的测试过程中遇到了不少困难，由于各种原因导致项目延期，其中虚拟数据的准备是其中一个重要环节。
由于第一次做这样的项目，前期的数据准备不合理，项目测试设计难免存在着一些问题，在项目进行过程中遇到了种种问题，比如说工具的使用问题，在测试执行过程中为了准备虚拟数据，设计SQL脚本就延误了项目大部分的时间，出现的问题如下：
1. 前期需求理解不充分（需求理解时间太短），测试计划中给予需要理解的时间不足，所以如果对于一些功能点理解的不充分，这样就会将问题遗留到测试执行过程中，然后你会在测试执行中把问题提出来，与客户交流，这必然导致项目的延期。
2. 工具使用不熟练，事实上，如果对一个项目进行性能测试，人员配置方面一定要有(至少一位)有性能测试经验的工程师来参与项目，这样可以降低项目的风险，由于该项目组有经验的工程师出差，所以只好由我们无经验的人员在自学或培训的情况下参与该项目的测试工作，在这样的情况下，我们会有一段熟悉学习测试工具的时间，显然自己学习理解过程当中会有很多问题，未解决的问题就会带到项目执行过程当中，而且在项目执行过程当中也会遇到不预期的错误，问题解决就会耗去一部分时间。
3. 最重要的一个环节，就是虚拟数据的准备，当然第一次做这样的项目在这方面并没有太多的经验，在测试执行中，才进行SQL语句的设计，数据的添加，在测试执行过程中，SQL语句的设计就会用掉大部分时间。
改善建议
据以上问题，结合在这个项目中的经验，给出以下几点性能测试方面改善的建议，在大家以后进行性能测试的项目中避免这样的问题再次发生，使项目能够按照进度顺利的完成，达到预期的测试目的。
1. 需求理解方面，建议针对一些准备测试的功能点一定要理解充分，若发现问题，尽早与测试负责人或客户进行沟通并解决问题，避免将问题遗留到测试执行中去解决；在做测试计划时，要根据项目的大小以及客户给予的工作量合理安排需求理解的时间。
2. 工具使用方面，大家可以在平时业余时间进行学习，一个项目结束与另一个项目启动之间一般会有一段时间空闲，在这段时间可以去学习测试工具，并且要具有针对性的学习，不要盲目的学习（既学LR，也学QTP），尽量学懂一门后再学一门（达到基本会用该工具做项目），不要急于求成，在学习的过程中将学到的东西做一个学习笔记，方便你以后的查阅；测试组也可以适当的为员工做培训。
3. 虚拟数据的准备方面，在性能测试的项目中一般都会分为两种情况：
1) 固定用户量，数据库中数据量的递增，测试该功能点的性能；
2) 固定数据库数据量，用户数量递增，测试该功能点的性能，其实，这样就会分为两个测试用例（当然这不是全场景测试），譬如：
TestCase 01：20用户在线，共有200个项目，定制显示默认（20条/页，8列/页），在数据库中其他项目记录数不断增加的情况下，系统的相应时间。
TestCase 02：用例描述： 固定数据库问题数为20万条，使用的项目问题卡数量1000，自定义显示（20条/页，8列/页），浏览用户不断增加的情况下响应时间；
情况一（建议后）：前提条件：TestCase 01与TestCase 02浏览的数据（问题卡 ）访问的是数据库同一张表；
1> 当你添加5万条数据，执行TestCase 01，记录结果；然后再添加5万条数据，数据量就是10万，再执行TestCase 01，记录结果；
2> 当添加的数据等于20万的时候，也就是TestCase 02的固定使用数据量，你就可以将TestCase 02的测试场景设计的用户量设置为10、15等等依次执行完TestCase 02这个用例，记录结果；
这样就是全局考虑，简单的说就是考虑每个测试用例中数据会使用数据库中的哪一张表，也许会有很多测试用例使用同一个数据库表，这样就要考虑到表中的数据量递增到多大的时候，执行哪一个测试用例，不是一味的按照一个测试用例，添加虚拟数据，一直到执行完该用例后，等执行下一个用例时，将该表的数据全部删除，再继续添加该用例要求的数据量。
情况二（建议前）：如果你一直添加数据执行完TestCase 01，你在执行TestCase 02的时候数据库该表的数据量已经到达50万，TestCase 02的固定使用数据量为20万，你还需要写一个SQL脚本去删除30万的数据量，才能到达TestCase 02执行时需要的数据量，所以这样就比情况一多了一步写SQL脚本删除数据的过程，其实并不是多了一步，其中：T2（情况二的时间）＝T（书写调试sql的时间）＋T（执行删除30万数据量）；对于30万的数据量的删除时间也会是比较长的一段时间，所以说改善后的方案T1（情况一时间）<T2（情况二的时间）。
总之，当然这是对于两个用例访问的都是同一个表，如果多个用例都会访问到一个表时，就可以全局考虑，在测试设计的时候就应该将这些考虑进来，将执行步骤或者执行方案写成文档，来指导测试执行，这样就不会在测试执行添加数据时盲目的按照测试编号顺序的去添加数据，执行测试用例，不考虑测试用例之间数据准备时候的联系，而是可以根据设计好的测试大纲和文档进行有效的测试执行，测试数据的准备可以按照如下流程进行：一、书写测试用例；二、根据测试用例整体考虑，设计出SQL脚本，并且可以做一个文档，记录SQL编号与测试用例之间的对应关系，同时要写出执行测试用例的顺序，其中这个顺序并不是按照测试用例里面的编号顺序执行，三、测试执行，按整体设计出的"添加数据及测试流程"进行执行。下面是整个顺序的设计测试流程以及几个文档的模板，大家可以见解一下。
一、 书写测试用例：
Testcase 01用例描述：固定用户为30人，页面显示（50条/页，4列/页）。每统计用户使用的日报数据不断增加的情况下响应时间。
Testcase 02 用例描述：固定日报数据为30万条。每统计用户使用数据固定为1万条。页面显示（50条/页，4列/页）。浏览用户不断增加的情况下的响应时间。
根据以上测试用例，就可以设计出添加虚拟数据得SQL脚本了，然后根据以下文档将设计的SQL脚本与测试用例对应记录，然后再设计出测试流程。
二、 书写SQL脚本
如：declare
p number;
q number;
begin
p :=15424;
q :=0;
while p<=15503 loop
select qmtools.PRPROBLEMSEQ.nextval into q from dual;
INSERT INTO PRPROBLEM ( PRPROBLEMID, PRRECORDID, PRPBTYPEID, PRBDESCRIBE, PRESENTER, SOLVE, STAFFID,
FACTSOLVEDATE, FACTEFF, PRSTATEID, MODULEID, CONFIRMSTAFF, CONFIRMDATE, PREFLAG, MEMO, PREWORKLOAD,
POSITION, PBMOVEKIND, MILESTONEID, PBGRADE, PBPINCHEFF ) VALUES (
q, p, 42, 'ertre', 'pmz5', 'erteert'
, 5489, TO_Date( '12/16/2006 12:00:00 上午', 'MM/DD/YYYY HH:MI:SS AM'), 33, 2, 8903
, ' ', NULL, 0, 'ertret', 0, 'ert'
, '需求理解', 0, 'C', 3);
p :=p+1;
end loop;
end;
将该SQL脚本命名为S1，记录到下表：
该表主要为了使设计的SQL脚本和测试用例依次对应起来，而且将变量描述清楚，有利用设计测试流程，而且当执行这些SQL语句时会明白每个变量其中的含义。
三、 设计测试流程
根据以上脚本与测试用例对应表以及测试用例，当执行SQL脚本和Testcase01时，数据量达到30的时候，也就是Testcase02的固定数据库的数据量时，这时候，设置Testcase02的场景，就可以将Testcase02的所有情况执行完毕，也就是Testcase02的优先级最高，执行完后将执行状态打√。所以说整个设计对于以后的执行是非常有好处的，正式开始执行测试用例的时候就可以根据以下设计的测试流程执行SQL脚本和测试用例。
总结
性能测试首先要将这些必要的设计在前期设计好，以免等到测试执行时候进行设计，这样就会延长项目的进度，同时也会造成不预期的风险，希望这篇文章能给大家一些好的借鉴，同时也希望大家能给该方法提出更好的意见和建议，提高我们的过程改善的质量。由于时间仓促，难免会有笔误，恳请大家批评、指正。
