WEB应用程序的性能

首先，这里有两个web应用程序性能方面的重要指标。请注意，下面的“定义”并不规范，仅供参考。

* Response Time - 响应时间

从初始化请求到完成响应所用的时间。这是一个测试WEB应用程序速度的重要度量。

* Scalability - 伸缩性

一个可伸缩的应用程序的响应时间随负载的增加而线性增加。

没有WEB应用程序可以处理无限数目的请求，但是一般我们可以预测一个范围，并保证我们的WEB应用程序可以在此范围内“优雅”的伸缩，即始终把响应时间维持在可接受的级别。

如果我们打算优化我们的WEB应用程序，那么至少我们应该知道它到底该不该优化。压力测试可以解答这个问题。

* Load Test - 压力测试

为WEB应用程序模拟用户请求以测量其伸缩性的过程。

它非常有用，虽然开始的时候会觉得有点“变态”。一般我们会模拟大量的用户请求以获得在WEB应用程序的速度恶化到无法接受的级别前能够处理的并发请求数量。

所谓“无法接受的级别”并不是一定要到实例池崩溃、应用服务器瘫痪甚至服务器当机的时候，这要视需求而定。

一般压力测试包含如下步骤：

* 确定接受请求并完成响应的最大允许的延时。

* 估计WEB应用程序的最大并发用户数量。

* 模拟用户请求，以一个比较小的负载开始，逐渐增加模拟用户的数量，

直到WEB应用程序的 相应延时超过最大延时。

* 如果负载比估计的用户数量小，那么应该优化这个WEB程序，否则你选择性的执行优化。

你不会在考虑自己写一个测试程序吧？算了，何必再重新发明一次轮子？这里有一些压力测试工具，它们各有特色，先介绍免费的：

* Web Application Stress Tool, Microsoft, http://www.microsoft.com

* JMeter, Java Apache Project, http://www.apache.org/

* AutoRunner, http://www.spasvo.com/autorunner/

如果你或你的公司很有Money，或者需要更加丰富的功能，可以使用以下商业软件，不过它们都价值$10,000，甚至更多：

* WebLoad, RadView Software, http://www.radview.com/

* SilkPerformer, Segue Software, http://www.segue.com/

* Benchmark Factory, Quest Software, http://www.benchmarkfactory.com/

* LoadRunner, Mercury Interactive, http://www.mercuryinteractive.com/

无论你选择哪种工具，它都至少应该提供以下的功能，以便为以提供丰富且有意义的测试数据：

* 发送GET和POST请求

* “记录”从浏览器发送的GET和POST请求（以免开发者需要手写这些合适的请求）。

* 获取和发送COOKIE。

* 多线程

* 模拟用户延迟

* 记录性能数据

* 控制带宽

我打赌如果你以前没有接触过以上这些内容，那么你的WEB应用程序很难在压力测试中获得令人满意的结果。你会看到响应时间会随着请求数量的增多而暴涨，甚至出现一些我们不想看到的情况，比如“拒绝连接”。

一旦没能通过压力测试我们应该如何应对呢？优化！没错，不过我们怎么知道那里应该优化呢？Profiler可以对此提供很多的帮助。（我不知道怎么翻译它更贴切一些，所以干脆不翻译了！）

Profiler提供这样的功能，它可以检测你的应用程序并提供一些有用的运行时信息，比如某块代码的执行时间、内存/堆的使用情况、内存中的对象实例数量等等。比如，我们想知道到底是哪个Java对象的哪个方法耗费了更多的时间。

以下是一些Profiler：

* Quantify，Rational Software，http://www.rational.com/

* Optimizeit，Intuitive Systems，http://www.optimizeit.com/

* JProbe，Sitraka Software，http://www.jprobe.com/

请注意，我们不能过分依赖工具，虽然它们很多时候可以极大的是我们的工作变得简单、轻松。一般如果你知道了系统的瓶颈所在，修改往往是一件相对轻松的事情。个人认为寻找、发现系统的瓶颈所在才是最关键、也是最体现一个人功力的步骤。这是一个非常专业的问题，它需要你对所使用的应用平台、软件架构、数据库系统、网络环境等等诸多方面非常深的造诣。这并不夸张，任何一个会JSP和JDBC的人都可以写出一个WEB应用程序来，但是那还相差太远……限于篇幅，话题先进行到这里。其实你可以在很多地方找到有关测试和优化技巧的文章，都非常有针对性，比如TheServerSide.com、JavaLobby.com等。好啦！休息一下！Java之路很长，一步一步走吧！！

描述性统计与性能结果分析

LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

为了解答上面的疑问，我们先来看一张表：

CmdID  测试时被请求的页面

NUM     响应成功的请求数量

MEAN   所有成功的请求的响应时间的平均值

STD DEV     标准差（这个值的作用将在下一篇文章中重点介绍）

MIN             响应时间的最小值

50 th(60/70/80/90/95 th)         如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th也是同样的含义

MAX     响应时间的最大值

我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：

1. 90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％；

2. 对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；

3. 从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；

4. 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；

5. 如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；

6. 在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；

7. 上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。

数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才

一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。

在这张图中，我们继续使用了上一篇文章——《描述性统计与结果分析》一文中的方法，对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对

Google.com 首页进行测试得来的，在测试中分别使用10/25/50/75/100 几个不同级别的并发用户数量。通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的响应能力。

这张图所使用的数据与第一张图一样，但是我们使用了另外一个视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒，分别表示了在整个测试过程中，响应时间在0-2000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在2001-5000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在5001-10000毫秒范围内的事务数量占成功的事务总数的百分比，以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数的百分比。

这几个时间范围的确定是参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

那么从上面的图表中可以看到，当并发用户数量为10时，超过95％的用户都可以在5秒内得到响应；当并发用户数量达到25时，已经有80％的事务的响应时间处在危险的临界值，而且有相当数量的事务的响应时间超过了用户可以容忍的限度；随着并发用户数量的进一步增加，超过用户容忍限度的事务越来越多，当并发用户数到达75时，系统几乎已经无法为任何用户提供响应了。

这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。

Note：上面两个图表中的数据，主要通过Excel 中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE几个统计函数获得，具体的使用方法请参考Excel帮助手册。

理发店模型

大概在一年前的一次讨论中，我的好友陈华第一次提到了这个模型的最初版本，经过几次讨论后，我们发现经过完善和扩展的“理发店模型”可以用来帮助我们理解很多性能测试的概念和理论，以及一些测试中遇到的问题。在最近的一次讨论后，我决定撰写一篇文章来专门讲述一下这个模型，希望可以帮助大家更好的理解性能测试有关的知识。

不过，在这篇文章中，我将会尽量的只描述模型本身以及相关的一些扩展，而具体如何将这个模型完全同性能测试关联起来，我不会全部说破，留下足够的空间让大家继续思考和总结，最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信，当大家在思考的过程中有所收获并有所突破时，那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^

当然，我要说明的是，这个模型仅仅是1个模型，它与大家实际工作中遇到的各式各样的情况未必都可以一一对应，但是大的方向和趋势应该是一致的。

相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳。

在我们的这个理发店中，我们事先做了如下的假设：

1. 理发店共有3名理发师；

2. 每位理发师剪一个发的时间都是1小时；

3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。

通过上面的假设我们不难想象出下面的场景：

1. 当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

2. 当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

3. 很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；

从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。

当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。

在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图

这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。

在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。

根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。

当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。

进一步理解“最佳并发用户数”和“最大并发用户数”

在上一节中，我们详细的描述了并发用户数同资源占用情况、吞吐量以及响应时间的关系，并且提到了两个新的概念——“最佳并发用户数（The Optimum Number of Concurrent Users）”和“最大并发用户数（The Maximum Number of Concurrent Users）”。在这一节中，我们将对“最佳并发用户数”和“最大并发用户数”的定义做更加清晰和明确的说明。

对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。

要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^

而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

1. 当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

2. 在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。

如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。

理发店模型的进一步扩展

这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了 ^_^

扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。

扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。

扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。

扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。

扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。

这篇文章就先写到这里了，希望大家在看完之后可以继续思考一下，也写出自己的心得体会或者新的想法，记下自己的不解和疑惑，让我们在不断的交流和讨论中走的更远 ^_^

性能测试相关术语的英文书写方法（不断更新ing）——知道了这些术语在英文中的正确书写方法之后，可以通过 Google 更加高效的获取到更多有用的资料。

理解性能

在这篇短文中，我将尽可能用简洁清晰的文字写下我对“性能”的看法，并澄清几个容易混淆的概念，帮助大家更好的理解“性能”的含义。

如何评价性能的优劣: 用户视角 vs. 系统视角

对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。

而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。正如在《理发店模型》一文中所描述的：系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。

换句话说，“好的性能”意味着更大的最佳并发用户数（The Optimum Number of Concurrent Users）和 最大并发用户数（The Maximum Number of Concurrent Users）。有关“最佳/最大并发用户数”的概念请参见《理发店模型》一文。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和 可恢复性（Recoverability）——我将会在本系列文章的第五篇“无处不在的性能测试”中专门讨论这三个属性的含义和相关的实践经验。

响应时间

上面这张图引自段念兄的一份讲义，不过我略作了些修改。从图中我们可以清楚的看到一个请求的响应时间是由几部分时间组成的，包括
C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server 所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；
N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；

从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。

在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。

吞吐量 vs. 吞吐量

在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。

并发用户数 ≠ 每秒请求数

这是两个容易让初学者混淆的概念。

简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。

所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。

无所不在的性能测试

提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。

本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

因此，本文的结构也将依据软件开发过程的不同阶段来组织。

另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。

需求阶段

我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。

如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。

分析设计阶段

系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。

数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。

在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。

另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。

最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。

编码阶段

一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。

如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。

另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。

测试阶段

产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^

如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。

在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。

维护阶段

维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。

与性能测试相关的其他测试

可靠性测试（Reliability Testing） 对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。

常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。

可伸缩性测试（Scalability Testing） 对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？

一种常用的方案是使用负载均衡（Load Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？

可恢复性测试（Recoverability Testing） 虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。

我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。

如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。

当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉

性能测试，并非网络应用专属

软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：

1. 当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？

2. 当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？

3. 杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？

4. 是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？

如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。

获取有效的性能需求

一个实际的例子

为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。

这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^

系统总容量达到日委托6000万笔，成交9000万笔

系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔

实际股东帐号数3000万

这个例子中已经包括几个明确的需求：

最佳并发用户数需求：每秒7300笔

最大并发用户数需求：峰值处理能力达到每秒10000笔

基础数据容量：实际股东帐号数3000万

业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

什么是“有效的”性能需求？

要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。

1. 明确的数字，而不是模糊的语句。

结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：

2. 有凭有据，合理，有实际意义。

通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。

3. 相关人员达成一致。

这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了

如何获得有效的性能需求

上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：

1. 客户方提出

这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

2. 根据历史数据来分析

根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。

3. 参考历史项目的数据

如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。

4. 参考其他同行类似项目的数据

如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。

5. 参考其他类似行业应用的数据

如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

6. 参考新闻或其他资料中的数据

最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。

文章来源于软件测试时代 http://www.testage.net/

作者在本文中描述了一些构建更易维护的和健壮的自动化测试脚本的技巧。作者给那些使用自动化测试工具并且为将来测试工作而建立自动化测试脚本库的测试人员提供了有价值的远见。本文提供了许多在文档化测试脚本，调试测试脚本，执行测试脚本的同行评审和同步测试脚本方面的建议。
 
增量式调试脚本
录制测试脚本，和其他的软件开发成果一样，会变得非常大。为了可以成功的回放，需要调试几百行的代码，为了参数化的数据驱动测试脚本，它可能包含了几个数据集。常见的调试测试脚本方法是首先录制所有的业务流程和需求，然后测试人员回放测试脚本以验证并纠正问题。测试人员继续调试脚本直到它和可以一（或多）组数据集一起成功地回放。
当测试脚本有成百的代码行，验证点，分支的逻辑，错误处理，参数和数据在多个已录制的业务流程之间的相关性时，调试并且解决测试脚本中的问题变得特别的乏味和难以处理。对于调试那些复杂且又冗长的测试脚本，一个更加容易管理的方法是录制脚本的一部分并且在录制测试脚本的其他部分之前分开调试他们。在测试单个的部分后，你可以决定测试脚本的一部分如何和另一部分工作和数据如何从一个已录制的流程流向其他的流程。在测试脚本的所有部分都录制后，测试人员就可以回放整个测试脚本，并确保脚本同一个或多个数据集一起从头到尾被正确地回放了。
举个例子，我录制并自动化了一个执行了以下业务流程的复杂的测试脚本：
检查在货仓中的库存
执行一次MRP运行
补充库存
挑出一些要发送的货物并且进行发货
确定交货需要移交的订单
验证发送的货物到达了它们的目的地。
这个测试脚本有一些代码行，参数，验证点和需要象一个整体一样工作的数据相关性。首先我录制了每一个单独的流程并且验证了他们分别可以成功的回放。然后我将所有录制好的流程集成尾一个大的测试脚本并且验证它同多个数据集一起能够成功的回放。如前面所述，一个关键的目的是确信在继续录制整个测试脚本的剩余部分之前每一个已录制的流程可以成功的回放。我没有录制所有提及的流程（从1到6）并把它们排列一起回放，而不首先验证所有的流程可以作为单独的流程成功的回放。
这部分是为了避免等待调试脚本，直到整个测试脚本录制好。

测试脚本的同步
测试工具会用比终端用户手工按键快的多的速度回放已录制的测试脚本。接着由于应用程序可能不够快地显示数据或从数据库取出数值以允许测试脚本正确地回放，这可能会击垮所测试的应用程序。当测试地应用程序不能响应测试脚本时，脚本执行会突然中断，然后需要用户干涉。为了同步所测试应用程序和回放中地测试脚本，测试小组在已录制的测试脚本中引入了人为的等待时间。为了放慢测试脚本的执行，嵌入在测试脚本中的等待时间是最任意的且通过试验和错误最佳估计。等待时间主要的问题是它们要不是等的太长就是不够长时间。 
例如，测试人员或许注意到对于所测试的应用程序测试脚本回放得太快。他可能打算放慢它几次直到测试脚本执行和测试的应用程序相同步。这个技巧可以会造成相反的结果－甚至失败－如果在测试执行时，由于外部的因素（例如网络有延迟或系统维护）导致应用程序运行比新引入的等待时间更慢。在这种情况下，每次测试人员将不得不不断的猜测一个新的合理的等待时间。用等待时间放慢脚本不是十分科学的，并且对于创建强健的，在没有用户干涉情况下能够成功运行的自动化测试脚本没有什么帮助。
如果有可能的化，测试人员应该避免引入人为的等待时间或任意的sleep变量以使测试脚本和应用程序同步。
"While"语句或嵌套的"loops"语句是用于同步需要同步点的测试脚本且不管所测试程序的响应时间都可以成功回放的正确的技术。在测试脚本种插入嵌套的loops或“while”语句也可以减少在测试脚本回放时用户的干涉。例如，我插入"while"语句在录制好的测试脚本里，不断按Enter键直到创建了一个计划中的协议，不管所测试应用程序要花多长时间产生协议。测试脚本不依赖所测试应用程序的响应时间工作。
 
已签核，通过了同行评审
作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。SMEs， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。
 
录制、回放隐藏的对象
脚本可能被录制为增加或是双击表格中一个字段或字段位置没有被固定的一个数组的值。如果表格或数组中字段的位置从开始录制时就不断地变化，脚本可能在回放时会失败。测试脚本经常在回放中失败就是因为那些没有显示或在屏幕中可见的对象的位置发生了改变。
为了回放那些位置敏感或位置受变更影响的脚本，有必要用功能性增强脚本，例如“向下滚屏”，“下一页”或“查找”。包含这些实用性功能可以确保需要回放的隐藏对象将可以被识别，增加或是双击而不顾其在矩阵，表格，显示的屏幕上的位置。 
举个例子，我曾经录制果一个脚本，在最初录制时它需要向下滚屏两次来查找一个可以在表格中输入的空字段。当我在几个星期之后回放它时，我不得不向下滚屏四次来查找空字段，而不是相之前录制的两次。接着脚本失败了，因此我在脚本中嵌入了逻辑判断以指导脚本向下滚屏需要的次数来查找一个空字段。我通过在一个“while”循环中放置一个“下一页”（"next page"）功能实现了这个目的，它可以驱动脚本不停的“下一页”（page down）直到找到空字段。
 
安排重运行脚本/储存执行日志
为了绕过测试工具不能在安排测试脚本重运行的局限，测试人员可以通过可以支持多种命令行选项的NT的scheduler安排测试脚本。测试百年应该将执行日志存储在一个共享的驱动盘或针对审核的测试结果的测试管理工具中。
 
为关键的脚本创建自动的消息通知
可以用错误处理程序逻辑增强测试脚本，当错误发生时它可以不断的发送错误信息给无限设备或email地址。一些测试脚本是关键性的业务并且可能在午夜批量地运行。正确并成功运行这些关键性业务的测试脚本会作为其他自动化任务的一个依赖或者前提条件。
通常也包括在关键业务脚本中一旦出现失败时自动发送消息通知的逻辑。
 
编制文档
为了使测试脚本可重用并且更容易维护，文档化所有和执行测试脚本，测试脚本的头文件，任何执行测试脚本的特殊条件相关的信息，例如：
为了关闭书本调整所测试应用程序中的日期
更新任何需要唯一数据的字段
为了环境判断模式（context sensitive）/ 模拟模式（analog） /位图录制，调整显示器设置
列出所有有依赖的测试脚本
指出为了执行脚本需要的权限级别或用户的角色
在什么条件下脚本会失败，以及重新运行脚本的绕行方法
需要在脚本运行过程中打开或关闭的应用程序
指明数据的格式，例如，欧洲日期格式VS美国日期格式，等等
此外，脚本中需要包含一个描述（例如，它是干什么用的）和特别用途（例如，回归测试）的文件头。脚本的文件头应该包括脚本的作者，所有者，创建和修改日期，脚本可以追溯到的需求识别符，脚本所支持的业务范围，脚本中的变量和参数数量。在测试脚本中提供这些信息使以后的测试工作中的脚本的执行，修改和维护更容易些。
 
实行测试脚本的版本控制
许多公司花好几万英镑购买测试工具，但是却忽略了测试工具的副产品－录制好的测试脚本。为了公司构建中的自动化测试脚本的库和存储库，强烈建议对自动化测试脚本实行版本控制。版本控制帮助追踪测试脚本中的变更，并可维护同一测试脚本的多个版本。
 
坚持测试脚本命名标准和存储
测试脚本应当遵循项目公认的命名标准，并且应该存储在指定的库中，例如一个共享的驱动盘或测试管理工具中。
 
测试经理应当指明包括如下方面的测试脚本命名标准：
项目的名称（例如，GSI代表着Global SAP Implementation）
版本号（例如，即将发布或部署的版本号）
主题或测试种类（例如，SC代表安全测试，LT代表负载测试）
有序的测试用例编号 
标题或将要测试的功能（例如，来自外部供应商的采购业务）
遵循这些技巧使测试人员能够为他们的组织构建更强健的测试脚本。当然，开发可维护的测试脚本最大化自动化测试工具的效益。当自动化测试脚本用在以后的测试工作中，减少了完成一个测试循环所需要的时间时，公司就可以意识到自动化测试工具带来的投资回报（ROI）。以上的技术将帮助公司构建符合这些目标的测试脚本。

经验举例1

交易的响应时间如果很长，远远超过系统性能需求，表示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格等方法来降低该值。

经验举例2

分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，这样，就可以在Web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。

经验举例3

UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。

经验举例4

UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器 。合理使用的范围在60%至70%。

经验举例5

UNIX资源监控（NT操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等，另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。

经验举例6

Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

经验举例7

SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

转贴]浮躁的国内测试界

一、根基不牢

　　问题：利用等价类划分的方法，对某问题设计测试用例。

　　分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

　　问题：根据事件描述，画出对应的因果图。

　　分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

　　小结：

　　上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

二、专业不精

　　问题：音视频文件都有哪些格式，这些格式之间有什么差别？

　　分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

　　问题：测试脚本运行不畅如何调试？

　　分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

　　小结：

　　从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

三、无测试体系概念，忽视理论

　　问题：请说出软件测试的定义，BUG的定义。

　　分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

　　问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

　　分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

　　小结：

　　目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小****的话，就要理论实践并重，方能有所作为。

四、周边知识知之甚少

　　问题：能给我介绍一下软件工程中的瀑布模型吗？

　　分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

　　问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

　　分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

　　小结：

　　我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

五、缺乏必要的责任心、细心、耐心、虚心等

　　问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

　　分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

　　问题：你离职的原因？

　　分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

　　小结：

　　我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

六、缺乏诚信

　　这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：1、虚报自己历史工薪；2、笔试题目作弊；3、编造离职原因；4、虚报学历，工作经验；5、夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

1. 检查在货仓中的库存
2. 执行一次MRP运行
3. 补充库存
4. 挑出一些要发送的货物并且进行发货
5. 确定交货需要移交的订单
6. 验证发送的货物到达了它们的目的地。

1. 为了关闭书本调整所测试应用程序中的日期
2. 更新任何需要唯一数据的字段
3. 为了环境判断模式（context sensitive）/ 模拟模式（analog） /位图录制，调整显示器设置
4. 列出所有有依赖的测试脚本
5. 指出为了执行脚本需要的权限级别或用户的角色
6. 在什么条件下脚本会失败，以及重新运行脚本的绕行方法
7. 需要在脚本运行过程中打开或关闭的应用程序
8. 指明数据的格式，例如，欧洲日期格式VS美国日期格式，等等

1. 项目的名称（例如，GSI代表着Global SAP Implementation）
2. 版本号（例如，即将发布或部署的版本号）
3. 主题或测试种类（例如，SC代表安全测试，LT代表负载测试）
4. 有序的测试用例编号 
5. 标题或将要测试的功能（例如，来自外部供应商的采购业务） 

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

• 查找瓶颈时按以下顺序，由易到难。

    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法 很有效

分析的信息来源：

•1 根据场景运行过程中的错误提示信息

•2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

分析：

•A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

•B、应用服务没有死

（应用服务参数设置问题）

    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

•C、数据库的连接

(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2 Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成

•A、应用服务参数设置太大导致服务器的瓶颈

•B、页面中图片太多

•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率; 

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 

很慢的响应时间(slow response time) 

CPU空闲时间为零(zero percent idle CPU) 

过高的用户占用CPU时间(high percent user CPU) 

过高的系统占用CPU时间(high percent system CPU) 

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization) 

太长的磁盘等待队列(large disk queue length) 

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 

太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率： 

select(sum(pins-reloads))/sum(pins) from v$librarycache; 

select(sum(gets-getmisses))/sum(gets) from v$rowcache; 

自由内存： select * from v$sgastat where name=’free memory’; 

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

如果想真的做好性能测试，需要学习的东西还是比较多的。简单列一下吧。

1. 精通性能测试的基本概念，过程，方法论，了解性能工程；
2. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；
3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；
4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；
5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；
6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；
7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；
8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；
9. 了解一般的大型企业应用的部署架构和应用架构；
10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；
11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；
12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；
13. 大量的实际性能测试及优化经验；
14. 积极的参与到各类圈子、社团的讨论和交流、分享中。

LoadRunner测试Web的常见问题

性能测试是一件非常严谨的事情，就像我以前写过的一样，很多用户的性能测试的问题在于测试本身。以下列举几条LoadRunner测试Web的常见问题。

• 网络带宽问题。

对Web进行压力测试时，通常百兆网络是不够的，当网络带宽不够的时候server端没有足够压力。用LoadRunner所在的Windows的性能管理器看一下网络利用率就知道了。

• Vuser脚本的检查。

虽然Loadrunner提供了方便的脚本录制功能，但由于录制时可能出现的操作偏差，也应手工检查生成的Vuser脚本。去除某些与压力测试无关的东西。否则可能会出现Loadrunner测试结果有误或压力上不去的情况（比如vuser访问一些不存在的资源）。

• Runtime setting。

在创建Loadrunner scenario时，每台机器的vuser的runtime setting都应该分别设置并检查，不能只对第一个vuser的runtime setting进行设置。通常你会关掉think time，以便能用较少的机器达到较大的压力。另外，如果返回页面里包含了一些访问其它资源的链接比如图片服务器，这时应关掉 download non-html resources。

• 没有检查返回页面。

当server端出错时应用程序有可能返回错误信息，但对HTTP来讲仍是成功的响应，返回码为200 O.K. 这样在Loadrunner就被记为成功的transaction。于是，server端出错越多，Loadrunner测出的性能越好。解决办法：开启并检查应用的错误日志；或者启用Loadrunner的返回内容检查功能。

• 当心Loadrunner所在机器的磁盘空间。

缺省情况下Loadrunner会把运行结果的详细信息放在C盘的Documment and Settings的用户目录下，当大压力长时间运行或有大量出错时，Loadrunner会生成大量的数据到该目录下。当磁盘空间满了后，机器的响应将变得很慢。

• 结语。

还是那句话，性能测试是一件非常严谨的事情。本身在实验室里的性能测试就很难模拟真实情况，另外世界上没有两个一模一样的系统，要做到apple-apple的比较很难。 所以做性能测试一定要仔细，测试条件一定要定义清楚。否则，最后的结果是：上了生产系统后被最终客户折磨地吃不下饭睡不着觉。这不是开玩笑，我在别人那里见过了太多的这种情况。

浅析软件项目管理中十个误区[转]
随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致， 以后对需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间 进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面 要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽 早地对需求变动问题进行沟通。

误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的 改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少， 容易被实现。

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是 着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。

误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般 的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。

误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。

误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体 参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好 心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培 训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系 。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不 一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。

误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味 工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对“成就感”的追求，应该向每一个人详细描述最终“ 作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作 效率。

误区10：为了保证项目继续，为了留住核心程序员，加薪吧。分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了——加薪的 人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。 既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形 成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水 ，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其 感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

 
（转）悲哀，你选择开发工程师做为自已的职业

　　本文所指的开发工程师，仅指程序开发人员和以数字电路开发为主的电子工程师。
　　当你选择计算机或者电子、自控等专业进入大学时，你本来还是有机会从事其它行业的，可你毕业时执迷不悟，仍然选择了开发做为你的职业，真是自做孽不可活。不过，欢迎你和我一样加入这个被其它人认为是风光无限的“白领”吧。
　　如果你不是特别的与人世隔绝，我想你一定看过金老先生的名著《笑傲江湖》吧，里面有一门十分奇特的武功叫做"辟邪剑法"，你看这个小说第一次看到这种功夫的练法时，我想你当时一定笑歪了牙“呵呵，真好玩！”，可是现在我很痛心的告诉你：你选择的开发工作就是你人生路上的"辟邪剑法"，而你现在已经练了，并且无法再回头。
相对同时刚出校门同学从事其它行业而言优厚的薪水，以及不断学习更新的专业知识不仅仅让你感到生活的充实，更满足了你那不让外人知的虚荣心。在刚出校门的几年中，你经常回头看看被你落在后面的同学们，在内心怜悯他们的同时，你也会对自已天天加班的努力工作感到

心里平衡：“有付出才会有回报”这句话在那几年中你说的最多，不管是对自已的朋友们还是自已的爱人。第二句最常说的话是对公司的领导：“不行我就走人！”，实际上你也真的走过几回。对了，在这几年中，因为你的经济条件不错，你开始买房、开始谈恋爱、结婚、开始有了自已的小孩。有时候你会对自已说再过两年就去买车。当然其中可能有许多大件是需要分期付款的，但你对前途充满了信心，你确信认为这种日子会永远的持续下去，即使不是变得更好的话。
　　日子总是在这种平淡中一天天的过去，就在那么不经意间，你突然发现自已已经快30岁了，或者已经30了，莫名的，你心里会漫延着一种说不清楚的不安情绪，你好像觉得前途并非像前几年那样变得越来越好，你也忽然发现你以前所瞧不起的同学里好像已经有不少开着车的了，也有几个人住着比你还大的房子，好像房款还是一次付清的，你突然明白你现在的生活比起你的同学来最多是中游偏上了。工作中最让你感到心里不舒服的是，你越来越不敢对你的领导说不了，即使比你来的晚的同事升职或提薪，你也只是在私下与朋友们一起喝酒时才敢发发牢骚，在头的面前你的声间越来越小、笑脸是越来越温柔。
　　你终于开始迷茫“再过几年我会是在干什么呢？”，这句话常常出现在你的心里。
　　计算机开发工作，是一种以年轻为资本的工作，说句通俗点的话是“吃青春饭的”，嗯，这句话好像在一种特别的行业也听到过。

其标志就是一：工作的时间性非常强，一个开发项目被定的时限通常是很紧张的，更有甚者，有些号称开发管理的书里面还非常卑鄙的号召将一个项目切成多个小片，每个小片都定一个叫“里程碑”的东东来严格跟踪开发进度，加班加点在其它行业是需要加班工资的，而在开发行业，加班工资好像还没见到几个公司发过，是啊，反正有时间限制着，你干不完我再找你算账.所以开发工作通常有着其它工作所没有的精神上的压力。

一旦一个人步入而立之年，因为家庭和孩子的负担，加上精力上面的衰退，加班工作时间变得越来越少，这点让很多老板们感到：这些人已经老了，不好用了。指示人事部门：“以后招开发人员限制在30岁以下！”，相对而言硬件开发会年龄方面限制会稍好一点点，但也是五十步笑百步。还有一个很重要的一点就是：计算机这个烂东东实在是进步的太快了，前两年买的顶级配置电脑，现在怎么看怎么像废品，这还是小事，更可气的是好像每天都需要学习新的知识，刚毕业时只会书本上的PASCAL，学会了用腐蚀的办法来做电路板，一上班就开始学习TURBOC和TANGER2.0，刚刚学会，还没来得及高兴，马上开始学Borland C＋＋和Protel3.0，好不容易学会了，却发现需要学习VC和Protel98了。单片机也是啊：Z80的指令背的很熟，工作中没来得及用就要学8031，好好学吧，本来想着这辈子就吃它了，又发现又出来什么PIC、DSP、CPLD、FPGA、ARM等等....这还不包括中间要学一大堆74系列、4000系列、XX系列...IC卡居然里面还有CPU卡..如果学习的知识里每个字都能变成一分钱，我想所有的开发工程师都是腰缠万贯的富翁。
　　一眼看去，这种日子好像见不到头，年轻时乐此不彼，但现在你一定对自已能坚持到什么时候感到怀疑了。我们都玩过像仙剑奇侠传这样的RPG游戏，刚开始时你只是一个一名不文的少年，随着你去打怪物、捡宝贝、学秘芨，最后终于有一天你会变成一个大英雄！那么你在实际生活中过得比那些小侠们还辛苦，为什么成不了一个生活中的大侠呢？呵呵，原因在这里：因为开发工作是邪门功夫，它虽然可以让你速成的变成小资，但它最大的特点是经验不积累！日新月异的知识更新，让你总是感到自已在退步，你就像在RPG中的主人公，开始时就给了你一把好剑和好盔甲，而且让你的级别很高，但让你的经验不累积，虽然刚开始打小怪物时你觉得自已很爽，但越到后来，你会发现你会死的很惨！比较一下你与其它非开发行业的同学你就可以知道了，例如和你学医的同学比起来。套用岳不群他老人家说华山剑宗和气宗的区别那段话：前十年你比你那些学医的同学收入和地位要好的多，但十年以后你和他基本上各方面都会持平，而二十年以后你的各方面远远不能与你学医的同学相提并论！嗯，你已经开始不笑辟邪剑法了吧。
　　“敢问路在何方？路在脚下...”，不过猴兄和八戒兄这么认为是可以的，你呢？
总结了许多开发朋友在30岁以后的生活之路，让我们一起看看开发人员“路在何方？”那么开发人员在30岁以后都干些什么呢？
其路一：继续做你这个很有“前途”的职业吧！
　　偶掰着脚指头仔细数了数，发现还真的有很多朋友在30岁以后还在从事开发工作，我这里说的从事，是指你还需要天天在电脑边上编程序和画电路板，与你手下是否有几个小兵无关，也与你是否头上顶着什么项目经理、主任工程师的帽子无关，只要你还需要亲自开发，你就属于这一类。其中有个年龄最大的朋友是63年的，从事医疗仪器的开发工作，35岁左右还在从事软硬件开发工作的仍有一大堆，分析这些仍然从事开发的朋友，基本上都有以下特点：
1　痴迷工作或者痴迷电脑，晚上八点到十二点的这段时间，基本上是在电脑桌或工作台前渡过的。
2　不喜欢与人交住，朋友很少，常联系的人不超过五个。
3　与朋友交往时谈工作多，但一般不主动谈钱。
4　体型偏胖或偏廋，不在正常区间。
5　无未来计划，对五年后自已生活怎么样、从事什么工作说不清楚。
6　俭省，从不乱花钱。
即使你是还不到30岁的开发人员，你也可以看看自己对以上几条是否符合，是否会在30岁后还从事开发职业，四条疑似，五条以上基本确诊你也是这类型的人。
　 这些朋友们通常报着过一天是一天的态度生活，到了这个年龄，也不敢再轻易的换工作了，年轻时的锐气慢慢的也消退了。唯一不变的希望是有一天从天上掉下来一大堆钱把自己砸伤。说实在话因为他们的性格所限，基本上可以确定他们以后不可能在职场上获得更好的发展，当个小头头，带几个人开发已经是他们发展的顶点。至于以后的人生之路，不仅他们自己迷茫，可能上帝也正在头痛。
不过像这类朋友，偶很奇怪的发现：他们的小孩都是儿子！不知是偶然还是有什么其它说法。
简单建议：要改变命运，先改变性格：坚持半年晚上不从事工作、游戏及电视，用此时间与人交往，你的人生会有改变。

其路二：转行从事技术支持、行政或生产等工作还有一些朋友，从事了几年的开发工作，因为自已并非特别的爱好，或者领导上面的强制工作安排，他们转到了技术支持、服务或行政等工作，至少当时从表面上看起来，他们的薪水较开发要少一些，但真正的统计这些人，发现他们之中有半数的人获得了更好的发展，升职为服务部经理或行政经理等职，最历害的一个朋友已升职为总经理助理，进入高层。
　　这类朋友当时转行通常并非自已志愿，属被逼无奈或者其它原因，但显然，拥有专业知识技术的他们显然在非技术部门中鹤立鸡群，遇到什么事情他们均可从专业的角度提出建言，久而久之，他们获得更多的升职和加薪机会也就不足为奇。
　　因为不从事开发，所以经验开始积累，这类的职业通常会给你一个很安定的感觉，你到30多岁后会发现这类职业反而比开发工作更容易获得新的工作机会。

　　简单建议：你如果确定在开发部无法获得很好的发展机会，不妨转到其它几个部门试试，换个活法，钱少点就少点吧，机会多。
其路三：开发管理
　　如果你现在已经是总工或开发部经理，或者你眼看就有机会被提升为这类职务，那么恭喜你，你走的是从“弼马温”到“斗战胜佛”这条金光大路，你不仅拥有很高的专业技能，而且很显然，你也有着很强的人际交往能力，你这类人根本不需要对未来有着任何的担心，你在即使一无所有的时候也很容易白手起家。
　　你这种人算是练辟邪剑法练成了仙，嗯，我无话可说。
　　你是不是这类人也很容易区别，就像围棋二十岁不称国手终身无望一样，你应该在工作三、四年以后，也就是说二十七岁左右就会发现自已工作中指手划脚的时间比亲自开发的时间要多了，而且大多数这类人在这个年龄手下应该有“兵”了，相反的，如果你快30岁了还天天埋头于电脑前编程序和画板子，或者30多岁了你还没升到部门经理（虽然你总是觉得自已很有希望），基本上可以确定你不是这类人。好了，如果你确定你是这类人，那么你唯一的想法就是尽快爬上中层和高层，因为有时候人生偶然性太大，不占住坑的萝卜很有可能被人拔出来！

　　简单建议：天天去你的老板家里面拖地和擦桌子！

其路四：出国或考研
　　有两个搞开发后出国的朋友，其中一个甚至打工打到了一个小公司总工的位置，数据库和软件方面水平巨牛，但仍感觉心里不踏实，于是将自己工作多年的钱忍痛掏出来，出国费加上机票大概将自已辛苦所攒的银子花完，然后又借了一些钱，在02年身上揣着一万美元跑去了加拿大，在加拿大不停的重复找工作，换工作，然后再找工作的循环，找的工作基本上与计算机无关，不过工资总是在1500加元左右，呵呵，折成人民币与他在国内打工拿的基本上差不多，不过租个地下室就花了300加元，然后吃吃喝喝，再买个电脑上上网这类的，基本每月平均还要倒贴一点。前段时间给我的邮件里说，现在身上花的差不多只有5、6000美元了，准备开个小公司，看看能不能往国内倒腾点东东，做最后一搏。另外一个朋友去澳州，时间稍早一些，先是大概摘了一年多的葡萄，后来总算找了个技术工作，每天的工作是画机械图纸，收入还算不错

将近3000澳元，买了个旧车，也算是过上了资本主义生活。不过前年回来一趟，唯一的感叹就是：在国外拿2000美元的生活，绝对不如在国内拿5000人民币的生活舒服。
　　也有两个考研的朋友，不过其中一个严格的说不是做开发的出身，偏重于市场方面的工作性质，不过我的朋友里面考研的不多，只好凑两个人说说，一个考研后在北京找了个工作，每个月5、6000元钱，但还是做开发，生活仍然与没考研之前没有任何的改变，前途仍然没见到什么大亮的光，还是搞不清楚以后再干些什么，标准的过一天算一天了。另外一个考研后在大学里面找了个工作，工资虽然比他原来打工少了不少，但毕竟终身有靠，稳定了下来，也算修成了正果，这位哥们心情一放松下来，也开始有时间琢磨着业余时间自已做点什么，好像现在慢慢的也开始有了点眉目。
　　简单建议：这两条路，对开发人员来说都不算是很好，出国十年前是好事，现在难说，考研能成功转行的概率恐怕也不是很大，多半仍然去搞开发，只不过研究生可以多干几年罢了。

其路五：转行到市场
　　绞尽脑汁的想想，我所知道的人之中只有两个开发人员去了市场，这两个人都不能说是朋友，认识而已。他们都是主动要求去了市场，结果是这两个人均在市场都是干到一年左右，然后都自已开公司了。呵呵，很奇怪，极高的转行成功率！不过仔细想想，我对这两个人的思路佩服的五体投地。能下决心仍掉每月5、6000元的开发职位，从事一个自已并不熟悉的岗位，每月拿个2000多元＋提成，但提成那是说不清楚的事情，这个决定，只能让人感觉到他们对自已前途清晰的把握和老谋深算的心机。而且他们不去服务不去生产，挖空心思说服领导去市场（市场部门与开发部门通常是一个公司的核心部门，进入其实并不容易），可以说是有着长远的考虑的。有技术了，再与客户交成朋友，马上就会产生很大的机遇应该是正常的事情。
　　有实力，有心机，也有着很强的决心力，这种人恐怕早在大学毕业时或更早的时候就已经决定了自已的人生之路，他们的每一步路在若干年前早就计划周全，现在看起来：学会技术－＞进入市场－＞寻找商机－＞开公司，一条多么清楚的人生之路。但就像我们上小学中学时，所有人都知道上大学是我们最清楚的人生路一样，最后只有少数人才能真正达到目标（当然，现在扩招的历害是另外一回事，我是说我们那个时候，也就是：“很久很久以前，当我像你那么大的时候”）。

　　简单建议：你若是这类人，我的建议是：...嗯?....那个你.你，你别走啊，我还有个事想请你赞助一下啊.....

其路六：开公司自已干

　　呵呵，看到这一条，发现你的眼睛已经圆了，你肯定千百次的想过这个事情吧，咳咳，其实我从事开发的时候也是天天梦想着这种事情。总想着过两年找个机会就自已干，这个梦想一年又一年的折磨着你也给着你希望。看看吧，开发后来开公司的还真的不少，里面有成功的也有很多失败的，通常开公司都是几个人合伙开始的，有做技术的，有做市场的，几个人一拍即合、狼狈为奸，共同策划了这一个大活动。一般说来能让这几个人下决心走出这一步，产品肯定是先进的，甚至是国内独一无二的，市场也是很大的，负责市场的那个哥们通常会拍着胸保证可以卖出去，并悄悄地告诉你他在某主管领导是他小舅子的同学的二叔，肯定没问题。于是你们几个人找地点、注册执照、买了几个破桌子，再攒了两台电脑，每个人又凑了几万银子，公司开张了！
　　产品很快出来了，市场的哥们也不负重望，有几个客户表示要试用了，一切看起来都是如此的正常，“.......你坐在老板桌前，不停的有人来汇报工作或者找你签字...人进人出中...你又想起公司再穷也不能只有一把椅子的故事.....”你在梦中笑出声来。
是如此的顺利，你们很快就有单子了，很快的单子让你们凑的那点钱不够了，你们很高兴的每个人又增加了投入，拿出钱时你眼泪汪汪的数着钱说：“这就是我那生蛋的母鸡啊”。你们的产品确实不错，市场也经营的很好，客户慢慢的多了起来，单子来的时候一笔接着一笔，你每天都处于兴奋之中，唯一美中不足的是好像客户回款总是会拖一些日子，不过客户给你保证说：过几天，过几天就付给你们，因为回款总是在计划外，所以你们为了资金的流畅运行又凑了一些钱，这个时候你有一些心事了，因为你的存款折上面的数字已经快趋向于零了。“没事，过两个月等回款了一切都OK了，谁干事业不吃点苦呢？”你这么安慰着自已又投入到工作中去，资金总是在回款和生产经营费用之间走着一个窄窄的小木桥，你的账上总是没有太多的钱，扩大了的公司规模和许多意外情况，使你又一次、二次、三次的与合作者们再次投入了自已的资金，当然，后来的钱你可能已经是借的了.....
　　终于有一天，你的会计再一次告诉你，老板啊，账上又没现金了，吃过多次苦头的你终于下决心开始重视资金的运行了，你裁掉了一些不必要的人手，减少了开发的投入，要求市场人员签单的时候必须予付XX%的款，回扣也必须等收过款后再付，同时也开始对产品的生产成本开始进行控制。
　　时间一天一天的过去，因为竟争对手的产品也对你的产品进行了仿造，你的产品慢慢变得不再先进，市场人员开始埋怨公司的合同资金方面规定太严格，不好签单，生产成本的下降通常也导至产品毛病的增多，客户也开始埋怨你的服务人员不能及时进行服务。
　　终于有一天，你重新走进了人才交流中心，以前你是来招人的，现在你拿着自已的简历开始寻找一个工作
......
公司的成功与否，与产品有关，与市场有关，但更重要的是与资金有关，产品与市场都可以通过资金来弥补，而却没有任何东西可以代替

资金，凡是倒下的公司，99%与资金链的断裂有关。在你决定要开公司以前，先估计一下你公司支持一年所需要的资金数额，包括人工费，生产，场地，广告宣传、市场费用、甚至电、水费等等等等，把你所想到的一切加在一起，得出的值就是..慢..如果你没有实际的开过公司的经验，你需要将此数字乘3，然后就是你开公司一年最少需要的费用，呵呵，公司的实际运营所需要的钱是你想像的3倍以上，你要是不信我也没办法。

简单建议：开公司前最重要的是先确立你后续的资金来源！也就是说钱不够了怎么办？－－－因为你投入的钱肯定会不够的。

其路七:第二职业
这类的朋友有不少,他们没有脱离开发工作,但是在业余时间又不停的接项目或者在卖产品,在单位里面他们显得并不出众,比起其它人来说他们属于最不愿意加班的一类.为此他们白天通常工作很勤奋.这类人也许不一定可以挣很多钱,但平均下来他们一年之中通常都可以比同事们多挣个几万元.有时候比上班拿得还多.但令人疑惑的是,这类人在生活中更加注重稳定,基本上没见到他们跳过蹧,即使私下里面已经开了个小公司,他们通常也不会辞职.
你的旁边有没有这类人呢?分辨他们很容易:
--电话很多,而且更愿意来电话时离开办公室找个没人的旮旯通话.神秘兮兮给人一种"这家伙是不是有二奶啊?"的感觉的人，通常是这类人。这类人是女性最佳的选择对象：很顾家，不象那些富人容易花心，而比起一般人来说，他们收入相对要高得多。但总结了一下几位这类的开发朋友：也得出了一个令人沮丧的结论：这种人通常个子不高，体形类似桶状.....

简单建议：这好像是开发人员最佳的出路了，但比较丰厚的收入通常让这类人不愿意去冒风险....到现在为止我所认识的这类人还没有一个真正算是成功的。
好了，虽然偶的经历远远说不上丰富，也没有什么成功之处可以自满的，但或许因为比其它朋友痴长了几岁，见过的人可能会稍多一些，所

以斗胆写出了以上的一些文字，让您掉牙了。
下面是偶走过开发这条路上总结出来的一点心得，你可以不看，但看了就千万别把嘴咧的太大：
一、不管是给别人打工还是自已干，都要全心全意的工作，因为你所做的任何一点工作都会让自已的人生多一点筹码，这一点最最重要!这样的例子我至少可以举出两起，优秀的开发人员被其它新公司挖走，并给一定的股份，成为新公司的股东的例子。当时与这样的开发人员一个部门同时工作或更早工作的有许多人，他们平时经常偷点懒，能少干点工作就少干点，有时候还笑话那个平时努力工作的人傻，几年过去了，究竟谁比谁傻？
二、多与市场人员交朋友，你接触他们时可能总会觉得他们知识比你少，甚至素质比你低，可能比你还有点黄。但实际上他们比你更懂这个社会！参加到他们这个圈子中去，和他们一起赌赌钱、一起聊聊天、一起洗洗桑拿、一起.....你会通过他们接触到另外一个世界。
三、机会远比钱重要，挣不挣钱在年轻时并不是特别重要！不论是在实际生活中还是在网上或其它地方，如果有机会参与到除本职工作外的一些项目或产品的开发中（包括你的朋友拉你去做点小生意之类的非开发性质的工作），那怕是帮忙的性质，也要积极介入，至少你会交到很多的朋友，这样你的人生会多出很多的机会。

　　由于没有得到足够的重视，软件缺陷管理处于失控状态。软件测试人员报告的缺陷常常被遗忘掉;或没有人知道在新的软件版本里究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。更重要的是纠正过程是否引入了新的缺陷也没有人知道，再或者就是缺陷报告书写不规范，使得开发人员不得不一次次找到测试人员来面谈，还有许多无效的文档使缺陷状态混乱，相关人员无法及时获得有关的变更信息。

　　什么是开发的缺陷管理?

　　软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。

　　软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。

　　(1)缺陷管理的目标

　　一般而言，缺陷的跟踪和管理需要达到以下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。

　　在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　(2)缺陷管理重在预防缺陷

　　正如我们所知，BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此，越晚修正BUG，需要重做的事情就越多。

　　对很多人来说，零缺陷的软件产品似乎是不切实际的。因此，我们总是听到许多软件开发人员说：“软件永远有BUG”。软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值提深思的事情了。

　　事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。为了能够预防BUG，我们首先需要了解BUG的来源。软件BUG可以分为几个类别：第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难预防。但是，适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。

　　但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。因此，BUG的预防尤为重要。

　　缺陷管理的核心：缺陷分析

　　缺陷预防的着眼点在于缺陷的共性原因(Common Cause)。通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。

　　BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费，但是却可带来极大的额外价值。

　　(1)BUG记录

　　BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。

　　(2)利用BUG分析了解开发质量趋势

　　对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。

　　BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。在这个时候，BUG分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。

一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。

　　实际上，BUG分析图表会告诉我们很多有价值的信息。比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点发现的故障数反而呈上升趋势，那么意味着往往有一些特殊事件的发生。通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。

　　(3)发布BUG分析经验,提高团队成员能力

　　分析得出来的BUG实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库，这将使得新的知识在项目内流动并被相关的开发人员所学习。

　　BUG分析带来了很多的好处。第一个好处就是帮助产生BUG的开发人员总结经验，并使他在将来避免类似的BUG。有时只修正一个具体的BUG而不去分析它产生的原因并不会帮助开发人员在日后得到提高，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。

　　从这个角度来看，BUG分析的价值不仅仅是缺陷的预防，更大的好处是通过记录和分析BUG，项目内的其他开发人员知道如何发现类似的错误。所以，我们可以通过某个开发人员产生的一个BUG提高整个项目团队的实践经验，而不仅仅是尽快修正它。这样，因为一个缺陷所浪费的时间也可以转化为收益：确保类似的错误不会再发生。除了分享项目内的测试知识和经验，BUG分析过程还可以促进开发更好的测试技术和工具，从而帮助发现类似的BUG。

　　如何高效地进行缺陷管理

　　(1)清晰缺陷分类，明确处理责任

　　首先要改变以前那种凡是BUG就是由开发人员负责的观念。跟据缺陷内容可分为需求BUG与程序BUG。对于程序BUG是由相关开发人员进行处理，需求BUG则要交由需求人员进行处理，对于这种分法的好处就是明确了BUG处理的责任人。

　　测试人员从本质上来说与程序员还是对立的，如果为了一个不是软件程序本身的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况。测试人员协调好与开发人员的关系，可让他们更高效的关注软件本身的缺陷。

　　(2)建立缺陷处理流程，减少无效运作

　　建立缺陷处理流程，这对测试人员和开发人员来说都是很有帮助的。BUG处理流程其实就是定义BUG处理过程的职责和权限，用明确的流程去指导如何对BUG进行日常管理，提高运作效率。

　　(3)使用缺陷管理工具:BUG管理库

　　为了跟踪和控制测试质量，便于管理测试发现的BUG，我们需要为项目配置一个专用的缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证缺陷。因此，开发过程中使用一套BUG管理工具是非常必要。

　　缺陷管理工具应便于项目组和管理人员获取正确、足够的信息，以简化信息共享流程，最大限度减少重复工作。BUG管理库就是记录、评估缺陷，并执行及维护系统配置，创造一个高效管理环境的最好工具。例如使用缺陷管理库可以很方便制作各种缺陷分析图表，从而预测项目风险或解释测试结果。整个开发过程是BUG数从少到多，再到少的过程。从BUG数量的变化，也可以推断软件产品的成熟性，推断产品的发布期。

　　(4)把管理制度和配置策略相结合

　　有了先进的缺陷管理工具，还需要有相应的管理制度与之相配套，否则BUG管理就只是一个摆设。目前BUG管理制度方面主要的问题是不重视测试，认为测试人员无关大局，随便测测就行了，再或者就是虽然认识到测试的重要性，但却走向了极端，制定了极其严格的规章制度。

　　例如无数琐碎、难用的测试工单，非常严密的层级权力控制等。把一个需要灵活变化的工作变成了工业制造车间流水线的一个工种，让测试人员陷入制度的泥潭，不能把主要精力投入测试工作本身。再或者就是项目负责人也没有制订明确的BUG处理流程及相关指导原则，让测试人员在黑暗中摸索，走到哪儿算哪儿，不能给他们以切实有效的指导和帮助，把软件的质量保证责任一股脑推到测试人员身上，任何问题都去指责测试人员。

　　最后，BUG管理制度还有一种常见的错误考核制度，就是项目主管用BUG个数去衡量测试人员的工作成绩，谁发现的BUG多谁的工作就做的好。这是一个十分危险的倾向，将直接导致测试人员去重视BUG个数这个数字本身、而不是产品的真正质量。最后重申强调一点：BUG不仅仅是被修正，更重要的是根据BUG管理来提高软件产品质量。

从事了几年测试工作，也着实见证了测试的发展，如今测试行业对从业者的要求是越来越高，不再仅仅局限于要求会写测试用例、会细致的执行测试、能有效的发现系统缺陷等；越来越多的企业对应聘者本身的技能要求也越来越高，招聘信息中诸如“精通VBscrīpt、Perl/Rbuy等至少一门脚本语言”、“至少熟悉一门开发语言”、“精通QTP、LR等自动化测试工具”、“有大型项目自动化实施成功经验”此类的字眼也逐渐增多。目前看来，除白盒测试内容和测试管理外，主流的方向有两个：功能自动化测试和性能测试。这就要求从业人员能够在短时间内快速的掌握这些知识，才能获取到更好的工作机会。本人是名功能自动化测试的工程师，以自己学习、工作的过程结合QTP讲讲该如何学习自动化测试

首先，想从事自动化测试，必须先了解What/Why/How，也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试，这类的资料在网上有很多，这里就不做重复了

其次，需要根据项目的特点，选择合适的自动化测试工具，并了解工具的特性。以QTP为例，该如何去掌握它呢？对于初学者，大多数都是通过录制的方式来生成脚本，这个阶段应该掌握的基础知识有

1)      QTP是如何去识别对象的，对于新手经常会出现录制的脚本回放的时候报错的现象，这个时候就应该考虑为什么呢？如果很了解QTP识别对象的原理啊，我想就能很快定位到原因了

2)      去掌握一些QTP对象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等，对于相似的方法应该去搞清楚到底区别在哪？像GetROPreperty、GetTOPreperty有什么区别等

3)      什么是Action参数、什么又是Test参数？两者有什么区别，又有什么联系，在同一Test和不同Test间这些参数如何工作

4)     什么是环境变量？环境变量是如何建立和使用的，环境变量在参数传递中和action参数、test参数有什么不同

5)     了解检查点的知识，明白什么是内置检查点，什么又是自定义检查点。并搞清楚在什么时候该如何使用检查点

6)     掌握对象库的操作，了解对象库对于测试的意义，象是否启用智能识别对测试脚本有何影响、为什么同一对象识别起来会有_1、_2之类的后缀等都是需要去研究清楚的问题

这几个问题都搞清楚的话，那基本就能够利用QTP生成正确的脚本了，当然以上只是部分必须掌握的内容，其实还是很多细节的设置，就需要在实际运用中去掌握了

接下来，就可以进一步提升自己的QTP运用水平了，这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了，同时在这个过程中还需要去学习html知识、DOM、XML、以及像excel、word等的API知识了，总的来说，这个阶段应该掌握的内容大体上包括

1)     VBscrīpt的基础知识，熟悉常用的方法和函数，掌握文件对象的操作等

2)     熟练掌握XML技术；excel、word等API对象，可以根据需要创建日志等

3)     熟练掌握DOM和HTML知识，能够结合这些技术对Web页面进行解析

4)     掌握数据库的基本操作语句，能够利用ADO对象进行数据操纵

5)     熟练掌握正则表达式，很多时候处理对象问题相当方便

6)     掌握如何调用dll进行工作

7)     能够利用QTP的自动化对象模型创建出需要的运行模式

8)     掌握WMI知识

以上只是我考虑到的部分，并不全面，呵呵，供大家参考，当然这些技术主要是针对Web系统运行，因为我们的系统就是B/S的，呵呵。如果这些知识都能够扎实的掌握的话，个人认为，基本上能够处理自动化过程中的绝大多数问题了，这个时候你对自动化测试的技术应该是有一定积累了

接下来就需要考虑自动化测试框架问题了。当脚本规模到了一定的程度，就会面临一些问题，如：

1)       如何有效的管理并调度脚本

2)     如何实现脚本运行的无人值守，测试过程中能够自动进行错误处理并进行日志记录

3)     如何生成简介明确的测试报告

4)     如何能够更加高效的维护测试脚本

5)     实现框架代码和业务代码的分层、业务脚本和业务数据的分离

这个阶段主要体现的是测试人员的测试思想，是可以脱离工具独立存在的过程。当然各个公司项目的实际情况不同，导致设计出来的思想不同，但总体上来说一般包括数据驱动和关键字驱动两种模式。后者实现的技术难度大于前者，大多数公司目前都采用的数据驱动模式。这个阶段不应局限于技术运用上，而需要从测试全局考虑，进行分层设计、模块化实现，减少代码之间的耦合

如果以上三个方面都能够做的很好的话，那么恭喜你，你已经可以独立负责项目的自动化测试建立工作了，呵呵！

总之，学习自动化测试需要在实际项目中进行，这样提高的会比较快，项目中运用了很多种技术，自动化实施过程会碰见各种各样的问题，是很好的学习机会，关键要善于总结、积累经验，只要能够把各个细节做好，那么你一定能够成为一名优秀的自动化测试工程师

转]数据库设计中的14个技巧
下面十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。

      1. 原始单据与实体之间的关系
　　
      可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。

      〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。

      2. 主键与外键
　　
      一般而言，一个实体不能既无主键又无外键。在E?R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
　　
      主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

      3. 基本表的性质
　　
      基本表与中间表、临时表不同，因为它具有如下四个特性：
　　 
        (1) 原子性。基本表中的字段是不可再分解的。
　　    (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
　　    (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
　　    (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

      理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

      4. 范式标准
　
      基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。

      〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
　　
      在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
　　
      表1 商品表的表结构
　　  商品名称 商品型号 单价 数量 金额
　　  电视机 29? 2,500 40 100,000
　　 
      5. 通俗地理解三个范式
　　
      通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
　　
      第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
　　  第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
　　  第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.
　　
      没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

      6. 要善于识别与正确处理多对多的关系
      
      若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。

      〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。

      7. 主键PK的取值方法
　　 
      PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。

      8. 正确认识数据冗余
　　
      主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。

      〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。

      9. E--R图没有标准答案
　　
      信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E?R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

      10. 视图技术在数据库设计中很有用
　　
      与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

      对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？

      11. 中间表、报表和临时表
　　
      中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

      12. 完整性约束表现在三个方面
　　
      域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。

      13. 防止数据库设计打补丁的方法是“三少原则”
　　 
       (1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
　　  
       (2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
　　  
       (3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
　　
      数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。
　　
      提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E?R图中实体的个数、主键的个数、属性的个数就会越少。
　　
      提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
　　 
      “三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

      14. 提高数据库运行效率的办法
　　
      在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
       (1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
      
       (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
　　
       (3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
　　
       (4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
　　
       (5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
　
      总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。

1、Web性能测试

Web性能测试涉及的范围太广，但一般web开发者在程序上线以后很多都曾遇到过性能的问题。普遍表现为页面速度开始急剧变慢，正常访问时间变的很长，或则干脆给你抛出异常错误页面。这里会涉及到很多可能发生的情况，举例几个最主要发生的情况：

• 数据库连接超过最大限制，目前一般表现为程序的连接池满，拒绝了与数据库的连接。
• 数据库死锁
• Web Server 超过最大连接数（一般在虚拟主机上才会限制）
• 内存泄漏
• Http连接数太多，即访问量超过了机器和软件设计正常所能提供的服务

2、CC攻击

CC主要是用来攻击页面的.大家都有这样的经历,就是在访问论坛时,如果这个论坛比较大,访问的人比较多,打开页面的速度会比较慢,访问的人越多,论坛的页面越多,数据库就越大,被访问的频率也越高,占用的系统资源也就相当可观。

一个静态页面不需要服务器多少资源,甚至可以说直接从内存中读出来发给你就可以了,但是论坛就不一样了,我看一个帖子,系统需要到数据库中判断我是否有读读帖子的权限,如果有,就读出帖子里面的内容,显示出来——这里至少访问了2次数据库,如果数据库的体积有200MB大小,系统很可能就要在这200MB大小的数据空间搜索一遍,这需要多少的CPU资源和时间?如果我是查找一个关键字,那么时间更加可观,因为前面的搜索可以限定在一个很小的范围内,比如用户权限只查用户表,帖子内容只查帖子表,而且查到就可以马上停止查询,而搜索肯定会对所有的数据进行一次判断,消耗的时间是相当的大.

CC就是充分利用了这个特点,模拟多个用户(多少线程就是多少用户)不停的进行访问(访问那些需要大量数据操作,就是需要大量CPU时间的页面).这一点用一个一般的性能测试软件就可以做到大量模拟用户并发。

假设服务器A对Search.asp的处理时间需要0.01S(多线程只是时间分割,对结论没有影响),也就是说他一秒可以保证100个用户的Search请求,服务器允许的最大连接时间为60s,那么我们使用CC模拟120个用户并发连接,那么经过1分钟,服务器的被请求了7200次,处理了6000次,于是剩下了1200个并发连接没有被处理.有的朋友会说:丢连接!丢连接!问题是服务器是按先来后到的顺序丢的,这1200个是在最后10秒的时候发起的,想丢?!还早,经过计算,服务器满负开始丢连接的时候,应该是有7200个并发连接存在队列,然后服务器开始120个/秒的丢连接,我们发动的连接也是120个/秒,服务器永远有处理不完的连接,服务器的CPU 100%并长时间保持,然后丢连接的60秒服务器也判断处理不过来了,新的连接也处理不了,这样服务器达到了超级繁忙状态.

我们假设服务器处理Search只用了0.01S,也就是10毫秒(这个速度你可以去各个有开放时间显示的论坛看看),我们使用的线程也只有120,很多服务器的丢连接时间远比60S长,我们的使用线程远比120多,可以想象可怕了吧,而且客户机只要发送了断开,连接的保持是代理做的,而且当服务器收到SQL请求,肯定会进入队列,不论连接是否已经断开,而且服务器是并发的,不是顺序执行,这样使得更多的请求进入内存请求,对服务器负担更大.

防范方法

说了攻击原理,大家肯定会问,那么怎么防御?使用硬件防火墙我不知道如何防范,除非你完全屏蔽页面访问,我的方法是通过页面的编写实现防御.

1. 使用Cookie认证.这时候朋友说CC里面也允许Cookie,但是这里的Cookie是所有连接都使用的,所以启用IP+Cookie认证就可以了.

2. 利用Session.这个判断比Cookie更加方便,不光可以IP认证,还可以防刷新模式,在页面里判断刷新,是刷新就不让它访问,没有刷新符号给它刷新符号.给些示范代码吧,Session:

程序代码:

〈% 

if session(“refresh”)〈〉 1 then  

Session(“refresh”)=session(“refresh”)+1 

Response.redirect “index.asp” 

End if 

%〉

 
关于软件测试及测试工具比较

来源：heiyou 作者：香山叶

1、测试自动化实现到何种程度为好

（1）、测试自动化的程度再高都不可能取代手工测试，即测试工具不可能取代测试人员；

（2）、一般来讲，测试自动化在整个测试过程中只能占到30%左右；

（3）、实现、运用自动化的程度还取决于各方面的资源，特别是软件的行业规范性和软件开发的稳定性；

（4）、对于部分白盒测试可以使用测试工具，如对代码性能分析等；

2、如何实现测试自动化的计划

（1）、首先将测试的基本管理形成自动化，如BUG管理等；

（2）、然后利用测试自动化工具来实现一些手工无法进行的测试活动，如：压力，并发，强度测试等；

（3）、接着利用测试自动化工具来完成回归测试中的缺陷跟踪测试；

（4）、再往后就可以利用测试自动化工具来记录两个版本的异同，以找出缺陷；

（5）、最后将整个回归测试都用自动化脚本保存，以完成每次的回归测试；

（6）、而对于白盒测试则可以引入测试工具进行代码分析；

3、对测试工具的使用现状及分析

（1）、目前，软件测试方面的工具很多，主要有MercuryInteractive（MI）、Segue、Rational、 Compuware和Empirix等公司的产品，而MI公司的产品占了主流。以下就各种常用测试工具进行简要对比：

主要厂商及其测试工具如下表：

Mercury Interactive Winrunner、loadrunner、TestDirector、Astra QuickTest

Rational Rational Purify （测试时用，检查运行时内存错误）

Rational Quantify （性能检测工具，查出系统瓶颈以便改进运行速度）

Rational TestManager （测试管理）

Robot （软件测试用，通过scrīpt自动模拟输入输出）

LoadTest

TestFactory （软件测试用）

Compuware QACenter、Perfromance Edition、EcoScope、TrackRecord

Segue SilkTest

Empirix eTest Suite

以下从常见测试工具功能、使用范围、目前市场情况、应用前景等方面做简要比较：

工具名称 功能范围

WinRunner-----功能：

1.插入检查点；

2.检验数据；

3.增强测试；

4.分析结果；

5.维护测试；、

６.为无线应用作准备。

范围：功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。

LoadRunner-----功能：

1.松创建虚拟用户；

2.创建真实的负载；

3.定位性能问题；

4.分析结果以精确定位问题所在；

5.重复测试保证系统发布的高性能；

6.Enterprise Java Beans的测试；

7.支持无线应用协议；

8.支持Media Stream应用；

9.完整的企业应用环境的支持。

范围：性能测试、压力测试、模拟多用户、定位性能瓶颈。

TestDirector------功能：

1．需求管理;

2. 计划测试;

3. 安排和执行测试;

4. 缺陷管理;

5. 图形化和报表输出;

范围：测试管理工具

Rational系列-------Rational Purify （测试时用，检查运行时内存错误）;

Rational Quantify（性能检测工具，查出系统瓶颈以便改进运行速度）;

Rational TestManager （测试管理）;

Robot （软件测试用，通过scrīpt自动模拟输入输出）;

LoadTest （负载测试）;

TestFactory （软件测试用）;

QACenter-----QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。

这些测试工具自动帮助管理测试过程，快速分析和调试程序，

包括针对回归，强度，单元，并发，集成，移植，容量和负载.

建立测试用例，自动执行测试和产生文档结果。

QACenter主要包括以下几个模块：

- QARun：应用的功能测试工具。

- QALoad：强负载下应用的性能测试工具。

- QADirector：测试的组织设计和创建以及管理工具。

- TrackRecord：集成的缺陷跟踪管理工具。

- EcoTools：高层次的性能监测工具。

QARun----

1.强大的测试脚本建立功能。

2.可反复运行，进行回归测试。

3．支持更多的应用访问

QALoad------

1.自动捕获实际执行过程，自动生成测试脚本。

2.通过控制台（安装在Windows NT）控制各个Agent（安装在Windows和Unix），进行脚本分配。

3.模拟实际操作，压力测试。

WebLoad-----Web压力测试工具

（2）、对于测试工具目前的使用状况，总结就是，大家都处于学习阶段，部分虽有一些应用到工作中，但也是比较有限的，最主要是应用在性能测试方面；