-
如何发现客户端软件中的内存泄露？
2008-06-12 12:19:08
08-06-06问：
这里的客户端软件包括C/S系统的客户端和B/S系统中的客户端控件，当用户使用客户端软件时，如果发现我们的软件会吃内存，那是很丢面子的事，有哪些好的测试方法呢？希望大家能踊跃提出自己的看法。
答：
公司限时上网了
项目也接近尾声
忙！很忙！非常的忙！
所以有段时间不能在更新了
-
如何设计或者挑选有效的回归测试用例？
2008-06-12 12:16:02
08-05-23问：
随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。
在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量的自动化测试脚本，会占用大量的时间。
引子就说这么多，看看大家对这一普遍问题有什么看法和建议答：
回归测试是个重复繁琐的工作，如果直接选择大量用处不大的用例，直接影响测试人员的心情，效率低下，严重时还遗漏bug，即浪费了时间、浪费人力，又得不到好的效果;
如果回归的用例不足，人、时间当然节约了，但是质量就得不到保障了.
实际工作中进行回归测试前，
首先需要知道哪些地方改过，哪些地方没有改过，改过的地方会对其他地方有什么影响（相关联的地方）
如果能知道可能会引起什么问题那是最好的（必需对软件非常的了解）
针对这些地方再去选择用例，进行回归测试，这样即保证了效率有保证了质量。
对于质量要求高的软件，那就必须进行完全的回归了，这时可以选用自动化工具（公司有条件可以自己开发工具），可以选用QTP,WR等
在软件没有完全稳定的时候可以选用描述性编程。
时间紧迫也可以采用80/20原则，把用户经常操作、还有bug经常发生的地方进行完全的回归或选择有效的用例回归，然后只要保证剩余的模块不出现高等级的bug，其他的地方可以等时间空下来的时候测试人员再进行测试
如果软件几经发布，发现bug以补丁形式发布。 -
做好测试计划和测试用例的工作的关键是什么？
2008-06-12 12:10:00
5-30问：
测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？答：测试计划的作用:
1.在测试过程中起指导作用（目标、方法、里程碑的时间……）
2.改善测试任务与测试过程的关系
3.提高测试的组织、规划和管理能力
计划文档中包括：
1.测试项目简介
2.测试项
3.需要测试的特征
4.不需要测试的特征
5.测试的方法 （测试人员、测试工具、测试流程）
6.测试开始条件和结束条件
7.测试的准入和准出
8.里程碑时间
9.全部挂起、部分挂起条件，及恢复条件
10.测试提交的结果
11.测试环境（软件、硬件、网络）
12.测试者的任务、联系方式与培训
13.测试进度与跟踪方式
14.测试风险与解决方式
15.变更方式
………………………………
（实际中不同的公司详细程度也不相同）
做任何事都必需有个计划
为什么需要测试用例：
1.在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性；
2.测试用例的使用令软件测试的实施重点突出、目的明确；
3.根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；
4.减少回归测试的复杂程度
5.在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
6.功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升；
7.根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报告；
8.可以根据测试用例的执行等级，实施不同级别的测试；
9.为分析软件缺陷和程序模块质量提供依据；
10.便于大型软件测试项目外包测试指导基础；
现实工作中很多时候会遇到这中情况
需求在哪边？开发脑子里！
需求不明确，没有以文档的形式记录下来，不明确，更变态的是1天一小变，3天一大变（夸张了点o(∩_∩)o），在这种情况下用例的作用是什么？说不定花了好久写了一千条用例（1000条用例不算多的，基本一个超过半年的系统在保证测试覆盖率的情况下用例肯定超过4000条），需求一变，六百条需要维护，工作量之大~~~~
OK变了就维护吧~谁知道刚刚维护好，需求又变了，又有400-500条需要维护~~崩溃了吧
所以就取巧了，测试就不按照测试用例来了，monkey test 单纯的靠脑子想到哪边就测试下，我也这样做过，最后结果是测试很盲目；不知道哪些bug是已经提交过的；不知道还有哪些地方没有测试到；有的时候状态好，发现的bug就多一点，状态不好就完蛋了；最主要的是不知道什么时候可以测试结束（本来以为可以结束了，谁知道一兴奋多点了几下，哇靠bug一个个排队出来，后来又一直点到经理说结束才停止了这个噩梦）
现在还没有想到最好的办法解决
个人觉得需求不明确的时候（测试介入比较晚，介入时界面可以看到，软件基本完成），测试人员应该多于开发沟通，因为开发是最了解需求的人。然后开始“玩”软件，慢慢的了解系统，一段时间后针对一些比较稳定的模块进行写用例进行测试。需求还不稳定的，先进行随即测试，找出的bug记录下来，分析原因，找到bug多发点，将一些严重的bug以用例形式记录下来。慢慢模块稳定后，需求不再大变动的时候，开始编写用例，将以前一些问题也写在用例中，bug多发的地方更全面的覆盖到…………具体编写用例方法就不说了
PS:用例最好不要使用word，excel，很难管理很难管理~~~~而且维护起来真TMD难受；密密麻麻的字和蚂蚁一样；不能测试结果的追踪（大问题啊）
还有测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。 -
测试人员最宝贵的是什么（原创）
2008-05-21 09:15:32
回想这几天有一些bug的遗漏，感觉测试人员最宝贵的经验不是技术，也不是心态，而是对bug的敏感度。这倒不是说技术、心态不重要，如果没有它们测试也是没有质量的。技术、心态也是老是挂在嘴边说的，我也就不想多说什么了。
谈谈对bug的敏感度吧。
何为对bug的敏感度呢，就是看到一个功能就条件反射的知道有一些地方是bug多发的，什么地方开发容易疏忽，什么地方可能会隐藏bug。
比如一个查询：
在C/S系统中查询条件很多开发就是疏忽判断（如%、*、/）
查询时是否刷新输出框
被查询数据的选择是否正确
未查询到是否有提示说明
………………
在B/S系统中条件反射的就是有没有防止DOS攻击
希望各位测试平时多回想自己的bug，想想哪些bug是经常出现的，这些都将慢慢转变你对bug的敏感度，才能成为一个大师级测试人员
Ps：人的第一次都会痛，何况是软件，万一软件闹点别扭，o(∩_∩)o…就###……
特别注意：窗体中数据第一次保存到数据库中（需要完全输入）
第一次打开软件
第一次录入文件
好多好多第一次哦！~~~~~
-
审查自己
2008-03-28 10:12:33
第一点，互相攀比。
谁谁谁一个月有多少钱，谁谁谁转正就有多少钱，呀，都比我高啊……
以前哪个班的平均月薪就有多少多少的……
这类的话我已经看到多次，也听到多次。我很心寒。
当然，人在一起，难免会要比较。
只是当比较超越一切的时候，老师们平时这么用心去给你们的建议和分析就已经毫无意义了。
薪水有什么好比的？进公司工作就是为了比薪水的吗？
每个人的能力，起点，机遇，个人努力程度都不一样。
每个人的未来和“结果”也不一样。
忽略最重要的“过程”，刚一参加工作就比薪水，能给你带来什么好处？
如果不能沉下心来，不能有一个正常的心态，不能有一个面对现实、良好的自我调整能力。
那么，你将永远陷入恶性循环的状态中，更不去要谈你的未来和前途了。
第二点，刚工作就想跳槽。
站在某种角度来说，我可以理解一些同学的想法。
因为可能工作和你想象的不一样，或是工作中有一些不尽人意的地方。
这些我都能够理解。我也很想帮助大家，哪怕是给点建议或是信心、支持。
但现实不是想象的，现实就是现实，现实就需要你去面对和承受。在面对中成熟，成长，进步。
这就是测试人员将会要面对的一些东西，这也是测试人员必须具备的东西。
这也是所有人在踏入社会工作的时候，都会面对和体会到的东西。
这可能只是暂时的，需要你的坚持和努力。
不管你今天是做测试，还是做什么别的工作。
频繁的跳槽，无缘无故的跳槽，对你不会有什么好处。
有的同学刚参加工作，椅子还没坐热，工作还没完全适应，试用期刚刚开始，就这不满那不满，想要跳槽。
买新鞋子穿，都需要一个适应的过程。何况是工作？
看到同学的公司不错，就想要辞到现在的工作去那家公司面试。
同学能进家公司，你就能进吗？
如果你辞了原先的工作，而想进的公司却又没有录用你，两头落空中楼阁，你怎么办？
如果最起码的耐心和适应能力都做不到，就算换了公司，你就能做的得心应手了吗？
更现实的一点，企业也不喜欢频繁跳槽的人，因为他们会认为你做事情不够坚持。
如果你觉得在公司学不到东西，觉得公司的流程太简单，觉得公司的工作太轻松。
那么，你测试知识掌握、运用的很好了吗？你的C语言很强了吗？你已经是一名合格的测试工程师了吗？
你又有多少测试经验？你拿什么去跳槽呢？转51论坛
-
工作
2008-03-25 13:56:09
现在才发现一天到晚坐在电脑边上也很不舒服啊
腰也酸了
背页酸了
手页酸了
-
做饭
2008-03-24 08:32:19
昨天我第一次亲自下厨了，3个菜一个汤！
红烧排骨
玉米烙
黄瓜
青菜豆腐汤
哎！~~~~人间美味啊！~~~
特别那个汤没放油也那么鲜。
哎~！没办法！太厉害了~~~
虽然有两个菜是买了
-
关于loadrunner安装和卸载的一下看法
2007-07-10 11:48:31
51论坛转载！！谢谢原版的作者！
loadrunner安装的问题很多，各个网站的帖子也很多，51test中就有很多。
安装的时候基本上的问题就是安装包所在路径为汉字名称或者别的什么。
主要说一下自己遇到的问题，和解决的方法，希望遇到的人可以绕过而行，不用在走弯路了。
安装的问题：
整个装的过程都是OK的，完成后，提示需要重启系统蔷椭仄袅耍墒堑鹊锹嫉胶螅岜ù恚谌荽筇迦缦拢骸八凳莝ystem32下的BHOManager.dll DLLRegisterServer return error 8007007e”（我的系统是番茄花园的xp系统），当你确定以后，lr安装目录下bin中的所有dll文件都不能注册了，所以安装就失败，就这个问题，刚开始我一直没有定位好，等看了一段时候之后发现，BHOManager虽然在system32下，但是不是系统本身的dll，而是lr自己写入的（因为以前装好的lr中IE加载项中，印象是见过的）， DLLRegisterServer return error 8007007e 意味着没有找到BHOManager这个dll文件，或者这个dll没有注册，但是手动去注册却是报错，那现在问题基本上已经可以看出端倪了，所有的不能成功的因素，全都是BHOManager.dll没有成功注册的缘故，（找到根源就可以迎刃而解了）。在百度中搜索，发现如下内容:
你问题的解决方法，我今天也遇到同样的问题，给你做回答，呵呵，这个跟双核没关系，可能是你用的也是番茄花园的xp系统把，它的atl.dll是没有注册的，导致lr的BHOManager。dll无法成功注册！！！（原理就是这些），方法如下：
附：
我再重新安装时遇到的另一个问题。可能遇到的朋友并不多，放上来给大家参考吧。
在安装到最后的时候遇到这样一个报错：BHOManager.dll 注册失败。
于是在提示重启时未重启，而是去手动注册该dll文件，却弹出了另一个提示，"DLLRegisterServer in BHOManager.dll failed
Return code was 0x8007007e"于是到网上搜了下，终于找到了解决方法。
1. 需要IE 6.0 及以上版本支持, 请检查你的IE浏览器是否为 6.0 以上版本。
2. 请检查Windows系统目录中是否存在以下三个文件: msvcp60.dll, mfc42.dll, msvcrt.dll 文件, 如果有缺少,请下载并拷贝到Windows系统目录中去即可。
3. 请查看您的系统中是否缺少 atl.dll 文件, 如果没有, 请从其他相同操作系统的机器上拷贝这个文件到Windows系统目录, 然后打开命令行窗口并在该目录下运行命令:
regsvr32 atl.dll
看到成功提示后，再次手动注册BHOManager.dll（注册方法：打开命令行窗口并在该目录下运行命令regsvr32 c:\windows\system32\BHOManager.dll），提示注册成功。
全部完成后重启电脑，该问题就解决拉 :)
LR终于装好了。
那就意味这，BHOManager.dll的注册是和atl.dll的注册有关，前者调用后者中的东西，只要后者成功注册，前者就可以OK解决了！呵呵~~~~世界清净了许多！！哈哈！！
卸载：
因为之前一直没有分析正确问题的所在，所以卸载和重新安装loadrunner好几次，关于卸载的一些问题，及时你按照卸载工具卸载了loadrunner，下次装的时候还是会包license失效，解决方法，要登录到注册表regedit中（当发现报错后，立即去注册表删除下边的内容，只要有相同的就删除，这样注册码就可以再次使用了，并不会报错，呵呵）。
删除如下内容：
HKEY_CLASSES_ROOT\Mercury.Lm70Control
HKEY_CLASSES_ROOT\Mercury.Lm70Control.1
同时删除
Mercury.Lm70ControlMgr
Mercury.Lm70ControlMgr.1然后就使用查找功能，搜索“Mercury”，发现有Lm70Contro字样的东西都要删除掉。
最后删除下面内容：
HKEY_CURRENT_USER\Software\Mercury Interactive
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive删除完成后，继续填入license，下一步，如果还是不行，继续去注册表中删除上边内容，知道没有了，就OK了。
这些都是自己做过实际操作的内容，希望对大家有帮助。此文来源51testing论坛，转载请注明出处！
-
验证码
2007-07-10 11:44:35
录制邮箱的注册流程时，需读出随机的附加码。自动化测试过程中遇到这个问题，应该和开发人员交流，了解随机的附加码的产生原理后在自动化脚本中可以随机控制。
猜测：
随机附加码功能为每次当用户注册的时候，程序中产生一个随机值，调用存储在服务器上的图片（附加码的图片），在前台显示出来。
根据和开发人员了解到的：
知道原理后，测试人员和开发人员交流有哪些图片在服务器上，只要知道图片都有哪些，就可以做到如下工作
这里是某个网站的登陆需要添加附加码的网页源文件
验证码：<!--验证码表单-->
<input type="text" name="codestr" maxlength="4" size="4"> <img src="xxx.xxx">
看到上边<img src=“调用的图片”>，你只要每次读取这个img src的值就可以，你可以根据和开发人员了解的图片顺序，写个函数--图片索引函数，通过读取的值你就知道那个图片对应的那个附加码
然后直接处理就可以了，各个程序有自己的实现算法，需要你自己去寻找答案！ -
LoadRunner监视的性能计数器
2007-07-10 11:27:05
Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\\ % Disk Time
Physical Disk\\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\\ Avg.Disk sec/Transfer 和 Memory\\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\\ Available Bytes 和 Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\\Private Bytes、Process\\Working Set 和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs 和 Process(process_name)\\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较SQLServer性能计数器：
Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
. Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S Q L查询是否可以被优化。
. Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
Buffer Manager(缓冲器管理器)：监视 Microsoft® SQL Server? 如何使用： 内存存储数据页、内部数据结构和过程高速缓存；计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定： 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
.Page Reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
.Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
.Buffer Cache Hit Ratio. 在“缓冲池”（Buffer Cache/Buffer Pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
. Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器) 对象提供计数器，用于监视 Microsoft® SQL Server? 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
. Cache Hit Ratio(高速缓存命中率，所有Cache”的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
. Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
. Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 (X) 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。
. Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
. Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
. Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
Memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Total server memory：sql server服务器当前正在使用的动态内存总量.监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404） -
cmm结构体系
2007-07-10 11:10:07
-
测试的7个注意点
2007-07-10 10:46:19
1。应把‘尽早和不断的测试’作为测试人员座右铭。
2。回归测试的相关联性一定要引起充分注意，修改一个错误而引起的更多错误出现的现象并不少见。
3。测试应以‘小规模’开始逐步转向‘大规模’。
4。不可将测试用例置之度外，排除随即性。
5。必须彻底的检查每一个测试结果。
6。一定要注意测试中错误集中发生现象。
7。对测试错误结果一定要有一个确认过程。
-
软件测试的10大原则
2007-07-10 10:38:23
1.所有测试的标准都是建立在用户需求之上。
2.软件测试必须基于‘质量第一’的思想去开展各项工作。
3.事先定义好产品的质量标准。
4.软件项目一启动，软件测试也就开始而不是等程序写完才开始进行测试。
5.穷举测试是不可能的。
6.第三方进行测试更客观，更有效。
7.软件测试计划是做好软件测试工作的前提。
8.测试用例是设计出来的，而不是写出来的，所以要根据测试的目的采用相关的方法去设计测试用例，从而提高测试的效率，更多的发现错误提高程序的可靠性。
9.对发现错误较多的程序段，应进行更深入的测试。
10.重视文档
-
QTP日志校验（研究）
2007-07-06 22:01:23
If browser(" ").Dialog("Microsoft Internet Explorer").Exist(1) Then
Call WriteLogMsg("fail"+","+Environment("TestName")+"--"+"查找用户失败"+"," +"wjj登陆")
browser(" ").Dialog("Microsoft Internet Explorer").WinButton("确定").Click
else
If browser(" ").Page(" ").Frame("Disp_3").WbfUltraGrid("UlUserGrid").ColumnCount then
Call WriteLogMsg("Success"+","+Environment("TestName")+"--"+"查找用户成功"+"," +"wjj登陆")
else
Call WriteLogMsg("Fail"+","+Environment("TestName")+"--"+"查找用户失败"+"," +"wjj登陆")
end if
End If -
windows性能计数器
2007-07-06 21:26:59
这些计数器是针对我对windows操作系统，C/S结构的sql server数据库及WEB平台.net产品测试时的一些计数器；大家可以继续补充，作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友，也希望把自己使用的计数器贴出来，让大家分享。
好了，先说这些了，希望通过这个专题，最终能让大家对自己的测试结果进行分析。Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\\ % Disk Time
Physical Disk\\ Avg.Disk Queue Length例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\\ Avg.Disk sec/Transfer 和 Memory\\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\\ Available Bytes 和 Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\\Private Bytes、Process\\Working Set 和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs 和 Process(process_name)\\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。
Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只
%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
SQLServer性能计数器：
Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S Q L查询是否可以被优化。
Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
Buffer Manager(缓冲器管理器)：监视 Microsoft® SQL Server? 如何使用： 内存存储数据页、内部数据结构和过程高速缓存；计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定： 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
.Page Reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
.Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
.Buffer Cache Hit Ratio. 在“缓冲池”（Buffer Cache/Buffer Pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器) 对象提供计数器，用于监视 Microsoft® SQL Server? 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
Cache Hit Ratio(高速缓存命中率，所有Cache”的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 (X) 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。
Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
Memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Total server memory：sql server服务器当前正在使用的动态内存总量.
监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）
-
Visual Studio.Net已检测到你的服务器运行的不是Asp.Net 1.1版,您将无法运行Asp.Net
2007-07-06 21:17:05
解决办法：
1.检查IIS是否可以用；
不行就得重装。
2.检查.NET是否可以用，就是运行***.aspx页面，看是否正常；
如果IIS可用，.NET不可以用，运行
cd C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
aspnet_regiis.exe -i
或者在.NET自带的工具下输入
aspnet_regiis -i 即可 -
QTP下脚本不能录制
2007-07-06 21:16:01
打开IE，在菜单中选择[工具]/[Internet选项]进入Internet配置界面。选择[程序]/[管理加载项]，查看目前加载的ActiveX的情况。
当看到存在BHOManager Class并且其状态是“禁用”时，点击“启用”开启这个功能，并保存后退出即可解决问题。
当在管理加载项里找不到BHOManger Class这个加载项时，如果你安装了QTP，那么在C:\WINDOWS\system32下会存在一个叫BHOManager.dll，或者可以直接在计算机里搜索BHOManager.dll，然后查看其路径。加载这个dll，加载，然后定位到dll所在目录，键入regsvr32 BHOManager.dll命令 -
我不想输
2007-05-28 15:26:36
我是个不服输的人，在我重视的几件事情中我还没输过，但是我这次彻底的输了，输的好彻底..
我不服，我会证实我自己的，世界等着吧~~~~~
时间永远可以证实一切，我会成长！
