-
遗传算法在黑盒测试中的应用
2008-11-04 21:24:56
摘 要：提出了一种利用遗传算法帮助测试人员在较短时间内完成软件模块的黑盒测试，并给出测试结果
和好的测试用例的方法。
关键词： 遗传算法 测试用例 耦合度在软件测试中，黑盒测试主要是针对模块进行的功能测试。最
普遍的方法是以软件的功能说明书为基础将软件的输入划分为若干个等价类，多次运行该软件来检验软
件对于不同的等价类是否能满足要求。但是在实际应用中，有的模块太大或输入参数太多，等价类划分
后需要进行的测试工作可能是一个极大的任务。这时，如何选择最优的测试用例就成为测试人员的一个
重要任务。
遗传算法是模仿生物遗传和进化机制的一种最优化方法，它把类似于遗传基因的一些行为，如交叉
重组、变异、选择和淘汰等引入到算法求解的改进过程中。遗传算法的特点之一是，它同时保留着若干
局部最优解，通过交叉重组或者解的变异来寻求更好的解。与贪婪算法相比，遗传算法更可能找到全局
最优解，而贪婪算法则容易限于局部最优而达不到全局最优。
如果能够将遗传算法有效地运用于黑盒测试中，帮助测试人员选择最优的测试用例，那么将给测试
工作带来极大的帮助。
１ 应用方法在设计具体的算法之前，我们先介绍遗传算法的基本算法，其算法框架如下１：
第一步，初始化：选取ｐ个候选解作为初始解，把其中最好的解作为暂定（最优）解。
第二步，解的改进：若满足终止条件，输出暂定解，算法终止。否则，进行以下的运算：
（１）解的交叉重组：从ｐ个解中选出两个或两个以上的解进行交叉重组，得到新解，重复该运算
若干次。
（２）解的变异：在候选解中随机加进一些变异，产生新解。
（３）局部搜索：对新产生的解用局部搜索法进行改良。若能得到比候选解更好的解，更新候选解
。
（４）从全部解中按一定的准则选出ｐ个解作为下一代的候选解，更新暂定解。
转第二步。
了解了遗传算法的算法框架后，进一步要做的就是在软件的黑盒测试中，如何将不同的等价类转变
为遗传算法的候选解， 如何设定解的优劣标准，如何设置合适的终止条件。
我们假定一个软件模块的输入参数有５个：Ａ、Ｂ、Ｃ、Ｄ、Ｅ，经过合理的等价类划分后，每个
参数又有５个不同的等价类：Ａ１～Ａ５，……，Ｅ１～Ｅ５。我们采用一个广义的遗传算法候选解概
念，一般的遗传算法往往将候选解形式定为二进制的数据串，比如：１１１０１０、０１０００１等等
，而在不同等价类输入作为候选解时我们将候选解形式定为（按照上面假定为基础）：Ａ３Ｂ１Ｃ２Ｄ
４Ｅ５、Ａ２Ｂ２Ｃ４Ｄ１Ｅ３等等。这样我们解决了候选解的问题，在解的优劣标准以及终止条件的
设定问题上，我们需要借助工具作为标准。
软件测试的目的是提高软件的可靠性，终止条件当然是软件达到了测试的目的及要求。而解的优劣
标准正好与软件质量相反，即软件失效几率越大，这个测试用例（一个输入的解）越优。文献２中
结合北大的青鸟黑盒测试环境提出了一种基于测试执行的失效数据模型ＪＢＦＤＭ（Ｊａｄｅ Ｂｉｒｄ
ｆａｉｌｕｒｅ ｄａｔａ ｍｏｄｅｌ）。利用该模型我们可以做到２：
（１）提供一致的失效数据建模、收集及管理的可靠性度量过程，从而支持可靠性度量；
（２）利用测试及软件现场收集的数据来评价测试计划、操作概图及测试方法的有效性。
软件测试的目的是发现错误，在黑盒测试中，错误表现的形式是软件失效。但是由于软件错误并不是软
件失效的充分条件，换句话说，并不是所有错误都会在测试或运行时暴露，所以黑盒测试的目的就是尽
可能的通过运行测试用例使软件失效而发现错误。在我们对测试用例的评价时，用以下的数据表示测试
用例的优劣：Ａ＝Ｐ＋λ／Ｍ＋μ×Ｆ。
其中Ａ表示遗传算法中的适应度Ａｄａｐｔａｔｉｏｎ，Ｐ表示该测试用例在实际中发生的几率Ｐ
ｒｏｂａｂｉｌｉｔｙ，Ｍ表示平均失效时间（ＭＴＴＦ），Ｆ表示失效等级。因为测试是针对使用的
，所以发生几率高的测试用例适应度高就不难理解了；而Ｍ——平均失效时间越长，该测试用例应该不
容易发现软件的错误，所以Ａ越低；Ｆ则表示某些特殊情况发生使软件严重失效（比如造成死机、损坏
仪器等等），中国IT室验实此时该测试用例以及其后代
必须被重点关注，所以此时Ａ越大。λ、μ是相应于各个具体的被测试软件模块而定的系数。在实际应
用中，由于软件失效的可能性不是特别大，所以遗传结果往往是发生几率高的测试用例后代较多。所以
我们应该针对具体被测试软件设计准确的发生概率产生算法。具体算法框架如图１所示。
对于该算法的说明如下：
*１。每一个输入参数往往有一个几率（可以事先定义），可以简单相加来求得该测试用例的概率。
但是在输入参数有较强相关性时，此方法并不能准确求得某个测试用例的发生概率，一个解决办法是设
置输入参数的相关耦合度。在遗传算法的交叉、变异时其同时进行的几率与相关耦合度成正比，即对于
相关耦合度高的输入参数，它们同时进行交叉、变异的几率高，反之则低。
*２。检验是否满足测试要求时，需要先设置一个计数器。每运行一个新的测试用例，测试计数器加
一。当发现第一次失效或故障时，计数器加二。若产生的遗传后代又使软件发生失效，则计数器加２２
。同理递推，当遗传算法产生的测试用例连续ｎ次使软件失效，则计数器加２ｎ。同时，记录所有的测
试情况（此工作由外围的测试环境完成，比如北大的青鸟黑盒测试环境）。如果出现严重错误则终止测
试，进行对程序的检查。如果连续ｋ代测试用例的遗传后代都运行良好，计数器的值加２ｋ。ｋ的值由
具体被测试软件的等价类数量、输入参数个数等决定。当测试计数器的值达到所有黑盒测试用例等价类
的数值时（对于我们上面所举的例子，该值为５５＝３１２５），结束测试。当生成的孙子代、子代与
父母代三代完全相同时，算法也必须结束，因为此时测试不会有新的结果。所以我们还要设置一个结束
条件。而且该条件强于计数器条件。
*３。每一组测试用例可以生成多个测试用例，根据适应度函数大小决定留下哪些测试用例组成新的
测试用例组。
从上面的算法框图和说明可以看出，如果某测试用例使软件的运行发生了问题（即某个软件错误发
作），它的后代也同样受困于该软件错误，算法很快能发现这些最佳测试用例并给出结果。测试人员就
可以将它们交给开发人员解决这些问题。若软件本身确实质量优良，这些测试用例及其不同的后代无法
发现失效，算法也能尽快结束，而不是完成所有测试用例（虽然从理论上，我们希望测试尽可能运行所
有测试用例）。
２ 效果
上节的算法，相对于运行所有测试用例，并没有比较明显的优点。尤其对于测试来说，算法并没有
加速运行测试用例，好象还降低了运行速度。其实算法本身的确不是用来加速运行测试用例的，其目的
是找到一组最佳测试用例。因为实际上对于很多模块运行所有测试用例或哪怕是所有等价类都是几乎不
可能的。
以上一节举的例子做说明，其输入等价类大致有５５＝３１２５。如果一个模块有１０个输入、每
个输入有１０种等价类，那么输入等价类为１０１０。按运行一个等价类需要１分钟计算（很多循环运
行模块可能不止１分钟），需要几个月才能运行一遍所有等价类。这时，运用遗传算法的优势就体现出
来了。
综上所述，本文提出了一种利用遗传算法寻求最佳测试用例的测试方法原理。它能在较短时间内完
成软件模块的黑盒测试并给出测试结果和好的测试用例。利用该算法原理，可以在测试集成环境中做一
些设置或修改测试集成环境，这样可以大大提高测试工作的效率。 -
敏捷测试中的系统测试模型
2008-11-04 21:12:11
系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说 ， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。
在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。
本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功 导致 （led） 了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。
在六个迭代中，系统测试核心团队与开发团队并行工作。这能够让传统的系统测试应用程序的子集的开发和执行在每个迭代的过程中执行。该并行导致了此处描述的各个方面的成功。
敏捷的过程实现模型
在开发的一年之后，使用现有的瀑布实践并交付开放的 alpha 和 beta，我们的项目转换了工具，并实现敏捷的开发模型。整个团队需要将敏捷的开发原则作为“现场实验”，从而满足特定客户的需求。第一个迭代是过渡的，通常着重于交付在瀑布开发模型下开发了几个月的代码。当第一个迭代开始时，整个团队包括大约五十五个人，包括设计人员、开发人员、测试人员、信息开发人员和客户交付团队。
迭代 1 用作过渡的迭代，用于完成已经处于开发中的可交付件。敏捷开发过渡适当地启动，并且带有对前一或两个迭代的适度的开发承诺。主要的焦点在于在团队和集成的过程之间构建并交流新的项目和人与人之间的文化，例如，并行的早期系统测试，这将会用于在新的环境中令团队成功。
九个系统测试人员（整个系统测试团队的子集）在先前的瀑布开发周期中兼职参与。在开发代码的过程中，他们关注构建技术技能、计划、测试案例开发，和应用程序单元测试。这样做，他们练就了项目所用的技术中的技能，但没有获得内行的经验。
当转变为敏捷开发时，九个系统测试人员中的五个全职参与项目。因此，在第一个迭代之前，系统测试团队已经了解了新技术，创建了测试应用程序，并且像团队一样一起工作。这些早期的测试及开发活动令敏捷周期的开始有更高的生产率。
系统测试团队参与的目的
五个系统测试人员面临的挑战是确保代码质量足以达到在任一已知的迭代中开发的功能的 beta 级交付。为了迎接这个挑战，他们决定在每个迭代中运行传统的系统测试应用程序开发和执行的子集，预期最终的迭代进行一组更复杂的具体客户的，基于场景的测试。系统测试团队与项目的高级架构师会面，并一起为了增强和执行选择一个现有的系统测试应用程序。然后，该应用程序将用于在迭代过程中的压力和寿命期运行，并且在最终的迭代里大量地使用。目的是在项目最终在世界范围内交付时，系统测试人员有限且同时的参与会为最终的完全的系统测试迭代建立起坚固的基础。
项目和迭代的时间线
迭代有六个星期之久。表 1 显示了一般的迭代规划，以及为每个星期计划的具体的系统测试活动。在迭代的第 1 周中，高级架构师提出建议的候选功能列表。该列表主要基于具体客户的需求，并且通过用例进行描述。该列表可在线访问，以便在迭代进行中，所有的团队成员都可以改进用例。每个团队成员都会审查候选的列表，并与团队成员和高级架构师一起讨论设计及问题，并且在周末提交在迭代结束时（是否）要交付的功能。每天举行一个小会。高级架构师每天都出席大部分小会议，并且在所有迭代过程中都与全部团队成员在一起。
如前面所提到的，最后的迭代计划着重于在开发迭代中不能实现的最终的缺陷清理和复杂的测试。为了提高稳定性，最后的迭代没有新的功能。六个迭代完成了。同时，在最后的迭代中，大量的开发人员需要加入系统测试团队成员中，通过提供对测试执行和调试的辅助来完成最终的迭代。其余的开发人员会处理缺陷。这意味着在较早的迭代中的开发阶段里，一些开发人员需要为了最后的迭代而培训系统测试的知识。
表 1：每个迭代的活动：开发和系统测试
周 开发 系统测试活动 1 开始
设计
团队承诺决定并提出迭代承诺，包括：根据在迭代中交付的新功能，定义压力测试的测试应用程序的提高及选择。 2 开发/测试 与高级架构师一起审查测试应用程序设计的增强。
开始应用程序增强的开发和单元测试。
利用可用的驱动程序开始回归测试。3-4 开发/测试
审查开发/测试结果继续应用程序增强的开发和单元测试，及回归测试。
创建测试场景并准备必要配置的机器。开发/提高自动化脚本。5 高优先级的缺陷，没有新的功能 压力运行新的功能。在连续的迭代中增加压力/负载。
对新的功能驱动程序进行回归。
打开缺陷，带补丁执行，提供追踪，并检验缺陷。培训开发人员加入 SVT 的工作。
用额外的细节改进测试场景，并追踪进展。6 审查系统测试结果
打包
演示
了解的经验
交付继续与第 5 周同样的活动。
参与演示的计划、准备及执行。
提出系统测试结果。
为所了解的经验提供输入。每天 功能测试的回归 对当前的驱动程序进行回归。 -
避免“测试逃逸”现象的措施
2008-11-04 21:01:37
“测试逃逸”是指测试人员在软件的测试过程中由于惰性或工作不认真，为图省事而设计测试用例不全面，故意少设计用例，或者没有按照测试要求执行测试，导致一些显而易见的软件缺陷或本来应该发现的软件缺陷没有被测试出来。由此可能造成质量不合格的软件版本被发布，使公司的形象或利益受到损害。
为了避免在测试工作中出现“测试逃逸”现象，制定了以下措施：
(1) 加强评审
将严格执行测试管理程序中规定的两个评审：测试用例设计评审和测试结果评审。尤其是测试用例设计评审，要严把测试用例质量关。
(2) 确定专门的SQA(质量保证)人员
规定本部门专门的SQA人员,并赋予以下权力和职责：
负责复查测试人员的《测试用例设计与执行报告》及《软件问题清单》；
负责监控每位测试人员按照规定的流程和规范执行测试；
有权责成每位测试人员纠正其不符合流程和规范的过程。
将每次的复查结果在工作会上进行通报。
(3) 加强测试部经理对测试过程和测试结果的监控做为测试部经理，将加强对测试过程的监控，及时发现不正常的作业过程，并给予警告，令其及时纠正。同时，将亲自进行抽样测试，将测试结果与测试人员的结果进行对比，以考核测试人员的工作结果。
(4) 建立通报与惩罚制度
每次SQA的复查结果，如果发现有“测试逃逸”现象，将由部门经理在每周一的工作例会上进行通报批评与警告。
将来公司的绩效考核制度在测试部实施后，将把质保人员和部门经理的检查结果记入绩效考核，与其工资收入挂钩。
如果多次批评和警告无效，则上报公司建议进行处罚、转岗直至辞退。
(5) 调动员工工作的积极性
通过以下手段调动员工工作积极性：
具体任务责任到人，把软件细化成功能块，分配给每一个测试人员，要求每个测试对自己测试部分的测试质量负责；
将来公司的绩效考核制度在测试部实施后，通过将测试质量与绩效考核相关联，提高工作的积极性。
-
几个常见软件测试面试题
2008-11-04 20:58:42
问题集
1.软件测试分哪两种方法？分别适合什么情况？
2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法5.在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6.在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程8.如果您是测试组长，您会采取什么样的方式管理团队？在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
问题解答：
1.软件测试分哪两种方法？分别适合什么情况？
软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：1）。测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
3）测试开发建立可重复使用的自动测试过程。
4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
3.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等
4. 测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程1、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
1） 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 2） 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
2）项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
3） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
4）开发者收到Email信息后，判断是否为自己的修改范围。
5） 若不是，重新reassigned分配给项目组长或应该分配的开发者。
6）测试人员查询开发者已修改的bug，进行重新测试。 -
软件测试中使用QTP的一些方法(收藏)
2008-11-04 20:54:37
1.增强QTP调试器功能的方法QTP的脚本编辑器中默认的调试器的功能十分有限，在调试过程中很多对象的属性都不能详细地看到。
但是如果安装了Visual Studio.NET 2008，则可以增强QTP的调试能力，在“DebugViewer”中可以查看到对象的大部分属性。
可以通过安装Visual Studio.NET 2008来增强QTP调试能力，也可以不安装，仅仅把其中一个名为PDM.DLL的文件拷贝到“C:Program FilesCommon FilesMicrosoft SharedVS7DEBUG”目录中，然后注册一下即可，注册方法是在命令行中输入“RegSVR32 “C:Program FilesCommon FilesMicrosoft SharedVS7DEBUGpdm.dll"”。
2.QTP测试脚本批处理运行的两个工具
在运行多个QTP脚本时，可以选择两个工具来完成，1个是QTP自带的Test Batch Runner，另外一个是MercuryMulti-Test Manager。
（1）两个工具都能运行Test Batch文件。
（2）Mercury Multi-Test Manager使用起来会更加灵活，能以HTML格式显示测试执行的状态信息和报告。
（3）Mercury Multi-Test Manager的运行方式更加灵活，通过在网络计算机上运行脚本，还可以模拟压力测试。
（4）让脚本执行任务更简单地创建和维护，并且可以发送邮件，告诉项目组测试脚本的运行状态。
（5）Mercury Multi-Test Manager支持COM访问和调用。
3.QTP操作注册表
在QTP中没有提供用于直接操作注册表的测试对象，但是利用Windows脚本的Shell对象，可以对注册表进行增删改等操作，例如下面的脚本：
Dim WshShell, bKey
' 创建Shell对象
Set WshShell = CreateObject("Wscrīpt.Shell")
' 使用Shell对象来读取注册表
bKey = WshShell.RegRead("HKEY_LOCAL_MACHINESOFTWAREMozillaMozilla Firefox 1.5ExtensionsPlugins")
Msgbox bKey
' 修改注册表
WshShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREMozillaMozilla Firefox 1.5ExtensionsPlugins", "D:Program FilesMozilla FirefoxPlugins", "REG_SZ"
' 删除注册表
WshShell.RegDelete "HKEY_LOCAL_MACHINESOFTWAREMozillaMozilla Firefox 1.5ExtensionsPlugins"
' 修改或写入注册表
WshShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREMozillaMozilla Firefox 1.5ExtensionsPlugins", "C:Program FilesMozilla FirefoxPlugins", "REG_SZ"
-
【整理】单元测试假成功和假失败的避免方法
2008-11-04 20:52:25
1 基本信息摘要：描述了单元测试要避免的几个问题，并给出几个最佳实践建议。
2 假成功的单元测试
<1>问题描述：
在testXXX方法中，看到有这样的测试代码：3. 解决方法：
public void testInvoke(){
try{
…
assertEquals(a,b);
}
catch(Exception e){
…
}
}<2>问题分析：如果运行过程中没有出现异常，整个流程不会有任何问题，JUnit也认为整个测试正常通过。
但是一旦try中的某段代码运行出错，我们会发现由于在assertEquals被调用之前就已经跳到catch中，所以assertEquals并没有被执行，而catch及之后的代码中并没有相应的assertEquals语句，因此JUnit认为这个testXXX方法对应的测试用例正常通过，我们被结果欺骗了。
将assertEquals语句移道try…catch之外，变成如下的代码样式：
public void testInvoke(){
Object a;
Object b;
try{
…
// assertEquals(a,b);
}
catch(Exception e){
…
}
assertEquals(a,b);
}3 假失败的单元测试
有的时候被测试方法在申明的时候有throws语句,那么单元测试代码应该小心处理这个问题.
如果测试方法直接throws被测试方法所扔出的异常,则在被测试方法扔出这个异常的时候,该单元测试被认为是失败;但是作为被测试方法来讲,扔出该异常可能是正常的处理逻辑,而不能被认定是代码有错误. 称这种情况为"假失败"的单元测试.
4 最佳实践
单元测试最好不要有try/catch这些内容，这些内容应该是正式代码中处理的。
单元测试只要在故意测试异常时才应该用到try/catch,如需要在某个环境下是否抛出某个异常；而其它情况try/catch应该避免使用。
-
Agitar 工具
2008-11-04 20:47:34
传说大名鼎鼎的AgitarOne就不用解释了，在昨天的随笔中有一些解释，今天主要说说Agitar 中Mockingbird的使用。为了提高测试代码的Coverage，仅仅靠AgitarOne来处理2K多行的方法，是肯本不够的。我现在搞的那个方法覆盖率才20%，不过比同事的 10%好多了。不过都是测试异常的Test Case，一个正向的Test Case的没有。只能硬着头皮看人家生成的代码来提高代码Coverage，在AgitarOne生成代码中，大量使用了MockingBird来 Mock对像，对于Mock对象我想大家都应该很清楚了吧。下面我将概要的介绍以下AgitarOne的MockingBird对象。
MockingBird 最主要的也就是以下5个API：
1.MockingBird.getProxyObject(), 该方法是创建一个Mock实例，比如我们想创建一个XXXHome 的mock 代码如下：
XXXHome xxxHome =(XXXHome)MockingBird.getProxyObject(XXXHome.class)
2.Mockingbird.setReturnValue() 该方法指定一个方法返回特定的值。比如我们想调用getConnection 返回一个Mock 真是的Xmock对象， 代码如下：
Mockingbird.getReturnValue(getConnection(),Xmock)
;
3.MockingBird.enterRecondingMode() 该方法就是使MockingBird进入录制模式。现在不好说清楚， 下面会有代码解释。4.MockingBird.enterTestMode() 该方法就是使MockingBird就如测试模式。
5.MockingBird.setException 该方法使一个方法抛出异常。比如我们想如果调用getConnection 抛出SQLException,代码如下：
MockingBird.setException（getConnection,new SQLException("sql exception!")）
下边将表述如何使用。
假如要测试以下方法，在这个方法中使用了第三方的代码，比如是EJB或者是数据库连接，那么我们在测试这个方法时难道好一定要有EJB容器或者真是的数据库吗？
使用了MockingBird 就OK了！
private int getValue()
{
thirdPart x = Global.getThirdPart();
Connection connecton = x.getConnection();
return connection.getValue("test");
}
对于Global.getThirdPart() 我们可以Mock一个thirdPart 而不是实际的对象，同理 Connection也是。首先我们创建两个Mock对象。
thirdPart x =MockingBird.getProxyObject(thirdPart.class);
Connection connection =MockingBird.getProxyObject(Connection .class);
// 进入录制模式
MockingBird.enterRecondingMode()；
//Mock Global.getThirdPart(); 方法
Mockingbird.setReturnValue(Global.getThirdPart()，x);
//Mock x.getConnection(); 方法
Mockingbird.setReturnValue(x.getConnection()，connection );
//Mock connection.getValue(); 使之返回为4
Mockingbird.setReturnValue(，connection.getValue("test") ,4);
进入测试模式
MockingBird.enterTestMode()
必须先进行录制状态进行录制，然后才能就是测试状态使用之前设置的录制值。
然后对于这个方法的测试将很简单 只要调用给方法 看是不是返回4就可以了，完全与环境无关。
-
制定合理的软件测试流程【整理】
2008-11-04 20:41:15
首先向大家介绍一下我理解的测试流程是什么，流程在词典上的解释是“工艺程序，从原料到制成品的各项工序安排的程序”，那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以我认为测试流程并不是只存在于有完整测试团队的公司，它分布在每一个对软件执行测试的公司中，哪怕这个公司只有一个测试人员。
软件测试想要在一个公司中从无到有进而逐步完善，也需要公司上层领导、开发人员等人从接受到理解、支持到尊重的一个过程。要想完成这个目标并不容易，需要公司外部整个软件测试行业和公司内部软件测试工作的双重影响。而整个软件测试行业实际上又是由各个公司内部的软件测试团体组成的，归根结底要让大家都接受软件测试还是要靠每个公司内部软件测试工作的影响。只有合适的测试流程才能快速的显示出测试工作的作用，才能让大家更快的接受测试工作，主动配合测试工作，进而完善测试工作，达到良性循环的作用。
制定合理的测试流程需要考虑的因素很多，毕竟它是大家进行测试工作的依据，又需要理清和需求人员、开发人员、市场人员等多方人员的关系，而且公司不同侧重点又有所不同，所以在这里不可能面面俱到列出所有因素，只是根据自己的经验列出认为比较重要的几点。
制定测试流程首先要清楚自己所在的公司正处在什么发展阶段，是处在最初的创业期还是已经度过了创业期希望通过测试来提高产品质量，以便取得更多的业务创造更大的效益。可能有的同行会觉得奇怪，我们软件测试是做技术的只管做好本职工作，为什么制定流程时要这么重视公司的发展情况呢。其实公司的情况和制定测试流程有非常大的联系，公司的情况直接决定着公司对产品的要求，而测试部门一般来说是产品投入市场的最后一个关口，这也就等于公司的发展情况决定了公司对测试部门的要求。开发软件前要先了解软件的需求，制定测试流程前当然也要了解清楚公司对测试部门的需求。了解了公司的情况和要求后，就要根据这些要求结合制定者的测试知识和经验，制定即符合公司要求又能起到软件测试目的的软件测试流程。当然这样做并不是说让软件测试向公司的一些不利于开展软件测试工作的现实情况妥协，只是根据公司的实际情况制定一些可以马上改变公司测试工作现状的流程。
一般正在创业期的公司面临的是公司生存的问题，它需要和其他公司抢市场，这时公司为了配合市场的要求不光要求软件产品的质量更要求整个项目的进度，但是对一些在软件测试过程需要的文档和产生的文档却不是特别在意。而且这样的公司开发人员往往都是测试人员8倍10倍，经常是软件代码已经快写完了，测试人员才会进入项目。这样我们在制定测试流程时就要注意软件测试工作的重点是执行测试，虽然前期的一些测试准备对以后的执行测试工作有很大的指导性作用，但前期准备工作如测试用例的写作等也会增加软件测试的时间，尤其是软件测试人员在软件已经开发出来才进入项目的时候，如果还要花大量时间去准备软件测试，更会让不了解软件测试的人误认为是软件测试拖延了整个项目的进度，让软件测试的推广工作受到更多的阻碍。这样我们就可以适当删减一些前期的准备工作，如减去用例评审工作，减少一些测试文档的写作工作，对一些测试文档的写作要求适当放宽等，更具体的就是我们可以不要求测试用例将操作步骤描述的很详细，但是要记录测试的思路可以简化为测试方案，达到对测试工作的跟踪目的就可以。但测试用例最好不要省略因为这个文档可以为以后再测试类似功能的产品做好经验的积累。
如果公司已经度过最初的生存期，这时公司会对产品的质量有更高的要求并且体现到对软件开发过程的要求。而且公司从软件开发计划制定、进度跟踪、项目管理等都有了一定的经验也有了一些历史数据可以参考。这样对软件测试的一些前期准备工作也会有所考虑，并适当满足，这时软件测试流程可以加强前期测试准备工作、后期测试分析工作。具体可以要求软件测试从需求介入以便尽早了解产品，制定独立的软件测试计划并将软件测试时间纳入整个项目进度中，细化测试用例写作的力度，增加后期对缺陷分析的工作进而逐步提高整个软件测试团队的技术力量，让软件测试渗透到整个软件过程中。
其实公司内软件测试一片空白或者测试流程比较完善的公司流程制定和执行相对来说都会比较容易一些，如果是一片空白你可以完全按照自己的想法去建立软件测试流程，剩下的困难只是如何去说服领导和开发配合这个流程。如果软件测试流程已经比较完善，大家对软件测试已经有了一定的支持和理解并且现阶段运行良好，你只需要在一些小节上进行一些修改，如果的确有利于工作会得到大多数人的支持。最难制定的是软件测试刚刚起步有了一些不成型的测试流程，也许不太符合你的想法也许不太适合公司的实际情况但的确在公司运行了一段时间，如果想改变不光要说服测试部门以外的人还要说服测试工作人员，增加了工作的难度，如果公司是这种情况请大家在制定软件测试流程前更要慎重考虑，详细了解公司的情况。
制定软件测试流程时可以参照一些比较完善的软件测试流程，但切忌不可照搬这些流程。我们经常会遇到这样的情况，如果在测试工作过程中碰到一些问题有人会说如果在微软或IBM公司是这样处理的，我们也可以这样。但是我们的工作环境和这些公司是不一样的，测试的思想已经深入贯穿到他们开发的每一个步骤中，而我们目前大多数公司的软件开发过程并没有达到这样的程度，我们大多需要解决的是在测试思想还没有贯彻彻底的公司我们怎么处理这个问题。无论是软件测试刚刚起步还是已经有了一定软件测试团队规模有多年软件测试经验的公司，都有一些属于自己公司特定的测试方法和流程，就是完善的软件测试流程也各有各的不同，IBM和微软在测试流程肯定是有所差别的。如果将他们的流程照搬过来，没有给公司同事一个慢慢接受消化的过程，很容易适得其反甚至引起公司同事的抵触情绪。这里并不是说这些测试流程不好，只是这些测试流程也不是一开始就建立起来的，而是通过多年的经验和教训逐步完善一步一步慢慢建立的，并且现在它们仍在进一步完善中。我们不仅要学习这些完善的软件测试流程是什么样的，我们更要学习为什么制定这套软件测试流程。给人金子不如给人点金术，也就是这个道理。那些软件测试流程比较完善的公司走在了我们的前面，我们就要学习他们这一路走来的经验和教训，避免走他们走过的弯路，缩短完善公司流程的时间。
制定软件测试流程要明确测试部门的职责。经常会有测试人员抱怨自己在公司里就是一个打杂的，什么工作都要做，其实这就是职责不明确引起的问题，这样会很大程度打击测试人员的工作积极性影响工作情况进而影响大家对软件测试工作的看法。一些如写用户手册、给用户培训等工作在公司里如果没有专门的部门来做，就很容易推给软件测试人员来做，但是都没有明文规定而且在对软件测试人员进行工作考核时又很容易疏忽这些工作，而且这些工作有时候看起来不太起眼，但是需要耗费大量的时间。所以我们要明确制定软件测试部门的职责、软件测试人员担任的工作内容，其他一些工作如果由测试人员来做，就要在制定软件测试计划中明确写出这些工作需要的时间，以防止这些工作占用测试时间，使测试人员陷于被动之中。
制定软件测试流程不光要制定软件测试部门内部的工作流程，更要制定与开发部门、需求部门等外部部门的接口工作的流程，一旦项目在进度、功能上有了变化要及时和测试部门沟通，不要让测试部门成为最后一个知情人。另外在具体执行测试流程时要注意执行的效果，将测试工作落实到实处，而不是为了走过场证明测试工作已经达到了某种程度，否则再好再适合的流程也不能起到它的作用。例如大家都一致认为测试应该从需求开始介入，但是从需求开始介入并不是测试人员参与了需求评审会议提出一些问题就达到了目的。而是要求测试人员在开发把产品开发出来前就要了解这个产品都要实现什么功能，虽然不知道开发怎么去实现这些功能，但是要知道实现了哪些功能。因为在产品在开发提交测试之后往往由于产品一些基本功能没有实现，使测试人员很难深入的对产品进行业务流程的测试，所以一些重大的流程问题往往在测试的后期发现，但是这时可能离产品提交用户的时间很近了，开发人员修改这个问题很可能会引发其他的问题增加产品的风险，而且一些开发还会抱怨为什么测试不早发现这些问题，还有可能使公司怀疑测试人员的能力，让测试工作的开展受到一定的阻碍。只有越来越熟悉产品才会发现越来越深入的问题，这是一般的发展规律我们难以改变。但是如果我们前期对产品需要实现的功能有很深的了解，前期就可以提前设计一些业务流程上的问题，一旦产品基本功能可以完成就马上进行业务流程的测试，使这个过程大大缩短。
制定合理的软件测试流程是一门很深的学问，它需要制定者有丰富的软件测试理论知识，软件测试执行经验、管理经验以及沟通能力等等多方面的经验能力，还需要许多测试人员经过长时间的实践来验证完善，仅希望此文对大家有所启发。 -
几个常用网络测试命令
2008-11-04 19:53:49
几个常用网络测试命令，在你测试中会常常用到，作用很强大就不用说了。
Ping
Ping是测试网络联接状况以及信息包发送和接收状况非常有用的工具，是网络测试最常用的命令。Ping向目标主机(地址)发送一个回送请求数据包，要求目标主机收到请求后给予答复，从而判断网络的响应时间和本机是否与目标主机(地址)联通。
如果执行Ping不成功，则可以预测故障出现在以下几个方面:网线故障，网络适配器配置不正确，IP地址不正确。如果执行Ping成功而网络仍无法使用，那么问题很可能出在网络系统的软件配置方面，Ping成功只能保证本机与目标主机间存在一条连通的物理路径。
命令格式: ping IP地址或主机名 [-t] [-a] [-n count] [-l size]
参数含义: -t不停地向目标主机发送数据;
-a 以IP地址格式来显示目标主机的网络地址 ;
-n count 指定要Ping多少次，具体次数由count来指定 ;
-l size 指定发送到目标主机的数据包的大小。
例如当您的机器不能访问Internet，首先您想确认是否是本地局域网的故障。假定局域网的代理服务器IP地址为202.168.0.1，您可以使用Ping避免202.168.0.1命令查看本机是否和代理服务器联通。又如，测试本机的网卡是否正确安装的常用命令是ping 127.0.0.1。
Tracert
Tracert命令用来显示数据包到达目标主机所经过的路径，并显示到达每个节点的时间。命令功能同Ping类似，但它所获得的信息要比Ping命令详细得多，它把数据包所走的全部路径、节点的IP以及花费的时间都显示出来。该命令比较适用于大型网络。
命令格式: tracert IP地址或主机名 [-d][-h maximumhops][-j host_list] [-w timeout]
参数含义: -d 不解析目标主机的名字;
-h maximum_hops 指定搜索到目标地址的最大跳跃数;
-j host_list 按照主机列表中的地址释放源路由;
-w timeout 指定超时时间间隔，程序默认的时间单位是毫秒。
例如大家想要了解自己的计算机与目标主机www.cce.com.cn之间详细的传输路径信息，可以在MS-DOS方式输入tracertwww.cce.com.cn。
如果我们在Tracert命令后面加上一些参数，还可以检测到其他更详细的信息，例如使用参数-d，可以指定程序在跟踪主机的路径信息时，同时也解析目标主机的域名。
Netstat
Netstat命令可以帮助网络管理员了解网络的整体使用情况。它可以显示当前正在活动的网络连接的详细信息，例如显示网络连接、路由表和网络接口信息，可以统计目前总共有哪些网络连接正在运行。
利用命令参数，命令可以显示所有协议的使用状态，这些协议包括TCP协议、UDP协议以及IP协议等，另外还可以选择特定的协议并查看其具体信息，还能显示所有主机的端口号以及当前主机的详细路由信息。 命令格式:
netstat [-r] [-s] [-n] [-a]
参数含义: -r 显示本机路由表的内容;
-s 显示每个协议的使用状态(包括TCP协议、UDP协议、IP协议);
-n 以数字表格形式显示地址和端口;
-a 显示所有主机的端口号。
Winipcfg
Winipcfg命令以窗口的形式显示IP协议的具体配置信息，命令可以显示网络适配器的物理地址、主机的IP地址、子网掩码以及默认网关等，还可以查看主机名、DNS服务器、节点类型等相关信息。其中网络适配器的物理地址在检测网络错误时非常有用。
命令格式: winipcfg [/?] [/all]
参数含义: /all 显示所有的有关IP地址的配置信息;
/batch [file] 将命令结果写入指定文件;
/renew_ all 重试所有网络适配器;
/release_all 释放所有网络适配器;
/renew N 复位网络适配器 N;
/release N 释放网络适配器 N。
在Microsoft的Windows及其以后的操作系统中，都可以运行以上命令。
-
负载生成器如何访问脚本
2008-11-04 19:46:24
运行方案时，默认情况下，脚本会复制到Vuser组计算机的临时目录中。
这样，Vuser组负载生成器便可以从本地而不是通过网络访问脚本。
当然你也可指示Controller将脚本存储在共享网络驱动器上。
-
【分享】LINUX常用技巧
2008-11-04 13:08:33
一次使用的常用技巧，分享下
1.取消^M字符
当你FTP一些DOS文件到unix下时，你经常会看见每行文件后面有个讨 厌的^M 字符，有两个简单的方法可以取消它。 用"vi"打开此文件，在Command mode下敲入： :%s/^V^M//g 或者，在UNIX SHELL下敲入: sed 's/^V^M//g' foo > foo.new
2.使用nohup命令
如果你想进程在你退出系统后还能执行，可以使用NOHUP命令 如： % nohup tar -cf /dev/tape /home & 你退出后再重新登录的话，使用'ps'命令可以看到进程还在执行3.查看文件的方法
如果你只想看文件的前5行，可以使用head命令，如： head -5 /etc/passwd 如果你想查看文件的后10行，可以使用tail命令，如： tail -10 /etc/passwd 你知道怎么查看文件中间一段吗？你可以使用sed命令 如: sed -n '5,10p' /etc/passwd 这样你就可以只查看文件的第5行到第10行。4.计算文件数和目录数 下面的语句可以帮你计算有多少个文件和多少个目录..
# ls -l * |grep "^-"|wc -l ---- to count files
# ls -l * |grep "^d"|wc -l ----- to count dir
还可以将以上的语句变成scrīpt或做个alias5.只列子目录的方法：
ls -F | grep /$ 或者
alias sub = "ls -F | grep /$"(linux)
ls -l | grep "^d" 或者
ls -lL | grep "^d" (Solaris)6.利用Find命令改变所有权
想要改变当前目录下所有文件的所有权,可以这样:
find . -exec chown OWNER.[GROUP] {} \; (Solaris)
find . -exec chown -R OWNER.[GROUP] {} \; (Linux)7.列出除了某些类型文件的当前目录所有文件
使用Ksh,用ls !(*.Z)可以显示所有文件，除了*.Z文件。 这个命令在一个目录里有许多种类型的文件的时候很有用 -
一次建立大量用户的方法
2008-11-04 13:04:26
在linux系统中，我们可以一次建立很多用户：
1. 假设用excel 完成数据域的建立，另存成 文字文件，ftp 到server 上，面资料文件的内容有三个字段，分别是帐号($1)、密码($2)、姓名($3)，存到server 上的檔名是 data.txt
2.编辑一个 awk 的程序 ，文件名：mkusers.awk，内容如下：
{ print "adduser -g users -d /home/st/" $1 " -s /bin/bash -c " $3 " " $1 }
{ print "echo " $1 ":" $2 " | chpasswd "}
请注意，蓝色部份是字符串，前后用"号，$1 $2 $3 是字段变量。
3. 执行
awk -f mkusers.awk ./data.txt | more
说明：先看看输出的结果对不对，正确无误后，把 more 改成 sh 就 可以了如果希望同时删除这些用户，只需要使用userdel -r username代替上面的程序就可以了
-
Unix中限制root远程登录的方法
2008-11-04 09:35:31
UNIX系统中，计算机安全系统建立在身份验证机制上。如果root口令失密，系统将会受到侵害，尤其在网络环境中，后果更不堪设想。因此限制用户 root 远程登录，对保证计算机系统的安全，具有实际意义。本文向大家介绍一些方法，能达到限制 root 远程登录的目的。
方法一：在/etc/default/login 文件，增加一行设置命令：
CONSOLE = /dev/tty01
设置后立即生效,无需重新引导。以后，用户只能在控制台（/dev/tty01）root登录，从而达到限制root远程登录，不过，同时也限制了局域网用户root登录，给管理员的日常维护工作带来诸多不便。
方法二：1.为了达到限制root远程登录，首先要分清哪些用户是远程用户（即是否通过另一台 Windows 系统或 UNIX 系统进行 telnet 登录），哪些用户是局域网用户。通过以下shell程序能达到此目的。
TY=`tty | cut -b 9-12`
WH=`finger | cut -b 32-79 | grep "$TY " | cut -b 29-39`
KK=` tty | cut -b 6-9`
If [ "$KK" = "ttyp" ]
Then
WH=$WH
Else
WH="local"
Fi
以上Shell命令程序中，WH为登录用户的主机IP地址，但如果在 /etc/hosts 文件中，定义了IP 地址和机器名之间的对应关系，则 WH 为用户登录的主机名。假设连接到局域网中的终端服务器的IP 地址为：99.57.32.18, 那么应在 /etc/hosts 文件中加入一行：
99.57.32.18 terminal_server
所有通过99.57.32.18终端服务器登录到主机的终端中，WH 是同一个值，即为终端服务器名terminal_server。
2.在root的.profile文件中，根据 WH 值进行不同的处理，从而实现限制root远程登录。
Trap 1 2 3 9 15
If [ "$WH" = "local" -o "$WH" = "terminal_server" ]
Then
Echo "Welcome......"
Else
Exit
Fi
方法三：有时为了工作的方便，允许局域网中部分电脑root登录,例如，允许局域网中IP 地址为 99.57.32.58 的电脑root登录，要实现这一点，需要在前述方法中，作两点补充：
1.在 /etc/hosts 文件中，加入一行：99.57.32.58 xmh。
2.在上述 Shell 程序段中，将下述内容：
If [ "$WH" = "local" -o "$WH" = "terminal_server" ]
修改为：
If [ "$WH" = "local" -o "$WH" = "terminal_server" -o "$WH"= "xmh" ]
方法四：经过以上处理后，仍存在普通用户登录后用su命令变成 root 用户的可能，从而达到 root 远程登录的目的。为了防止用这种方法实现 root 远程登录，需要限制普通用户不能执行 su 命令：
1.将su命令属主改为 root；
2.将su命令的权限改为 700。
方法五：在上述方法中，虽限制了普通用户执行su 命令，但“精明”的用户可以用 ftp 命令上载一个用户可以执行的 su命令，从而实现 root 远程登录。为了防止这一点，需要在路由器上设立防火墙，限制用户执行ftp协议，这里不再赘述。
-
LR算当前时间（整理）
2008-11-04 09:31:49
自己在LR中调试过，代码如下：
Action() { typedef long time_t; time_t t; /* Get system time and display as number and string */ lr_message("Time in seconds since 1/1/70: %ld\n", time(&t)); lr_message("Formatted time and date: %s", ctime(&t)); return 0; } -
LR监控计数器整理（六）
2008-11-04 09:29:19
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服务器当前正在使用的动态内存总量. -
LR监控计数器整理（五）
2008-11-04 09:23:42
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非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。 -
LR监控计数器整理（四）
2008-11-04 09:22:41
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 :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 -
软件项目中的风险归纳
2008-11-03 20:40:31
软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IＴ项目开发中常见的风险有如下几类：ü 需求风险
①需求已经成为项目基准,但需求还在继续变化;②需求定义欠佳,而进一步的定义会扩展项目范畴;③添加额外的需求;④产品定义含混的部分比预期需要更多的时间;⑤在做需求中客户参与不够;⑥缺少有效的需求变化管理过程。
ü 计划编制风险
①计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;②计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";③计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;⑤完成目标日期提前,但没有相应地调整产品范围或可用资源;⑥涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。
ü 组织和管理风险
①仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;②低效的项目组结构降低生产率;③管理层审查 决策的周期比预期的时间长;④预算削减,打乱项目计划;⑤管理层作出了打击项目组织积极性的决定;⑥缺乏必要的规范,导至工作失误与重复工作;⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
ü 人员风险
①作为先决条件的任务(如培训及其他项目)不能按时完成;②开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺乏激励措施,士气低下,降低了生产能力;④某些人员需要更多的时间适应还不熟悉的软件工具和环境;⑤项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;⑥由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;⑦不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;⑧没有找到项目急需的具有特定技能的人。
ü 开发环境风险
①设施未及时到位;②设施虽到位,但不配套,如没有电话、网线、办公用品等;③设施拥挤、杂乱或者破损;④开发工具未及时到位;⑤开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;⑥新的开发工具的学习期比预期的长,内容繁多。
ü 客户风险
①客户对于最后交付的产品不满意,要求重新设计和重做;②客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;③客户对规划、原型和规格的审核 决策周期比预期的要长;④客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;⑥客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。
ü 产品风险
①矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;②开发额外的不需要的功能(镀金),延长了计划进度;③严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;④要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;⑥开发一种全新的模块将比预期花费更长的时间;⑦依赖正在开发中的技术将延长计划进度。
ü 设计和实现风险
①设计质量低下,导致重复设计;②一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;③代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;④过高估计了增强型工具对计划进度的节省量;⑤分别开发的模块无法有效集成,需要重新设计或制作。
ü 过程风险
①大量的纸面工作导致进程比预期的慢;②前期的质量保证行为不真实,导致后期的重复工作;③太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;④过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;⑤向管理层撰写进程报告占用开发人员的时间比预期的多;⑥风险管理粗心,导致未能发现重大的项目风险。
-
【讨论】如何进行软件度量？
2008-11-03 20:36:51
软件度量（software measurement）是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。
一个简单软件度量流程图：
随着软件定量方法（如：软件度量）的重要性不断增加，市场上出现了许多度量工具。然而，度量工具目前还是很混乱。因为没有统一的度量标准规范，每种工具发明商家都是按照他们自己的软件度量规范。文献[44]对度量工具做了好的综述。Daich等根据分类学把度量工具分成了以下几种：● 通用度量工具；
● 小生境度量工具（Niche Metrics Tool）；
● 静态分析；
● 源代码静态分析；
● 规模度量那么有这么多工具进行软件度量，我们度量的目标是什么呢？简单地说可以分从两个角度去看吧
第一：对管理者来说
1.需要度量软件开发过程中的不同阶段的费用。
例如：度量开发整个软件系统的费用（包括从需求分析阶段到发布之后的维护阶段）。必须清楚这个费用以决定在保证一定的利润的情况下的价格。2.为了决定付给不同的开发小组的费用，需要度量不同小组职员的生产率。
3.为了对不同的项目进行比较、对将来的项目进行预测、建立基线以及设定合理的改进目标等，需要度量开发的产品的质量。4.需要决定项目的度量目标。例如：应达到多大的测试覆盖率、系统最后的可靠性应有多大等。
5.为了找出是什么因素影响着费用和生产率，需要反复测试某一特定过程和资源的属性。
6.需要度量和估计不同软件工程方法和工具的效用，以便决定是否有必要把它们引入到公司中。
第二：对我们软件工程师来说
1.需要制定过程度量以监视不断演进的系统。这包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等等。
2.需使用严格的度量的术语来指定对软件质量和性能的要求，以便使这些要求是可测试的。例如：系统必须"可靠"，可用如下的更具体 的文字加以描述："平均错误时间必须大于15个CPU时间片。"
3.为了合格需要度量产品和过程的属性。例如：看一个产品是否合格要看产品的一些可度量的特性如"β测试阶段少于20个错误。"，"每个模块的代码行不超过100行。"，和开发过程的一些属性如"单元测试必须覆盖90％以上的用例。"等。
4.需要度量当前已存在的产品和过程的属性以便预测将来的产品。例如：
(1).通过度量软件规格说明书的大小来预测目标? 的大小。
(2).通过度量设计文档的结构特性来预测将来维护的"盲点"。
(3).通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。 -
测试用例在软件测试中的作用
2008-11-03 20:25:51
1、指导测试的实施
测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
2、规划测试数据的准备
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。3、编写测试脚本的"设计规格说明书"
为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
4、评估测试结果的度量基准
完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。
5、分析缺陷的标准
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
我的栏目
标题搜索
我的存档
数据统计
- 访问量: 106284
- 日志数: 144
- 图片数: 1
- 建立时间: 2008-11-02
- 更新时间: 2010-03-25
