请教：在录制好的网页访问脚本中“屏蔽图片和css下载”后的测试结果合不合理？
最近在测试一个案例，发现一个查询场景支持的并发数很少，而且响应时间很长，不符合性能要求。通过查看脚本，发现里面有很多css和图片下载，在脚本中屏蔽掉图片和css下载后重新测试了一下，在相同的并发用户下，响应的时间非常快，不到一秒，能够满足性能要求。我初步研究了一下，css和图片只要访问过一遍以后都会保存在ie的本地缓存中，这样下次访问时只要没有变化都不需要重新下载，只需要进行一个是否更新的对比即可。在脚本中屏蔽掉图片和css下载后，连请求也一起屏蔽了，所以实际性能肯定不如测试结果，但不知道影响有多大！
现在我的困惑是第二种测试方式能不能作为最终的测试结果？还是第一种方式更合理些？请大家指教，谢谢！
[ 本帖最后由 billy 于 2008-11-11 01:58 编辑 ]
个人观点，仅供参考
第二种测试方法作为某一功能的性能测试是可以说明的。但是问题是用户是不是会有同样的感知？我相信用户可能不会有这种观点，他会问为什么下载这么慢。我觉得，网页的设计本身就可能存在问题。另外，如果只是读取本地文件而不从服务器读取，也是不正确的。读取是最重要的是对服务器产生压力，而不是对客户端。何况，今后的实际情况是不同的客户端发起，不太可能会存在这种情况。
如果作为一个模拟真实的测试场景，这些内容是不应该被屏蔽的。更合理的应是第一种情况（即CSS和图片等下载包含在内进行测试）。 顶楼上，
真实模拟用户操作，不要以开发的眼光来看用户，用户是“无知”的，用户什么都“不知道”，
一个系统开始进行测试的时候，在测试过程中一般是不允许对其进行修改。 谢谢楼上两位的回答!:)
可能有些情况我没有说清楚,我们的用户群基本是固定的,所以基本都是老用户,一般在本地缓存中都会保存有下载过的文件!这种情况下第二种测试方式能不能作为最终的测试结果呢？ 我觉得还是要以第一种情况，
LZ说的很有道理，但是难免有些用户会不定时重装下系统，或者经常清理下缓存，或者外出办公等等情况。
我觉得还是要以程序为主，以程序为本，build出来的程序是什么样的，我们就用这样的程序来测试，不要过多的对程序修改。
如果LZ很质疑，不妨用上面说到的两种情况测试两遍，相互比较，写入一个报告中。 难免有些用户会不定时重装下系统，或者经常清理下缓存，或者外出办公等等情况。
上面这些情况肯定都是存在的，但都是少数的基本可以忽略不计，比如系统有100个用户，每天有5个这种情况的都算多了吧，何况都不是同时下载，所以对服务器的影响非常有限！
这两种情况当然可以都做，但关键是现在一种通过，一种不通过，不知道应该拿哪个结果来评判啊，尤其是设计到验收外包商的程序时，更是需要一个评判标准！
请问楼主
请问楼主，您在脚本中是怎么把页面的图片和css屏蔽掉的？？？？我是个新手，请教教我另外，我也支持第一种测试方法。 屏蔽的方式很简单，在代码中找到css和图片等的代码注释掉即可！ 今天讨论的结果如下，大家看看合不合理？
1、100个用户并发且都是第一次访问这个页面对服务器的压力如何测试：采用录制的不加任何修改的脚本直接模拟100个用户并发进行测试，这点相信大家都没有什么意见！
2、100个用户并发且都是第二次访问这个页面对服务器的压力如何测试：采用录制后屏蔽掉css和图片下载的脚本模拟100个用户并发进行测试，测试结果加上10％的时间作为测试的结果，例如并发测试结果90％平均响应时间小于2秒，则取2.2秒为最终测试结果，这个添加的百分比可以根据评估增加或减少。为什么要加上一个百分比作为最终测试时间呢？因为如果屏蔽了css和图片下载的脚本，则测试结果肯定会比实际性能好，因为这个场景对服务器的压力应该由未屏蔽的脚本和屏蔽的css和图片下载脚本两部分的压力组成的，css和图片下载在实际第二次访问场景中虽然不会真的下载css和图片，对服务器产生下载那么大的压力，但还是对服务器有同样的请求数，只不过传输的数据没有那么多而已，所以要加上屏蔽掉的这部分压力影响！当然这个百分比不准确，要靠经验来评估了！ 顶下 我觉得要分析一下：
如果用户都是会重复登陆，那么第一次下载图片和CSS等文件应该影响不大，如果在页面标注第一次使用会加载缓存等提示，用户会期待第二次登陆的速度，这样对用户来说是可以接受的；
但是如果每次用户都是清除缓存重新登陆，或者都是新用户，那么你无法忽略下载图片和CSS的问题。 同意楼上兄弟的意见，都是新用户或清过缓存后登陆那肯定要考虑下载图片和css的情况，但我这个场景是绝大部分用户都是老用户，而且没有清过缓存的，所以应该不用考虑实际下载，但同样有请求到服务器那边，现在就是不知道这个请求的影响会有多大，应为图片和css很多，所以感觉不能忽略，如果只有几张图片和几个css，这些请求的压力基本应该就可以忽略了；
页:
[1]
