回复 18# 的帖子
我还没写完呢，希望继续关注并就文中的任何问题和我讨论。:lol 原帖由 小肥羊 于 2009-2-5 15:28 发表 http://bbs.51testing.com/images/common/back.gif刚接触性能测试和LoadRunner，LZ的这番总结给人的压力很大啊
很大
我又不是你boss，有什么压力:lol
还有就是，负载，压力，性能是三种不同的测试，有时间也想跟大家讨论一下。实际工作中，确实是很不同的三个东西。 楼主很强，这那像刚做性能测试的。写的不错，自己亲身经历的性能测试很烦人，再加上有些客户也比较BT。那就更没治呢。。。。。
期待楼主的更新，更新结合一块，出个完整版，很赞！！！ 写的不错 我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的 写的不错 我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的 楼主总结得不错,很符合实际过程中性能测试的实况,期待与楼主的交流!:loveliness: 很好哦 楼主厉害 谢谢啦 确实不错，小弟刚好也在做这方面的测试。以后多交流。
新手
看了比较多软件工程方面的书，对自动化测试工具没多少了解。觉得楼主说不是所有的测试都需要自动化说的很对。也让我压力稍微小了一点了 这么多人顶，我决定先顶再看 看完了到目前为止，楼主写的内容，确实不错，把性能测试的一些要点和注意事项，存在的问题都写了出来
但其中有一处，我提个建议：楼主在文中有提到了“功能点”这个概念，功能点是一个作为软件规模的国际衡量单位，类似于米，厘米，千克，秒等，楼主的“不是所有的功能点都需要做性能测试”就如同“不是所有的米(厘米，秒等）都需要做性能测试”，意思虽然清楚，但表达上个人建议为不是所有的功能特性，以免歧意。
另外楼主说的负载，性能，压力三大测试，我个人观点是，负载和压力是性能测试的涉及领域，但性能测试不仅止于此，还有如：资源占用情况，可扩展性测试，稳定性测试等，期待楼主继续 原帖由 yzylion 于 2009-2-8 17:00 发表 http://bbs.51testing.com/images/common/back.gif
看完了到目前为止，楼主写的内容，确实不错，把性能测试的一些要点和注意事项，存在的问题都写了出来
但其中有一处，我提个建议：楼主在文中有提到了“功能点”这个概念，功能点是一个作为软件规模的国际衡量单位， ...
非常感谢你的细心提醒，我是按照function point的字面理解用了这个词，现在看来确实是错的。已经做了修改。 原帖由 123 于 2009-2-6 21:30 发表 http://bbs.51testing.com/images/common/back.gif
写的不错 我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的
还是不很确定你问的具体内容是什么，如果按照帖子里面的内容，lr监控哪些指标是从需求中来的，如CPU占用，内容剩余量，磁盘IO等。lr实际上是把windows或者linux的性能监控结果读出来做了一个汇总，监控哪些是从系统提供的几百个指标选出的一个子集。 好文章，顶顶 好文章，顶！ 原帖由 trapezia 于 2009-1-22 09:36 发表 http://bbs.51testing.com/images/common/back.gif
事务的命名很重要，在设计阶段搞定命名可以避免一些麻烦。据个例子：一个网站的10个页面中可能有7个检索，如果这些检索的业务都叫做“search”，那在整理报告的时候就很难分清哪个是哪个。对于事务的命名，放置的位置，一些规约性的东西，要提前约定好，因为脚本不一定是一个人开发的。需要保持团队之间的一致。一些大家都要使用的共性的东西，比如服务器IP，参数，公共函数，文件，数据文件等，PM要在项目的早期就开发好并编制使用方法文档，作为项目资源约定和规范下来，这个和开发项目有相似性。
很实用！ :lol 很用心的总结。 顶下~文章还得细细品味.... 祝大家元宵节快乐！大家的关注和支持给了我很大的动力。
*************************************************************
今天更新一小段，说一下测试执行的记录问题。
测试执行的原始记录是重要的成果（可能也是唯一的，尤其是测试结束很久以后，原有的场景和结果很可能已经被清除了。）对测试用例和记录的内容、格式的要求都要严格。要求达到什么标准呢？
1.测试现场可追溯。要求根据记录中的内容可以追溯和还原测试现场，比如软、硬件环境；并发用户数；网络环境；场景的组成；测试步骤。说一下场景的组成，一个脚本是由哪些脚本组成的，组成方式，脚本各是做什么用的，要在记录中表述清楚。这些信息在追溯现场、查找错误时都可能会有用。
2.记录的表述要清晰完整。数据、图标、图例要充分，记录不要带有对判定的倾向性，要尽可能全的记录所有的信息。因为记录的数据需要进一步进行分析才能发现深层的结果。“本来是一个推理过程，但当原先的推理一步一步地被客观事实给证实了以后，那主观就变成客观了，我们就可以自信地说达到了目的。”福尔摩斯这句话用在测试中同样有用，测试结果的判定实际上也是一个反向推理的过程，在所有的主观都变成客观之前，不要下结论。
3.唯一标示。呵呵，其实这个东西是让你的记录看起来正式的一个捷径。如果实在做不到IEEE829里面要求的那一大堆东西，先搞个命名准则在搞个唯一标示绝对是捷径。举个例子XN-09-EPORT-01代表了EPORT项目在09年进行性能（XN）测试的第一号用例。
4.目的和需求。该用例执行的目的。比如“用于验证功能A在10用户并发的情况下响应时间是否小于3秒。”或者“功能A，功能B，功能C按照50%，20%，30%比例分配，200用户并发情况下，系统可否正常运行12小时。”
————————————————————————————————————
用例编号 |XN-09-EPORT-01
————————————————————————————————————
需求 |功能A，功能B，功能C按照50%，20%，30%比例分配，200用户并发情况下，
|系统可否正常运行12小时
————————————————————————————————————
前提条件 |网络畅通
————————————————————————————————————
预期结果 |12小时平均CPU占用不超过50%，平均可用内存大于1500M，磁盘等待队列小
|于0.5，事务A响应时间小于X秒，事务B响应时间小于Y秒，
————————————————————————————————————
场景描述 |脚本A主要功能为..预热20分钟，20分钟后达到最大压力并持续12小时。
|脚本B.....
————————————————————————————————————
实际结果 |
————————————————————————————————————
结论 |
————————————————————————————————————
记录人 | trapezia | 时间 |2009年02月09日12:30
———————————————————————————————————— 楼主
“预期结果 |12小时平均CPU占用不超过50%，平均可用内存大于1500M，磁盘等待队列小
|于0.5，事务A响应时间小于X秒，事务B响应时间小于Y秒，”
这类具体的需求是客户给的还是你们自己根据经验来设定的？
