现在一说性能测试、性能调优，好多人首先想到的是用LOADRUNNER等测试工具，好像没有这些工具就不能进行性能测试就不能进行性能调优。真是这样的吗？其实工具

　　固然重要，但更重要的是系统的分析、测试案例的设计。正好刚刚结束了一个软件性能测试的项目，有些感触，整理一下，也为了给大家一个参考。

　　前段时间一直在搞自动化测试框架SAFS、STAF等方面的东西，那个确实比较难搞。领导突然安排去做一个性能测试项目，已经近4个月没有搞性能测试了，心里

　　确实有点没有底。配置的人员也比较少，并且经验也不足。我们首先分析了系统架构、业务特点、运维数据。发现系统的性能和用户数的多少并没有太多的关系，

　　初步确定是因为某些模块的程序编写有性能缺陷。在运行程序时，明显发现有些功能响应缓慢。因为时间比较紧，并且测试环境并不是独立供性能测试使用，功能

　　测试也在同一环境下进行，并且还没有给我们开通数据库DBA权限和服务器操作系统的超级用户权限，限制非常多，所以我决定分两步进行，让其他同事编写性能测试

　　测试案例和脚本，我来分析系统响应时间缓慢的原因，初步判断应该是数据库方面的原因。因为给我开通的数据库用户只有查询权限，所以我只能用SQL语句来查询

　　追踪后台运行的SQL，通过select sql_text,sql_id,users_executing,executions, loads from v$sqlarea;来查询后台正在执行的SQL,通过得到的SQL_ID查询SQL语句

　　select * from v$sqltext where sql_id ='75yzszjxyrrva'，然后根据HASH_VALUE得到完整的SQL,select * from v$sql where hash_value='2079055722'.捕获SQL后发现

　　两条SQL语句运行较慢：

1、select b.case_id,report_no,report_time,b.organ_id,realname,accident_time, reporter_name,accident_type,certi_type,register_id, recorder_id,  certi_code,  accident_status, has_image, accident_type, diff_date,   to_char(max(ti2.scan_time), 'YYYY-MM-DD HH24:MI:ss') as scan_time from (  select distinct tcc.case_id,tcc.case_no as report_no,tcc.report_time,tcu.real_name as realname,tcc.accident_type, tcc.accident_time,tcc.register_id,tcc.reporter_name,trc.certi_type,trc.certi_code,tcc.accident_status,tcc.recorder_id,tcc.organ_id,tcc.case_type,  sysdate - trc.insert_time as diff_date,decode(ti.case_id, null, -1, 1) as has_image  from t_report_case trc ,t_claim_case tcc,t_customer tcu,t_image ti ,t_employee te where trc.case_id = tcc.case_id  and tcc.case_id = ti.case_id(+)  and tcc.register_id = te.emp_id  and tcc.register_id = 3381221 and tcc.insured_id = tcu.customer_id(+)  and tcc.case_status=4  and tcc.case_type = te.case_type   )b  , t_image ti2 where ti2.case_id(+)=b.case_id     group by b.case_id,report_no,  report_time,      b.organ_id,       realname,       accident_time,       reporter_name,       accident_type,       certi_type,       register_id,       recorder_id,       certi_code,       accident_status,       has_image,     accident_type,       diff_date order by has_image desc,report_time asc

　　执行用时6.672秒。

2、(   select tpp.prem_id,tpp.policy_id,tpp.fee_type,tpp.pay_mode,           tpp.fee_status,tpp.actual_prem,tpp.due_time,tgp.holder_id as customer_id,           tgp.send_code,tgp.policy_code as policy_code, tpp.policy_type,          tpp.insured_id,tif.insured_num,' ' as notice_code      from t_policy_prem tpp,t_group_policy tgp,t_insured_first tif    where  ((tpp.fee_status=0 and tpp.pay_mode in(1,2))or(tpp.fee_status in(0,3,4) and tpp.pay_mode=3))      and tpp.fee_type= :1      and tpp.insured_id=tif.insured_id(+)      and tpp.policy_id=tif.policy_id(+)      and tpp.policy_type = '2'      and tpp.policy_id = tgp.policy_id      and tgp.send_code = :2  )  union  (   select tpp.prem_id,tpp.policy_id,tpp.fee_type,tpp.pay_mode,           tpp.fee_status,tpp.actual_prem,tpp.due_time,tp.holder_id as customer_id,           tp.send_code,tp.policy_code,tpp.policy_type,           tpp.insured_id,tp.insurant_num as insured_num,' ' as notice_code      from t_policy_prem tpp,t_policy tp    where 1=1      and  ((tpp.fee_status=0 and tpp.pay_mode in(1,2))or(tpp.fee_status in(0,3,4) and tpp.pay_mode=3))      and tpp.insured_id is null      and tpp.policy_type in ('1','3')      and tpp.fee_type= :3      and tp.send_code = :4       and tpp.policy_id = tp.policy_id     )    order by due_time,fee_type

　　执行用时4.8秒左右。分析这两条SQL语句的执行计划，SQL1的COST值是一个天文数字，SQL2的COST的值是1700多，不算太高。明显第一条SQL语句需要优化，分析SQL1后

　　建议优化为：select b.case_id,report_no,report_time,b.organ_id,realname,accident_time, reporter_name,accident_type,certi_type,register_id, recorder_id,  certi_code,  accident_status, has_image, accident_type, diff_date,   to_char(max(scan_time), 'YYYY-MM-DD HH24:MI:ss') as scan_time from (  select distinct tcc.case_id,tcc.case_no as report_no,tcc.report_time,tcu.real_name as realname,tcc.accident_type, tcc.accident_time,tcc.register_id,tcc.reporter_name,trc.certi_type,trc.certi_code,tcc.accident_status,tcc.recorder_id,tcc.organ_id,tcc.case_type,  sysdate - trc.insert_time as diff_date,decode(ti.case_id, null, -1, 1) as has_image,scan_time  from t_report_case trc ,t_claim_case tcc,t_customer tcu,t_image ti ,t_employee te where trc.case_id = tcc.case_id  and tcc.case_id = ti.case_id(+)  and tcc.register_id = te.emp_id  and tcc.register_id = 3381221 and tcc.insured_id = tcu.customer_id(+)  and tcc.case_status=4  and tcc.case_type = te.case_type   )b       group by b.case_id,report_no,  report_time,      b.organ_id,       realname,       accident_time,       reporter_name,       accident_type,       certi_type,       register_id,       recorder_id,       certi_code,       accident_status,       has_image,     accident_type,       diff_date order by has_image desc,report_time asc

　　修改后的执行用时是0.047秒左右。

　　第二条SQL比较麻烦，通过用具体数据替代绑定变量执行速度很快，而在程序中却很慢，真的不知道是什么原因，与开发人员通过写日志逐行对代码进行检查，发现

　　在receivedao.java文件中checkFullARSENDCODE(String s)函数中有这这行代码，

　　preparedstatement.setLong(4, Long.parseLong(s));检查数据库，SENDCODE字段是字符型，传递的参数却是LONG型，

　　更改为：preparedstatement.setString(4, Long.parseLong(s));

　　效率明显提高，因为在SQL语句中传入的参数类型错误，如果传入的是长型就不走索引了，是全表扫描。这样的错误还真不好发现啊！

　　通过这个例子，可以发现，不用自动化工具，不用编写脚本就可以发现一些明显的性能瓶颈的。

本文出自lovetest007的51Testing软件测试博客：http://www.51testing.com/?198071

版权声明：原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。