-
如何测试报表
2010-08-16 16:23:56
报表测试主要分为：报表界面测试、报表安全性、报表准确性、报表展示速度（也就是性能）。
数据准确性测试
报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。
另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。
对系统中的报表数据准确性测试方法较为灵活：
①系统中报表重叠的进行比对
②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对
③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。
报表差错测试
原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。
数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。
数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。
数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。
由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else，这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。
最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。
报表的界面和输入输出测试
界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。输入界面要求是：
①输入项字段长度不允许超过字段长度；
②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。
③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。
④对于选项，应不出现可选择的用户权限以外的选项。
⑤对于汉字模糊查询，考虑不常见字，如“㭎”即汉字因译码问题，造成的汉字存储出现乱码问题。
输出界面要求：
①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框
②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序
③报表标题明确，不能含糊误导用户
④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。
-
偶然性不可重现BUG怎么处理
2010-06-29 14:59:28
偶然性不可重现BUG怎么处理
一、一定要提交！！
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现！！
三、下次再遇到的时候，拉他们来看就可以了。因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )
四、你可以告诉程序员，测试过程是没有错误的。测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。
测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。
八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：
关于“无法重现”我看是有这么个问题存在。首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击“取消全选”按钮再办理业务不会发生；全选全消后，先点击人员再办理业务也不会发生。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。
下面是其它一些人的观点：
doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。
liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!
ericzhangali(另一个空间)：首先一定要提交bug；其次不要企图RD一定去解这个bug；某些时候还得关闭这个bug。如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试）
liyan_1014(雁子)：我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受 -
测试
2009-06-19 18:45:11
测试依次为单元测试，系统测试，集成测试，用户接受性测试，操作准备性测试等。
单元测试：
程序员做单元测试，确保自己的每个方法都运行，有的方法很简单，不需要单独测试
系统测试（system test）
他是完成某一个稍微集合的工作，比方批准一个定单，等等.
这个测试可以是测试人员，程序员，或者是用户来做。
系统测试最重要的就是： 要有一套测试的文档， 详细的说明了，输入什么，点什么按钮，然后结果是什么。没有这个，就会很乱。所以，如果系统很大就会有上千个测试用例
如果有太多组合，测试文档是非常必要的
集成测试（SIT， system Intergration Test）：
如果系统比较大，单元测试，系统测试之后可以做 集成测试，就是SIT，是专门来测试接口的，和system test 一样，要有好的准备，
当然，如果系统不是很大，可以和System Test一起做，这时，虽然叫 System Test， 也同时测试了总的系统
用户接受性测试（UAT User Acceptance Test）接下来就是用户接受性测试，这个是让客户自己测试，客户可以自己做测试数据，等等，
这个控制要好，因为客户很多会随便点，这个不行，会乱套的
如果这个测试通过，说明项目通过了，这是项目成功的标志。
操作准备性测试（ORT Operational Readiness Test） （不知道这样翻译对不对^_^）UAT后就是ORT，这个之后大型项目才常见，目的就是在正式运行前先试验一下，做一些比较关键的东西，确保正式运行时候可以通畅，之后就可以正式运行了
在测试中，所谓的白盒测试用的不多，除非你在找寻问题，才一行一行的查
另外还有就是压力测试和性能测试。压力测试就是测试程序的极限，如果1万个客户同时用，系统多块，给出一个统计，可以看出趋向。做完了SIT，或者ST， Before UAT，它要和系统测试分开做；性能测试可以单独做也可以和系统测试一起做，它主要是看系统运行多快，例如：每秒可以处理多少个记录；对于网页来说，打开一个网页等待时间是多少
这些测试只是一个测试， 因为和硬件有关，所以也要计算一下的 ，测试的电脑可能配备不怎么样，所以结果只是参考，但是，当项目运行了后， 这些东西还要看的。这就需要程序设计中的日志，分析日志找错是最直接也是最简单的方法，一般正式运行中，数据的复杂度高很多，需要好的日志系统来记录这些，要不然出了错，都不知道哪里出的
程序中要设计比较好的日志方法，来给写程序的人用，让他们在开发的时候就把这些放进去，
项目正式运行后，管理的只需要看日志就能做很多分析了， 比方哪里慢啊， 那些记录没有处理对啊， 哪些异常啊，有了比较好的日志系统，找错误、问题等很方便
-
内存泄漏的知识
2009-06-19 18:39:31
有关内存泄漏的知识
最近在看LR，对于内存泄漏的知识有点模糊，查找的有关资料，跟大家分享，本文只是介绍了内存泄漏的概念，例子，分类，表现，和检测方法，抛砖引玉，希望大侠们能分享自己检测出的内存泄漏实例。1.概念
简单的说就是你申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。由程序申请的一块内存，且没有任何一个指针指向它，那么这块内存就泄露了。2.泄漏的例子
举几个例子
void fun0()
{
char *p=new char[100];
}
执行完上面的函数就发生了泄露
指针p是局部变量，函数执行完后，指针p被销毁，造成 new char[100]的内存没有指针指向它
，也就无法再使用，造成内存泄漏。
void fun1()
{
char *p=new char[100];
p=new char[100];
}
这也泄露了
void fun2()
{
new char[100];
}
这东西肯定泄露完了
void fun3(char *a)
{
char *p=new char[100];
char *b=p;
p=a;
a=b;
}
可能有泄露，赶紧去加内存条。3.泄漏的分类
以发生的方式来分类，内存泄漏可以分为4类：
(1). 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
(2). 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。(3). 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
(4). 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。4.内存泄漏的表现
内存泄漏或者是说，资源耗尽后，系统会表现出什么现象哪？
cpu资源耗尽：估计是机器没有反应了，键盘，鼠标，以及网络等等。这个在windows上经常看见，特别是中了毒。
进程id耗尽：没法创建新的进程了，串口或者telnet都没法创建了。
硬盘耗尽： 机器要死了，交换内存没法用，日志也没法用了，死是很正常的。
内存泄漏或者内存耗尽：新的连接无法创建，free的内存比较少。发生内存泄漏的程序很多，但是要想产生一定的后果，就需要这个进程是无限循环的，是个服务进程。当然，内核也是无限循环的，所以，如果内核发生了内存泄漏，情况就更加不妙。内存泄漏是一种很难定位和跟踪的错误，目前还没看到有什么好用的工具（当然，用户空间有一些工具，有静态分析的，也会动态分析的，但是找内核的内存泄漏，没有好的开源工具）
内存泄漏和对象的引用计数有很大的关系，再加上c/c++都没有自动的垃圾回收机制，如果没有手动释放内存，问题就会出现。如果要避免这个问题，还是要从代码上入手，良好的编码习惯和规范，是避免错误的不二法门。5.内存泄漏的检测
内存泄漏检测工具介绍： http://bbs.51testing.com/thread-87138-1-1.html，只是列出了各个工具，具体实践没有。
另外网上还有很多针对java和c＋＋等的内存泄漏的文章
Java内存泄漏：http://www.blogjava.net/galaxyp/archive/2006/04/28/43724.html
VC6.0内存泄漏检测：http://leoman95.spaces.live.com/blog/cns!87f442ce8fa434b1!131.entry
LR中：如果Process\Private Bytes计数器和Process\Working Set计数器的值持续升高，同时Memory\Available bytes计数器的值却持续降低的话，说明很有可能是存在内存泄漏。 -
Windows 服务器崩溃
2009-06-19 18:31:05
磁盘已满
导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。
日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与操作系统不同的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。线程死锁
由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形：在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。
解决死锁没有简单的方法，这是因为使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。
如果程序使用了永久锁，比如锁文件，而且程序结束时没有解除锁状态，则其他进程可能无法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。内存泄漏
C/C++程序还可能产生另一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操作系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。
解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法无法找到由其他原因引起的库中的泄漏，因为库的源代码是不可用的。另一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个原因创建和清除子进程。
虽然Java本身并无指针，但总的说来，与C程序相比，Java程序使用内存的情况更加糟糕。在Java中，对象被频繁创建，而直到所有到对象的引用都消失时，垃圾回收程序才会释放内存。即使运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操作系统。结果是：Java程序会用光给它们的所有堆，从不释放。由于要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。
还有一个问题，情况与此类似。从连接池分配一个数据库连接，而无法将已分配的连接还回给连接池。一些连接池有活动计时器，在维持一段时间的静止状态之后，计时器会释放掉数据库连接，但这不足以缓解糟糕的代码快速泄漏数据库连接所造成的资源浪费。服务器超载
Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。操作系统级别可能还在不断地接收新的连接，而应用程序（Web服务器）却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected（已连接）的提示消息，但这以后什么也不会发生。
解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值，这样如果越过RqThrottle的值，就不会接收新的连接。那些不能连接的服务器将会停止工作，而连接上的服务器的响应速度则会变慢，但至少已连接的服务器不会被挂起。这时，文件描述符至少应当被设置为与线程的数目相同的数值，否则，文件描述符将成为一个瓶颈。数据库中的临时表不够用
许多数据库的临时表（cursor）数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。
这是一个不容易被程序员发觉的问题，但会在负载测试时显露出来。但可能对于数据库管理员（DataBase Administrator，DBA）来说，这个问题十分明显。
此外，还存在一些其他问题：设置的表空间不够用、序号限制太低，这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。
另外，还有许多因素也极有可能导致Web站点无法工作。如：相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无意间锁住了关键的表。C指针错误
用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引用指针（即，访问指向的内存）中出现一个错误，就会导致操作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。进程缺乏文件描述符
如果已为一台Web服务器或其他关键进程分配了文件描述符，但它却需要更多的文件描述符，则服务器或进程会被挂起或报错，直至得到了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络连接。默认时，大多数shell有64个文件描述符，这意味着每个从shell启动的进程可以同时打开64个文件和网络连接。大多数shell都有一个内嵌的 ulimit命令可以增加文件描述符的数目。
标题搜索
我的存档
数据统计
- 访问量: 17168
- 日志数: 42
- 图片数: 1
- 建立时间: 2007-09-17
- 更新时间: 2013-05-27
