51Testing软件测试论坛

标题: 【2月9日更新】性能测试过程手记 [打印本页]

作者: trapezia 时间: 2009-1-15 17:29
标题: 【2月9日更新】性能测试过程手记
最近刚做完一个不大的但是比较完整的性能测试项目，趁热打铁想总结一下，因为本身也很菜，怕总结的不全，所以帖出来供大家讨论。我也好收集一些好的建议和知识。我会持续更新这个帖子的。希望大家支持。
先从性能测试的过程开始说起吧：
性能测试组成
1.测试策划
被测系统概述、测试目标、测试范围、定义需要测试/不需要测试的特性；分析测试设备、人员、时间等资源情况；最后生成《测试计划》。
从待测试系统提交到开始着手进行测试，需要面对测试需求\范围不明确，测试资源不明确，测试目的不明确等问题，而测试策划的阶段主要就是来应对这几个问题。其中对测试需求不明确要尤其加以重视，越来越多的信息系统使用方开始关注性能，但是由于性能测试处于初级阶段，许多系统只是要做性能测试，但是对于性能测试的目的、方法、重点等考虑的不到位。这就可能导致在花费时间、金钱进行了性能测试后发现得到的和预期的不同，或者性能测试没有有效避免后期的性能故障。
性能测试是在功能性测试完成后进行的，在进行性能测试设计时，需要分析哪些功能点要测试，哪些不测试。9

[ 本帖最后由 trapezia 于 2009-2-9 19:41 编辑 ]

作者: jiang860718 时间: 2009-1-16 09:17
能不能把完整的测试计划发上来看看啊？学习一下！

作者: trapezia 时间: 2009-1-16 10:22
回楼上的，因为目前项目还没有结项，所以暂时资料还不能发布，过一段时间我会发的。
另：如果关注测试计划，可以参考国际标准IEEE829，这个对测试计划的文档规范有很详细的描述。虽然事无巨细，但是确实有用。
************************************************************************************
我继续：
-->测试策划阶段分析哪些要测试哪些不要测试？
这个很重要，例如：一些功能，只有管理员在用，而系统管理员总共只有2个，且权限划分不同（其实很多系统的管理功能都是这样的）。还有必要测50用户并发操作吗？显然是没必要。这类功能可能对系统长时间稳定运行更关注（疲劳度测试）。
在策划阶段，需要对每个功能点进行分析。回答下列问题：需要进行性能测试吗？进行哪一类（疲劳的？并发的？大数据量的？速度的？）性能测试？关注哪些性能指标？不关心哪些性能指标？有没有潜在的测试风险（例如测试不完整？测试失败？）。
进行良好的取舍分析，可以有效的避免测试过程中的不必要劳动和目的性不明确的劳动。同时，这种分析也是一个对被测系统加深了解的过程。
-->应对需求不明确。
一个系统来做性能测试，对于PM，什么最可怕？我认为是甲方需求不明确。这有可能造成所得非所想，工期延误，纠纷甚至项目失败。还记得那个经典的“奥运售票系统”第一天崩溃和“欧洲图书馆”第一天崩溃的例子吧。其实说白了都是需求不明确造成的。用户会问：性能测试人员为什么不测试一下800万人并发访问时的服务器负载情况呢？实际情况是：没人让性能测试人员去测试800万人并发访问时的服务器负载情况，因为他们“认为”系统只会有800个人访问。
如何拿到合适的需求信息，是一个集合了管理、技术、文档、人性的复合型问题。需要PM，需求方，相关人员的配合。

[ 本帖最后由 trapezia 于 2009-1-16 11:15 编辑 ]

作者: yetties2005 时间: 2009-1-16 10:31
帮顶下。

作者: 星驰 时间: 2009-1-16 10:39
直播中~~~顶！

作者: trapezia 时间: 2009-1-16 11:07
既然版主都来捧个人场，那我今天就多写一点。
2.测试设计
根据测试策划中对人员、设备、测试点、指标分析都的结果，相关人员就可以开始进行测试设计。测试设计的结果是《测试用例、记录》，《测试环境和配置》，《测试脚本和场景》，这些可以是独立的文档，也可以是一个文档。
-->测试脚本和测试场景
我在前面说了测试策划中对测试范围等的选择的重要性，现在，如果进行了良好的测试筛选，哪些部分需要进行哪种类型的测试，就可以直接生成测试用例和场景了。如果在写测试用例的过程中，你还在不断的问自己：“这部分到底还tmd需不需要测试啊？测多久？”那你应该反思第一部分的工作是否到位了。
还有一个需要重视的问题就是测试脚本和测试场景的区别。
测试脚本是录制或者编辑的，用于实现某个功能的脚本。而测试场景则是一些测试脚本通过特定方式组合在一起用于模拟大量用户实际行为的。
这两个有本质的不同，技术人员由于天性，在脚本录制和回放上经常投入大量的时间，对场景考虑的一般都不多，这就导致
--有可能脚本和场景之间有冲突（单独的脚本可以跑，几个脚本一起就跑不了。跑10分钟可以，跑10小时不行。）
--也可能导致脚本录制不全（等到执行的时候才发现某个功能没有录制）。
--更可能导致多余劳动（考虑了半天复杂的技术实现，后来发现场景中根本就没有相应要求。）
作为PM，应该在全局上对项目实际进展进行把握，及时的追踪每个技术人员执行的进度，防范技术人员在过多细节技术问题上纠缠而耽误了整体进度。定期组织小组讨论，对技术问题进行收集，对于影响进度的要及时处理。
测试脚本应该在设计阶段录制还是在执行过程中录制，这个有争议，我倾向于在设计阶段录制，但是确实在实际中执行过程中的修改也无法避免，但是设计阶段脚本考虑的多一些，可以避免时间和进度上的风险。

作者: Zee 时间: 2009-1-16 13:07
继续。

作者: ★星の金币 时间: 2009-1-16 14:43
搬个板凳坐着看~

作者: trapezia 时间: 2009-1-22 09:36
继续更新
*******************
在设计和计划阶段，除了基础的工作，还需要对一些细节进行规定。比如关心的哪些事务和哪些指标，关心的事务的命名。事务的命名很重要，在设计阶段搞定命名可以避免一些麻烦。据个例子：一个网站的10个页面中可能有7个检索，如果这些检索的业务都叫做“search”，那在整理报告的时候就很难分清哪个是哪个。对于事务的命名，放置的位置，一些规约性的东西，要提前约定好，因为脚本不一定是一个人开发的。需要保持团队之间的一致。一些大家都要使用的共性的东西，比如服务器IP，参数，公共函数，文件，数据文件等，PM要在项目的早期就开发好并编制使用方法文档，作为项目资源约定和规范下来，这个和开发项目有相似性。
如果项目需要进行配置管理和文档规范化，PM也要在计划和设计阶段搞定。
>从总体上来说，测试计划应包含哪些内容（欢迎大家指正，这只是我的看法）？
-概述包含项目名称、编号、背景、系统概要说明。
-测试目标包含测试目标列表和相关术语解释
-测试范围包含测试对象（软件）的功能分解和指标筛选，不需要测试的内容
-测试依据测试的标准、文档依据
-测试环境测试的概要环境介绍和资源需求
-其他技术和场景细节例如关注指标的分析和解释
-进度计划谁在什么时间完成什么工作，生成何种内容，有谁负责内容审查。
-关于进度和计划的其他细节

[ 本帖最后由 trapezia 于 2009-1-22 09:39 编辑 ]

作者: archonwang 时间: 2009-1-22 10:02
标题: 总结帖子，送花！

作者: ipkh840122 时间: 2009-2-2 15:50
学习学习

作者: kevin_swpi 时间: 2009-2-2 17:43
期待完结篇
上最终相关文档

作者: spook2008 时间: 2009-2-3 20:51

作者: trapezia 时间: 2009-2-4 15:36
很久没有更新了，过了一个很忙的年，给顶帖子送花的筒子们也拜个年吧。
******************************************************************************
3.测试执行
测试执行阶段，就是一干性能测试工程师在PM带领下，辛勤劳动，不顾白天黑夜的把测试设计内容转化为测试结果的阶段。
曾经有测试同仁跟我抱怨：“黑盒真是枯燥，还是白盒和性能测试好...”我的回答都是：“好个p。”黑盒测试枯燥可能不假，但是性能测试绝对更枯燥。比如说：黑盒测试可能1个礼拜就能见个新面孔，性能测试经常数周都和同一个功能在较劲；黑盒测试关心输入、步骤、输出，性能测试就要和很多个变态公司的产品的变态指标打交道，天天都是看着一堆枯燥的123456...；黑盒测试经常可以学到软件设计思想和业务流程，性能测试能学到的大多都是如果解决编号为XXXX的lr错误，如何从乱七八糟的数据中判断性能故障；最后也是最关键的一点，黑盒测试组经常有mm，性能测试组不提也罢...
综上，性能测试的枯燥指数和BT指数绝对在功能性测试之上，而测试执行阶段就是性能测试枯燥之最了。
经常在网上看到某大公司测试人员说：我们的测试都是自动化地，我们的PM又帅英语又好，我们用英语开着快乐的小组会议，愉快的写着脚本，一杯咖啡过后，结果出来啦...某些网络写手就是这样一边犯贱一边给大家传授错误思想。
以上这些论调哪些是错误的呢？
1.测试不需要都自动化，也不是所有功能[感谢yzylion的提醒，我查过了，你说的是对的]都要进行性能测试，资本家只关心成本和收益（别告诉我bill gates不是资本家）。真正要用性能测试一遍一遍折腾的功能也就那么一小部分，如果大老板让你把所有的功能不加设计都搞一遍性能，先戳他汽车轮胎然后辞职回家。
2.英语好就nb？如果是国内项目，能用中文命名事务就用中文，搞一堆乱七八糟命名方式弄出来的中英文混杂的报告，从又红又专年代过来的领导没有几个喜欢的。
3.小组会议很重要，但是肯定不愉快。如果每个人都按时保质完成任务，那PM搞定设计以后就可以回家休假，该种地的种地，该打渔的打渔。小组会议干什么？提问回答。哪几个问题呢？How？Why？When？
4.写脚本一点也不愉快。这拜如下几点所赐，①lr的易用性差②lr不开源③定位问题耗时太长④其他工具还不如lr⑤51testing的众牛人要么太忙，要么太抠...
5.一杯咖啡的时间什么也干不了，没有几个性能测试能在分钟级别的时间搞定。数小时、数十小时、数天更常见。跑5分钟出来的性能数据没什么价值。

[ 本帖最后由 trapezia 于 2009-2-8 20:49 编辑 ]

作者: trapezia 时间: 2009-2-4 18:57
在家更新一小段。
******************
测试执行确实是非常非常枯燥，同时也极其重要的阶段。再好的蓝图，只有经过建筑才能称为大厦；再好的方案，只有正确执行了才能得到结果。所以，执行性能测试的筒子要有泥瓦匠那样的吃苦耐劳品质和体力。
lr的执行路线是【脚本】--【场景】--【结果】--【分析报告】
脚本是技术人员开发的，但是由于智商过高的原因，很多大侠写的都是不可读代码，他们基本认为其他人不会再读和修改代码了，同时呢自己的代码也不会有错误。不过呢，多花点时间写写注释，改改结构，可以减少你在和mm约会的途中被叫回单位改代码的概率。
从脚本到场景的过程，执行人员需要按照设计文档要求对脚本进行组合，对监控指标进行添加。执行大仙们一般不重视保存场景，因为他们认为不会再第二次执行场景了，准保一次通过，再说再加一次windows啊网络啊was资源什么的也是学习过程。不过如果不想在夜里1点lr controller死机以后，头晕眼花的加那些指标的话，还是烦劳花1分钟保存一下场景并取个好名字。
场景设置完毕，很多人就开始兴高采烈的跑测试了，不过作为PM或者其他执行人员，最好还是再次确认一下场景监控指标的正确性和完整性，如果跑了72小时以后才发现有几个细小的指标忘加了，迎接大家的绝对是免费加班的好日子。
还有，lr8.1的中文版报告模块无法获取windows监控资源，知道的就算了，不知道的加以注意。

[ 本帖最后由 trapezia 于 2009-2-4 20:24 编辑 ]

作者: AJan1000 时间: 2009-2-5 10:01
LZ有才

作者: Gray 时间: 2009-2-5 10:26
情不自禁的顶一个

作者: tester_ran250 时间: 2009-2-5 14:07
标题: 无意中拜读，留言
很久没在论坛中溜达了，今天无意中在坛子中看到了楼主的大作，一口气看完，很赞

作者: creatysun 时间: 2009-2-5 14:41
顶一下，跟楼主颇有同感啊

作者: 小肥羊 时间: 2009-2-5 15:28
刚接触性能测试和LoadRunner，LZ的这番总结给人的压力很大啊
很大

作者: trapezia 时间: 2009-2-5 15:49
标题: 回复 18# 的帖子
我还没写完呢，希望继续关注并就文中的任何问题和我讨论。

作者: trapezia 时间: 2009-2-5 15:52

原帖由 小肥羊 于 2009-2-5 15:28 发表
刚接触性能测试和LoadRunner，LZ的这番总结给人的压力很大啊
很大

我又不是你boss，有什么压力

还有就是，负载，压力，性能是三种不同的测试，有时间也想跟大家讨论一下。实际工作中，确实是很不同的三个东西。

作者: zhangtao 时间: 2009-2-6 18:07
楼主很强，这那像刚做性能测试的。写的不错，自己亲身经历的性能测试很烦人，再加上有些客户也比较BT。那就更没治呢。。。。。
期待楼主的更新，更新结合一块，出个完整版，很赞！！！

作者: 123 时间: 2009-2-6 21:30
写的不错我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的

作者: cap5210 时间: 2009-2-6 21:31
写的不错我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的

作者: lihui82 时间: 2009-2-8 09:17
楼主总结得不错,很符合实际过程中性能测试的实况,期待与楼主的交流!

作者: yurong517 时间: 2009-2-8 09:51
很好哦楼主厉害谢谢啦

作者: david.wang 时间: 2009-2-8 13:45
确实不错，小弟刚好也在做这方面的测试。以后多交流。

作者: devotionme 时间: 2009-2-8 15:44
标题: 新手
看了比较多软件工程方面的书，对自动化测试工具没多少了解。
觉得楼主说不是所有的测试都需要自动化说的很对。也让我压力稍微小了一点了

作者: yzylion 时间: 2009-2-8 15:55
这么多人顶，我决定先顶再看

作者: yzylion 时间: 2009-2-8 17:00
看完了到目前为止，楼主写的内容，确实不错，把性能测试的一些要点和注意事项，存在的问题都写了出来
但其中有一处，我提个建议：楼主在文中有提到了“功能点”这个概念，功能点是一个作为软件规模的国际衡量单位，类似于米，厘米，千克，秒等，楼主的“不是所有的功能点都需要做性能测试”就如同“不是所有的米(厘米，秒等）都需要做性能测试”，意思虽然清楚，但表达上个人建议为不是所有的功能特性，以免歧意。

另外楼主说的负载，性能，压力三大测试，我个人观点是，负载和压力是性能测试的涉及领域，但性能测试不仅止于此，还有如：资源占用情况，可扩展性测试，稳定性测试等，期待楼主继续

作者: trapezia 时间: 2009-2-8 20:55

原帖由 yzylion 于 2009-2-8 17:00 发表
看完了到目前为止，楼主写的内容，确实不错，把性能测试的一些要点和注意事项，存在的问题都写了出来
但其中有一处，我提个建议：楼主在文中有提到了“功能点”这个概念，功能点是一个作为软件规模的国际衡量单位， ...

非常感谢你的细心提醒，我是按照function point的字面理解用了这个词，现在看来确实是错的。已经做了修改。

作者: trapezia 时间: 2009-2-8 21:00

原帖由 123 于 2009-2-6 21:30 发表
写的不错我想问一下lr指控windows资源的那些指标，是不是从perfmon里面掉出来的

还是不很确定你问的具体内容是什么，如果按照帖子里面的内容，lr监控哪些指标是从需求中来的，如CPU占用，内容剩余量，磁盘IO等。lr实际上是把windows或者linux的性能监控结果读出来做了一个汇总，监控哪些是从系统提供的几百个指标选出的一个子集。

作者: sky_zhouw 时间: 2009-2-9 09:56
好文章，顶顶

作者: dashi68 时间: 2009-2-9 10:23
好文章，顶！

作者: hmilyjch 时间: 2009-2-9 10:52

原帖由 trapezia 于 2009-1-22 09:36 发表
事务的命名很重要，在设计阶段搞定命名可以避免一些麻烦。据个例子：一个网站的10个页面中可能有7个检索，如果这些检索的业务都叫做“search”，那在整理报告的时候就很难分清哪个是哪个。对于事务的命名，放置的位置，一些规约性的东西，要提前约定好，因为脚本不一定是一个人开发的。需要保持团队之间的一致。一些大家都要使用的共性的东西，比如服务器IP，参数，公共函数，文件，数据文件等，PM要在项目的早期就开发好并编制使用方法文档，作为项目资源约定和规范下来，这个和开发项目有相似性。

很实用！

作者: yetties2005 时间: 2009-2-9 11:23

很用心的总结。

作者: yangwanp1984 时间: 2009-2-9 11:37
顶下~文章还得细细品味....

作者: trapezia 时间: 2009-2-9 19:25
祝大家元宵节快乐！大家的关注和支持给了我很大的动力。
*************************************************************
今天更新一小段，说一下测试执行的记录问题。
测试执行的原始记录是重要的成果（可能也是唯一的，尤其是测试结束很久以后，原有的场景和结果很可能已经被清除了。）对测试用例和记录的内容、格式的要求都要严格。要求达到什么标准呢？
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
————————————————————————————————————

作者: kevin_swpi 时间: 2009-2-10 10:44
楼主
“预期结果 |12小时平均CPU占用不超过50%，平均可用内存大于1500M，磁盘等待队列小
|于0.5，事务A响应时间小于X秒，事务B响应时间小于Y秒，”

这类具体的需求是客户给的还是你们自己根据经验来设定的？

作者: trapezia 时间: 2009-2-10 11:32

原帖由 kevin_swpi 于 2009-2-10 10:44 发表
楼主
“预期结果 |12小时平均CPU占用不超过50%，平均可用内存大于1500M，磁盘等待队列小
|于0.5，事务A响应时间小于X秒，事务B响应时间小于Y秒，”

这类具体的需求是客户给的还是你们自己根据经 ...

理想的情况是客户给出，如果没有具体指标就在分析阶段和客户沟通然后确定下来。客户什么都没有给的项目就是坑，跳下去再往上爬，爬不爬的上来看运气。

作者: 玻璃心 时间: 2009-2-18 09:32
楼主真是大方，康该，且有才，我也忍不住的顶一下，赞一声！

作者: 玻璃心 时间: 2009-2-18 09:33
慷慨，光顾着称赞了，字都打错了，呵呵

作者: 110784008 时间: 2009-2-20 17:12
谢谢楼主的分享很有用啊
支持+1

作者: chop123 时间: 2009-2-23 09:47
我强烈顶个，期待下一个

作者: zhangxinnow 时间: 2009-2-23 11:56
受益匪浅，谢了。

作者: q789789q 时间: 2009-2-23 14:05
好久没来了,看到LZ的大作,真有才

作者: xiemojia 时间: 2009-2-23 14:17
标题: 佩服的五体投地了
真是牛人，不过呢，多花点时间写写注释，改改结构，可以减少你在和mm约会的途中被叫回单位改代码的概率。3.小组会议很重要，但是肯定不愉快。如果每个人都按时保质完成任务，那PM搞定设计以后就可以回家休假，该种地的种地，该打渔的打渔。小组会议干什么？提问回答。哪几个问题呢？How？Why？When？最后也是最关键的一点，黑盒测试组经常有mm，性能测试组不提也罢...
这些话是从里面摘录的，哈哈，真是好心得，希望再看到楼主更多精彩的文章

作者: zhuyuancan 时间: 2009-2-23 17:30
赞一个！

作者: trapezia 时间: 2009-2-24 13:27

原帖由 zhuyuancan 于 2009-2-23 17:30 发表
赞一个！

感谢大家捧场，最近忙的头晕，也没有时间更新，见谅，只要抽出空闲我就立刻更新！

作者: bagwell333 时间: 2009-2-25 13:31
支持一下。。

作者: bagwell333 时间: 2009-2-25 14:30
楼主性能测试刚接触吗？其中一些流程和注意事项同样适合黑盒系统功能测试。
楼主理解很深，佩服，佩服。

作者: trapezia 时间: 2009-2-25 17:29

原帖由 bagwell333 于 2009-2-25 14:30 发表
楼主性能测试刚接触吗？其中一些流程和注意事项同样适合黑盒系统功能测试。
楼主理解很深，佩服，佩服。

其实，性能测试也是黑盒的，也是系统级别的，也是要测试功能的...

作者: yxfqjj 时间: 2009-2-26 10:06
楼主太有才了
另外呢楼主的坚持很值得赞哈哈这就是做测试的人应该坚持的呢

作者: gmyeti 时间: 2009-3-10 13:38
顶

作者: catexiaona 时间: 2009-3-12 15:49

楼主你太牛了~~~

作者: trapezia 时间: 2009-3-17 10:12
最近着实是太忙了，都没有时间来照顾这个帖子，一个多月没有更新，实在是罪过。今天趁着有一点时间，更新一小段。
***************************************************************
性能测试大多规模较大，看到的信息和数据也都纷繁芜杂，完全记录肯定不可能，那样的记录领导和客户没人喜欢，太少的记录也有很多问题，可能在追踪问题时发现某部分的信息不全而无法做出判断。

[ 本帖最后由 trapezia 于 2009-4-28 11:47 编辑 ]

作者: Lorita 时间: 2009-3-17 10:32
标题: 想跟LZ学习下
我想从事性能测试，我该重点往哪努力

作者: shanshan3346 时间: 2009-3-17 21:46
楼主，我最近在忙着考软件评测，有点问题搞不明白，希望能向你学习一点东西

作者: jsyzcz_37 时间: 2009-3-18 11:53
我看LZ很快就要成为PM了

作者: genius-hao 时间: 2009-3-18 16:51
标题: .....
不得不顶

作者: trapezia 时间: 2009-4-28 11:45

原帖由 shanshan3346 于 2009-3-17 21:46 发表
楼主，我最近在忙着考软件评测，有点问题搞不明白，希望能向你学习一点东西

什么不明白，问！

作者: shuishixingyu 时间: 2009-7-7 17:29
楼主，期待你的更新

作者: lxhsally 时间: 2009-7-8 15:58
怎么没有总结陈词呢？期待！！

作者: tytesting 时间: 2009-7-8 18:00
我也来顶一下，最近公司做了个电子商务网站的项目，马上就要进行性能测试了，公司总共就两个测试人员，也没有专门的性能测试人手，我这心里可一点底也没有，根本不知如何下手，期待楼主的总结

作者: 愚人 时间: 2009-7-8 23:54
再看直播，呵呵

作者: tangdian1988 时间: 2009-7-9 11:18
很真实,看了以后感触很大啊...
楼主真是nb!
赞一个!

作者: huangkai 时间: 2009-7-9 15:18
情不自禁的想顶一下。。。

作者: taotaoma 时间: 2009-7-15 11:11
谢谢，我自己整理成一个文档了。

作者: taotaoma 时间: 2009-7-15 11:11

作者: huiyanni 时间: 2009-7-28 11:23
继续，谢谢了，以后得多注意点

作者: chenjinmiao 时间: 2009-7-28 17:11
先顶下，再细看，嘿嘿。

作者: boymarco 时间: 2009-7-28 18:08
期待LZ的更新

作者: wangliang1639 时间: 2009-7-30 14:29
标题: 51testing的众牛人要么太忙，要么太抠
51testing的众牛人要么太忙，要么太抠……
能看见这么真实的东西不容易啊……

作者: trapezia 时间: 2009-11-2 18:25
标题: 实在抱歉
接近半年没有照顾这个帖子了，今天终于得时间来看看，竟然还有人在回复，实在是感动。
未来抽时间把这个帖子做个了结

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)