ECS测试经验总结
注:这个主要是对于之前的ECS项目的一些总结,由于本人刚工作半年,之前对于性能测试没有什么概念,通过这个项目有门外到了入门阶段,希望通过分享这个文档,给性能测试的新人们一些启发,少走一些弯路~~~有疑问可以联系我QQ:4861165 1.
性能测试需要扎实的软硬件、编码、网络基础,如: Ø
B2C场景的TPS曲线不稳定是由websphere服务器连接池设置过小造成; Ø
中间件也有缓存的概念:B2C航班查询使用了缓存,对短时间内的航班信息缓存起来,因此测试时不能只使用同一个查询操作; Ø
各种监控指标的意义,如cpu指标中system time与user time反映出的问题; Ø
Aix系统下的操作指令以及监控工具的使用 Ø
日志的分析,以及统计方法 Ø
网络拓扑结构对环境的影响 Ø
等等 2.
与功能一样需要熟悉业务需求 Ø
某单场景测试中,查询历史记录的参数只设定了一个日期,造成返回的结果为该日期以后的所有记录,数据库使用率达90%以上,而实际的客户操作不可能查询如此大的数据量,因此脚本的参数设置要事实际业务使用相符。 3.
脚本的正确性是得出有意义测试结论的前提 Ø
如上面第二点所述,脚本的参数设置有问题,造成测试结论认为该查询场景占用过多数据库资源,这个结论是明显不符合实际的 Ø
某次稳定性测试:验证混合场景时,使用随即参数的方式发现有个别报错,手动对报错的参数进行手动验证后,发现没有产生错误,而且参数重新复制粘贴后错误依然发生,因此当时片面认为是服务器处理不及造成,继续实施24小时稳定性测试,结果第二天发现该场景正确与错误事物的比例接近1:1,分析日志后没有发现异常,最后把参数文件删除后重新生成,问题解决,因此推测为参数文件生成出现异常; 4.
每一次的版本更新都应该先验证环境 Ø
B2C系统需验证的点为:特定URL使用了https、404错误链接、重复链接、验证码、出发地与目的地的正确显示等,基本上每次有更新,都需要像功能那样进行回归测试,而且也基本每次都会反复出现之前的错误,因此以后的环境验证需要在每次有功能修改或更新的时候再进行。 5.
有条件要测,没有条件就让项目组创造条件去测 Ø
由于测试环境的局限性以及测试的针对性,不是所有场景都能完全模拟实际生产,如调用了其他系统的接口,又或者某些大并发的测试会造成测试环境的带宽不足,这时可以向项目组提需求,做桩或者屏蔽掉某些不影响测试的代码,有或者去掉一些不关注的URL降低带宽,或直接让项目组提供接口等,但以上的操作都必须充分考虑是否影响性能以及是否可以用更好方法替代 6.
做桩的策略 Ø
第五点的补充,做桩只是一种折中的方法,之前B2C生成订单以及行程单登陆等场景都是用了各种桩和代码屏蔽,而其中一些是不必要且影响了性能的,如屏蔽了身份证的检验,密码的加密算法等,这样直接降低了服务器的运算量,而且这些都可以很好地真实模拟的;而验证码,外部接口的调用要模拟的话需花费很大的代价,因此可以是用桩的方法,但风险评估必须充分考虑这些问题; 7.
要有质疑的精神 Ø
对于项目组或运维等部门提供的资料和环境,一定不能理所当然地认为是正确的,例如网络环境,经常会出现多台服务器接到一台交换机上等明显不符合测试需求的现象,而对项目组提供的系统资料、故障分析报告等,也可能出现描述错误的情况,具体原因比较复杂,作为测试人员,对所有环境和功能都必须亲自验证。 8.
经过验证的测试环境还是很有可能有问题的 Ø
由于系统不是自己开发,因此对系统的环境不一定能完全掌握,之前旧B2C的环境验证虽然已根据文档进行了确认,但单场景测试就出现服务自动关闭,后来询问项目组,推测未websphere 6.0没有打补丁,打补丁后,问题得到解决; 9.
即使是成熟的产品依然可能出现问题 Ø
oracle数据库虽为使用多年的产品,但不代表不会产生问题:稳定性测试过程中发现RAC的一个节点下orarootagent.bin进程占用过多服务器内存,占用量达到10GB以上,造成该节点可用内存不足。通过查询oracle metalink,认定该问题为bug(9794120),升级数据库版本到11.2.0.2后,上述问题未再发生。因此对测试结果还是必须进行细致的分析,不能漏掉如数据库内存等指标 10.
对于供外部使用的系统需进行安全测试,漏洞渗透测试 Ø
B2C系统上线后受到恶意访问,因此认为:对提供外部服务的系统,不能认为其用户全都按照常理进行操作,当中会有黑客对系统进行各种攻击和渗透以牟取利益,因此应加入安全测试增加系统的健壮性和安全性 11.
sql语句缓慢的简单确认方法 其中一种方法为执行脚本过程中,使用PL\SQL中的显示session选项,查看active session中的项,若有长期存在的session,查看其具体信息。 |