软件生命周期模型

2008-09-18 10:49:33

们把软件的开发过程分成了这样几个阶段：需求规格阶段，概要设计阶段，详细设计阶段，代码阶段，单元测试阶段，集成测试阶段，以及系统测试阶段。也就是说，在实际的开发过程中，我们要逐一完成每个阶段的工作，当完成最后一个阶段的工作后也就完成了整个软件项目。像这样组织软件开发过程的规则，就可以称为软件生命周期模型。一个定义良好的软件生命周期模型，可以很好的指导我们的开发工作，使漫长的开发工作易于控制。事实上，我们可以任意定义自己喜欢的软件生命周期模型。但是，如果生命周期模型定义不合理，却会制约我们的开发过程。软件开发人员在长期开发过程已经总结出了几种常用的软件生命周期模型，我们可以根据项目的特点来选择一个合适的模型，然后在此基础上再加以裁减。这些生命周期模型是：
        1）瀑布模型，
        2）快速原型模型，
        3）渐增模型，
        4）演进模型。
        下面我们重点阐述前3种常用的生命周期模型。

2．1瀑布模型
        顾名思义，该模型就是像瀑布一样。这是一个最传统的生命周期模型，是一种顺序的模型，自顶向下把一个软件开发过程分为：系统定义、需求分析、设计、编码、测试和维护等阶段。在开发过程中这些阶段顺序进行，就像是一个飞流直下的瀑布，因此得名。该模型可以用下面的图形来表示。
        系统定义
          \|/
        需求分析
          \|/
         设计
          \|/
         编码
          \|/
         测试
          \|/
         维护
        有时，根据项目的特点，设计又可分为概要设计和详细设计。
        上图中各阶段所要完成的工作在一般的论述软件工程的书籍中都有描述，这里就不再细述。
        虽然上面的阶段是顺序进行的，但是这并不是限定我们的软件项目必须在完成了上个阶段的工作后才能进行下个阶段的工作。在实际的开发过程中，我们常常会遇到这样的情况：阶段反复和重叠。
        在前面的需求管理部分我们曾经阐述过需求变更管理。也就是说，在软件开发的某个阶段可能发生需求变更，而一旦软件需求发生变化，就势必会造成软件设计的改变，因此，如果该软件项目已经进行到了测试阶段，那么我们就必须回过头来重新进行需求分析、概要设计、详细设计和编码。像这种在后面的阶段又返回来做前面阶段工作的情形，就成为阶段反复。当然，也有可能因为开发人员前面的工作做得不够准确而导致阶段反复。阶段反复常常会造成进度延迟，但是，只要严格控制好每个阶段的输入和输出，我们还是可以有效的控制软件项目的开发过程。
        在实际的开发过程中我们还会遇到这种情况：如果一个软件项目规模较大，而且各功能模块相对独立，那么，我们就没有必要要求所有模块的进度都一致，也就是说，模块1可能很快就能完成概要设计和详细设计，而模块2由于太复杂概要设计可能就需要很长的时间。对于这种情况，只要控制好模块1各阶段的输入和输出，完全可以让模块1先行，直到完成或者必须停下来等待其他模块。像这种情况，一个软件项目的各模块可能处于不同的阶段，就成为阶段重叠。出现这种情况，必须是某些模块比较独立，否则就不可能比其他模块先行。
        虽然阶段的重叠和反复是允许的，但是我们却不能允许这种情况随意发生。比如说，需求分析和设计可以重叠，但是如果需求分析和编码也重叠就很难说代码会写成什么样了；编码阶段可以因为需求变更回过头来进行需求分析和设计，但是如果已经进行系统测试了还在进行阶段反复，这就等于又开发一个新项目了。因此，为了更好的控制软件开发过程，要尽量减少阶段重叠和反复，如果实在不可避免，应该对所有的变更进行严格控制，这样才能保证我们的开发过程陷入无序状态。
        另外，在该模型的基础上，还衍生出了强调测试活动的V模型。它把瀑布模型的测试阶段进行细分，并于前面的阶段进行对应。细分出来的这些阶段分别为：单元测试阶段、集成测试阶段和系统测试阶段。V模型的结构图如下。

     系统定义                           维护
------\------------------------------/------------

         需求分析       .....       系统测试
              \                      /
            概要设计    .....   集成测试
                 \               /
               详细设计  ...  单元测试
                      \       /
                        编码

        与需求分析对应的是系统测试。因为需求分析的工作是分解用户的功能和性能需求并规格化，所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现。
        该测试把软件作为一个黑盒，针对每个需求规格组织各种输入并根据软件输出来判断该需求规格是否正确实现，因此系统测试属于黑盒测试。与概要设计对应的是集成测试。因为概要设计的工作主要是根据功能把大的系统进行模块分解，所以集成测试的工作主要是，把各模块逐步集成在一起，来测试数据是否能够在各模块间正确流动，以及各模块能否正确同步。因为这种测试依赖于软件的架构但又不关心每个函数的实现细节，所以该测试又常称为灰盒测试。与详细设计对应的是单元测试。它主要是详细设计中的每个功能单元（通常是函数或过程）进行逻辑覆盖测试，因此这种测试属于白盒测试。与从需求到设计、统测试，于是就形成了一个V字形的结构。
        与在瀑布模型中描述的一样，这些测试活动也是顺序进行的，并遵循一定的输入和输出规则（具体的测试在以后的章节中会详细描述），但是这些阶段也同样可以重叠和反复。

        瀑布模型的优点是清楚地标识出了软件开发的阶段。它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。
        瀑布模型的缺点正是它自身的顺序性所导致的。实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程。
        实际的开发过程中，用得较多的就是瀑布/V模型，只是可以根据实际需要进行阶段合并与裁减。

查看(268) 评论(0) 收藏分享管理

如何编写测试用例

2008-08-27 11:38:59

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

一、测试用例是软件测试的核心

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

二、什么叫测试用例

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

三、编制测试用例

着重介绍一些编制测试用例的具体做法。

1、测试用例文档

编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2、测试用例的设置

我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

按功能测试是最简捷的，按用例规约遍历测试每一功能。

对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

四、测试用例在软件测试中的作用

1、指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

五、相关问题

1、测试用例的评审

测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新

测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

3、测试用例的管理软件

运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

查看(207) 评论(0) 收藏分享管理

初学者入门：软件测试从零开始（一）--转

2008-07-11 13:37:15

本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。

　　【关键词】软件测试、测试用例、测试需求、测试结果分析

　　引言

　　几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。

　　测试准备工作

　　在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？

　　向有经验的测试人员学习

　　如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。

　　如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

　　阅读软件测试的相关书籍

　　现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。

　　走读缺陷跟踪库中的问题报告单

　　如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 Clear Quest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

　　走读相关产品的历史测试用例

　　如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

　　通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。

　　总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

　　学习产品相关的业务知识

　　软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。

　　因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

　　识别测试需求

　　识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：

　　主动获取需求

　　开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

　　当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：

　　软件输入：与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。

　　处理过程：描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

　　软件输出：描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。

　　性能要求：与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。

　　运行环境：软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

　　确认需求的优先级

　　确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。

　　加入开发小组的邮件群组

　　测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。

　　与开发人员为邻

　　建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。

查看(397) 评论(1) 收藏分享管理

界面测试的总结[10]

2008-07-07 11:23:21

软件测试时代关键字：界面测试 2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
C1n!ts?a2P;b^V3K
L(a8]F TWT~    3)：关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。

    4)：尽量防止对系统的独占使用。
"HW)HW'pa
    5)：窗口能否基于相关的输入或菜单命令适当地打开？

    6)：窗口能否改变大小、移动和滚动？
k$H?2e'N?0A(C
G-Mr2z}8Mq&~i#F$Ur_    7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？
+I1Kq6ks#xG
A3fNY@%Dg7u    8)：当被覆盖并重调用后，窗口能否正确地再生？

"W_I Uh c+~(_    9)：需要时能否使用所有窗口相关的功能？
F9c+R7Se^i,lJ#jHG
+J+S\,XB'G    10)：所有窗口相关的功能是可操作的吗？

5g1e,O0|9b)a9I$G    11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？

    12)：显示多个窗口时，窗口的名称是否被适当地表示？
3le R W0j#U2f _+}a
    13)：活动窗口是否被适当地加亮？
%nb R Q Y5h[h F
    14)：如果使用多任务，是否所有的窗口被实时更新？
[h{*M/` u7g!G
:xf_+R"]%r"O"l-j/o    15)：多次或不正确按鼠标是否会导致无法预料的副作用？
;~tr v;rD
    16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
uLqB @ e(RM
$N8`*J;G$I/xWE    17)：窗口是否正确地关闭？

查看(306) 评论(0) 收藏分享管理

界面测试的总结[9]

2008-07-07 11:21:55

软件测试时代关键字：界面测试  3)：采用相关控件限制用户输入值的种类。
mo&o} \\
5pQ%u |pz'D.dkp    4)：当用户作出选择的可能性只有两个时,可以采用单选框。
V7|3kw `U M
0|o4GNj4a U^    5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
/R'w(d-OX,|3`gzp w
'JV+w0wR2Cw D2hq,IA&v    6)：当选项特别多时，可以采用列表框，下拉式列表框。
5?6A i/bZ#_r
s v nmL(F    7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
-S.b}1D\S9Vf*Y
$}Z_:pv Cew3\2p    8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。

    9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
~s W@~yN!u;]0a(Y
;l8].C-B)ALR.F    10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
J-~'a t@#c[
l(]~H)u`nMVz2qn O    11)：对错误操作最好支持可逆性处理，如取消系列操作。
&YxO#F8xb/M|*q
    12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。

    13):对可能造成等待时间较长的操作应该提供取消功能。
.t1ib(Jj0U K@,h Q
    14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
-xK/I/k2J!oRG
.Na Oa"No1e    15)：与系统采用的保留字符冲突的要加以限制。
6M5cQ$s9{1F
\;M_'J%MRjI    16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
1n3[/u o!g$[#r-XC
    17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

*i!s*ki#B　　多窗口的应用与系统资源：
pds EM0N6B*\C?
    设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

vX2q&?u:zWZ"@ku    1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。

查看(260) 评论(0) 收藏分享管理

界面测试的总结[8]

2008-07-07 11:20:54

软件测试时代关键字：界面测试 5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

o,T&J4O3_a?1|.~/^'s    快捷方式的组合
n)j8gFE2YW%z Q5CC
@8J]7O:Z~`;T    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
v Es2q2y7Q#VE菜单中：

    1):面向事务的组合有: Ctrl-D 删除；Ctrl-F 寻找；Ctrl –H替换；Ctrl-I 插入；Ctrl-N 新记录；Ctrl-S 保存 Ctrl-O 打开。
9Xn7NV0})D+Q3y
    2)：列表: Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件。
Ho_ GI
!qZ*eYq:Q` yJ7A    3):编辑:Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。

SVs,h:b'?*YBTe JT    4)文件操作:Ctrl-P 打印；Ctrl-W 关闭。
rF.aw Q(i7b.Q
    5):系统菜单Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
+lt Qy^ \
    6):MS Windows保留键:Ctrl-Esc 任务列表；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用；Enter 缺省按钮/确认操作；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。按钮中：可以根据系统需要而调节，以下只是常用的组合。Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。

;F:fa6C:R8R    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

O*N } NpDrVw#rz　　安全性考虑：

x?~d3F$n    在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

    安全性细则：
,~+W~'G$J Y `-T
-i\KcD@3?d9WjM    1)：最重要的是排除可能会使应用非正常中止的错误。
_"Oh'F:I z`#[7d x
"Z\],SB6W'yc    2)：应当注意尽可能避免用户无意录入无效的数据。

查看(386) 评论(0) 收藏分享管理

界面测试的总结[7]

2008-07-07 11:19:43

软件测试时代关键字：界面测试 18):是否可能通过鼠标访问所有的菜单功能？

    19):相同功能按钮的图标和文字是否一致？
|*\3][0~r3?
!M9LDD|XP's    20):是否能够用其他的文本命令激活每个菜单功能？
"_j4xj`b"W
7^7n]$m~.c[    21):菜单功能是否随当前的窗口操作加亮或变灰？

    22):菜单功能是否正确执行？

Y rn lZ    23):菜单功能的名字是否具有自解释性？
C8B$p8Fs} {#V&w!Tl
-s]@J,y ^    24):菜单项是否有帮助，是否语境相关？
6m4Yih`l0VOd
    25):在整个交互式语境中，是否可以识别鼠标操作？

    26):如果要求多次点击鼠标，是否能够在语境正确识别？

    27):如果鼠标有多个按钮，是否能够在语境中正确识别？
9DS'^/?!x'U}
    28):光标、处理指示器和识别指针是否随操作恰当地改变？

　　独特性：

I$?+Y9F%p(qu    如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
;_v9~ }b^h1@8r kI测试细则：
},z!Jw{3B
    1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
v-\{vTw
3p-YG{i#Q`7N    2):　主界面，最好是大多数界面上要有公司图标。

    3):　登录界面上要有本产品的标志，同时包含公司图标。
tS-e'n SR? @
    4):　帮助菜单的“关于”中应有版权和产品信息。

查看(324) 评论(0) 收藏分享管理

界面测试的总结[6]

2008-07-07 11:18:36

软件测试时代关键字：界面测试菜单测试细则：

)x6]\B7e {    1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
1u+BV5U0rOqz@f
a$xb-LX ~7]#j    2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
CQgZnt5khN.Z {
PT'e{a(su/^*W    3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。

    4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
D#E$k4U&r`'M$n-O [
    5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。

A)]1A-ST[E,\B    6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。

    7): 菜单深度一般要求最多控制在三层以内。

NbR2ihhm    8): 对常用的菜单要有快捷命令方式，组合原则见8。

1n3C,J`#z,F] cQ#S2Z    9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
hr q,X,[f%T3@
/tVs2i7k#g @T Y    10): 菜单前的图标不宜太大，与字高保持一直最好。
/v1?%s7{2e7A:RL
    11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
.J2j Rq~[C0T8_ s m
i-^1e0s'WCd*J/q    12): 主菜单数目不应太多，最好为单排布置。
Ux(r!@8k)C5plx
M,@n/Z3jIdi`    13):菜单条是否显示在合适的语境中？

/GA1A @V?5u#B    14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

gz8_7`_B{N    15):下拉式操作能正确工作吗？

    16):菜单、调色板和工具条是否工作正确？
L0kM!gG bQl
    17):是否适当地列出了所有的菜单功能和下拉式子功能？
J~E'd6Ax

查看(284) 评论(0) 收藏分享管理

界面测试的总结[5]

2008-07-07 11:17:33

软件测试时代关键字：界面测试美观与协调性细则：
^;@4\ LL${(z(h2O
    1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。

    2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。

)bn |v'G4NVgO:ow    3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
AZ1tXok&n'v
    4): 按钮的大小要与界面的大小和空间要协调。
po{h0_.jq
    5): 避免空旷的界面上放置很大的按钮。

f!s[+p iZ    6)：放置完控件后界面不应有很大的空缺位置。

ZWt8T j    7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
(l2W|r LrX`!vq
    8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。

    9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
0hIF ~\:H ^
Zlg]xi%R.h    10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
Bc i$`N}&])ld)z
    11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
!Ca3d-?JkR _M fc
lF+QiA}4W    12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。

6r3c;J_CbZB&rd    13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

    14): 通常父窗体支持缩放时，子窗体没有必要缩放。
)S^2v5k,oJA1_
"a/aF VGz S;I    15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

　　菜单位置：

E k%Ns+D@@j {    菜单是界面上最重要的元素，菜单位置按照按功能来组织。

查看(285) 评论(0) 收藏分享管理

界面测试的总结[4]

2008-07-07 11:14:48

软件测试时代关键字：界面测试  6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
WL4I\NF9c-{"O k
4W:]"Q[C7h.~k7d3O o    7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。

    8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

%uW"VXS,P*o    合理性：

9M9a C3DE mmkV    屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
.u3}iVjbP mj b
    合理性细则：
U9\amS#d v n@
@.Q4d~7P \i    1)：父窗体或主窗体的中心位置应该在对角线焦点附近。

    2)：子窗体位置应该在主窗体的左上角或正中。

"ZTS o-O1~c{t    3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
m%UbtL4W.H
    4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

_0{D4^'g4k0IB7da    5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。

    6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

    7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。

    8)：非法的输入或操作应有足够的提示说明。

#?c)q1s#j.Ii    9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
ZPN_!`F2b
    10): 提示、警告、或错误说明应该清楚、明了、恰当。
iB(q.@7y
;d"~ \)ML[y4g　　美观与协调性：
/Vw5DZu6Vg
    界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

查看(339) 评论(0) 收藏分享管理

如何编制软件测试用例[3]

2008-07-07 11:08:29

软件测试时代关键字：测试4、评估测试结果的度量基准完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

HBg.TMY8A8rD6M 5、分析缺陷的标准通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

"`3V k'yNg,t 五、相关问题

1、测试用例的评审测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

ycu _hs 3、测试用例的管理软件运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

"|4UMAis5w8| 有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

:VyzGCpP| 开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护，使测试用例不断完善并与产品功能、特性（features）的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。

P:D,ZR;x g|WW.z 根据产品特性和test case一致性，分下面几种情况分别处理：

A|:d:~8S1j 1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case，也就意味着当前修改的test case，对目前和以前的版本都有效。

1Qu1S~UGEB 2. 原有产品特性发生了变化，不是new feature，而是enhanced features（功能增强），这时候原有的 test case 只对先前版本（如version 1.0、2.0）有效，而对新的版本（如 version 3.0）无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0）。

\ FNo n+AX2D] _ 3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。

4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。

这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！

查看(342) 评论(0) 收藏分享管理

界面测试的总结[2]--转

2008-07-07 11:05:16

软件测试时代关键字：界面测试
!O.x7{ R&O!B x    12):复选框和选项框要有默认选项，并支持Tab选择。

    13):选项数相同时多用选项框而不用下拉列表框。

'}_!Zo8T    14):界面空间较小时使用下拉框而不用选项框。
gF-K7@x
6^ZOY-iIH9[`U    15):选项数叫少时使用选项框，相反使用下拉列表框。

1_hB)b mq    16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

　　规范性：

    通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

| f_$Tm1w    规范性细则：

&d i;F`K x    1):常用菜单要有命令快捷方式。
K8C"W^h"A,ok,UW
7e4T+B)W ^s    2):完成相同或相近功能的菜单用横线隔开放在同一位置。
| c"^#?(KO
    3):菜单前的图标能直观的代表要完成的操作。
X&D]jRG8Vy3Gx
    4):菜单深度一般要求最多控制在三层以内。

^YT/Rp#q    5):工具栏要求可以根据用户的要求自己选择定制。
wU(Arw4?'l`?7|
    6):相同或相近功能的工具栏放在一起。
!QMT!T|5cT*P{
    7):工具栏中的每一个按钮要有及时提示信息。

0?%W VY*h    8):一条工具栏的长度最长不能超出屏幕宽度。
"yi2tF0R5r
    9): 工具栏的图标能直观的代表要完成的操作。
$O tw t*x-u
    10):系统常用的工具栏设置默认放置位置。

查看(307) 评论(0) 收藏分享管理

界面测试的总结[1]

2008-07-07 11:01:39

软件测试时代

关键字：界面测试  界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。

P'FV/PGj&o9Z　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

\fkdf　　易用性：

`:{mOhTP　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

3A}hNCw    易用性细则：

6R w&x _/yO!h(z,i    1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。

z@n0_/|4Xy(F    2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。

fQ5VzQJjWA    3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。

8q Xma%H@    4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
^ e WBPK.A D
    5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
+f%CJU)M[
    6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。

fn PPx)uwxo    7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab

fsdMhKc    8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
J'X4n-@c;m
    9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
7^|2K)n#Ly d
    10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
,tf8d'G-Xr7]'q
    11):复选框和选项框按选择几率的高底而先后排列。

查看(365) 评论(0) 收藏分享管理

如何用英语回答外企面试常见问题--转

2008-06-04 10:17:07

1. "What can you tell me about yourself?" This is not an invitation to give your life history. The interviewer is looking for clues about your character, qualifications, ambitions, and motivations.

　　The following is a good example of a positive response. "In high school I was involved in competitive sports and I always tried to improve in each sport I participated in. As a college student, I worked in a clothing store part-time and found that I could sell things easily. The sale was important, but for me, it was even more important to make sure that the customer was satisfied. It was not long before customers came back to the store and specifically asked for me to help them. I'm very competitive and it means a lot to me to be the best."
　
mX'a)U'I${a%S HH0　　"关于你自己，你能告诉我些什么？"这一问题并非在请你大谈你的个人历史。雇主是在寻找有关你性格、资历、志向和生活动力的线索。

　　下面是一个积极正面回答的好例子："在高中我参加各种竞争性体育活动，并一直努力提高各项运动的成绩。大学期间，我曾在一家服装店打工，我发现我能轻而易举地将东西推销出去。销售固然重要，但对我来说，更重要的是要确信顾客能够满意。不久便有顾客返回那家服装店点名让我为他们服务。我很有竞争意识，力求完美对我很重要。"

　　2. "Why do you want to work for us? This is an obvious question and, if you have done your research on the company, you should be able to give a good reason. 0rganize your reasons into several short sentences that clearly spell out your interest.

　　 "You are a leader in the field of electronics. Your company is a Fortune 5O0 company. Your management is very progressive." 　

　　"你为什么想为我们工作？"这是个明确的问题。如果你对该公司做过调查研究，你应该能够给出很好的理由。你要将你的理由编成几句简短的话清楚地表明你的兴趣。

　　如可答："你们在电子领域是领头人。你们公司是《财富》杂志评选的500强之一。你们的管理很先进。"

　　3. "Why should I hire you?" Once again, you should not be long winded, but you should provide a summary of your qualifications. Be positive and show that you are capable of doing the job.

　　Based on the internships that I have participated in and the related part-time experiences I have had, I can do the job.

　　"为什么我应该聘用你？"同样，你不应长篇大论，而应提供有关你资历的扼要说明。要肯定自己，表明你能胜任此项工作。

　　如答："根据我参加过的实习和与此相关的打工经历。我能胜任。"
jA)Uym o0　　4. "How do you feel about your progress to date?" Never apologize for what you have done.

　　 "I think I did well in school. In fact, in a number of courses I received the highest exam scores in the class." "As an intern for the X Company, I received some of the highest evaluations that had been given in years.

　　"对于你至今所取得的进步你是怎样看的？"绝不要对你以前的所作所为表示内疚。

　　如可答："我认为我在学校表现不错。事实上，有好几门功课我的成绩居全班第一。""在某公司实习时，我获得了该公司数年来给予其雇员的好几项最高评价。"

　　5. "What would you like to be doing five years from now?" Know what you can realistically accomplish. You can find out by talking to others about what they accomplished in their first five years with a particular company.

　　 "I hope to be the best I can be at my job and because many in this line of work are promoted to area manager, I am planning on that also."

　　"从今以后5年内你想做些什么？"你要清楚你实际上能胜任什么。你可以事先和他人交流一番。问问他们在某公司的头5年都做了些什么。

　　如可答。"我希望能在我的职位上尽力做好工作，由于在同一领域工作的许多人都被提为区域负责人，所以我亦有此打算。" 51Testing软件测试网J-j&hI(U
　　6. "What is your greatest weakness?" You cannot avoid this question by saying that you do not have any, everyone has weaknesses.

　　The best approach is to admit your weakness but show that you are working on it and have a plan to overcome it. If possible, cite a weakness that will work to the company's advantage. "I' m such a perfectionist that I won't stop until a job is well done.

　　"你最大的弱点是什么？"你不应该说你没有任何弱点，以此来回避这个问题；每个人都有弱点。最佳策略是承认你的弱点，但同时表明你在予以改进，并有克服弱点的计划。

　　可能的话，你可说出一项可能会给公司带来好处的弱点，如可说："我是一个完美主义者。工作做得不漂亮，我是不会撒手的。"

　　7. "What is your greatest strength"?" This is a real opportunity to toot your own horn. Do not brag or get too egotistical, but let the employer know that you believe in yourself and that you know your strengths.

　　 "I feel that my strongest asset is my ability to stick to things to get them done. I feel a real sense of accomplishment when I finish a job and it turns out just as I'd planned. I've set some high goals for myself. For example, I want to graduate with highest distinction. And even though I had a slow start in my freshman year, I made up for it by doing an honor's thesis."

　　"你最突出的优点是什么？"这是你"展示自己"的最佳机会，不要吹嘘自己或过于自负，但要让雇主知道你相信自己，你知道自己的优点。

　　如可答："我认为我最大的优点是能够执着地尽力把事情办好。当做完一件工作而其成果又正合我的预想时 51Testing软件测试网k dx,e"O}:Tg
，我会有一种真正的成就感。我给自己定了一些高目标。比如说，我要成为出色的毕业生。尽管在大学一年级时我启动慢了些，但最终我以优等论文完成了学业。"

查看(145) 评论(0) 收藏分享管理

TestDirector缺陷监控跟踪程序

2008-06-04 09:30:21

TestDirector

用过TestDirector的都清楚，她本身就具有定制邮件自动发送功能，不过其功能只能基于缺陷某个状态改变时触发发邮件的事件，要想达到相对负责的监控功能，只能基于TD的数据库开发一个程序。为了能给开发人员、测试人员提供更多的及时的缺陷信息，或者给测试组长及领导一份关于缺陷修改情况的简要报告，自己开发了一个TestDirector缺陷监控跟踪程序，算是一种额外的服务吧。此程序的功能说明如下：

功能说明：

实现了根据设定好的TD项目，指定时间、运行方式，程序根据参数自动跟踪TD项目中的缺陷情况，并发邮件（OutLook）给相关负责人。跟踪内容有以下三个方面：

1. 统计提醒开发人员，Open、Reopen超过1周没Fixed的BUG。

2. 统计提醒测试人员，Fixed后超过1周未验证的BUG。

3. 统计提醒开发人员，BUG的修改时间（即Actual_Fix_Time字段没填写时间）未填写完整。

4. 监控TD服务器的硬盘空间（C、E盘）情况，当空间少于一定数值时，自动发送邮件给负责人。

注：前面三项的结果会自动保存在log目录下的log文件中。

配置说明：

程序中的参数配置在以下四个文件中设置：

1. ProjectListConfig，配置要监控的TD项目，即TD项目的数据库名称，格式为，一行一个。

2. ReportMailUserList，配置监控结果发送接收人列表，格式为，第一行为收件人地址，第二行为抄送人地址，多个收件人以半角逗号隔开。

3. ServerConfig，配置OutLook邮件服务器地址及端口号，TD数据库服务器地址，及TD数据库服务器的帐号及密码。

4. SysMailUserList，配置监控TD服务器的硬盘空间结果的邮件接收人。

注：以上具体格式，参考各文件例子

启动程序说明：

按照以上配置说明，配置好各项参数后，一可直接运行AutoMonitor.exe，而通过StartAutomonitorApp.exe调用AutoMonitor.exe，第二种方式可达到只启动一个监控程序的目的。

退出程序说明：

在任务栏，右键点击程序图标，可退出程序。

程序下载：TestDirector缺陷监控跟踪程序

查看(242) 评论(0) 收藏分享管理

(转)测试工程师如何规划自己的职业生涯？

2008-06-03 13:40:53

前几天在51的论坛里看到了这篇帖子，贴过来给大家共享一下，顺便明确下自己以后的发展方向，呵呵。

观点一：

具体的流程图见下图所示。（好经典，，，值得收藏）

观点二：

step1：校园阶段（毕业前1年～1.5年）
很多人的职业规划是到了工作以后才开始进行的，其实，这样做，有很大的局限性。凡是工作过的人，都有一个体会，就是自己的第一份工作，会影响到5～10年的发展轨迹，甚至会对一生产生影响。因此，选择一份合适的工作作为起点，是必须要在校园内思考清楚的问题。
由于中国的教育基本是理论教育，大家在工作前的实践能力大多比较弱，固然有其不足，但也有好的一面，那就是可塑性比较好。可塑性好代表了选择的余地可以很大，因此，大家在选择第一份工的时候，要充分结合自己的教育背景、个人能力、兴趣爱好、长期目标等等，作出理性的决策。
软件测试，特别是黑盒软件测试是一种入门起点较低、上手迅速、且发展空间比较大的职业，因此，对于很多学生而言，作为进入IT就业的初级岗位，是非常合适的。
校园阶段的规划，主要是选择大的入门方向，当然，此时也可以给自己一个长期的目标，但是不必规划过细，因为，在没有入行前，一切都还未知，把握好路线即可。

下文假设大家选择的是软件测试～～

step2：入门阶段（入行后3个月～1年）
对于刚刚入行的新人，这个时期是一个全面熟悉期，最能够学习到新的知识，也最有拼搏的热情和动力。建议大家可以借着这股冲劲，尽可能了解所在领域的全貌，了解各个主要分支的内容、特性、优势、局限性等等，并考察自己当前的工作环境，结合个人匹配程度和兴趣爱好，根据前述内容调整自己的规划。
对于测试行当而言，技术方面一般有几类：黑盒测试、白盒测试、自动化测试、测试工具、专用业务技能等；相关的管理方面一般有：测试管理、质量管理、项目管理等。
面对上述形形色色的方向，建议大家可以都稍稍了解下内涵，然后确定1～2个，作为中长期的主攻方向，达此标准，基本已经实现了入门，至于能否进得厅堂，就要看后期的努力了。

step3：提高阶段（入门后3年～5年）
对于入门后选择管理还是选择技术，其实这种问题，是无可无不可的，关键是看对自己的长期的定位了。不过，我个人建议当前阶段还是技术为重吧。毕竟，在一个技术环境中，要做好管理，没有扎实的基础，也难服众嘛。
本阶段是人最容易懈怠的阶段。毕竟，刚刚入行的热忱早已被日复一日的繁复工作给冷却，有了一定的工作经验，胜任本职，对于大多数人而言，绝不是问题。家庭、娱乐方面开始占据了业余生活的主流。可是，毕竟大家还很年轻，大多数人此时也不过20多岁，就此懈怠也是非常可怕的。因此，有规划的提高自身核心竞争力，在这个时候尤为关键。
提高是要提高的，但是对于大多数人而言，也没有必要很拼搏，此时处在一个比较稳定的职位上的你，可以考虑进行细化自己的中期规划了。根据选定的方向，制定一个自我提升的计划，并定义好自我检查的里程碑（譬如：每个季度或半年算一个阶段），每天或者每周，有规律的学习一点即可。抱定一个目标——“每天进步一点点”，几年一大成不是问题。
我个人是反对急功近利的，倾向于稳打稳扎，这个阶段忌做“万金油”，而应努力成为有一技之长的“专家”。
对于选择做技术的人而言，这个阶段的达成标准，一般至少要能够熟悉你所选技术方向的大多数技术细节，“细节决定成败”嘛，虽然把握全局的能力是必要的，但是作技术而言，倘若不能钻的很细很深，恐怕也很难以高手自居吧。
对于选择做管理的人而言，我个人倾向是：此阶段接触管理的理念，并可以介入管理，但是此阶段不宜全面进入管理（除非你有更深层次的考虑，可以不去稳打稳扎）。学习管理的理念是非常重要的，其实管理更多一种思维和做事的方式，这门学问很深入，也不像技术，会不会是那么的显著，因此，建议多看多学，取长补短，并努力形成自己的做事风格。高级测试工程师，测试组长等，都是不错的含有技术特征的管理职位，此时的你应该能够胜任于此。

这个阶段的达成后，你也可以跻身老手行列，不必为求职犯愁，你应该可以很容易跳槽或时不时被猎头骚扰下，达成此阶段，你要做更深入的规划。

step4：升华阶段（老手后5年～10年）
此时的你，即将步入中年，不论是曾经专注技术还是偏爱管理的，都面临着家庭和社会的双重压力，你不可能像年轻人一样整天拼搏了，你需要稳定，因此，不能频繁的跳槽，建议考虑比较正规且有潜力的企业，要考虑给自己一个长远的发展规划。
正因为有前期的细节的背景的支撑，此时，你需要努力提升自己的宏观把握能力。哪怕做技术的，也要考虑适当的转型管理（中国特色是：工程师很难超过35岁的，一般人到了30岁不是转管理就是转商务了）。当然，一般人是技术做得越好，管理的时候，越容易切中项目要害。但是，对于从技术上来的人，关键是要开始培养和人打交道的能力。此阶段的关键是，需要逐步形成自己的管理风格，具备协调并行事务的能力。
当然，纯管理和技术型管理还是有所区别的。对于纯管理的人，熟练应用管理的科学理念，形成自己的风格尤为重要。纯管理的测试经理人，不仅仅可以做好测试方面的管理，其实也可以做好项目甚至其他的管理。其实，不管管理的对象是什么，它们的管理理念还是相通的。从测试管理中摸索出来的很多经验，可以很好的推广于其他的管理领域。而对于技术型管理的人，主要是带好技术团队，同时，不断补充新的技术知识，跟紧技术潮流。此时的你，有强大的技术背景支撑，不需要过分钻研细节，只需洞察核心，合理安排好你的团队成员即可。
这个阶段，也可能少数的人会选择离开具体的企业，而开始从事测试咨询，那是一个充满挑战的崭新开始，也必须有前期的积累方能胜任。
对于大多数人而言，此阶段中一个需要重点考虑的问题是，是否将测试作为自己的终生职位，如果是，基本上达到上述的目标，保持状态，基本可以做到退休的。如果不是，那就比较可怕了。其实我不建议此阶段的人转型，除非有充分的理由和很好的机遇。毕竟，达到此阶段，你已经付出了至少5年的努力，而且还是人生的黄金时段，时光一去不复返啊。当前状态下转行，请务必慎重。

观点三：

初级测试工程师：刚走出大学校门或者刚从些培训机构出来的学员，之前没有或具备很少的测试经验，这个阶段主要是掌握最基本的测试方法、测试计划、测试用例、测试报告、环境搭建等。北京上海地区，该职位薪水一般在2000-5000之间。

中级测试工程师：从事过2-3年实际工作的测试工程师，能够独立制定测试计划，编写测试用例，对初级测试工程师进行指导等。北京上海地区，该职位薪水一般在4000-6000之间。
达到中级测试工程师水准后，以后的发展可以存在多种方向：
管理方向：
测试组长：一般5人以下团队，能够同时承担2-3个较小项目（程序代码在5000行以下）或者1个中、大型项目（程序代码在5000行-25000行左右）。北京上海地区，该职位薪水一般在5000以上，好的过万。
测试经理：可以管理多个小型测试团队，能够承担多个中型及较大型项目的测试，及具备至少1个大型项目（程序代码在25000行以上）的测试管理能力。该职位薪水一般过万，年薪二三十万正常。
质量经理/项目管理：跳出测试的执行转而关注过程。SQA待遇差别比较大，但有2年以上测试或开发经验的人5000以上应该没问题，好的也过万。

技术方向：
白盒测试：这个由开发人员转过来的比较多，一般技术上要至少达到技术经理的水准。待遇比较好，一般7k以上，好的年薪二三十万。
自动化测试方向：熟练使用一种以上自动化测试工具，做的好的待遇与白盒测试有的一拼，一般6k以上,不过最近学的人多了，待遇贬值可能比较快。
测试分析师/技术总监:主要职责是对系统的测试结果进行综合的分析，例如缺陷分析、性能分析等。不但测试技术能力较强，还要具备数据库、操作系统等多方面的技术知识。这个待遇一般过万了吧.
行业测试专家：物以稀为贵，过万一般问题不大。

经历了以上一些阶段，大概在35岁左右，职业发展上基本达到瓶颈，此时只要混的不是很差收入一般可以算的上中产阶级，日子可能依然过的比较郁闷，之后的方向可能有做培训，咨询，自己开公司创业等。

10851_200803191431071

查看(282) 评论(0) 收藏分享管理

如何在脚本中做关联（在网络上搜到的）

2008-05-12 10:17:41

如何在 LoadRunner 脚本中做关联 (Correlation)
当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen的Recording Log中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了client端要对server端所说的话，而Recording Log则是完整纪录二者的对话。

当执行脚本时，您可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。
所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。这样的作法在遇到有些比较聪明的服务器时，还是会失效。这时就需要透过「关联（correlation）」的做法来让VuGen可以再次成功地骗过服务器。
何谓关联（correlation）？
所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。
举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易，服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。（比如饭票，当月使用可以，下月使用就过期了，食堂和用户手里都有这个饭票）
下面的图示说明了这样的情形：
当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再送出网页B的情求时，这时就要用到ID=123的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。
在执行脚本时会发生什么状况？浏览器再送出网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。

要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。
哪些错误代表着我应该做关联（correlation）？
假如脚本需要关联（correlation），在还没做之前是不会执行通过的，也就是说会有错误讯息发生。不过，很不幸地，并没有任何特定的错误讯息是和关联（correlation）有关系的。会出现什么错误讯息，与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP 404的错误讯息。
要如何做关联（correlation）？
关联（correlation）函数
关联（correlation）会用到下列的函数：
• web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。
语法：
web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
• web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。
详细用法请参考使用手册。在VuGen中点选【Help】>【Function reference】>【Contexts】>【Web and Wireless Vuser Functions】>【Correlation Functions】。
如何找出要关联（correlation）数据
简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。
VuGen提供二种方式帮助您找出需要做关联（correlation）的值：
1. 自动关联
2. 手动关联
自动关联
VuGen内建自动关联引擎（auto-correlation engine），可以自动找出需要关联的值，并且自动使用关联函数建立关联。
自动关联提供下列二种机制：
• Rules Correlation：在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。规则来源有两种：
o 内建（Built-in Correlation）：
VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建关联规则，这些应用系统可能会有一种以上的关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则，则当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。
您也可以在【Recording Options】>【Internet Protocol】>【Correlation】检视每个关联规则的定义。
o 使用者自订（User-defined Rules Correlation）：
除了内建的关联规则之外，使用者也可以自订关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】建立新的关联规则。
• Correlation Studio：有别于Rules Correlation，Correlation Studio则是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次，Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。
Rule Correlation
请依照以下步骤使用Rule Correlation：
1. 启用auto-correlation
1. 点选VuGen的【Tools】>【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】>【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。
2. 假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。
3. 或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。
4. 设定当VuGen侦测到符合关联规则的数据时，要如何处理：
 【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。
 【Perform correlation in sceipt】：直接自动建立关联
2. 录制脚本
开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。

3. 执行脚本验证关联是OK的。
Correlation Studio
当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。
Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。
使用Correlation Studio的步骤如下：
1. 录制脚本并执行
2. 执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。

3. 扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。

4. 检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。
5. 一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。
有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。
手动关联
手动关联的执行过程大致如下：
1. 使用相同的业务流程与数据，录制二份脚本
2. 使用WinDiff工具协助找出需要关联的数据
3. 使用web_reg_save_param函数手动建立关联
4. 将脚本中有用到关联的数据，以参数取代
接下来将详细的说明如何执行每个步骤
使用相同的业务流程与数据，录制二份脚本
1. 先录制一份脚本并存档。
2. 依照相同的操作步骤与数据录制第二份脚本并存盘。注意，所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。
有时候会遇到真的无法使用相同的输入数据，那您也要记住您使用的输入数据，到时才能判断是您输入的数据，还是变动的数据。
使用WinDiff工具协助找出需要关联的数据
1. 在第二份脚本中，点选VuGen的【Tools】>【Compare with Vuser…】，并选择第一份脚本。
2. 接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。（假如没看到红色字体，请点选【Options】>【View】>【Show Inline Differences】）。
3. 逐一检视二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。选取差异的脚本，然后复制。
在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。
注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。

4. 接着要在Recording Log（单一protocol）或是Generation Log（多重protocol）中找这个值。将鼠标光标点到Recording Log的第一行开头，按下Ctrl+F，开启【Find】窗口，贴上刚刚复制的脚本，找出在Recording Log第一次出现的位置。

结果会有二种：
o 在Recording Log中找不到要找的数据，这时请先确认您找对了脚本，毕竟现在开启了二个几乎一样的脚本，很容易弄错。
o 在Recording Log中找到了要找的数据，这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头，从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中，则表示此数据是由client端产生，不需要做关联，但是有可能需要做参数化（parameterized）。
您要找的标头格式如下：
*** [tid=b9 Action1 2] Receiving response from host astra.merc-int.com:80 ( 25/11/2002 12:04:00 )

5. 现在您已经找到录制二次都不一样，而且是由服务器所产生的动态数据了，而此数据极有可能需要做关联。
使用web_reg_save_param函数手动建立关联
在找到是由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param函数，将这个动态数据撷取到某个参数中。
1. 要在哪里使用web_reg_save_param函数？
在之前的步骤，我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制，我们将会利用这段文字，来帮助我们找出要关联的动态数据。

不过在这之前我们要先找出使用web_reg_save_param函数的正确位置，所以我们要再重新执行一遍脚本，而且这次会开启所有的Log。
1. 在VuGen中点选【Vuser】>【Run-Time Settings】。
2. 点选【General】>【Log】。
3. 勾选【Enable logging】、【Always sends messages】、【Extended log】，以及【Extended log】下的所有选项。
4. 按下【OK】就可以执行脚本了。
执行完脚本之后，在Execution Log中搜寻刚刚复制的字符串。找到字符串后，在字符串前面会有A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是要插入到脚本的第7行。
在脚本的第7行前插入一行空白行，然后输入
web_reg_save_param(“UserSession”,
“UserSession” 这个 “UserSession” 就是到时要使用的参数名称，建议给个有意义的名字。
注意：到这里整个web_reg_save_param函数还没完成。

2. 找出web_reg_save_param中要用到的边界
web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。
找出左边界字符串
再回到Execution Log中，选取动态数据前的字符串并且复制它。
这时会有个问题，到底要选取多少字符串才足以唯一识别要找的动态数据呢？建议是越多越好，但是尽量不要包含到特殊字符。
在这边我们选取「input type=hidden name=userSession value=」字符串。选好之后，还要再确认一次这段字符串真的是可以唯一识别的，所以我们在Execution Log中透过Ctrl+F的搜寻，找找看这段字符串是否可以找到要找的动态数据。假如找不到，web_reg_save_param函数还有个ORD参数可以使用，ORD参数可以设定出现在第几次的字符串才是要找的字符串。
将这个边界字符串加到未完成的web_reg_save_param函数中：
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”,
找出右边界字符串
接下来要找出动态数据的右边界字符串，这个字符串就比较好找了，从动态数据的最后一个字符开始，通常就是我们要找的右边界字符串了。
以这个例子来看，就是「>」，所以再把右边界字符串加入，web_reg_save_param函数中，这时web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”, “RB=>”, LAST);

将脚本中有用到关联的数据，以参数取代
当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。
范例：
将
“Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,
换成
“Name=userSession”, “Value={UserSession}”, ENDITEM,

到这里您已经完成了一个关联了，接下来就是执行脚本，是否能成功运行，假如还是有问题，就要检查看看是否还需要再做另一个关联。
关于 web_reg_save_param 函数
对于关联(correlation)来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，透过设定的边界字符串，找出特定的数据并将其储存在一个参数中，以供后续脚本使用。
接下来将针对web_reg_save_param做比较详细的说明。
Service and registration type function
web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的，如关联、设定proxy、提供认证信息等，当其作用时，不会对网页的内容做任何的修改。
web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼，表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将web_reg_save_param放在此web_url之前，则web_reg_save_param会在web_url执行完毕后，也就是网页内容都下载完后，再执行web_reg_save_param找寻要做关联的动态数据并建立参数。
所以要记住一点，要使用registration type function时，要注意其放置的位置必须在要作用的action function之前。
语法
int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
参数说明
ParamName:存放动态数据的参数名称
list of Attributes:其它属性，包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写，例如 Search=all。以下将详细说明每个属性值的意义:
• Notfound:指定当找不到要找的动态数据时该怎么处置。
o Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。
o Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对角本除错时，可以使用此属性值。
• LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。
• RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。
• RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。
• Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。
• ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。
• SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。
• Convert:可能的值有二种:
o HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式
o HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
• SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。
范例
web_reg_save_param("A", "LB/ic=<a href=", "RB='>", "Ord=All", LAST);nner会搜寻网页中所有以「<a href=」开头，且以「’>」结束，当中包含的字符串，并且储存在「A」参数中。
Tips and Tricks
以下提供一些关联的常见问题：
• 如何打印出参数值？
lr_output_message这二个函数来做到。例如：
lr_output_message(“Value Captured = %s”, lr_eval_string(“{ParameterName}”));
lr_eval_string与lr_output_message函数的使用说明请参考LoadRunner Online Function Reference。
• 在脚本的data目录下找不到路制时的快照（snapshot）
造成在脚本的data目录下找不到路制时的快照（snapshot）的可能原因如下：
o 脚本是由VuGen 6.02或更早的版本所录制的
o 汇入的Action不会包含快照（snapshot）的档案
o 脚本是储存在只读的目录下，早成VuGen无法储存执行时撷取的快照（snapshot）
o 某些步骤并不会产生快照（snapshot），如浏览某个资源
o 快照（snapshot）功能被取消
【Tools】>【General options】>【Correlation】tab >【Save correlation information during replay】
• 开启WinDiff时出现「File no longer available」的错误讯息
WinDiff这个工具有些限制，无法开启包含空格符的目录或是脚本，所以建议命名时不要使用空格符，并且尽可能将名称取短一点。
• 录制时突然跳出【Correlation warning】对话窗口
当你有勾选自动关联的【Issue a popup message and let me decide online】选项，当VuGen发现有可能要做关联的数据时，就会跳出【Correlation warning】的窗口，询问你要做关联（Correlation in scrīpt）还是要忽略（Ignore）。
另外你也可以勾选【Perform correlation in scrīpt】，让VuGen自动作关联，不会再跳出询问窗口。
或是勾选【Disable correlation engine】，关闭自动关联的功能。

• 如何手动启动「Scan action for correlation」的功能
要手动启动「Scan action for correlation」的功能，请先执行脚本一次后，点选【Vuser】>【Scan Action for Correlation】。

• 执行完脚本后并未出现【Scan Action for Correlation】窗口
要启用【Scan Action for Correlation】功能，请点选【Tools】>【General options】>【Correlation】tab，勾选【Show Scan for correlation popup after replay of Vuser】选项。

查看(300) 评论(0) 收藏分享管理

LoadRunner 没有告诉你的（二）---转

2008-05-08 14:29:34

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

^_^

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

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

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帮助手册。

查看(133) 评论(0) 收藏分享管理

LoadRunner 没有告诉你的(一)--转

2008-05-08 14:23:19

2008-05-05 11:42:30 / 个人分类：loadrunner

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\" href="http://jakarta.apache.org/jmeter/" target=_blank>JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。
,A(\ s3VL N^0

事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。

查看(378) 评论(1) 收藏分享管理

关于软件测试的几个经典问题（1）

2008-05-08 14:11:05

什么是“软件测试”？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü 对于该项目的用途而言，哪种功能最重要?

ü 哪种功能对用户最明显?

ü 哪种功能对安全影响最大?

ü 哪种功能对用户最有用?

ü 对客户来说，该应用软件的哪个部分最重要?

ü 在开发过程中，该应用软件的哪个部分可以最先测试?

ü 哪一部分代码最复杂，容易导致出现错误?

ü 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü 哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü 需求和设计的那些部分不清楚或不容易读?

ü 开发人员认为在应用软件中哪些部分是高风险的?

ü 哪些问题能造成最差的发行?

ü 哪些问题最能引起用户抱怨?

ü 哪些测试可以容易地覆盖多种功能?

ü 哪些测试在覆盖高风险部分的测试时使用时间最少?

如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü 好的代码注释和好的文档有助于开发人员作出相应的改变。

ü只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü在项目的时间表中应当留出余量，以应付可能出现的变更。

ü尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变更进行适当的风险分析，以减少回归测试的要求。

ü在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

查看(467) 评论(0) 收藏分享管理