常用的性能测试方法和测试要点说明.docx

常用的性能测试方法和测试要点说明.docx

《常用的性能测试方法和测试要点说明.docx》由会员分享，可在线阅读，更多相关《常用的性能测试方法和测试要点说明.docx（12页珍藏版）》请在冰豆网上搜索。

常用的性能测试方法和测试要点说明

常用的性能测试方法和测试要点

2008-12-1613:

58:

04/个人分类：

好东西

常用的性能测试方法和测试要点

　　1、明确用户的性能需求（显示的和隐式的），性能测试点，找出瓶颈

　　1）用户直接需求的和使用过程中（行业经验）可能遇到的性能瓶颈点必须测试和分析到。

当然，客户不需要的，也没有必要去花时间和精力。

　　2）从中获取相应的性能测试参数，峰值和平均值。

　　3）客户的性能容忍度和系统所能承受的容忍度同样重要。

　　4）确认系统运行的最低硬件环境要求（虽然硬件便宜的多了，但客户能不能改造自己的环境还得客户说了算）

　　5）如果可以的话，将系统的容错性做为性能测试的一部分进行测试

　　2、测试对象和性能负载分布

　　1）基本的3个对对像：

C/S、B/S中的客户端和服务器，其中还有网络进行连接或中间件。

　　2）服务端可能分为数据端、业务端和服务容器。

　　3）跟据实际的测试结果合理的进行相应的性能负载分布。

　　3、负载、容量和压力测试逐一进行（如果需要）

　　1）更多的情况下，性能测试中出现的问题是最初的设计时应存在的问题。

如果可能，建议对相应的性能提前做测试和优化。

　　2）够用就好，不是所有的系统都要进行性能测试，一切以客户需求和实际需要为准。

　　4、测试点

　　1）CPU和存使用（系统自身的原因）。

是否可以正常的使用和释放，是否存在存溢出。

　　2）访问的速度（客户需求或是实际的应用要求说了算）

　　3）网络。

网络传输速度，网络传输丢包率。

（找些工具，有免费的）

　　4）服务器。

指令、服务应答响应时间，服务器对信息处理的时效性，服务器对峰值的处理（建议进行服务器优化或是进行服务负载均衡，有大量的文档对此进行描述）

　　5）中间件。

中间件在信息传递中的处理性能及信息处理的正确性。

　　5、测试和监控数据

　　1）均值下的持续运行（通过分析对整体的性能进行预测和评估）

　　2）短时间的峰值运行（分析系统的处理能力）

　　3）最低配置和最佳配置下的性能对比

　　4）多用户。

同时访问，同时提交。

　　5）对4中的数据进行记录和监控

　　6、选择测试工具

　　现有的测试工具太多了，不在一一列举。

　　适用就好，推荐开源的工具。

作为一名测试新人加入团队，大多数情况下，项目组成员都是一种热情欢迎的态度，并且主动提供力所能及的支持和帮助，如何快速熟悉项目业务和测试环境，尽快投入到实际工作中去，我谈谈个人的经验和一些看法，供同行参考：

1、寻找新公司的团队元老：

一般来说，一个新人进入新公司，都要指定一个师傅带一段时间，这也就是我们说的测试前辈。

很多时候，测试前辈都是经验非常丰富的测试高人，如何您和他相处融洽，关系不错，凭他个人丰富的业务经验，给您指点迷津，也许会比你自己摸索10倍的时间效果还好。

很多的测试新手，刚进入新公司时，自高自大，眼高收低，测试前辈都不愿意交，结果到了试用期转正答辩的时候，一问三不知，被迫离开公司，被炒鱿鱼。

这样的例子我看到的不下于10例，很可惜丢失了很多工作机会。

2、虚心的学习态度：

刚到一家新公司，保持谦虚的学习态度非常必要。

记得我刚毕业那年，公司招聘了一个测试主管，他有4到5年的工作经验，阅历算是不简单，也是我们心目中的牛人吧。

但是那个人，除了听总监的话以外，对于我们部门的其它人来说，他简直是自高自大，目中无人，根本不把部门里的其他人放到眼里，觉得部门的人都不如他。

他作为一个空降兵，老员工和新员工，对他都很冷漠，碰到什么问题，需要小组成员帮忙的时候，大家都不愿意帮助他，互相推诿，并且经理也找他谈了几次话，效果不明显，结果他呆了不到2个月，估计是自己觉得很不开心，被迫离开了公司。

其实，保持低姿态，谦虚的学习态度，必不可少。

3、阅读项目相关的文档：

一般来说，新人一到公司，就会安排到项目中去。

作为测试新手，快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。

我们能够通过需求规格说明书等文档，快速熟悉系统相关的知识，获取编写测试文档的相关信息。

如果项目已经编好了用户手册，您完全可以根据文档的步骤，一步一步傻瓜式的熟悉每项功能。

只有掌握的这些文档的精髓，测试才会变得异常轻松呀。

4、快速熟悉项目相关业务知识：

刚到新公司的测试人员，如果你是跳槽到以前做过的相近行业，有丰富的经验了，那么您熟悉业务没什么大的问题。

如果您换的新公司是您以前都没有接触到的行业，那你一定得努力一点，买些相关的业务知识看看非常必要。

我深有体会，以前从一家“通讯公司”跳槽到做“银行系统”的公司，业务完全两样，很多业务知识都是从零开始。

不过有一定的工作经验，学习起来也挺快，关键取决于个人是酷爱学习和坚强的学习毅力。

5、尽快介入了解被测试系统：

刚跨入一家新公司，如果被测试系统已经开发的差不多了，部分功能已经OK了。

你可以部署到测试环境下，尝试从直观测试的角度去尽快了解系统，尽快结合文档熟悉起来。

很多的时候，通过页面操作实际的系统比看文档效果好的多，并且印象更深刻，熟悉系统更快。

新加入公司的朋友不防试一试。

6、了解公司类似的相关产品：

大多数的公司，都不可能在每个行业都非常强，基本上都是在某一个较小的领域很强势，公司主要就是研发强势相关业务的产品。

所以说，相关的产品一般来说是很多的，如果要你测试的系统没有开发完毕，如果时间和条件允许，不妨先了解一下公司类似的产品，以便尽快熟悉起来。

大多数情况下，公司很多的产品都是相通的，大部分的产品是在不同的客户要求下，修改了部分功能和界面而已。

个人认为：

了解类似的产品，也是测试新手快速熟悉产品的一条捷径。

7、尽量多参加项目的各种会议：

每个项目，特别是在项目的启动阶段，大会小会不断，很多时候项目组成员抱怨居多，都认为很浪费时间，耽误开发进度。

如果作为测试新手的您这个时候加入，那太好了，多参加这样的讨论会。

大部分时间都是在讨论项目的重点和关键，如果大家意见不一致，必然要对不一致的东西展开细节讨论，您肯定是收益匪浅。

特别是对业务方面的讨论，您参加几次讨论，比您看10篇需求还强，并且理解也很透彻。

如果您对需求有所了解，但是部分功能模块还有问题，就可以在讨论会上随时提出来，大家一起讨论，共同解决。

如果有这样的机会，切勿放弃哟。

8、阅读类似项目已有的测试用例：

如果项目已经启动并进入了测试阶段，如果你在这个时候介入，通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。

这些测试用例也是您快速上手测试的重要参考资料。

如果还没有编写测试用例，你就介入了，那你就得重头开始，您可以阅读项目类似的测试用例，并结合以前项目的测试经验，根据公司相关的测试用例模板开始编写测试用例。

如果在编写测试用例中碰到您不了解和很难处理的问题，您可以记入测试需求疑问表格，等部门开会时，提出来大家讨论。

最好不要碰到一个问题就去问，经常打乱人家的思路，弄得别人嫌烦，那就不值了。

9、查看缺陷数据库中旧有的缺陷：

一般的测试缺陷跟踪系统，都是按模块来分类软件缺陷的。

如果老大给你分配了测试任务，你就可以有目的的去熟悉即将测试的模块缺陷。

登录系统后，对缺陷进行筛选，尝试按测试前辈的Bug描述步骤进行操作，看看是否能够重新缺陷？

这种方法能够借鉴测试同行的经验，尽快发现问题，避免测试的盲目性。

一来可以拓宽您的视野，避免递交类似问题的Bug或是重复的Bug，二来还可以为您快速熟悉被测试系统添砖加瓦。

10、必须明白自己领导是谁：

一般的员工进入公司，公司和部门领导很多，搞不清楚谁管我，碰到问题问谁？

谁可以帮忙解决问题？

如果真是这样那就麻烦了。

部门领导臃肿的情况实在是太多了，有的公司，既有2测试经理，又有几个测试主管，还有多个项目经理和研发总监，不知道工作向谁回报，对哪个领导负责。

弄得每个领导都回报，很累呀！

！

我的做法是：

测试项目中负责领导只有一个那就是测试主管，测试主管负责安排和分配每个测试人员的工作和任务，我直接Review测试主管。

如果项目中碰到有什么解决不了的问题，组成员可以直接找我，同时我也定期加入项目参加部分测试，了解测试项目的一些进展情况，必要时还要找一些人谈心。

这样，工作汇报比较简单明了，很轻松。

11、熟悉与测试相关的管理软件的使用：

我说的这个测试相关的软件包括缺测试需求管理软件（如TestDirector或QC）、陷跟踪管理软件（如：

TestTrackPro、TestDirector等等）、版本配置管理工具软件（CVS、VSS，还是SVN等等），具体熟悉到什么程度，那就要看您的职位了。

如果您是一般的工程师，那你就只了解一般的使用就够了，如果您是测试经理，您不仅要了解一般的使用，还要更深层次的了解软件的权限和项目的配置，因为您要作为该软件的Admin，碰到问题大部分都由您搞定呀，高工资不是那么好拿的呀，哈哈！

！

！

如果作为新入职的您，连这些都不会，那你就得加把油了，不然到了测试启动阶段，你才开始熟悉管理软件，那么你觉的能够快速展开测试吗？

12、注意沟通技巧，把握请教良机：

为了尽快熟悉项目，展开测试工作，沟通技巧必不可少。

您作为新入职的测试人员，尽量了解每个开发人员开发的模块和每个开发人员的性格特点，寻找一些共同语言，拉近与开发人员的距离，让他们对您产生好感。

只有这样，当您碰到问题的时候，他们才会鼎立的帮助您。

如果您与开发人员关系不好，看了就觉的很讨厌，那他们肯定不会帮助您的，更不原意和您配合，当您提错Bug的时候，他们就会抓住这些Bug不放，有时候还要说您什么都不懂，这样你就很郁闷，肯定呆不长久的，只有走人的份了，呵呵。

特别是开发人员很窝火的时候，您更要多一些理解和宽容，切勿火上浇油，您可以给他一些表扬，给他一些鼓励。

他一听准开心死了，总觉得还是您们最了解我，把您当成自己人。

这个时候，你再问开发人员问题，他也许态度就不一样了，他准会仔细的给你讲解，并且以后的什么事情，他也会百厌齐烦地帮助您的，因为他觉您最了解他们，无意识的把您当成了好朋友和哥们。

还有的时候，开发人员有空过来测试部门逛逛，准备和您交流时，一定要把握机会，和开发人员开开玩笑和一些必要赞赏，也能够调节和开发人员的关系。

总之，这一点做起来真的很难，如果做的好，那效果确实就不一样了。

欢迎各位同行继续补充指正！

！

项目背景：

此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为Hertfordshire政府做一个软件用于各服务点（servicepoint）的数据收集、整理、评估，以前他们是用Excel来处理这些数据的，现在需要将其自动化。

后来客户决定将这个软件项目外包，我们公司就争取到了这个项目。

情况介绍：

　　这个项目主要包括两个部分：

前台的Web端，主要用于数据收集处理；后台管理端，用于管理用户、制定数据计算标准、导入数据等。

　　我们公司是将其作为一个加班项目来处理的，所谓加班项目也即也是说在每工作日规定的８小时，不得做此项目，需要自己安排晚上或周末时间来完成任务。

若有问题需要与项目成员沟通，则一般采用形式，或者是在中午以及临近下班的时间开小会。

在来这个公司前，对此我是闻所未闻的，后来了解到，大约这在外包公司比较常见，项目多任务紧时，为了压缩成本（大概也为了日后考虑），并不会立即招人，而是将部分小项目以加班项目的形式分配下来，当然，项目奖金也是很可观的。

然而加班项目无论在成员沟通、时间进度把握以及项目成员的心理认知都会存在一定的问题，所以，这也就为项目后来的进展埋藏了不少的隐患。

　　还值得一提的是，公司的很多项目都是以ODC报价，可是这个项目却采用的是固定报价形式，不管你花多久的时间做，最终成功交付了，才能得到所有钱。

这种形式本身没多少不对，可是，有时在一种心理的影响下，可能就会令项目进入一个恶性循环。

　　我是今年６月中旬应聘进入公司的，从另一个测试人员手上接手了这个项目的测