日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | 31 | ||||||
搜索标题
![测试者家园[Fish_yy的家园]](http://www.51testing.com/user/40/photo_19940.gif)
音乐欣赏
统计信息
- 访问量: 3601
- 日志数: 100
- 图片数: 1
- 建立时间: 2008-11-02
- 更新时间: 2008-11-28
RSS订阅
我的最新日志
-
如何正确对待需求的变更
2008-11-28
软件项目，在开发/测试进行中，需求改变是很平常也很正常的事情；为了不影响开发和测试的进度及项目整体进度，那么我们如何正确对待它的变更呢？
1． 对于需求和需求变更的理解
软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。
软件需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而需求变更在软件开发项目中应该尽量避免。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。
2． 减少需求变更
正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求并更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。
相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。
让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。
虽然需求不可能是完备的，但是在项目开始设计时尽量使得需求完备还是应该的，也是值得的。
3． 规范文档
需求文档作为客户和开发人员的接口在整个项目开发过程中起着举足轻重的作用。需求文档应该按照一定的格式和规范书写，而且应该具备完整性、一致性、基线控制、历史记录等特性。文档书写完毕以后应该交给客户审阅，在客户满意的基础上确定基线。一个完整规范的需求文档不仅能够有助于设计人员和编码人员完成项目开发，更重要的是它作为一个阶段性的成果可以供软件需求变更时参考。
需求变更发生后，也应该生成相应的文档，并且这些文档的书写也应该采用规范的形式书写。需求变更文档也应该包含基线以供下一次修改参考，还应包含历史记录以供开发人员和客户清楚当前的文档内容的新旧以及历史文档的情况，以备以后查看。
4． 设计良好的体系结构
开发软件就如同建造一座房屋，软件体系结构则如同建房屋时的规划。两层高的家庭住宅和几十层高的商业大厦建造时的规划必然不同，同样，大型软件和小软件采用的体系结构也必然有所区别。因此，设计一个合理的体系结构对于项目的成败也是十分关键的。
体系结构的建立一般位于需求分析结束之后，软件设计之前。软件体系结构的设计是从结构的角度对整个系统进行分析，选择合适的构件，安排构件间的相互作用以及他们之间的约束，形成一个系统框架以满足用户需求。在设计软件体系结构时，不仅应该想到如何完成满足现在已经提出的用户需求，同时也应适当地考虑到需求的变更。
采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护代价，能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因而能够快速的对需求变更作出响应，并且对已经开发好的系统产生尽可能少的影响。
体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外，还应尽量采用松散耦合的结构，使得结构中的各个构件之间的关联程度尽可能的少，这样就能在需求发生变更时一个构件的变化对另一个构件产生尽可能少的影响。
现有的软件体系结构很多，包括管道－过滤器结构、B/S结构（含C/S结构）、解释器/虚拟机结构、黑板系统以及基于中间件技术的体系结构。在设计体系结构时，首先应该选出适合项目需求的系统结构，然后在从中挑选出那些扩展性比较好，构件之间耦合性比较小的体系结构。基于中间件技术的体系结构就是扩展性比较好的体系结构。采用中间件技术，中间件作为用户界面和操作系统以及网络的连接点，向上为用户提供服务，向下屏蔽操作系统和网络的细节。这种分层的思想能够很好的适应操作系统和网络的变化，可扩展性十分的好。同时，可以在中间件中给出容易改变的接口或是为系统将来改变预留接口来实现功能上的需求变更。当然可扩展性比较好的体系结构远不止基于中间件技术的体系结构这一种，具体的选择和运用应该由设计人员根据实际需要考虑。
5． 采用面向对象思想
需求是不稳定的，因而没有不变的需求，然而需求之中却有稳定的东西，这就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物、植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。
面向对象（OO）技术的三大特征保证了采用OO技术可以建立易于改变和加强可重用性的软件系统。封装可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单；继承可以使改变基于原有技术基础，很大程度上减少重复开发工作；多态的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为。
显然，OO技术是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。因此，在系统开发过程中应该尽量的采用面向对象的思维方式来构建系统和开发系统。
6． 需求变更控制
正如前文所言，需求变更不可避免的会发生，那么当需求变更发生后项目开发人员应该如何应对呢？
一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理也比较容易。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面，再与客户商讨是否有必要进行变更和如何在最小代价下实现变更。
当客户确实希望进行需求变更时，可以让开发人员开发一个快速原型，让用户体验一下，以确保客户确确实实的希望添加这些需求。在客户和项目开发人员共同确定了需求变更后，项目开发人员应该与客户签订一份新的合同。
当客户提出需求变更并且签订了合同后或是开发人员根据市场和国家政策作出的需求变更得到确证后，项目开发人员应该决定何时实施这些变更。对于那些对系统影响不大和一些优先权十分高的需求变更可以立即在项目中实施，而对于那些对于整个系统现阶段的开发影响很大，而且又不是十分紧急的需求可以放在下一个版本中进行。无论是立即实施还是放在下一个版本中，都应该给新的需求一个充足的开发和测试时间，保证产品质量。
结论
在面对需求变更时，除了通过减少需求变更和规范文档，从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们设计的意识和对需求变更的理解，做好对需求变更的控制和管理，做到对需求变更的灵活应对，在一定程度上降低维护代价和提高用户满意度。 -
QPS解释
2008-11-26
引擎压力测试中，我们常常会说QPS，那么什么是QPS呢？
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，用这个来衡量性能
-
【转】软件测试的创新之路
2008-11-19
软件测试在国内仍处于起步阶段，各种软件测试的方法、技术和标准都还在探索阶段。国内软件行业普遍规模偏小，缺乏大型软件产品经验，开发过程不够规范，这决定了国内软件质量和测试行业，必须根据国内行业现状，确定软件质量目标和测试策略方法，而不是照搬照抄国外成熟软件企业的测试方法。
1、观念创新
提高软件质量的决定因素不是软件测试技术，而是对软件质量和测试的思想观念。只有把提高软件质量上升到企业战略发展的高度，才能从根本上解决问题。长期以来，国内软件行业对软件质量重视程度不足，对于软件测试的作用认识不够，造成项目因质量问题造成进度推迟甚至失败。
为了彻底改变这种被动现象，企业高层管理人员必须从管理思想、资源支持等方面为软件质量和测试部门提供全力支持。软件项目经理必须坚持软件开发和软件测试并行处理并且互相协调。软件开发人员重视和配合软件测试人员。
观念创新不要仅停留在口头上，而要落实在具体行动上，通过软件质量和测试的有效流程进行推动，通过过程改进进行提高。通过有效组织管理，形成以重视软件质量为荣，以轻视软件质量为耻的工作氛围。
2、流程创新
测试流程决定软件质量。软件测试如同软件开发一样，需要经过收集测试需求、确定测试策略、设计测试、执行测试、分析测试等流程。软件测试不是软件开发的最后阶段，而是贯穿于软件项目的整个生命周期。决定软件测试成败的关键是软件测试需求是否完整、准确，测试策略是否有效和实用，测试设计是否覆盖了测试需求。
软件测试流程既不是僵化的生搬硬套，也不是随机的增添取舍。软件企业的质量管理部门和项目开发团队需要根据公司技术、资源现状，针对项目的特点和客户需求，从保证软件质量、项目进度和测试成本等方面，进行优化设计并且不断改进流程管理。对于项目周期长、应用领域广、对质量要求高的软件，必须制定和遵守严格的测试流程。
测试流程创新的目标是在公司内部制定和执行完善的项目质量管理体系。优化项目生产方式，跟踪和度量生产过程和产品，使得生产过程和各阶段产品处于可控制和可度量状态，保证产品符合客户的功能和进度需求。
3、技术创新
软件测试是一项软件工程领域的专业技术，而不是简单的把软件测试认为随便找个人运行几次软件，就可以发现全部的软件问题。前文已经提到，软件测试需求和测试设计是决定软件测试效果的关键因素，因此，加强测试技术创新的重点是在测试需求和设计设计的创新。
在软件测试技术创新方面，要避免陷入过渡追求自动化测试技术的误区。自动化测试确实可以在某些方面显著提高测试效率和准确性，但是自动化测试只适合测试软件的某些方面的质量（例如性能测试，回归测试等），80%左右的软件缺陷是靠测试人员手工测试发现的。
对于某些特别需要自动化测试的软件特性，需要加强开发软件测试工具，而不是全部依赖市场上的现有测试工具。这是因为商业工具功能繁多，价格昂贵，培训和学习周期很长，选择不当就会造成巨大浪费。
4、管理创新
软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强过程跟踪，从而顺利完成质量保证和测试任务。
测试管理创新的核心是软件质量和测试的团队建设，软件质量和测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。质量和测试团队建设的重点是设置和培养各类技术和管理人才，进行有效交流，形成良好的评估和促进机制。 -
回归测试的风险
2008-11-19
假设设置一个场景： “但是，它仅仅是一个很小很小的改动！我们怎么会预先想到它会造成这么大的问题？”
怎么会，确实！没有回归到的功能点可以造成很大的问题。
回归（向后追溯）是软件系统的现实生活。即使之前是很好地工作的，但是不能确保它会在最近的“很小”的改变后也能工作。是的，模块设计和充分的系统架构可以减少这种问题的出现，但是不能完全消除。
回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动，我们怎么进行充分的回归测试呢？我们怎么知道查找哪些方面？我们怎么减少出现问题的风险？
回归的问题
回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加，更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。
随着系统构建的时间越长回归的问题也会增多。在几年后，可能已经被更改了很多次，通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构，更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多，系统变得越复杂直到变得非常脆弱。
脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱，人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆（不可维护）是旧的软件系统被替换的主要原因之一。
即使现在我们用自动化来回归主干流程，但也不能回归到很小的点，只能检查出不会有大的问题，小的问题还是要我们去回归测试的
回归测试的困难
因为任何系统都需要回归，所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢？对一个只是1周多点的开发，我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了；更通常的情况是，只允许几天的时间。
既然完全的重测不可能，我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢？我们怎么预见这些不可预见的问题呢？（就像老板要求你把这些会出现的意外情况做个列表一样可笑！）
现实中，我们总是有测试压力，即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试，因此我们必须充分利用可用的时间，用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。
基于风险的测试
基于风险的测试的本质是我们评估系统不同部分蕴含的风险，并专注于我们的测试在那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试，甚至完全不测，但是它保证了这样做的风险是最低的。
“风险”对于测试与风险对于其他任何情况是一样的。为了评估风险，我们必须认识到它有两个截然不同的方面：可能性和影响。
-“可能性”是可能出错的机会。不考虑影响程度，仅仅考虑出现问题的机会有多大。
-“影响”是确实出错后造成的影响程度。不考虑可能性，仅仅考虑出现的问题的情况会有多糟糕。
使用这些风险信息，我们可能选择这样分配我们的测试：
- 50%的测试专注于新改的模块
- 30%的测试放在与新改模块相连的模块
- 15%的测试放在与新改模块相关的模块
- 5%的测试时间放在与新改模板不太相关的模块
使用基于风险的测试策略不能保证没有回归。但是会显著地减少对一个大系统进行的小更改的风险。现在我们就是采用自动化做全网回归测试来检查是否有重大问题，从运行的效果来看，成效应该说很不错的，几次发现了A类故障的问题，都是在非正式环境下扼杀掉，不然就可想而知了。。。
我们如何把回归测试做的很全面，很到位，其实就现在用自动化来跑的话还不是很智能，因为中间会有很多因素影响到自动化回归的功能和回归范围。这个问题还在思考中。
-
测试团队的建设(整理)
2008-11-19
有关测试团队的建设，这个话题很大。思考一下，查找一推，整理一把，让自己的工作更有序、更系统，做到有意识的去完成它，并收获工作中细微变化带来的快乐。1 、团队基础设施建设：让自己和其他人都强烈的感受到团队的存在、以及团队的力量，让团队中的每个人都从团队中受益
。我们是一个团队（ team ），并非一个组（ group ）： team 和 group 的最大区别在于“是否存在目标”，目标产生合力，让 1 ＋ 1>2 成为可能；首先确定自己的目标，成为我们建设测试团队的首要任务。我们为了生存，制定短期目标；我们为了发展，制定长期愿景。
－长期目标：
。长期目标让团队生存更长的时间，它能够打发我们的闲暇时间
。长期目标让团队的每个人都感受到希望
。一个设想：让我们成为业界认可的一支测试团队，一支受人尊敬的团队。（也许我们每个人都不是业界顶尖高手，也许我们需要改进的地方还有很多，但我们产生的力量足以漂亮的完成每个任务）
－短期目标：
。我们要独立，自己养活自己，尤其在队伍建设初期
。将眼前的任务完成，或者基于当前任务考虑短期目标
。在完成短期任务的同时，考虑长期目标，一个个短期目标的完成，最终实现长期的愿望，积累在这里显得十分重要
－－目标：是这支队伍存在的根本。
。个人的发展
－角色的划分，职责的确定
。分工的明确，让每个人都知道自己的工作范围，也为绩效考核提供依据
。角色的划分符合团队的长、短期目标，而且划分也需要随着目标的改变而改变
。减小角色划分后的盲区，消除个人的重复劳作
。有了“目标”和“工作内容”以后，每个人都可以发挥主观能动性，自己创造方法将事情做好
－个人发展路线
。确定角色之间的相互联系以及发展顺序
。提供每个角色对应的技能要求，并且给出获得该技能的方法参考
。考虑个人的特点和兴趣，如技术型人才、管理型人才等等
－绩效考核
。确定绩效考核的标准（得到大家的认可）
。确定绩效考核的时间间隔
。将绩效考核与薪酬挂钩
。让直接领导与薪酬支配者共同决定结果
。绩效考核的反馈，让每个人了解领导的意图
。绩效考核的目标：主要是为了其下一步发展，推行好的方面
。绩效考核的关键：公平
。淘汰：为那些停止进步的人准备的
。内部交流
－工具的使用（ RPM、wiki 、 blog 、Confulence、旺旺...）
。通过 web 的方式展示， wiki 方便更多人了解，让更多人参与
。 blog 记录并形成自己的知识库
－沟通模式化：一致的方法沟通，提高沟通的效率，减少沟通带来的误解
－让大家形成习惯
。定期的内部交流，有利于习惯的养成
－不要总是由领导发起
。组间接口（更大的团队中与其他 team 的合作）
－让其他人（包括领导）清楚的知道我们的职责
－和其他团队一起制定组间接口
－我们可以多做一点，帮助他们一起完成工作，但一定要让他们知道我们“在帮助他们”
－宣传我们的思想，赢得更多人的认可
－与领导协商，建立更广泛的沟通模式
。积累：让我们感受到自己的成长，让新人尽快的进入角色
－应用库的建设：我们在做什么，做过什么，让它留些痕迹；方便后来同类项目的完成
－问题库的建设：大量的问题出现，将其分门别类的记录下来，对这些问题的解决过程中，我们自己在进步
－知识库的建设：
。自己的随笔，团队的共同提高，处理某些问题的经验，犯过的错误
。关键要记录下这些知识的适用范围
－使用与维护：
。积累是为了使用，在建设的初期就要考虑到将来使用的方式、以及使用的方便
。一定要有人维护， 3 分建设、 7 分维护一点都不为过；尤其在大家养成习惯之前
。我们的文化，我们的风格
－我选择，我喜欢
。为了适用不同的环境，完成特定范围的任务，我们形成了自己的风格
。因为我们的不同，所以我们存在
。我喜欢轻松的氛围，喜欢能让我集中精力的地方
－让喜欢团队文化的人加盟：物以类聚、人以群分
2 、新人招募
。我们需要什么样的人？这取决于团队目标
。新人对我们的文化认可吗？
。能力与潜力是我们关注的
。沟通真的很重要
。也许也需要一个题库，让招聘规范一点
。告诉 hr ，我们需要什么样的人才
3 、新人培养：新人刚开始需要更多的关注
。培训：
－告诉他需要做什么，需要哪些技能，大家的工作方式，如何融入团队？
－技能让他自己去学，可以提供一些参考方法
－只是一个开始
。学徒与导师：相比培训，工作中的导师的指导更有意义
－让导师清楚指导的意义，认同这一点，并愿意做
－以学徒的成长速度为参考对导师进行考核
－学徒可以寻求其他人的帮助
。用人之长、理人之短
－帮助其认识自己，挖掘他自己的潜力
－帮助他找到自己的位置
－管理他的缺点，不要影响他人；适当的时候，提醒他注意一下
－扬善于厅堂，归过于私下：宣传的东西，大家都是学习的——所以一定要学好的
4 、改进——让我们做的更好
。改进的方向？来自于我们的目标
。每年一个主题
。推行团队学习、主题学习
总结一下，建设一支测试团队，考虑如下步骤：
。设定团队的目标
。考虑团队中的角色与职责划分
。确定队员职崖规划和绩效考核标准
。招募合适的人
。搭建组内沟通的平台，确定组件沟通的渠道
。建设各种知识库，并在工作中不断总结、不断积累，丰富库的内容
。日常管理，尤其注意新人
。形成自己的文化
。改进——永恒的话题
-
测试团队的核心目标是什么？
2008-11-19
最近在想一直在想一个问题，我们测试团队的核心目标是什么呢？
作为一名测试人员一定要清晰，我们的使命和目标，只有明确方向才能有效的发挥出测试人员的价值，不仅考虑眼前，而且谋划长远目标，向着预定目标前进，从而焕发出不屈服于任何困难和障碍的勇往直前的力量。。。
-
浅谈并发测试
2008-11-19
这样说的并发测试不是性能测试中的并发量来测试，这里只是对某些功能进行并发测试，从业web页面测试的人对这个功能并发测试肯定不陌生了。
（1）一般情况下，一个页面的功能，比如新增、修改和删除等操作，做并发测试很简单，只要我们同时用一个帐号登录，打开2个IE，一边操作完成，一边在原来的状态再去操作，检查点就是坚持页面是否异常，数据库是否异常。我们可以把这样的简单的并发测试叫同步操作并发测试
（2）一些特殊的审批流程中的操作并发检查，就不是一般的功能同步检查了，因为一个流程审批往往会有很多环节，那么我们如何去检查呢？
其实方法是一样的，只不过我们要准备大量的数据去检查页面和数据库是否系会异常，如数据库状态为0和3的状态是可以关闭的，那么我们要准备0和3两种状态下与1、2、4、5（假设有5种状态）之间的操作异步并发检查，也是开2个IE，只不过另一个IE操作与前一个页面状态不一致，我们可以把这样的并发测试叫为异步操作并发测试
并发测试在黑盒子测试是很重要的，如果不进行测试验证往往会给用户留下功能操作的漏洞
-
每秒连接数图的解释
2008-11-16
每秒连接数图是每秒打开新的Tcp/ip连接数。
该新连接数应该只占每秒点击次数的一小部分，因为就服务器、路由器和网络资源消耗而言，新的 TCP/IP 连接非常昂贵。在理想情况下，很多Http 请求都应该使用同一连接，而不是每个请求都打开新连接。
-
度量趋势Y轴的计算公式
2008-11-16
新Y值=（以前的Y值-以前值的平均值）/以前值的STD 可以归一化除网页细分图的所有折线图。
其它方式可能也能可到这个值。
-
关于Page Fault的一些整理
2008-11-16
Pages Input/sec 是为了解决硬错误页，从硬盘上读取的页数，而Page Reads/sec 是为了解决硬错误，从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。
Page Faults/sec 是指处理器中“页面错误”的数量。当一个进程引用不在主存储器“工作集”中的虚拟内存页时，就会发生页面错误。如果该页面在 Standby 列表上，因而已在主存储器中，或者如果另一个与其共享该页面的进程正在使用该页，那么发生“页面错误”时，不会从磁盘读取该页面。
Pages Input/sec 是指内存引用时页面不在内存，为解决这种情况而从磁盘读取的页面数量。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。如果您担心过量的内存压力（即，系统颠簸）以及可能造成的过量调页，那么这是个需要查看的重要计数器。
Pages Output/sec 是指因主存储器中的页面已修改而写入磁盘的页面数量。
Pages/sec 是指引用不在内存中的页面时，为解决这一问题，从磁盘读取或写入到磁盘的页面数量。它是 Pages Input/sec 与 Pages Output/sec 之和。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。该值还包括取自或保存到非高速缓存的映射内存文件的那些页面。如果您担心过量的内存压力（即，系统颠簸），以及可能造成的过量调页，那么，这是个需要查看的主要计数器。在 WTS 测试中观察到的结果表明，内存瓶颈对系统性能的影响比 CPU 瓶颈的影响严重得多。出现 CPU 瓶颈时，仍会处理所有的客户请求，但处理速度变慢。受 CPU 限制的机器上的所有客户均可以继续操作，只是在处理过程中，会有持续几秒的定期暂停。 在受内存限制的 WTS 中，测试已表明，只要可用的物理系统 RAM 已达到某个水平，系统就会开始从转换文件读取页面和写入页面。在物理系统 RAM 的数量达到临界水平后，WTS 就会充斥大量转换文件的调页信息。由于影响很大，所以应密切观察内存的使用情况。
最重要的两个性能计数器是 Available Bytes 和 Page Inputs/sec。如果观察到 Page Outputs/Sec 和 Page Inputs/Sec 有上升的趋势，则系统中可能存在内存瓶颈。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec 计数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。Page Faults/sec 是处理器每秒钟处理的错误页（包括软错误和硬错误）。
