Rational Robot简单的说是这样一个东西：它能记住你所有的操作（键盘和鼠标），并且不走样的再来一遍。

       我们先来看看传统的手工测试的过程。假设我们测试Windows自带的计算器应用程序。我们要验证“1＋2＝3”这么个简单的加法运算，看看计算器应用程序是否正确。我们用鼠标依次点击“1”，“＋”，“2”，“ ＝”，然后我们用眼睛看结果栏里面是不是“3”，如果是，就OK，如果不是我们就要分析：是不是自己点错了？是不是别的误会？很有可能我们会重新再来一遍（因为这个操作并不复杂），最后我们确信地给出结论：“这个应用程序不能正确的算出1＋2＝3”，然后我们要做的事情是填写相关的报告，报告这个BUG。不久之后你得到了一个新的版本，然后你再重复上面的测试过程。不久之后，又来了个集成测试要求，要求你再做一遍，最后，发布前还有一次验收测试，对不起，你再来点一遍。哦，对了还要求对老版本Win95/98的支持，准备环境，再来几遍。。。
好了，大家已经看到恶果了。但事实上我们要么就正在这么傻傻地做，要么就在偷工减料。随着迭代开发模式被广泛地采纳，测试被更加快速的要求重复着。因此，自动化测试有了它的用武之地。

       现在我们再来看看Rational Robot是怎样帮助我们节省时间的。我们用一次手工测试的时间（数量级的相同），记录一个GUI脚本，然后需要的时候就让它回放（Playback）一次。如果你说开发小组现在逻辑还没有完全实现，没关系，你自己心中肯定知道将来一定会实现1＋2＝3的，不会是别的东西，因为最原始的需求没有改变，我们就可以手工改写GUI脚本，将预期结果3记录下来。甚者，你说现在开发小组连界面都还没有完成，那你的要求就太过分了，没有办法去测是一个连基本输入输出都不能实现的东西，手工测试也不行啊。除此之外，我们还可以用数据池（Datapool）来给脚本“泵”数据，这样不单单测试了“1＋2＝3”，还可以测试“2＋1＝3”，“2＋2＝4”，如果愿意，我们可以让这个脚本把所有整数范围的加法一个不漏的全部执行一遍，计算机反正不知道累。

       上面的道理看上去很简单，但是这就是自动测试的精髓所在。但是人的活动是很复杂的，也就是说，手工测试有很高的权威性，因为不管什么软件，它最后的运行结果都是靠人来判定正确与否。所以，不管什么自动测试工具都只是一个子集，Rational Robot之所以很有名气，就是因为它比别的工具模仿手工测试模仿得更象一些。再加上Rational家族其它工具的配合，使我们整个的测试工作显得很有序。

       因此，我们学习Rational Robot的自动测试，我建议一切从我们的需求出发，每一个问题，我们都先考虑怎样手工来测试，然后我们去在Rational Robot中找替代物。比如说，例子中我们是用眼睛去看用脑子去判断是不是等于3，那Rational Robot就是靠捕获界面上那个文本框的属性（Object Properties）来判断的，换句话说，将我们手工测试中的每一个动作和每一个思考都“翻译”成Robot的方式。这样很快的我们就能上手用Robot了。再碰到一些棘手的问题，查看帮助也解决后，我们就能慢慢积累一些生僻的经验。你就成为Rational Robot自动测试高手了。最后，你还能用Robot提供的接口进行一些特殊功能的扩展开发，恭喜！你已经是Rational Robot自动测试专家了。

        在安装IBM Rational Robot后，往往很多朋友便急忙的打开Robot，想看看它的界面，可是发现出现的并不是他们实际相要的东西，Robot需要经过一定的配置之后，才能正常的投入到使用中去。本文是作者在一次项目实施中使用的配置，留给自己日后参考。

在首次安装并倒入Licens后，首先会启动如下界面，但是我们会发现在Project中没有任何项目，而且我们也暂时无法获得admin用户的Password：

1，  首先，我们打开Rational Administrator

开始- 所有程序- -IBM Rational- - Rational Administrator

2，  新建一个项目：

File- -New Project

项目名称：MyRobotProject

项目路径：C:\Documents and Settings\Administrator\My Documents\Rational Project\

3,  点击下一步，弹出如下窗体，点击OK继续，不用理会：

   

4，  直接点击下一步，暂时务须输入任何密码

5，  点击完成

6，  配置项目

这里我们只对Test Assets做相关配置，其他请参考相关文档。

因为实验环境，所以选择Microsoft Access作为Robot数据库。开始数据库的配置，请连续点击下一步。

点击完成。

Test Datastore成功创建。

点击OK。Robot Project成功创建。

7，  运行项目

打开Robot，因为前面这里的密码设置为空，所以这里不用输入任何密码，你可以在登陆进后在菜单里面进行密码的设置。

点击OK。

Robot启动界面如下，你就可以开始你的测试了：

8，  开始一个项目的测试：

功能测试用例设计积累（一）：软件界面

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

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

　　1：易用性

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

　　易用性细则：

　　1）完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。

　　2）完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。

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

　　4）界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。

　　5）界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。

　　6）同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。

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

　　8）默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。

　　9）可写控件检测到非法输入后应给出说明并能自动获得焦点。

　　10）Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。

　　11）复选框和选项框按选择几率的高底而先后排列。

　　12）复选框和选项框要有默认选项，并支持Tab选择。

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

　　14）界面空间较小时使用下拉框而不用选项框。

　　15）选项数叫少时使用选项框，相反使用下拉列表框。

　　16）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

　　2：规范性

　　通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

　　规范性细则：

　　1）常用菜单要有命令快捷方式。

　　2）完成相同或相近功能的菜单用横线隔开放在同一位置。

　　3）菜单前的图标能直观的代表要完成的操作。

　　4）菜单深度一般要求最多控制在三层以内。

　　5）工具栏要求可以根据用户的要求自己选择定制。

　　6）相同或相近功能的工具栏放在一起。

　　7）工具栏中的每一个按钮要有及时提示信息。

　　8）一条工具栏的长度最长不能超出屏幕宽度。

　　9） 工具栏的图标能直观的代表要完成的操作。

　　10）系统常用的工具栏设置默认放置位置。

　　11）工具栏太多时可以考虑使用工具厢。

　　12）工具厢要具有可增减性，由用户自己根据需求定制。

　　13）工具厢的默认总宽度不要超过屏幕宽度的1/5。

　　14） 状态条要能显示用户切实需要的信息，常用的有：

　　目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。

　　15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。

　　16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。

　　17）菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。

　　18）菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。

　　19）右键快捷菜单采用与菜单相同的准则。

　　3：帮助设施

　　系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

　　帮助设施细则：

　　1）帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。

　　2）打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。

　　3）操作时要提供及时调用系统帮助的功能。常用F1。

　　4）在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。

　　5）最好提供目前流行的联机帮助格式或HTML帮助格式。

　　6）用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。

　　7）如果没有提供书面的帮助文档的话，最好有打印帮助的功能。

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

 

 

功能测试用例设计积累（二）：错误推测法分析与实践

关键字：功能测试、测试用例、错误推测法

　　1、方法定义：

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

　　2、思路：

　　分析程序中最易出错的场景和情况，在此基础上有针对性的设计测试用例。需要完成的前提条件如下：

　　A、深度熟悉被测系统的业务、需求。

　　B、对被测系统或类似系统之前的缺陷分布情况进行过系统的分析。包括功能缺陷，数据缺陷，接口缺陷和界面缺陷等等。

　　3、测试用例举例

　　（1）聊天窗口功能

　　A、输入特殊字符（全角，半角）后，窗口是否能够正常显示

　　B、输入空格，是否能够过滤，是否会算入长度计算

　　C、输入html字符

　　D、输入脚本语言函数

　　E、在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容是否能够通过

　　（2）查询功能

　　A、无条件查询

　　B、是否支持模糊查询

　　C、查询的关键字之间是否可用连接符

　　D、输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

　　（3）登录功能

　　A、输入的数据前存在空格，是否能够正常登录

　　B、输入的密码是否能够加密显示

　　C、用户在注销之后是否能够再登录成功

　　4、优缺点

　　优点：充分发挥个人的经验和潜能，命中率高

　　缺点：覆盖率难以保证；过多的依赖于个人的经验

 

功能测试用例设计积累（三）：正交表分析与实践

关键字：功能测试、测试用例、正交表、正交试验法、软件测试方法

　　OATS正交表测试策略

　　在上面的文章中，Zee已详细讲述了正交试验设计方法的概念、优点以及如何将此方法运用到用例设计当中的具体步骤，这里不再赘述。

　　由于在设计测试用例当中经常会用到这个方法，我把搜集到的几个文档放在这里。

　　关注点：

　　1、运用正交试验法设计测试用例时遇到的几种情况和解决方法：

　　1）因素数、水平数与正交表相符

　　2）因素数不同

　　3）水平数不同

　　2、用正交表设计测试用例的步骤：

　　1）确定因素（变量）数

　　2）确定每个因素的水平数

　　3）选择一个合适的正交表，不同的正交表生成的用例数会有很大的差别。需要让正交表尽量和因素数和水平数吻合，因素数肯定是要一致，水平数要考虑出现最多的水平数

　　4）将变量的具体取值映射到正交表中

　　5）将每一行数据的组合抽取出来，形成测试用例

　　6）再次分析（用错误推测法）可能需要测试的数据组合（查漏补缺），添加到测试用例当中

　　3、正交表查询地址：

　　http://www.york.ac.uk/depts/maths/tables/orthogonal.htm

 

功能测试用例设计积累（四）：在没有需求文档的情况下如何设计测试用例

 

　　“测试用例应该依照需求文档来开发，但是我们的项目根本就没有需求文档？那测试用例该如何开发呢？”

　　1、根据客户的功能点整理测试需求追朔表：

　　一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

　　2、根据开发人员的Software Specification List整理我们的功能测试点：

　　一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

　　3、开展项目跨部门讨论会：

　　可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

　　4、测试人员整理用例需求疑问递交项目组和客户代表回复：

　　测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

　　5、项目内部用例评审：

　　测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

　　6、邮件和客户代表确认部分争议问题：

　　测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

　　7、项目Demo和部分已开发系统：

　　大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

　　8、参考同行业和竞争对手的类似产品：

　　假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

　　9、交叉模块的测试，最容易被人忽略：

　　一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

　　10、可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：

　　我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

 

功能测试用例设计积累（五）：等价类划分法分析与实践

关键字：功能测试、测试用例、等价类划分法

　　1、方法定义：

　　从软件测试的角度来说，等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。等价类划分包含两个部分：有效等价类和无效等价类。

　　1） 有效等价类

　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。主要为了检验程序是否实现了规格说明中所规定的功能和性能。

　　2） 无效等价类

　　与有效等价类相反，主要为了程序的健壮性与可靠性。

　　2、方法运用到用例设计中的思路：

　　1） 根据需求说明书，把需要输入的数据划分成若干个子集合。在这里要确保两点：

　　A、每个子集中的数据在测试过程中对于发现程序缺陷是有效的。

　　B、每个子集中的数据在测试过程中对于发现程序缺陷是等效的。

　　C、子集之间数据互不相交。

　　2） 然后从每个集合中选择部分代表性数据形成测试用例中的输入数据。

　　3） 覆盖所有有效的和无效的等价类

　　3、确定等价类的原则

　　1） 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

　　例如：成年人每分钟的心跳60-100之间为正常。

　　有效等价类：60-100 无效等价类：<60 和 >100

　　2） 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

　　例如：用户连续输入错误密码的次数最多为3次。

　　有效等价类：<=3次 无效等价类：>3次

　　3） 在输入条件是一个布尔量的情况下，可确定一个有效等价类。

　　例如：单选的选中与不选中。

　　4） 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

　　例如：输入数据为省份的选择。

　　5） 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

　　例如：规定必须输入非0的正整数。

　　这种例子应充分考虑规则是否可以拆分为具有单一的子规则，然后得到从不同角度违反规则的无效等价类。

　　该例子起码可拆分为非0、数字、正数、整数4个子规则，至少每个规则对应一个无效等价类，即0、字符串、负数、小数，甚至可挖掘出输入为空的隐含等价类。

　　6） 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

　　例如：核对日期的有效性，初步有效等价类是1<=Month<=12，1<=Day<=31

　　可是考虑到2月以及闰年、闰月、长月、短月等，需要进一步细分，当然其中还涉及到了年月日组合的问题。

　　4、测试用例举例

　　竞猜系统中：投注的金额要求是大于10的正整数。

　　根据分析等到以下等价类表。

输入条件	有效等价类	无效等价类
>10的正整数	大于10的正整数	空 小数 <10的数 负数 字符串

　　5、优缺点

　　优点：避免了盲目或随机选取输入数据的布完整性和覆盖的不稳定性

　　缺点：没有对组合情况进行充分的考虑，需要结合其他测试用例设计的方法进行补充

 

功能测试用例设计积累（六）：在敏捷测试中如何设计用例

关键字：功能测试、测试用例、敏捷测试

　　敏捷宣言：

　　个体和交互比过程和工具更有价值；

　　能工作的软件比全面的文档更有价值；

　　顾客的协作比合同谈判更有价值；

　　及时响应变更比遵循计划更有价值。

　　并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。测试用例的设计是其中一项。

　　1、测试用例的粒度

　　测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。

　　测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

　　测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

　　大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

　　软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

　　2、基于需求的测试用例设计

　　基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

　　要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

　　不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

　　3、测试用例的评审

　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

　　因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

　　4、测试用例数据生成的自动化

　　在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

　　很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

　　可利用一些工具，例如TConfig、PICT等来产生这些数据。

　　在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。

　　工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。

 

　　软件测试之功能测试用例的设计方法：

　　1.等价类划分法：

　　有效等价类：指输入完全满足程序输入的规格说明，是由有效且有意义的输入数据所构成的集合，利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。

　　无效等价类：和有效等价类相反，即不满足程序输入要求或者由无效的输入数据构成的集合。

　　2.边界值分析法：

　　指对输入的边界条件进行分析，设计出针对边界值的测试用例。

　　数值的边界值检验

　　字符的边界值检验

　　如： ASCII和 Unicode编码方式

　　其他边界值检验

　　选上所有选项（最大值）

　　不选上任何一项（空，零）

　　只选一项 （最小值）

　　3.因果图法：

　　就是利用图解法分析软件输入（原因）和输出条件（结果）之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

　　4.功能图法：

　　功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

　　5.错误推测法：

　　推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例。

　　6.正交实验设计方法：

　　主要步骤是：

　　（1）对软件需求规格说明中的功能要求进行划分（层层分解与展开），分解成具体的、相对独立的基本功能。

　　（2）根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。

　　（3）确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。

　　权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。

　　（4）加权筛选，生成因素分析表。

　　（5）利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。

　　利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。

　您在做测试设计时是否发现自己写的测试用例超多，但却发现不了几个bug？是否发现经过您的测试之后，还是有较多问题漏测试？本文将大概介绍一下如何避免此类问题的思路。

　　当您拿接到一个产品/项目拿到需求后，您需要对这个产品的需求进行分析/分解，写出测试方案，然后根据测试方案写测试用例，这就是测试设计的流程。如何避免上面提到的问题，我们就得从需求-->方案-->用例一步一步来分析。

　　拿到需求文档后，我们要分析此次的产品/项目 新增、修改、删除那些功能，修改、删除时对原来功能会有什么影响，此时您需要把功能及影响一条一条的列出。

　　列出完之后，在方案时就得考虑各种不同的分析方法的应用了，如下：

　　1、首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类，这是减少工作量和提高测试效率最有效的方法。

　　2、必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。

　　3、可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。

　　4、对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。

　　5、如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。

　　6、对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

　　7、对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。

之前做过一个框架是由一个excel表来控制性能监控的运行以及运行参数，并且把测试结果也保存excel表中。这样做的优点在于框架简单，需要投入的时间少。但是，由于对excel的读写操作有着速度较慢，需要多处定位等问题存在，感觉不是很好，因此进行重新做了这个B/S架构的框架。

　　我是这样做的：

　　1、获取数据：

　　使用ruby调用httpwatch，进行修改，已达到自己需要的需求，获取页面性能的数据（整体页面下载时间，各页面元素的下载时间）。这里的修改是要注意的，我就在这遇到过有些页面要采集数据，有些不需要采集，而ie浏览器是不能改变的，因此需要对其做不少修改。

　　首先，由于之后一连串的页面监控都需要在一个ie中实现（涉及到登录权限等操作），因此先新建一个ie_init的方法来初始化ie：

def ie_init @ie = Watir::IE.new end

　　然后把打开url的方法分为2种，其中1个为需要进行采集页面性能数据及页面元素参数的方法open_page(link)，1个位不需要进行采集数据，只是普通操作的方法gotourl(link)。其中，open_page这个方法，需要调用httpwatch控件，同时要加入连接数据库的一个文件oracle(自己写，调用dbi.rb即可，主要内容为往数据库插采集下来的数据)，代码很简单：

def insert1(字段) dbh = DBI.connect('DBI:OCI8:SID', 用户名, 密码) sql1 = sql       dbh.do(sql1,字段) dbh.commit dbh.disconnect

　　上面是插入操作，所以需要commit，其他的一些如更新等也需要，其他如select则不需要。

　　数据采集是在原有的基础上自己加需要的，我加了很多需要的数据，然后将采集下的数据存入oracle中。

　　最后加一个ie_close方法来关闭ie。

　　2、数据存储及分析：

　　把这些采集到的数据都写入oracle数据库（需要安装oci8,我用的oracle版本是10g），在数据库建立2张关联的表，一张用来存放整个性能点的数据，如url、总体的下载时间、错误数、发送及接收到的字节数等。一张表用来存放每个监控点的页面元素信息（这个量是很大的，往往一个页面一次会下载 60-200个左右的页面元素，一次运行下来，性能点多些的话，就有几千个数据，每5-10分钟自动运行一次，一天下来的量…………嘿嘿，不少吧），主要是些采集时间（这个是和前面一张表关联的字段）、元素链接、元素的下载时间、元素开始下载的时间（在分析性能问题的时候很有用）、httpcode、元素类型（对页面调优、瘦身等意义很大）。

　　3、数据展现：

　　当ruby与oracle都弄好了，进行调试，需要的数据都进入数据库了，那么接下来就开始做页面客户端了。为什么要用页面客户端呢?在web上，人人都可以访问你的结果页面，鼠标轻点，就可以自动生成自己想要的图表数据。我使用的是tomcat，配置起来超级简单。图表生成我用的是open- flash-chart-1.9.7，这个东东做出来的图表很好看，也比较好用，鼠标垫在曲线上，可以显示出该点数据。总而言子，易用又美观。还有一点要注意的是，数据列表展现的时候，一定要做分页。否则一大堆数据显示出来，你的浏览器要卡死的（特别是现实页面元素，那个恐怖啊，我吃亏过）。

　　4、自动执行自动化脚本：

　　自动化脚本如何进行自动执行呢？我这里提供了2种方法：

　　1）把自动化脚本做成一个exe文件，然后通过页面调用这些exe文件来进行执行，具体方法如下

Runtime runtime = Runtime.getRuntime(); 　　runtime.exec("D:/fun2.exe");

　　2）将自动化脚本放置在windows自带的计划任务中，设置好后可以循环执行。

 

 

测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

OMV r[(bU0

  这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。51Testing软件测试网:qvbcR&h f9P

（一）  先说测试计划吧51Testing软件测试网.L vXSH(cb-Z

诚如magic_zhu所言，现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写？这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。51Testing软件测试网/Y1YIFQt-s4J:F{5_

我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。

/TN7F2}eN;a#EI `|q ?0

一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。51Testing软件测试网0e8VG\aa!sBM

作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。

k'N7NBPg0

除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。

F$f | br)Uo6L`0

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：51Testing软件测试网-rm{V3}z:y*R

a.  上面提到的三要素不能少51Testing软件测试网v+Q|3W#}n0Go(c/F'i4C

b.  测试策略一定要交待清楚，就是大概怎么测试51Testing软件测试网SA:b"K`b'i

c.  需要其他人员（部门）协调的，要交待清楚51Testing软件测试网'N x.j(ul p;wz

d.  在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数51Testing软件测试网 j@ b\D3F

e.  测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚51Testing软件测试网p"~'ge'S7XJ

f.  测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check51Testing软件测试网'N-}5a7s7@|*Q

g.  一定要有风险控制，要不然计划缺乏可执行性51Testing软件测试网.^4EY5| ^ G5w.S-O

h.  计划写完之后不是装在兜里，要组织PM和Dev进行评审51Testing软件测试网)us-XO ~ Z2Zbh[

i.  要不断更新计划，记住：每个计划都是动态的，不是一成不变的51Testing软件测试网5NTu$jL"l2jS S

（二）  再说测试用例

Fx(`UYSZW ]U0

和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。51Testing软件测试网G p!`o_Oi
g D

下面我就个人体会谈谈做好测试用例的关键。51Testing软件测试网k.n0B1MeU7e

首先，在做用例之前，要做两件事情。

.G"z'h+Q t2c9X.|4w0

第一，  透彻了解程序（需求和架构）。51Testing软件测试网Lv_/xnr(L

第二，  做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）51Testing软件测试网Bu$tn-_1s

一般来说，设计一个比较实用的测试用例，注意如下几个方面：51Testing软件测试网
M)wP&P4}

a.  选用好的用例管理工具（这个很重要，千万不要用word，excel）

bX0Y"|cxu0f0

b.  用例一定要及时更新（补充新的想法，删除过时的需求）

v:}{"Zl+`;s*ix"i0

c.  做好用例分级

"V#sn c2Q)`0

d.  做好用例评审，写用例之前可以征询相关人员的意见51Testing软件测试网Up_o"Wv XZ

e.  可以考虑结对编写，这个是不错的主意51Testing软件测试网&uqDFF/Tpp

f.  要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

7L*jX$^4R%n r0

g.  注意把握适当的颗粒度

　1、总计架构测试

　　1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。

　　2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。

　　2、Web架构组成部分是否满足需求

　　成本、功能、安全性要求、容量要求、传输实时性。

　　3、服务器配置分布是否满足要求

　　Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。

　　4、客户端设计测试

　　1）功能设置测试：信息服务、办公自动化、Internet支持；

　　2）信息组织结构测试：线性结构、分层结构、非线性结构；

　　3）页面设计测试：

　　a) 页面一致性测试

　　b) 用户界面友好性及导航直观性测试；、

　　c) 是否适合多种浏览器；

　　d) 页文件的命名；

　　e) 页面布局技术。

　　5、服务器端设计测试

　　1）容量规划测试：点击率、延迟和流量、服务器资源；

　　2）系统安全测试：

　　a) 常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等；

　　b) 使用加密技术；

　　c) 构造防火墙，网络级、应用级、电路级；

　　d) 构建网络防毒体系。

　　3）数据库设计测试。

　　6、Web开发测试

　　1）源代码分析，主要是使用检查工具来完成；

　　2）链接测试，主要借助工具来完成；

　　3）框架测试：

　　a) 自动调整窗口大小；

　　b) 是否提供滚动条；

　　c) 打开新页面是否正常。

　　4）表格测试，随窗体变化自动调整大小；

　　5）图形测试：

　　a) 颜色饱和度及对比度；

　　b) 链接标识；

　　c) 图形显示是否正确。

　　7、与一般应用软件相比，Web测试有以下区别：

　　第一、Web测试的侧重点是性能、安全、易用性、兼容

　　第二、测试工具有所不同，如链接测试、表单测试、界面测试

　　8、功能测试

　　1）客户端的选择，优先测试流行的客户客户端；

　　2）客户端浏览器的配置

　　3）客户端的显示设置

　　4）内容测试

　　9、链接测试

　　1）该链接将用户带到它所说明的地方

　　2）被链接的页面是存在的

　　3）保证没有孤立页面

　　工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

　　10、链接测试工具的优势：

　　1）简单易用

　　2）在实现上采用多线程技术，检查速度特别快；

　　3）对断开的链接可以再次测试，可以避免误判；

　　4）没有检查链接的数量限制，只受系统资源的约束；

　　5）可以分析Web应用的结构；

　　6）检查结果可以分类查看，自动生成HTML格式的报告；

　　11、Web应用链接主要测试点如下

　　1）测试内部链接和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；

　　2）测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；

　　3）分析Web应用的结构是否合理，包括显示和某个URL相关的链接以及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。

　　12、易用性测试

　　易用性测试要考虑以下几个方面：

　　1）用户的计算机使用经验；

　　2）用户对浏览器以及Web的使用经验；

　　3）用户的业务专业知识。

　　13、Web系统的易用性测试分为三个方面：

　　1）界面测试

　　2）辅助功能测试

　　3）图形测试

　　● 界面测试要考虑以下几个问题

　　A．WEB应用系统的最终用户群是谁？

　　B．WEB应用界面的设计策略是什么？

　　C．页面中各元素布局的协调性

　　a) 各元素位置的协调性

　　b) 各元素颜色的协调性

　　c) 各元素大小比例的协调性

　　D．不同页面风格的统一性

　　E．用户在界面中操作的便利性

　　F．界面动态操作测试

　　a) 屏幕分辩率设置的影响

　　b) 浏览窗口最大化/最小化的影响

　　c) 选定目标元素的置中与缩放

　　● 辅助功能测试

　　A．使用说明，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容

　　B．导航功能

　　C．站点地图

　　D．帮助，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容

 

数据库测试
   随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。

　　数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试。

　　从测试过程的角度来说我们也可以把数据库测试分为：

　　系统测试

　　传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。

　　这个阶段我们的测试主要通过数据库设计评审来实现。

　　集成测试

　　集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是：

　　数据项的修改操作；
　　数据项的增加操作；
　　数据项的删除操作；
　　数据表增加满；
　　数据表删除空；
　　删除空表中的记录；
　　数据表的并发操作；
　　针对存储过程的接口测试；
　　结合业务逻辑做关联表的接口测试；
　　同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。

　　单元测试

　　单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。

　　而我们也可以从测试关注点的角度对数据库进行分类：

　　功能测试
　　对数据库功能的测试我们可以依赖与工具进行。

　　DBunit
　　一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。

　　QTP
　　大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。

　　DataFactory
　　一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。

　　数据库性能

　　虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能。

　　性能优化分4部分：

　　1.物理存储方面
　　2.逻辑设计方面
　　3.数据库的参数调整
　　4.SQL语句优化

　　我们如何对性能方面进行测试呢，业界也提供了很多工具。

　　通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。

　　Loadrunner
　　这个不用多说，我们可以通过对协议的编程来对数据库做压力测试。

　　Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）

　　数据库厂商也意识到这点，例如：

　　oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。

　　还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。

　　安全测试

　　软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端。自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。

　　对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点，我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求.

Mercury QuickTest Professional™是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。

Mercury QuickTest Professional为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

QuickTest Professional是新一代自动化测试解决方案，采用了关键词驱动（Keyword-Driven）测试的理念，能完全简化测试的创建和维护工作。QuickTest关键词驱动方式独有之处在于，测试自动化专家可以通过一个整合的脚本和纠错环境，拥有对基础测试脚本和对象属性的完全访问权限，这些脚本和纠错环境与关键词视图（Keyword View）可以互为同步。

QuickTest Professional同时满足了技术型和非技术型用户的需求，让各个公司有能力部署更高质量的应用，同时部署的速度更快，费用更低，风险也更小。QuickTest Professional和我们新的测试自动化系统Mercury Business Process Testing™的紧密结合，可以将非技术型的业务专家（SME, Subject-Matter Experts）引入质量流程，这一意义重大的引入可以将IT和业务更好地融合，最终建立起更出色的应用。

有了该产品，您的QA机构可以获取多方面的优势：
        用最少的培训赋予整个小组创建成熟测试方案的能力。
        确保跨所有环境、数据包和业务流程的正确功能点。
        为开发人员全面记录和复制缺陷，使他们能更快地修复缺陷，满足最后上线期限。
        对不断变化的应用和环境展开便捷的回归测试。
        成为帮助整个机构实现高质量产品和服务、提高总收入和收益率的关键角色。

QuickTest Professional是如何工作的
QuickTest Professional易于操作，即使是初级的测试人员也能在短时间内对其驾轻就熟。您可以使用无需脚本的关键词视图来表现测试的每个步骤，仅由此就可创建一个测试。您还可以通过QuickTest Professional所集成的录制能力来捕获测试步骤。该产品用简单的英语以文档形式记录每个步骤，并通过活动屏幕将文档与一个集成截屏相结合。传统的脚本记录工具所生产的脚本不易修改，与此不同的是，QuickTest Professional的关键词驱动方式能让您便捷地插入、修改、数据驱动（data-drive）和移除测试步骤。

QuickTest Professional可以自动引入检查点来验证应用的属性和功能点，比如确认输出量或检查链接的有效性。在关键词视图的每一步骤中，活动屏幕可显示被测应用在该步骤中的确切状态。您还可以为任意对象加入几种检查点，仅仅在活动屏幕中点击该对象，就可以验证该组件行为是否达到了期望值。

然后您可以将测试数据输入数据表（Data Table），它拥有和Excel同样完善的功能特性，是一个集成的电子数据表格。您可以使用数据集并创建多种重复测试，无需编程就可以扩展测试案例的覆盖面。数据可以通过键入的方式输入或从数据库、数据表格或文本文档中导出。

高级测试人员可以在专家视图（Expert View）中查看和修改他们的测试，在专家视图中显示了由QuickTest Professional自动生成的基于行业标准的基本VBscrīpt语言。在专家视图中所做的任何改动将自动与关键词视图同步。

一旦测试人员运行了一个脚本，TestFusion报告将显示测试运行各方面的信息，包括：高水平的结果纵览；一个可扩展的测试脚本树状视图（Tree View），其明确指出了应用错误的发生位置；被使用的测试数据；每个步骤的应用截屏，其中并标明了所有的差异；以及通过或未通过每个检查点的详细解释。您可以将TestFusion报告和QuickTest Professional结合，从而与整个QA和开发小组分享这些报告。

QuickTest Professional处理一些应用的新版本问题。当一个被测应用发生变化时，比如把一个”Login”按钮被改名为”Sign in”，您可以在共享对象容器（Shared Object Repository）中做一次更新，接着此次更新将扩展到所有涉及这个对象的脚本。您可以将测试脚本公布给Mercury Quality Management，使其它的QA小组成员也可以使用您的测试脚本，从而减少了重复工作。

通过与Business Process Testing的整合，在一个基于Web的系统中，QuickTest Professional被用于实现自动化操作，使非技术型用户可以便捷地在一个完全的无脚本环境中也能够建立起测试。

QuickTest Professional支持多种企业环境的功能测试，包括Windows、Web、.NET、 Java/J2EE、SAP、Siebel、Oracle、PeopleSoft、Visual Basic、ActiveX、Mainframe terminal emulators和Web services。

Mercury功能测试
那些在Mercury WinRunner®测试工具上投入大量资金，并想转入Mercury QuickTest Professional™的用户，可以使用Mercury Functional Testing™来实现这种转变。Mercury Functional Testing将QuickTest Professional和WinRunner结合成一种集成产品，它不仅可以使用WinRunner脚本，也可以使用QuickTest Professional脚本，使测试资源得到极大地利用。质量工程师可以使用Mercury Functional Testing来创建“复合脚本”测试，这些脚本是在WinRunner和QuickTest Professional中建立的。Mercury Functional Testing是WinRunner和QuickTest Professional的集成，产品间可以相互调用脚本，测试结果可以在一个共有的报告界面上呈现。

Mercury质量中心的组成部分之一
Mercury QuickTest Professional是Mercury质量中心（Mercury Quality Center™）的组成部分之一，Mercury质量中心集成了一整套软件、服务和最佳实践，用于自动化关键质量活动，包括需求管理、测试管理、缺陷管理、功能测试和业务流程测试。

特点和优势
        具有行业 Mercury QuickTest Professional™是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。

Mercury QuickTest Professional为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

QuickTest Professional是新一代自动化测试解决方案，采用了关键词驱动（Keyword-Driven）测试的理念，能完全简化测试的创建和维护工作。QuickTest关键词驱动方式独有之处在于，测试自动化专家可以通过一个整合的脚本和纠错环境，拥有对基础测试脚本和对象属性的完全访问权限，这些脚本和纠错环境与关键词视图（Keyword View）可以互为同步。

QuickTest Professional同时满足了技术型和非技术型用户的需求，让各个公司有能力部署更高质量的应用，同时部署的速度更快，费用更低，风险也更小。QuickTest Professional和我们新的测试自动化系统Mercury Business Process Testing™的紧密结合，可以将非技术型的业务专家（SME, Subject-Matter Experts）引入质量流程，这一意义重大的引入可以将IT和业务更好地融合，最终建立起更出色的应用。

有了该产品，您的QA机构可以获取多方面的优势：
        用最少的培训赋予整个小组创建成熟测试方案的能力。
        确保跨所有环境、数据包和业务流程的正确功能点。
        为开发人员全面记录和复制缺陷，使他们能更快地修复缺陷，满足最后上线期限。
        对不断变化的应用和环境展开便捷的回归测试。
        成为帮助整个机构实现高质量产品和服务、提高总收入和收益率的关键角色。

QuickTest Professional是如何工作的
QuickTest Professional易于操作，即使是初级的测试人员也能在短时间内对其驾轻就熟。您可以使用无需脚本的关键词视图来表现测试的每个步骤，仅由此就可创建一个测试。您还可以通过QuickTest Professional所集成的录制能力来捕获测试步骤。该产品用简单的英语以文档形式记录每个步骤，并通过活动屏幕将文档与一个集成截屏相结合。传统的脚本记录工具所生产的脚本不易修改，与此不同的是，QuickTest Professional的关键词驱动方式能让您便捷地插入、修改、数据驱动（data-drive）和移除测试步骤。

QuickTest Professional可以自动引入检查点来验证应用的属性和功能点，比如确认输出量或检查链接的有效性。在关键词视图的每一步骤中，活动屏幕可显示被测应用在该步骤中的确切状态。您还可以为任意对象加入几种检查点，仅仅在活动屏幕中点击该对象，就可以验证该组件行为是否达到了期望值。

然后您可以将测试数据输入数据表（Data Table），它拥有和Excel同样完善的功能特性，是一个集成的电子数据表格。您可以使用数据集并创建多种重复测试，无需编程就可以扩展测试案例的覆盖面。数据可以通过键入的方式输入或从数据库、数据表格或文本文档中导出。

高级测试人员可以在专家视图（Expert View）中查看和修改他们的测试，在专家视图中显示了由QuickTest Professional自动生成的基于行业标准的基本VBscrīpt语言。在专家视图中所做的任何改动将自动与关键词视图同步。

一旦测试人员运行了一个脚本，TestFusion报告将显示测试运行各方面的信息，包括：高水平的结果纵览；一个可扩展的测试脚本树状视图（Tree View），其明确指出了应用错误的发生位置；被使用的测试数据；每个步骤的应用截屏，其中并标明了所有的差异；以及通过或未通过每个检查点的详细解释。您可以将TestFusion报告和QuickTest Professional结合，从而与整个QA和开发小组分享这些报告。

QuickTest Professional处理一些应用的新版本问题。当一个被测应用发生变化时，比如把一个”Login”按钮被改名为”Sign in”，您可以在共享对象容器（Shared Object Repository）中做一次更新，接着此次更新将扩展到所有涉及这个对象的脚本。您可以将测试脚本公布给Mercury Quality Management，使其它的QA小组成员也可以使用您的测试脚本，从而减少了重复工作。

通过与Business Process Testing的整合，在一个基于Web的系统中，QuickTest Professional被用于实现自动化操作，使非技术型用户可以便捷地在一个完全的无脚本环境中也能够建立起测试。

QuickTest Professional支持多种企业环境的功能测试，包括Windows、Web、.NET、 Java/J2EE、SAP、Siebel、Oracle、PeopleSoft、Visual Basic、ActiveX、Mainframe terminal emulators和Web services。

Mercury功能测试
那些在Mercury WinRunner®测试工具上投入大量资金，并想转入Mercury QuickTest Professional™的用户，可以使用Mercury Functional Testing™来实现这种转变。Mercury Functional Testing将QuickTest Professional和WinRunner结合成一种集成产品，它不仅可以使用WinRunner脚本，也可以使用QuickTest Professional脚本，使测试资源得到极大地利用。质量工程师可以使用Mercury Functional Testing来创建“复合脚本”测试，这些脚本是在WinRunner和QuickTest Professional中建立的。Mercury Functional Testing是WinRunner和QuickTest Professional的集成，产品间可以相互调用脚本，测试结果可以在一个共有的报告界面上呈现。

Mercury质量中心的组成部分之一
Mercury QuickTest Professional是Mercury质量中心（Mercury Quality Center™）的组成部分之一，Mercury质量中心集成了一整套软件、服务和最佳实践，用于自动化关键质量活动，包括需求管理、测试管理、缺陷管理、功能测试和业务流程测试。

特点和优势
        具有行业领先的便于使用的特性，以及支持提前配置环境的功能，确保了快速的投资回报。
        可独立运行，也可以同Mercury Business Process Testing和Mercury质量中心集成。
        引进了QuickTest Professional 8.0中新一代的“零配置”关键词驱动测试技术，从而实现了快速建立测试、测试脚本更易维护，和更强大的数据驱动能力。
        使用独特智能对象识别（Unique Smart Object Recognition）来发现对象，即使对象创建不断在改变，但仍可保证无监控方式脚本执行的可靠性。
        恢复管理器（Recovery Manager）可处理不可预知的应用意外事件，实现24x7的不间断测试，赶上测试项目的最后期限。
        自动文档技术把测试文档的建立与测试脚本的建立同步。
        通过集成的数据表，可数据驱动任意对象、方式、检查点和输出值。
        为QA工程师提供全面的集成开发环境。
        通过使用QuickTest Professional和WinRunner集成的TSL资源，使您在Mercury WinRunner测试脚本上的投资得以保值。
        TestFusion报告可快速隔离和诊断缺陷。
        通过完善检查点，实现应用的全面验证。 
领先的便于使用的特性，以及支持提前配置环境的功能，确保了快速的投资回报。
        可独立运行，也可以同Mercury Business Process Testing和Mercury质量中心集成。
        引进了QuickTest Professional 8.0中新一代的“零配置”关键词驱动测试技术，从而实现了快速建立测试、测试脚本更易维护，和更强大的数据驱动能力。
        使用独特智能对象识别（Unique Smart Object Recognition）来发现对象，即使对象创建不断在改变，但仍可保证无监控方式脚本执行的可靠性。
        恢复管理器（Recovery Manager）可处理不可预知的应用意外事件，实现24x7的不间断测试，赶上测试项目的最后期限。
        自动文档技术把测试文档的建立与测试脚本的建立同步。
        通过集成的数据表，可数据驱动任意对象、方式、检查点和输出值。
        为QA工程师提供全面的集成开发环境。
        通过使用QuickTest Professional和WinRunner集成的TSL资源，使您在Mercury WinRunner测试脚本上的投资得以保值。
        TestFusion报告可快速隔离和诊断缺陷。
        通过完善检查点，实现应用的全面验证。 

性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试项目由于性能测试需求定义不合理或不明确，导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进行科学、准确的评估。
1 引言
基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。
在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。
1.1 术语定义
性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。
虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。
请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。
吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。
1.2 Web应用系统技术架构
Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。
2 Web应用系统性能测试过程
标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。
2.1 确定性能测试需求
科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。
2.1.1 基于在线用户的性能测试需求
该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。
2.1.2 基于吞吐量的性能测试需求
该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
2.2 开发性能测试脚本
在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。
性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。
任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。
在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。
此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。
2.3 建立性能测试负载模型
性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：
虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。
虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。
虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。
2.4 执行性能测试
执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。
2.5 形成性能测试报告
性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。
针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。
图一：在线用户数和响应时间时间的趋势图
针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。
图二：响应时间、吞吐量和并发用户数的趋势图

   基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。

　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。

　　在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就　　会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

　　一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

　　网站测试流程、要求及测试报告

　　一个网站基本完工后，需要通过下面三步测试才可以交活。

　　一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

　　a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

　　b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

　　二、 全面测试 根据交工标准和客户要求，由专人进行全面测试

　　也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。

　　三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误

软件缺陷的原则

　　软件缺陷区别于软件bug，它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等；
　　软件未达到产品说明书标明的功能；
　　软件出现了产品说明书指明不会出现的错误；
　　软件功能超出产品说明书指明范围；
　　软件未达到产品说明书虽未指出但应达到的目标；
　　<a href="http://www.51testing.com/" target="_blank">软件测试</a>员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

　　测试的主要方面：

　　一、功能测试

　　对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：

　　1)测试所有链接是否按指示的那样确实链接到了该链接的页面;

　　2)测试所链接的页面是否存在;

　　3)保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　Xenu------主要测试链接的正确性的工具

　　可惜的是对于动态生成的页面的测试会出现一些错误。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

　　B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。

　　我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

　　在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

二、性能测试

　　网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。

　　网站的性能测试主要从三个方面进行：连接速度测试、负荷测试(Load)和压力测试(Stress),

　　连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。

　　1、连接速度测试

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2、负载测试

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

　　3、压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　采用的测试工具：

　　性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具

　　ab -----Apache 的测试工具

　　OpenSTA—开发系统测试架构

三、接口测试

　　在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、

　　验证数据或提交订单。

　　1、 服务器接口

　　第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器

　　记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

　　2、 外部接口

　　有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行

　　为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

　　3、错误处理

　　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错

　　误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况?

　　订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服

　　务器的连接。在这些情况下，系统能否正确处理这些错误?是否已对信用卡进行收费?如果

　　用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致

　　电用户进行订单确认。

四、可用性测试

　　可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　(2)验证所有页面字体的风格是否一致。

　　(3)背景颜色应该与字体颜色和前景颜色相搭配。

　　(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

五、兼容性测试

　　需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

　　采用测试工具：

　　通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。

　　3.视频测试

　　页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

　　4.Modem/连接速率测试

　　是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测

　　试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，

　　但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

　　5、打印机测试

　　用户可能会将网页打印下来。因此网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

　　6、组合测试

　　最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容

　　机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。

　　如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，

　　那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。

　　(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能

　　在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，

　　系统能在所有机器上运行，这样就不会限制将来的发展和变动。

六、安全测试

　　Web应用系统的安全性测试区域主要有：

　　1、 目录设置

　　Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页

　　面，这样就不会显示该目录下的所有内容。如果没有执行这条规则。那么选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。但是进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中有些都是已过期页面。如果该公司每个月都要更改产品价格信息，并且保存过期页面。那么只要翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

　　2.登录

　　现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　3.Session

　　Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。

　　4.日志文件

　　为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　5.加密

　　当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　6.安全漏洞

　　服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，

　　工具如下

　　SAINT------- Security Administrator’s Integrated Network Tool

　　此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。

七、代码合法性测试

　　代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查。

　　1、程序代码合法性检查

　　程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。

　　2、显示代码合法性检查

　　显示代码的合法性检查，主要分为Html、Javascrīpt、Css代码检查，目前采用

　　HTML代码检查------采用CSE HTML Validator进行测试

　　Javascrīpt、Css也可以在网上下载相应的测试工具。

　　八、 文档测试

　　l、产品说明书属性检查清单

　　1)完整.是否有遗漏和丢失，完全吗? 单独使用是否包含全部内容

　　2)准确.既定解决方案正确吗? 目标明确吗? 有没有错误?

　　3)精确、不含糊、清晰.描述是否一清二楚? 还是自说自话?容易看懂和理解吗?

4)一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突

　　5)贴切.描述功能的陈述是否必要?有没有多余信息? 功能是否原来的客户要求?

　　6)合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?

　　7)代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码

　　8)可测试性.特性能否测试? 测试员建立验证操作的测试程序是否提供足够的信息?

　　2、 产品说明书用语检查清单

　　1)说明。 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.

　　2)总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.

　　3)当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.

　　4)某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.

　　5)等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.

　　6)良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.

　　7)已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.

　　8)如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

　　相关的测试工具

　　OpenSTA

　　主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。

　　SAINT

　　网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。

　　CSE HTML Validator

　　一个有用的对于HTML代码进行合法性检查的工具

　　Ab(Apache Bench)

　　Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。

　　Crash-me

　　Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。