51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 7603|回复: 27
打印 上一主题 下一主题

[原创] 一个项目的心得总结

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-5-9 11:34:09 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 wyh1987com 于 2011-5-9 11:37 编辑

之前一个项目的总结,由于我自己也是测试新人,所以总结的东西也比较表面啦,仅供新人们相互交流
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2011-5-9 11:37:37 | 只看该作者
汗,发不出附件
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2011-5-9 11:39:26 | 只看该作者


ECS
测试经验总结

注:这个主要是对于之前的ECS项目的一些总结,由于本人刚工作半年,之前对于性能测试没有什么概念,通过这个项目有门外到了入门阶段,希望通过分享这个文档,给性能测试的新人们一些启发,少走一些弯路~~~有疑问可以联系我QQ4861165

1.
性能测试需要扎实的软硬件、编码、网络基础,如:

Ø
B2C场景的TPS曲线不稳定是由websphere服务器连接池设置过小造成;

Ø
中间件也有缓存的概念:B2C航班查询使用了缓存,对短时间内的航班信息缓存起来,因此测试时不能只使用同一个查询操作;

Ø
各种监控指标的意义,如cpu指标中system timeuser time反映出的问题;

Ø
Aix系统下的操作指令以及监控工具的使用

Ø
日志的分析,以及统计方法

Ø
网络拓扑结构对环境的影响

Ø
等等

2.
与功能一样需要熟悉业务需求

Ø
某单场景测试中,查询历史记录的参数只设定了一个日期,造成返回的结果为该日期以后的所有记录,数据库使用率达90%以上,而实际的客户操作不可能查询如此大的数据量,因此脚本的参数设置要事实际业务使用相符。

3.
脚本的正确性是得出有意义测试结论的前提

Ø
如上面第二点所述,脚本的参数设置有问题,造成测试结论认为该查询场景占用过多数据库资源,这个结论是明显不符合实际的

Ø
某次稳定性测试:验证混合场景时,使用随即参数的方式发现有个别报错,手动对报错的参数进行手动验证后,发现没有产生错误,而且参数重新复制粘贴后错误依然发生,因此当时片面认为是服务器处理不及造成,继续实施24小时稳定性测试,结果第二天发现该场景正确与错误事物的比例接近1:1,分析日志后没有发现异常,最后把参数文件删除后重新生成,问题解决,因此推测为参数文件生成出现异常;

4.
每一次的版本更新都应该先验证环境

Ø
B2C系统需验证的点为:特定URL使用了https404错误链接、重复链接、验证码、出发地与目的地的正确显示等,基本上每次有更新,都需要像功能那样进行回归测试,而且也基本每次都会反复出现之前的错误,因此以后的环境验证需要在每次有功能修改或更新的时候再进行。

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,查看其具体信息。

回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2011-5-9 11:39:51 | 只看该作者
12.        某些场景无法准确模拟时应退而求其次
        如存在验证码的场景,可以通过屏蔽掉验证码或加入白名单的方式进行测试;
        B2C恶意访问中,由于测试环境的带宽成为瓶颈不能很好地模拟生产,因此删掉其他URL,保留关键的URL进行测试

13.        对无法解决问题的推测和求证
        对某稳定性测试性能下降的推测:TPS值随时间的推移不断下降,推测为数据库记录逐渐增加,查询速度变慢
        三链路下TPS差异巨大:通过两两链路的组合进行测试,发现某两条链路相互影响,推测为该两条链路共用了一个交换机
        P6,PC环境TPS差异大:通过部署相同版本对比验证,推测为网络和版本差异造成的影响



14.        做事要灵活
        统计日志的方法:对B2C系统各个场景的访问数进行统计时,不应该执着于找到对应的,唯一的标记场景的串,那样不现实,即使项目组提供的串也不能唯一地标记场景,应该使用两个串来标记场景:采用日志同一行中前一条和后一条的串进行判断,能更准确地标记出场景,而且实现方法与查找一个串的方式一样简单;
        不必拘泥于测试方式:具体情况具体分析,不必每次测试都遵循同样的方法,如测试都从一个并发开始,都使用LOADRUNNER进行监控等,实际上,应该从节约成本的角度上考虑,不能用LOADRUNNER监控的数据就用其他工具监控,如websphere,几时使用sitescope,占用的资源也是十分大的,而且时间长了后容易造成系统不稳定,不如使用websphere自带的监视器。


15.        要了解某个不熟悉的工具,软件系统时,应该直接查看其使用文档,而不是先到网上查
        测试经常面对不同的系统和技术,因此需学习不了解的内容,之前总是习惯直接百度一下,但后来多次实践中发现这样往往会影响效率,因为网上很多人云亦云的现象,很多文章和技术论坛的内容都是反复的复制粘贴,作者很多都没有经过验证就随便发表,如之前的sitescope配置,方法与网上差异较大,前期浪费了很多时间研究网上的步骤,后来直接看软件的文档,很快就解决了问题(即使是英文文档,也比看网上错误的中文文档要快)

16.        发现问题时的排除顺序
        网上盛传的排除性能问题的顺序为:硬件》中间件参数》数据库sql》程序代码,经过ECS系统测试后,个人认为应该是:质疑脚本的正确性》质疑测试环境》硬件》中间件参数》数据库sql》程序代码;

17.        loadrunner只是压力生成工具,分析要靠日志和其他工具
        loadrunner是优秀的负载工具,但反馈的现象是经过loadrunner处理后抛出的,没有分析的意义,对于出现的性能问题,重点还是查看服务器的日志信息,以及依靠其他的内存分析工具,数据库监控工具等

18.        对并发数,TPS的策略
        假设ihs提供的访问日志信息是正确的,但我们依然不应该根据日志的最大处理数作为TPS的唯一依据,因为日志记录的仅仅是系统在该点时间上处理过的请求数,不能反映在某一点上用户的访问量,这个在之前的测试就有过疑问,而在B2C恶意访问上更能清晰反映这个问题:在大并发下,不管是请求丢失还是IHS日志记录不完整,但日志上的确没有记录下所用的请求。同样地,在生产中,如果在高峰期下某些用户的请求超时没有处理或某种原因被丢失了,而IHS上没有记录下这些信息,那么我们根据ihs统计出的TPS值肯定不能准确反映出系统应该要承受的压力。而这却正是性能测试的前提,因此必须找出正确反映用户访问量的方法。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2011-5-9 11:40:08 | 只看该作者
将就着看吧。。不会发附件
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2011-5-11 13:43:46 | 只看该作者
呵呵,学习了。。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2011-5-12 18:33:47 | 只看该作者
鼓掌支持,谢谢分享
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2011-5-12 23:08:52 | 只看该作者
学习了,感谢楼主。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2011-5-12 23:25:02 | 只看该作者
贡献经验!顶一把!
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2011-5-12 23:48:48 | 只看该作者
好东西  看看
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2011-5-19 13:52:42 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2011-5-19 16:01:35 | 只看该作者
呵呵,学习了!
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2011-5-19 16:02:46 | 只看该作者
呵呵,学习了!
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2011-5-19 16:27:31 | 只看该作者
学习了
3Q
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2011-5-20 09:37:33 | 只看该作者
顶一下
回复 支持 反对

使用道具 举报

该用户从未签到

16#
 楼主| 发表于 2011-5-22 18:14:58 | 只看该作者
第一次发有这么多人看的帖子。。。
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2011-5-24 10:33:42 | 只看该作者
回复 16# wyh1987com


    哥也是87的呀
回复 支持 反对

使用道具 举报

该用户从未签到

18#
 楼主| 发表于 2011-5-30 21:35:20 | 只看该作者
回复 17# lihailing


    在哪工作呢
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2011-5-31 10:54:38 | 只看该作者
回复 18# wyh1987com


    广州
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2011-6-10 18:34:42 | 只看该作者
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-25 14:32 , Processed in 0.077120 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表