你的报告写的让一般人看上去得不到重点,感觉你就是在记录,没有针对性的分析用例的性能情况,只是罗列。
这就是我乍看的感觉,但是你写的还是比较细,作为报告,模板应该是有的
谢谢,在分析上,我是很欠缺的。 老实说,太细节了,没有重点。看完了也不知道哪里有问题。
一个静态的JS - public.js 这么慢,一定哪里有问题了。
这个报告不是在提供解决意见,而是在陈述问题。 看看呢,学习学习哈
回复 1# 的帖子
谢谢分享!!:victory: 谢谢分享,楼主加油 写的比较详细,感谢楼主共享资料,学习了。 :) 自己需要学习的地方还很多啊 向楼主学习这种共享的精神。这个觉得叫性能测试结果更适合,如果要写成正规的测试报告的话,这个报告里面的内容相当测试结果那一部分。
要写报告的话:
首先先要写测试目的和环境、测试计划,接着是测试的基本数据信息,然后才是测试步骤和结果(例如楼主的报告内容),然后是结果统计和分析,最后给出测试总结和调优建议等。如果正式生成报告的话需要这些内容。 这个响应时间你理解的可能有点问题
如果你在这么大压力下 同时进行手工操作的话 可能你会对你的响应时间产生疑问
这个响应时间是算上用户等待的时间 所以是不准确的 不喜欢东软....
回复 49# 的帖子
说的对,谢谢,不过因为对结果分析有限,所以就这样写的,以后还要加强分析能力。 学习学习 顶一下,看看! 学习一下! 事务粒度太粗了 感觉太繁琐了,最好整理下,报告是越简洁越好(前提是把该写的描述清楚就行了) 感觉跟我第一次写性能测试报告一样,分析来分析去,没有分析到重点——其实就是什么都没分析出来。:lol
仔细看了一下报告,感觉很多情况都和当时我测时的一个样。
比如细分时firstbutter时间很长,再一查看,主要消耗是servertime;cpu队列数超过2;加载十几个用户,CPU占用就上去啦;90%的用户响应时间都很长;context switches/sec值在15000以下等等。
不过开发其实不关注这,也看不懂那些数据,只想知道哪些页面响应比较慢,慢的原因。而这些从这上面是看不出来的(至少不明显)。
记得当时找原因实际上是用了各种profiler,比如sqlserver和vsstdio的,并且是和开发协同分析完成的,中间还多次迭代(就是测了改,调优后再验证,如此往复多次)。 楼主,请教页面的响应时间究竟怎么测试啊?
我现在正测这个,若把页面从打开到加载完毕定义为一个事物,除开think time后页面打开只有零点几秒,明显的不正确,怎么才能测到页面的响应速度啊?000000000000000000 学习了我也要写第一个报告了 向你学习了还有楼上的兄弟姐妹们 给我们这些新手提供了很多建议 谢过大家