我们常说，测试人 员，不仅仅要懂测试，还有懂业务，那对咱们来说，什么叫懂业务呢？——我们的用例来源大部分是产品文档，如果说，能够把产品文档落实到case上就算懂业 务了对不对？——相信咱们team的同学一定记得咱们常常说的那句话，只是懂产品文档对我们的测试人员来说是远远不够的。。。

　　如果要成为对咱们的产品、业务最熟悉的人，需要做到几个层次：

　 　首先，除了产品文档描述的功能之外，你是否了解你所负责的项目的内外部接口？——这里的接口是指功能上的接口，比如我在pc客户端也可以往空间上传照 片，这就是空间对pc的外部接口，比如我在论坛能够发帖转到空间，那这是空间的内部接口。这是我们对咱们自己的产品了解的第一个层次。

　　 第二个层次，还是有关接口，但是这个接口则是落实到程序上的。还是打个比方，在功能上说，我开通飞信、关闭飞信是两个功能点，但是很有可能是一个程序接口 来完成的。那么，对于这些程序接口的了解，对我们设计用例的简洁性和效率提高上，将是非常有作用的。——那这些接口怎么来了解到呢？两个方式咯，书面的也 就是开发设计文档，以及口头的传授，我们来总结。

　　第三个层次，是关于业务的整个数据的走向，比如，我发一篇日志可能会出现在几个地方？比如我的统计的一个数字会在统计系统中影响到哪些数据。这些就是数据层面的知识，谁能说这些不是关于业务的呢？

　　第四个层面，则是要落实在用户交互上，对于我们这种互联网性质的产品，用户交互千变万化，如何在这些复杂的交互中科学的设计用例，将是我们永恒追求的目标，当然，解决这些问题，还是有一些可以普遍试用的方法存在的，这也是我为什么让大家注意总结和提炼，也是为什么要推广咱们的正交试验法啦～

　 　第五，用户体验。我们要时刻明白，我们在测试的不是程序，而是有生命的产品～用户体验做的好不好直接影响到我们产出的结果是否被广大用户所接受。在这 里，用户体验怎么测对测试人员来说，才是一个大挑战，怎么既要站在功能点设计开发的角度，又要站在用户的角度设计case，是我们需要时刻思考如何转换思 维的～希望在这个挑战上，咱们能够多多总结，多多提炼～～

　　其实还有好多方面，一次写的有点多了，以后再慢慢补充，也欢迎大家来讨论。其实这些，归根到底是我们一直强调的风格，一手抓产品文档，一手抓设计文档，头顶用户体验，胸怀数据交互逻辑，——那，我们就人剑合一了～～～

燕子（化名）从前是学经济贸易的，由于对测试行业的强烈兴趣，毕业后在学校学习软件测试工程专业。工作不到一年的时间里，她已经从测试员升职到测试主管了。对于学习、工作，她积累了许多点点滴滴的经验，愿意与大家分享。

　　走入测试行业：兴趣、知识

　　说实话，我做测试工作的时间不是很长，学完软件测试工程师的课程后，到现在也就是一年多的时间吧，不过，我愿意自己学习和工作中积累起的这些点滴与大家分享。

　　我走入测试行业完全是因为兴趣，兴趣产生学习和工作的热情，真的是一点都不假。从我选择走入这个行业，学习、工作，从测试员到测试主管，我都是快乐的，也很充实，很有成就感。

　　我觉得，在决定走入测试行业后，就要在这方面多做准备和积累，首先要有坚实的测试理论基础，这些知识不仅是学习的时候要学的扎实，在以后的工作中还要继续不断的完善。其次，要有一定的行业知识。毕业后找工作时，有做手机测试的， 也有做外包测试的。我做的是ERP产品。大家都知道，ERP（Enterprise ResourcePlanning）就是企业资源计划系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平 台。我在学习测试专业前曾接触到ERP，所以，在毕业的找工作的时候就往这方面发展了。

　　说到找工作，我觉得精心制作简历是一方面，同时还要有灵活的面试技巧。有时还要把在生活中 学到的东西应用到面试中去。我记得我第一次去面试的时候比较凑巧，面试前的头天晚上我在电视里刚好看到一个和面试有关的节目，结果，第二天在我自己去面试 的时候就被我用到了。当时是在问到薪金待遇时。我觉得这是很多人包括我自己在面试时都会觉得是比较头疼的问题，因为，说的多了，不行；说的少了，也不行。 这时，你就要用一些技巧了。这时你可以先试探性的询问对方公司在招聘这个职位的时候是怎么规定的？等你了解了这些后，你再就自己的技术能力来衡量相应薪金 的比价，另外就是看这个公司的实力，还有一点就是行业内这个职位的大致待遇情况。这样的话，在你说出你对薪金的要求的时候，如果，应聘的公司较小，但是还 是存在一定发展空间而且你也想试试的情况下，你要得工资低，对方会考虑到可能是你已大致了解了公司的实力所以才开出这样的条件，而不是你自己的技术不行； 如果你看到这个公司的状况还是比较好的，是家有一定实力的公司，这时，你可以适当抬高自己的身价。

　　我的应聘还是比较顺利的，第一天应聘，第二天就上班了。我记得当时面试的时候大约谈了两个半小时，就一次性面试过关。另外我自己也比较引以自豪的是我是我们公司唯一一个在两个月之内转正的。

　　初来乍到：熟悉环境，尽快融入

　 　开始进入公司的时候首先要熟悉公司的环境。在一些大的公司可能会给大家熟悉环境的时间，还会安排一些相应的培训什么的。我当时进的那家公司比较小，没有 什么相关的培训，当初只是我们部门经理拿来一些相关的资料，文档，让网管给配置工作环境。不过小公司有小公司的好处，他会很快让你介入到工作当中，给你分 配任务。所以，你必须尽快的在一到两周之内熟悉公司各个方面的环境，尤其是人员环境。我觉得人际关系在整个公司里面也是很重要的一方面，夸张一点说甚至是 比你的本职工作还要重要的。因为，掌握技术是你智商方面的问题，而与人交往就不是那么简单，因为我们的兴趣、爱好可能差别很大，性格也有内向和外向的，所 以在进入社会步入工作岗位后与人交往真的是很考验一个人。如果你在公司人际关系搞得好的话，工作各方面的协调顺利，工作的进展也会很顺利。

　　还有就是要尽快的熟悉公司的测试环境，操作系统、 开发语言、平台，接着就是要了解公司的产品，掌握产品相关的知识。像我们公司是自己研发的经销群、财务这样的一个系统。你要了解公司产品的时候，可以向产 品研发部，或设计部要些相关的说明文档，尽快的介入这个行业，熟悉自己要做的测试项目。说实话，我是学习经贸专业的，不是学计算机的，所以我当初的时候有 点晕，我就直接拿着产品自己在那儿摸索，自己写出一个产品使用说明。向这样的事情，可能在大的公司会有专门的配选，在小公司可能就要自己学习产品了。不 过，我觉得这样是挺锻炼人的，又发掘了你另一方面的潜能呢。

　　尽可能多的参加研发部的会议

　　员工间的技术交流。在我们公司像这样的会一周大概要有一到两次，大家相互交流工作进展情况，或者是一些相关的技术方面的交流。不一定是非常正式的，但我感觉这样的会议是非常有必要的。

　 　还有就是公司研发部召开的会议，你也要一定要也应该的介入、参加。我当初介入最早的是他们的研发意向，然后他的一些需求调研啊，还有其他的一些设计啊等 等一些会议。像这样的会议我觉得是一定要抽出时间来参加的，因为这确实是对你的工作有很大的帮助的。因为在立项会议上，你可以了解项目的可操作性，以及项 目的特点；在调研会议上，了解需求，市场需求是开发的依据，也是测试的依据。同时一定要参加需求更改会议，以便你更好的进行测试工作。在这些都做到位后， 我们就开始写测试计划了。

　　测试计划

　　写测试计划就像我们在课堂上学到的那些，测试计划、测试用例， 开始我们的测试流程。这时就是具体应用的时候。写测试计划的时候要跟研发部要详细设计文档、产品规格说明书和需求调研的说明（产品使用说明）这样的相关文 档。如果在大公司的话，他的设计部会写产品使用说明或者是一些测试规约。还有就是一定要他的开发计划，因为你做每一步测试是根据开发进度来进行的，开发计 划是必不可少的。

　　最后根据上述的文档，从时间、内容、资源、所用工具，还有人力安排，这样一份简单的测试计划已经成形。像一般小的公 司，他会对哪个人在哪天完成那项工作是很关注的，像我们原来学的那种比较完整的文档，在这样小的公司是需要变通的，因为他们也没有很多的人力物力没有很多 的时间去看那样的文档。

编写测试用例首先要根据产品的特点编写。你的产品的特点在产品没有成型之前，你肯定不是特别了解也不是特别清楚，但是你可以根据它的框架大概的给搭 出来，你能想到的尽量给细化写到文档里面，然后在测试过程中不断的完善。如果在测试执行的过程中突然间发现一个比较好的测试用例，一定要及时给补充进去， 你不给它补充上去是你的一大损失，因为你以后的工作中可能还会需要这样的文档，或者以后接手你工作的人，他可能会看到这个文档，这对他以后的工作也会有很 大的帮助。在大的公司有专门的测试设计人员来编写这些东西，在小公司就是测试主管或者测试员编写。像我们公司从测试用例、测试计划、测试执行什么的都是我 来做的。当初是因为公司比较小，我自己做，本来是给我招了一个助手，也就用了大概一两个月吧。我个人的感觉是除非你招特别熟练的，对行业，对测试技术各方 面都比较熟悉的，一来就能上手工作的还行。如果不这样，招一个刚毕业的应届生，他对测试行业不是很了解，而小公司人手本身就少，你根本就没有时间给他做培 训，而你还要工作，也没有那么大的精力去手把手的教人家。

　　在设计测试用例的时候要考虑周到，不要重复。就我的工作来说做ERP产品就是注意各个模块的借口以及数据测试。有好多的接口，比如说销售模块是和财务模块在测试时是会发生重复的部分，这个要自己注意。行业性比较强。

　　接下来说执行测试。要按照测试用例来执行。你不能说做了测试用例而在工作的时候根本就不看，这样对你的工作是没有帮助的。因为你按照测试用例来 执行的话基本就是按照自己的思路来做，这样你走到哪一步心里都非常的清楚。这样最大的好处就是减少重复的工作，可以提高工作效率。我想这点无论是在小公司 还是大公司，还是就我们工作的本身都是很重要的。

　　然后，最好是做测试日记录，目的就是明确自己测试到哪里，以免重复工作。就我自己来说，我在做测试的时候每天都会做测试日记，一个是记录我今天 发现了多少个bug，工作到哪一步了？做了哪些工作。我发现这个做测试日记录是很有意思的。每天测出了多少各bug，我虽然在那个bag管理工具上录了一 遍，但是我还是要把它记录下来。我当初第一天去上班的时候，第一次接触到这个执行测试的时候，我记得特别清楚，我是找出了65个bug。我觉得这说明两个 问题，一个是我工作特别认真，一个是研发部有问题确实是有问题。所以，你不要觉得搞研发的都很厉害，很牛啊，你会有点怵。当初我们公司也是联想、方正、惠 普的这三个主力支柱，但是我没有觉得怵，虽然他们很自负。基本上很小的错误都能提出来，他们认为那根本不是bug。但是你到了讨论会或技术交流会、评估会 的时候可以提出来，因为这是你作为一个测试员最基础的必须的工作，也是你对工作认真负责的态度。

　　和开发人员的沟通。这个是对测试人员很重要的。这个我在前面提到过，每个人不是独立的在做事情，工作中都是需要相互的配合，特别是测试工作，有 问题，你需要及时的和研发人员沟通。如果你连沟通都做不好，那么，你的测试工作根本就没有办法进行。在这当中，你要坚持自己的原则，就是对事不对人，因 为，这个产品有问题，它就是存在bug，那么，就要有人负责去修改。你不能说，对方是部门领导你就不敢坚持自己提出的问题。第二，就是要坚守其他的测试原 则，这就是我们在学习理论的时候所掌握的一些知识。因为，我们学习时的课程设计就是根据项目来设置的，很多东西基本和实际工作中相吻合。

　　作为测试负责人，在测试工作中我给自己订了一个基本的工作流程，现在也就当作是部门的规章制度在执行。就是录入bug以后，我会在下面做bug 描述，开发人员是否要修改，为什么要修改，大概时间是多少，这样督促对方的话，会有利于工作的进度。不然，如果工作没有完成，就会出现相互推诿的现象。

　　查出bug后就是督促开发人员修改bug。同时也要注意bug管理工具。自己要用好bug管理工具，也要督促开发人员用好bug管理工具。因 为，有很多开发人员还都是比较懒的，他当时会跟你说，都有什么bug，你到我的机器上演示给我看不就行了吗？这是一个不好的习惯，也很费时间。所以，你一 定要督促他们使用bug管理工具。这是我深有体会的，而且，还在两次较大的公司会议上提出，最终是被大家所接受认同。大家都知道，一般开发的男同事较多， 做测试的女孩子较多，你在提出问题的时候态度不要太强硬，在日常的工作中委婉的提醒他，大家一般都不会太为难你的。不但工作解决了，同事间的关系也很融 洽。

　　接着就是测试报告的编写。这些我们在就业班的时候都学过，就是测试背景、内容、测试通过率。以及产品的优点、缺陷，还有你对项目的建议。这一切都做好了就是开测试评估会了。

　　关于自动化测试我的个人意见

　　我个人认为现在是自动化成风。现在很多的公司，无论是大是小，无论这公司有没有用过这个测试工具，他都会问你会用几种测试工具，会自动化测试 吗？我当时去面试的时候，也遇到这个问题，当时我首先问他的是，咱们公司做过手工以外的不管是性能啊还是功能其他测试吗？他们回答说没有。一个没有做好手 工测试的产品，是坚决不能用工具代替手工的。自动化测试是不能代替手工的。自动化测试用好了可以节省时间提高效率。但是如果你用不好，反而会增加自己的工 作量。如果你的需求和界面一直在增加，那么自动化也是用不起来的。我觉得适合自动化测试的公司，一个是产品对安全和性能要求严格的；一个可以有专人对教本 文档进行维护的。像那些手工测试不过关，需求经常变动，人员少，产品的GUI 经产改动的公司都不太适合用自动化测试。

　　一不小心就整理了这么多点滴出来，还真没想到自己还是很能写的嘛。估计这和我在公司除了做测试工作，还做些其他工作有关。我说过，因为我们是小 公司，所以，一些产品的使用说明、产品的安装说明，包括客服培训，都是由我来写的。在测试之余，一些和测试无关的工作我也会去做，比如测试制度的编 写，OA 产品管理员，售前咨询顾问 这样的工作。我想我就是这么锻炼出来的。

接口测试用例主要包括两大类：
1. 正常情况，也即是合法情况测试,可以包括以下几种情况：

    1). 接口逻辑测试
    2). 路径覆盖测试
    3). 数据量测试
2.异常情况
    1). 非法参数
    2). 通讯网络异常

1). 接口逻辑测试

　 　如果要保证接口测试的顺利进行，开发人员JavaDoc的输写定不可少，如何测试JavaDoc这里并不讲述，这里主要讲根据JavaDoc来编写测试用例，一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述，在接口逻辑测试中主要是根据所描述的业务逻辑，进行用例的设计，主要目标是测试在正常输入的情况下能得出正确的结果，测试用例的设计方法跟黑盒测试差不多，主要运用等价类，边界值两种方法。

测试的各个方面，包括数据的各个出口，路径，入口都应考虑周全。

2). 路径测试

经过了上述处理后，单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的。路径测试用例例子如下：

　　这里的测试用例有：

　　1.ABC

　　2.ABD

　　3.AE

　　4.AFG

　　如果考虑到A这条路径不只一个测试接口可以操作，可在上述用例的基础上再增加以下用例：

　　5. A’BC

　　6. A’BD

　　7. A’E

　　8. A’FG

　　如果 C,D路径等有多个接口可以实现，也可以根据这种方法增加用例，达到路径的覆盖，但是此种路径的覆盖组合会非常多，因此在实际的情况下需要根据实际业务场景进行设计，如A’BC这个路径，在现实的业务逻辑中可能是不存在的，这里就无需列出来了。

3).数据量测试

不仅需要用一般大小的数据量去测试，也需要用预期的或者规定的最大数据量去测试。

4).参数非法测试

接口逻辑的测试中主要测试的是正常逻辑，即对外提供的接口服务是能够工作的，但是这是这些测试不能保证数据的安全，及程序在异常情况的逻辑正确性，因此需要测试出错测试，主要包括以下几个方面：

　　1)空值输入，如当传入一个对象参数时，需进行NULL值的参数

　　2)参数属性的测试，如果输入一个未赋值参数

　　3)异常的测试，制造一些异常的测试场景，测试的异常描述是否清晰

　　4)另外如参数个数，参数类型(如int型输入String的参数)的出错测试，由于IDE本身就会报编译出错的信息，这里可以不做测试用例的设计。

 5).网络通讯异常

   模拟非正常情况下的网络通讯中断，时间延迟等，查看系统是否能够正常处理做出合理的反应。

 

1    自动化测试基本概念
1.1    定义：自动化测试一般是指通过计算机软件来模拟人的测试行为，替代人的测试执行工作
1.2    通常测试过程分为五个步骤：标识：标识测试需求、设计：测试用例设计、建立：测试环境建立、执行：测试用例执行、检查：测试结果检查
1.3    手工测试比自动测试发现的缺陷更多、不能完全取代手工测试、自动测试不能提高测试有效性
1.4 第三代测试自动化系统特点：提高测试的可维护性、加强测试设计、减少功能、系统、回归测试的成本、受被测系统的变化的影响小、角色分工，人尽其才，合适的人做擅长的事。
1.5    第四代自动化测试系统特点：基于模型开发、尽早得到用户行为模型、尽早发现规格和设计中的含混错误、自动生成用例和脚本、提高效率和质量
1.6    自动化测试生命周期方法六部分：1、自动化测试决策 2、测试工具获取 3、自动化测试引入 4、测试计划、设计、开发 5、测试执行与管理 6、测试程序回顾与评估
1.7    自动化测试指标：测试自动化率＝自动化执行率×自动化覆盖率
1.8    自动化执行率：测试组或者域测试部所有本季度结束的测试轮次（包括所有的转测试版本）的测试执行自动化用例数总和占测试执行用例数总和的百分比
1.9    自动化覆盖率：测试组或者域测试部自动化用例总数和测试用例总数的百分比
1.10   ActionWord概念：ActionWord(缩写AW)是一种业务的抽象，比如测试用例里的测试步骤、检查验证、消息序列等等，它的格式通常包含名字定义和参数部分，它的形式非常象我们编程语言中的过程定义。
1.11   ActionWord定义格式：AW名称   必选参数   可选参数；(缩写AW)是一种业务的抽象，比如测试用例里的测试步骤
ActionWord实现：AW实现是指使用某种语言实现一个具体逻辑
1.12   AW实现和AW定义有什么区别：AW定义指的是自动化工程师根据产品的特点抽象出来的一些动作，而该动作的运行需要AW实现的支持。从应用场景来看，AW定义用于编写用例，AW实现用于执行用例。
1.13   业软自动化测试框架特点：支持ActionWord分层、支持ActionWord共享、支持多种语言来实现ActionWord、提供强大的日志功能，方便定位问题、支持用例执行策略
1.14   业软自动化测试框架：测试管理层、测试表达、测试执行层、适配层
1.15   GUI自动化测试：测试管理层、测试表达、测试执行层

一直研究QTP，学的东西多了，总结的东西也多了，反而显得零散。

不如这样吧，弄个实战演练的东西，把以前的内容串一串，也算是做个备忘。毕竟懒惰可不是我们这一行的任职标准，多一份勤劳->多一份积累->多一点成功。

首先看看这次要测试的内容，

背景：

       选择公司的一个现有产品，公司的产品实际是以硬件形式进行销售的，也就是软件系统最终是要集成到硬件平台上并作为最终的销售产品，在软件研发过程中，测试人员需要指定的硬件平台下进行功能测试、性能测试，最终的发布版本是软件系统和硬件平台(硬件设备型号)一同发布的。虽然在研发阶段，测试人员通常还是通过手动方式进行测试，但是由于产品发布后进入销售阶段，产品生产完成后为了保障产品的出货质量，每台设备都需要进行出货前的测试，这就给测试人员带来的繁重的工作压力，面对批量的产品销售，测试人员手工测试非常的消耗人力资源也浪费了很多精力和时间成本在这上面，特别是销售业绩好的时候，测试人员只能每天完成大量的重复性的出货测试，在有限的人力资源情况下，测试人员无法再投入到其他产品研发测试的工作中去。

       也是为了解决这种问题，测试团队决定启用自动化测试，特别是这种成型产品、重复性测试的过程非常符合自动化测试的要求。同时，在使用QTP工具对现有产品进行部分功能实验表明，该工具适合用于公司产品。

       特别要说明的是，在手工进行出场测试的时候，为了使所有测试人员能够对设备进行相同的测试内容，经过测试团队、研发团队、产品经理的多方讨论和沟通，专门制定了《产品出货测试手册文档》，这个文档中列出了产品的最核心的功能，同时以测试用例的方式进行呈现，测试人员只要按照这个手册执行测试就可以了。这就为自动化测试准备了最为重要的一步，即 测试内容，接下来所有的实战内容，都是依据这个手册的内容进行选择和实践的。

选择测试的业务内容：

在业务选择的最初，先由最简单的入手，选择产品中较为核心的功能，同时业务也比较简单，描述如下：

    1、登录待测系统

    2、登录后，在制定模块进行相应配置

虽然描述起来简单，但是要真正做好可就不容易了（这是我的感觉）。

 在本章内容中，我们先要做的是完成‘登录待测系统’这个工作，同时也要把我们的QuickTest基本框架搭建起来。

第一步（把冰箱门打开）

这一步，对于新手来说往往是进入QTP世界最为神圣的一布，也就是脚本录制 但对于我这个旧手来说。。。

so,在这里我不具体描述脚本录制的方法，而是把我在录制中实际遇到的问题和解决这些问题所采取的方法拿出来做个分享

公司产品是基于PKI体系的应用产品，登录系统必须要通过https协议，同时在登录系统时，会弹出证书选择窗口，选择管理员证书后，才能真正进入到系统。(这个过程可能没有接触过pki体系产品的人会有些疑惑，我这样做个简单说明，其实就像你在登录sohu的邮箱，需要输入用户名和密码一样，通过https协议来登录时，用一个更高级的安全密码--证书 取代了你用户名口令的输入)

这个登录过程还是很简单的，录制出来的脚本内容也不多，如下：

Browser("Browser").Dialog("选择数字证书").Activate
Browser("Browser").Dialog("选择数字证书").WinListView("您要查看的网站要求标识。请选择证书。").Select "normal"
Browser("Browser").Dialog("选择数字证书").WinButton("确定").Click
Browser("Browser").Dialog("安全警报").WinButton("是(Y)").Click 

这里要注意的是在选择证书时 WinListView("您要查看的网站要求标识。请选择证书。").Select "normal"  ,这是我选择的一个名为 normal的证书，这是一张管理员证书，选择后可以正常登录到系统中，而对于证书实际上可以做一些文章，比如，我可以选一张非管理员的证书进行登录，如果也能登录成功，那这个bug可就大了。由于我的目标限于出场测试，出货测试手册中也没有这方面的要求。因此，这项工作省略了(凡事还是需要突出重点地)。

第二步(把大象放进去)

脚本录制完成后，需要对脚本进行一些优化。比如说，添加个检查点啦。登录后添加检查点还是有必要的，因为登录后，我们最先需要判断一下产品的版本，如果版本都错了，在执行测试也没有什么意义，因此增加了如下内容：

Browser("Browser").Page("安全系统").Frame("WorkArea").Check CheckPoint("版本3.7.0.18")

增加检查点并不困难，作为优化，我这里考虑的不仅仅是当前的这个脚本，而是我所有录制的脚本，在今后的运行过程中如何组织，如何更便于维护，如何更具适用性，让任何人拿到我的脚本，只要安装了qtp，就可以通过微小的改动就可以测试他想测试的设备(我可不想所有的设备都由我自己来测)

出于这种想法，我先在电脑中创建了一个目录，F:\TOO\version001\Action ,把我录制好的脚本存储到这个目录下，起名action_000_login

然后做了一个实验，把版本检查点进行了参数化处理，处理的方式是，我在外部建立了一个VBS文件，在这个文件里，写了如下的函数：

Public Function Version
 Version="版本3.7.0.18"
End Function

并将这个vbs存储到 F:\TOO\version001\lib 下(这些目录都是新创建的，里面什么都没有，很干净)，名为 custome.vbs

接下来，我在我录制的脚本中添加了如下语句：

dim file_vbs_name

file_vbs_name= "F:\TOO\version001\lib\custome.vbs"

ExecuteFile file_vbs_name

Dim version_value
 version_value=Version

最后，我把刚才添加的检查点修改为：

Browser("Browser").Page("安全系统").Frame("WorkArea").Check CheckPoint(version_value)

*******************************

在这里，我犯了一个灰常，灰常低级的错误，我把检查点的名称当作了传入的参数，也导致了这个检查点的失败，灰常灰常 感谢 superliming  的提醒。我决定要找到一个正确的方法来解决，于是我进行了下面的实验：

1-重新录制了检查版本信息的脚本

2-通过QTP把该检查点进行参数化，选择该检查点要检查的内容为qtp中的datatable 如下图：

注意，name位置我自定义了一个名字，叫version.执行确定后，在数据表区域看到action_000_login 工作簿中增加了一个列，名为version，在最初设置后，这列得第一行会有个默认值，将这个值清除掉

到此为止，是我们为检查点参数化的一个准备工作，重点即将呈现

3.在脚本中增加代码

Dim dtsheet
set dtsheet=datatable.GetSheet("action_000_login")
dtsheet.getparameter("version").value=version_value
这段代码的功能就是为version列的第一行赋值，取值就是我们在custom.vbs中定义的vesion值，为了在执行的时候检验一下这个值是否赋值成功，可以通过下面的语句验证

txt=dtsheet.getparameter("version").valuebyrow(1)
msgbox txt

qtp会在执行到这一步时，弹出一个消息框，显示出txt的值，方便我们来确定值是否满足要求。

完成后，使用有效的版本值执行，好，检查通过，执行通过。为了确保确实检查点有效，在custom.vbs中输入一个错误的值，再运行一遍。OK，检查点给出错误提示，大功告成。

*******************************

***********************

可能有人回问：“您这是弄的啥玩艺儿啊~~~”

其实是这样的，我在录制的脚本中，通过ExecuteFile 执行了我前面写的custome.vbs，把这个vbs里的version值去了出来，传给变量version_value，然后让检查点就检查这个变量的值。

那么这样做的意义何在？？其实，这个意义就在于，我会把我的一些用例通过文本，或者excel文档在QTP脚本的外部进行维护，通过一些文件调用、读取的方式把这些用例读给QTP脚本，让他来执行我给他的值，这样就更便于我对测试用例及用例值的维护，而不需要每次打开QTP才能维护，更为灵活。

到这一步，殊不知，我们已经悄悄地建立起一个小小的框架了，如果你还没看出来，那也不用着急，在后续的文章中，这个框架会渐渐的壮大起来。

为了能让QTP脚本执行我所指定的一个URL，而不依赖于qtp自身的record and run setting,我又做了如下的工作，在刚才的custom.vbs中，我又增加了几行代码：

Public Function Address
 Address="https://190.160.5.244:6333"
End Function

随即在action_000_login脚本中，增加如下

Systemutil.Run("C:\Program Files\Internet Explorer\IEXPLORE.EXE"),"","","open","3"

browser("Browser").Navigate Address

注意：需要将QTP中 record and run setting 中的设置，调整为record and run test on any open web browser

再次执行，QTP顺利自动打开IE，访问指定的URL进行模拟登录操作

第三步（把冰箱门关上）

为了让QTP执行时，能够把系统中已经打开的IE窗口都关闭，保障运行的唯一性，这样需要在action_000_login脚本中增加如下语句:

Systemutil.CloseProcessByName("iexplore.exe")

再试一试脚本运行，QTP会把所有打开的IE窗口都关闭掉，哦了，这关建的第一部分内容，就完成了

注：文章中提到了一些对象和对象的方法，这里并没有重点说明，有兴趣的朋友可以参考一下QTP自带的帮助文档

一．           接收资料完整，如资料不完整，则不予接收

1.         经过代码走查和单元测试的程序源代码。

2.         经过评审的用户需求、软件需求、概要设计、详细设计文档。

3.         用来运行程序和表结构（pdm）和基础数据文件

4.         经过审核的用户手册和安装说明文档。

二．           功能实现

1.         根据安装说明能正确搭建测试环境。

2.         概要设计说明书所描述模块功能均已实现。

3.         各模块中详细设计说明中的功能均已实现。

4.         界面风格一致（包括控件的大小、快捷键的命令名称），美观大方。

5.         各菜单项功能均已实现，各菜单项快捷键可以使用，无错字别字，能望文知意。

6.         根据冒烟测试用例测试，基本流程、正常业务可以走通。

三．           其他

1.         代码审查核心业务代码覆盖率大于80％，其它业务代码覆盖率大于60％。

2.         单元测试核心业务功能覆盖率要求大于95％，其它业务功能覆盖率大于80％。

去年参加校园招聘时，有一位学生问我：“做测试是不是比较枯燥？”我不想骗他：“在测试过程中，有许多工作是很琐碎的，与开发者的创造性工作相比没有明显的成就感，的确很枯燥、很无聊。但是，测试也有乐趣。测试的乐趣来自于全局观，来自从于不同的角度考察系统的满足感。”

Kent Beck在介绍TDD的时候，建议开发者在不同的开发活动中要戴不同的帽子——交替用“测试”和“开发”的视角处理当前的工作。这篇短文将介绍测试者的帽子和戴上帽子的乐趣。

攻击者的帽子。Myers在1979年就指出：测试是为了发现错误而执行程序的过程；成功的测试用例是使程序失败的测试用例。这使得测试者象士兵一样去搜索被攻击阵地的弱点和漏洞。这些弱点可能来自产品经理含糊的邮件、来自紧迫进度压力下的手忙脚乱、来自咖啡因、可乐、茶水混在一起的头昏脑涨。测试者需要反复地搜索、猜测、尝试和攻击，才能获得成功。通过艰苦的努力发现去发现隐蔽的bug，这就是测试的根本乐趣。这也许只有测试从业者才能理解。

客户的帽子。在许多开发团队中，产品经理负责规划产品功能，但并不真正使用产品；开发者负责开发框架或模块，但并不部署整个产品。是测试者，他们代表客户，通过部署、使用被测试软件，率先获得产品的全局观。而全局观是至关重要的：成功的产品不是没有错误的产品，它必须满足用户目标且提供良好的使用体验。测试者要学会“角色扮演”，将自己沉浸在用户的情景中，去保护用户的价值。这不是一件容易的工作。

咨询师的帽子。产品经理不喜欢别人对他的开发安排说三道四，开发者也不喜欢别人对他的设计指手画脚，但是他们都愿意接受有价值的建议。由于测试者从多个角度考察系统，他们往往可以发现遗漏的细节，提出有力的证据，贡献良好的想法。在资源允许的情况下，测试者可以评审规格说明、设计、代码，并贡献自己的想法。以我自己的经验，“易测试性”和“对调试的内建支持”是最容易被忽视的功能点，测试者需要从项目的初始阶段就开始持续增强它们。正如Martin Flower所说，测试移到了编程的前沿和中心位置。

开发者的帽子。对于自动化系统测试，测试者的测试开发是基于被测试系统(SUT, Software Under Test)的二次开发。测试者通过在SUT上构建“面向测试的应用系统”，一方面检查SUT的正确性，一方面检验SUT能否支持客户去实现客户目标。既然是开发应用系统，测试者就要考虑架构、部署和维护。而且，测试处于开发的下游，经常受到上游活动的影响，因此对测试系统的易扩展性（需要持续地加入新的测试用例）、可维护性（在上游工件发生变化的情况下，将影响控制在可接受的程度）、可调试性（能够快速地定位产品代码和测试代码中的缺陷），有较高的要求。此外，测试者承担的任务很多，能够用于开发、调试的时间相对较少。因此，对测试代码的质量和生产率的要求要高于平均水平。谁说测试开发没有挑战性？

系统管理员的帽子。测试者需要将构建出的产品部署到测试环境中，运行测试用例来模拟业务过程，监控测试结果和系统运行状态以发现潜在的错误，生成报告以反映当前系统的情况。这与系统管理员的工作非常类似。不同之处在于，测试者将系统管理员数月的工作压缩在几天内完成，且反复迭代以适应产品的变化。对于一些在线系统，系统管理员是很重要的客户，他的工作对于系统的稳定性和可靠性有重要作用。测试者需要在测试环境中扮演他的角色，去发掘他可能会遇到的场景和问题，通过改进产品设计，以简化和便利他的工作。

侦探的帽子。遇到一个难以解释或复现的bug，测试者需要调动各类工具、使用多种技巧、发挥往日经验去探索可能的原因。而解决问题的唯一武器，就是思考。测试者需要戴上福尔摩斯的帽子，不放过问题中的任何一个细节，尽可能地分析出可能的因果关系，来探索背后的真相。不断否定已有思路的思考、不断向终点探索的思考，可能是软件开发中最痛苦也最有趣的活动。

数据分析员的帽子。在软件开发过程中会有许多数据，测试者需要有选择地收集、分析和解释它们，来指导进一步的开发活动。例如下图反映了产品代码(App Code)和测试代码(QA Code)的行数随时间变化的趋势。这里有两个有趣的现象：一、产品代码远多于测试代码；二、产品代码有快速的增长，但是测试代码的增长却很缓慢。这是不是在暗示测试有跟不上开发的风险呢？也许不用担心。对于现象一，可能的解释是：(1) App Code包括开发者的单元测试，因此不完全是产品代码；(2) 测试者用高阶脚本语言开发自动化测试，用较少的代码可以实现更多的逻辑；(3) 许多的测试用例是数据驱动的方式，QA Code没有包括存储在文件或数据库中的测试数据。对于现象二，可能的解释是：(1) 作为下游活动，测试总是落后于开发。测试者还在测试前一阶段的产品代码，还没有开始测试最新签入(check-in)的代码；(2) 测试者正在准备测试数据，还没有编写新的测试代码；(3) App Code增长是因为开发者引入了新的开发库，签入了大量已有代码。总之，数据很有趣，但是更有趣的是对数据的解释。要想获得真实的情况，就必须和相关人员讨论。

服务者的帽子。睿智的前辈教诲我们：测试是一种服务角色。测试员是否成功，主要是看其是否很好地满足了客户和要求和最佳利益。这里的客户包括项目经理、程序员、技术支持人员、系统管理员、管理层、最终用户和项目相关人员。测试者要认真研究，找出对项目最重要的人，找出要服务人。这是做好测试工作的第一步。如何为客户提供更好地服务，是测试者需要持续思考的问题。

当然，测试者还有许多其他的帽子，更多的帽子也会随着职业的发展在未来出现。尽可能宽泛地思考，频繁地更换帽子，是测试者的乐趣。坚持一种视角，持续地挖掘，是测试者的快乐。Happy testing!

方法一：

一、在服务器上安装rstatd守护进程
安装步骤：
1. 从网上下载rstatd.tar.gz
2. 将该文件放到usr目录下
3. chmod 777 rpc.rstatd----改变该文件读写的权限，拥有所有权限。

4. cd /rpc.rstatd
5. chmod 777 configure ---同上
6. ./configure ---配置
7. make ---编译
8. make install ---安装
9. rpc.rstatd ---启动rstatd进程

10. 配置LR

11.  在LR中监控Linux资源OK。

 

二、在lr中配置
从LR里面add measurement， 填写linux机器的IP，出现所有unix/linux的计数器，包括cpu的，mem的，disk，network的。介绍几个常用的：
average load :在过去的1分钟，的平均负载
cpu utilization: cpu的使用率
disk traffic: disk传输率
paging rate： 每秒从磁盘读到物理内存，或者从物理内存写到页面文件的内存页数
Swap-in rate: 每秒交换到内存的进程数
Swap-out rate: 每秒从内存交换出来的进程

 

如果发现服务器重启后不能监控了，可以手动重启rpc.rstatd

 

方法二

LR监控Linux系统资源详解：
Average load：                               
    Average number of processes simultaneously in Ready state during the last minute 
    上一分钟同时处于“就绪”状态的平均进程数
Collision rate                             
    Collisions per second detected on the Ethernet
    每秒钟在以太网上检测到的冲突数。
Context switches rate                     
    Number of switches between processes or threads, per second
    每秒钟在进程或线程之间的切换次数。
CPU utilization         
    Percent of time that the CPU is utilized
    CPU 的使用时间百分比。
Disk rate
    Rate of disk transfers
    磁盘传输速率。
Incoming packets error rate      
    Errors per second while receiving Ethernet packets
    接收以太网数据包时每秒钟接收到的错误数。
Incoming packets rate                    
    Incoming Ethernet packets per second
    每秒钟传入的以太网数据包数。
Interrupt rate
    Number of device interrupts per second
    每秒内的设备中断数。
Outgoing packets errors rate
    Errors per second while sending Ethernet packets
    发送以太网数据包时每秒钟发送的错误数。
Outgoing packets rate
    Outgoing Ethernet packets per second
    每秒钟传出的以太网数据包数。
Page-in rate                                     
    Number of pages read to physical memory, per second
    指标表明的是每秒交换到物理内存中的页面数。
Page-out rate                                     
    Number of pages written to pagefile(s) and removed from physical memory, per second
    表示每秒从物理内存中移出或者写入到页面数。
Paging rate
    Number of pages read to physical memory or written to pagefile(s), per second
    每秒钟读入物理内存或写入页面文件中的页数。
Swap-in rate
    Number of processes being swapped
    每秒交换到内存的进程数。
Swap-out rate
    Number of processes being swapped
    每秒从内存交换出来的进程数。
System mode CPU utilization
    Percent of time that the CPU is utilized in system mode 
    在系统模式下使用 CPU 的时间百分比。
User mode CPU utilization
    Percent of time CPU is utilized in user mode
    在用户模式下使用 CPU 的时间百分比。

一些常见的问题及处理方法：
1、在执行配置或安装命令过程中出现“拒绝的权限”的提示？
答：是由于文件的权限引起的，应该给当前用户所有文件的“777”权限，即完全控制权限。

2、安装好后从LoadRunner中看不到信息，但是没有报错？
答：可能是返回的信息值比较小，所以在图中几乎看不到，例如：如果没有运行程序的话，CPU的使用率接近于0，所以在监视图中看不到变化。也有可能是采样的频率过大，可以在图表中设置没1 秒获取一次信息，这样界面就刷新的比较及时了。

3、监视一段时间后LoadRunner中提示有错误发生不能继续监视到信息？
答：可能是由于CPU长时间处于高负荷状态，而导致系统自动关闭了该服务。可以在LoadRunner中重新加一次计数器，并且设置取样的时间稍长一点，就会避免这种情况。

4、以前用LoadRunner监视都是成功的，但是再次监视不到信息？
答：有可能是由于系统重新启动，而没有打开rstatd守护进程。可以手工重新打开一次，使用命令“rpc.rstatd”，另外可以使用“rpcinfo -p”命令来查看当前系统是否已经启动了rstatd守护进程。

5、使用LR监视Linux窗口，经常丢失？
这是你图形显示时间设置问题，跟lr稳定不稳定没关系，具体设置如下：

1.运行Controller
2.在"Unix Resources"图形窗口中，点击右键，选择Configure选项
3.随后弹出“Graph Configuration”窗口，在该窗口有一个选项“Graph Time(sec)”，默认显示是60秒
这里共有4个选项：60秒，180秒，600秒，3600秒，whole scenario（整个场景运行都显示图形数据）
注：如果按照你疲劳测试动则十几小时的情况来看，应该选择whole scenario（整个场景运行都显示图形数据）

 

方法三

二、监控linux
1 准备工作
   可以通过两种方法验证服务器上是否配置了rstatd守护程序：
    ①使用rup命令，它用于报告计算机的各种统计信息，其中就包括rstatd的配置信息。使用命令rup 10.130.61.203,此处10.130.61.203是要监视的linux/Unix服务器的Ip，如果该命令返回相关的统计信息。则表示已经配置并且激活了rstatd守护进程；若未返回有意义的统计信息，或者出现一条错误报告，则表示rstatd守护进程尚未被配置或有问题。
    ②使用find命令
#find / -name rpc.rstatd,该命令用于查找系统中是否存在rpc.rstatd文件，如果没有，说明系统没有安装rstatd守护程序。
    如果服务器上没有安装rstatd程序（一般来说LINUX都没有安装），需要下载一个包才有这个服务,包名字是rpc.rstatd-4.0.1.tar.gz. 这是一个源码,需要编译,下载并安装rstatd（可以在http://sourceforge.net/projects/rstatd这个地址下载）
下载后，开始安装，安装步骤如下：
tar -xzvf rpc.rstatd-4.0.1.tar.gz
cd rpc.rstatd-4.0.1/
./configure —配置操作
make —进行编译
make install —开始安装
rpc.rstatd —启动rstatd进程

2）安装完成后配置rstatd 目标守护进程xinetd,它的主配置文件是/etc/xinetd.conf ,它里面内容是一些如下的基本信息：
#
# xinetd.conf
#
# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.
# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.
#
defaults
{
        log_type        = FILE /var/log/xinetd.log
        log_on_success = HOST EXIT DURATION
        log_on_failure = HOST ATTEMPT
#        only_from       = localhost
        instances       = 30
        cps             = 50 10
#
# The specification of an interface is interesting, if we are on a firewall.
# For example, if you only want to provide services from an internal
# network interface, you may specify your internal interfaces IP-Address.
#
#       interface       = 127.0.0.1
}
includedir /etc/xinetd.d

我们这里需要修改的是/etc/xinetd.d/下的三个conf文件 rlogin ,rsh,rexec 这三个配置文件,打这三个文件里的disable = yes都改成 disable = no ( disabled 用在默认的 {} 中 禁止服务)或是把# default: off都设置成 on 这个的意思就是在xinetd启动的时候默认都启动上面的三个服务!
说明：我自己在配置时，没有disable = yes这项，我就将# default: off改为：default: on，重启后(cd /etc/init.d/     ./xinetd restart）通过netstat -an |grep 514查看，没有返回。然后，我就手动在三个文件中最后一行加入disable = no，再重启xinetd，再使用netstat -an |grep 514查看，得到tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN结果，表明rsh服务器已经启动。

     只要保证Linux机器上的进程里有rstatd和xinetd这二个服务就可以用LR去监视了
两点小的技巧:
①检查是否启动: rsh server 监听的TCP 是514。
[root@mg04 root]# netstat -an |grep 514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN
如果能看到514在监听说明rsh服务器已经启动。
②检查是否启动: rstatd
输入命令: rpcinfo -p
如果能看到类似如下信息：
程序     版本 协议 端口
100001    5   udp    937 rstatd
100001    4   udp    937 rstatd
100001    3   udp    937 rstatd
100001    2   udp    937 rstatd
100001    1   udp    937 rstatd
那就说明rstatd服务启动了,(当然这里也可以用ps ax代替)
③重起xinetd方法：
在suse linux如下操作：
cd /etc/init.d/
./xinetd restart
看到网上有的地方说使用如下命令：
# service xinetd reload
# /sbin/service xinetd rstart
不知道是在什么系统用的。
④安装rsh，和rsh-server两个服务包方法
a. 卸载rsh
# rpm –q rsh----------查看版本号
# rpm -e 版本号---------卸载该版本。
b．安装
# rpm –ivh rsh-0.17-14.i386.rpm rsh-server-0.17-14.i386.rpm
⑤在启动rpc.rstatd时，会报错“Cannot register service: RPC: Unable to receive; errno = Ction refused”。
解决方法如下：
# /etc/init.d ./portmap start
# /etc/init.d ./nfs start
然后再次启动rpc.rstatd就好了。

最后，在controller中，将UNIX resources拖放到右边窗口里面，右击鼠标选择Add Measurements，添加被监控linux的IP地址，然后选择需要监控的指标就可以了。

三、监控UNIX
lr监控UNIX ，UNIX先启动一rstatd服务

以下是在IBM AIX系统中启动rstatd服务的方法：
1、        使用telnet以root用户的身份登录入AIX系统
2、        在命令行提示符下输入：vi /etc/inetd.conf
3、        查找rstatd，找到
#rstatd   sunrpc_udp     udp     wait    root    /usr/sbin/rpc.rstatd rstatd 100001 1-3
4、将#去掉
5、:wq保存修改结果
6、命令提示符下输入：refresh –s inetd 重新启动服务。
这样使用loadrunner就可以监视AIX系统的性能情况了。

注：在HP UNIX系统上编辑完inetd.conf后，重启inetd服务需要输入inetd -c
UNIX上也可以用rup命令查看rstatd程序是否被配置并激活
若rstatd程序已经运行，重启时，先查看进程ps -ef |grep inet，然后杀掉进程，再refresh –s inetd进行重启

 

HP-Mercury软件测试工具下载，随时更新
 
官方下载：
http://downloads.mercury.com/cgi-bin/portal/download/index.jsp

LoadRunner 8.1下载
http://esd.mercury.com/akdlm/trial/lr/LR81Download.exe

TestDirector for Quality Center
http://esd.mercury.com/akdlm/trial/qc/quality-center-starter-edition.zip

QTP 9.2下载
http://esd.mercury.com/akdlm/trial/qtp/qtp92.zip

其他下载地址：
LoadRunner 8.0下载
http://www.tomore.com/catalog/3_25/7.htm
LoadRunner.8.0.工业级测试工具.part01.rar
……
……
LoadRunner.8.0.工业级测试工具.part22.rar

QTP 8.2下载：
http://www.tomore.com/catalog/3_25/5.htm
QuickTest.Pro.8.2.中文版.强大测试工具.QuickTest_Pro_82_CHS_ENG.part01.rar
……
……
QuickTest.Pro.8.2.中文版.强大测试工具.QuickTest_Pro_82_CHS_ENG.part18.rar

测试工具下载推荐
CC/CQ，PCVS, CVS ,WinCVS , TD/QC所有配置管理工具下载网站：
SCMLife--致力于做一流得配置管理社区电驴测试工具资源下载：
1)        LoadRunner7.8
http://lib.verycd.com/2005/01/07/0000034096.html
2)WinRunner7.6
http://lib.verycd.com/2005/03/16/0000042388.html
3)TestDirector 7.6 http://board.verycd.com/t162206.html
FTP:TD7.6下载：
TD 7.6 SP4 企业版
TD 7.6 SP4标准版
4）WinRunner 7.6下载用快车就行http://www.clzx.net.cn/Soft/ShowSoft.asp?SoftID=450
WinRunner8。0电驴下载
http://lib.verycd.com/2005/09/18/0000065515.html
5）QuickTest Pro 8.2 电驴下载http://lib.verycd.com/2005/09/19/0000065551.html
6）LoadRunner 8.0下载地址：http://lib.verycd.com/2005/10/01/0000067173.html
LoadRunner 8.1下载地址
Ftp: LoadRrunner 8.0下载http://esd.mercury.com/akdlm/trial/lr/LR8DownLoad.exe
7）.  TestDirector 8.0 电驴下载http://lib.verycd.com/2006/03/19/0000095046.html

七  Java开源测试工具汇总

        1  JUnit 
JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。

http://www.junit.org/

2 Cactus 
Cactus是一个基于JUnit框架的简单测试框架，用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法如HttpServletRequest,HttpServletResponse,HttpSession等

http://jakarta.apache.org/cactus/

3 Abbot 
Abbot是一个用来测试Java GUIs的框架。用简单的基于XML的脚本或者Java代码，你就可以开始一个GUI。

http://abbot.sourceforge.net/

4 JUnitPerf 
Junitperf实际是junit的一个decorator，通过编写用于junitperf的单元测试，我们也可使测试过程自动化。http://www.clarkware.com/software/JUnitPerf.html

5        DbUnit 
DbUnit是为数据库驱动的项目提供的一个对JUnit 的扩展，除了提供一些常用功能，它可以将你的数据库置于一个测试轮回之间的状态。

http://dbunit.sourceforge.net/

6        Mockrunner 
Mockrunner用在J2EE环境中进行应用程序的单元测试。它不仅支持Struts actions, servlets，过滤器和标签类还包括一个JDBC和一个JMS测试框架，可以用于测试基于EJB的应用程序。

http://mockrunner.sourceforge.net/index.html
7        DBMonster 
DBMonster是一个用生成随机数据来测试SQL数据库的压力测试工具。

http://dbmonster.kernelpanic.pl/

8        MockEJB 
MockEJB是一个不需要EJB容器就能运行EJB并进行测试的轻量级框架。

http://mockejb.sourceforge.net/

9        StrutsTestCase 
StrutsTestCase 是Junit TestCase类的扩展，提供基于Struts框架的代码测试。StrutsTestCase同时提供Mock 对象方法和Cactus方法用来实际运行Struts ActionServlet，可以通过运行servlet引擎来测试。http://strutstestcase.sourceforge.net/

10  JFCUnit 
JFCUnit使得你能够为Java偏移应用程序编写测试例子。它为从用代码打开的窗口上获得句柄提供了支持；为在一个部件层次定位部件提供支持；为在部件中发起事件（例如按一个按钮）以及以线程安全方式处理部件测试提供支持。
http://jfcunit.sourceforge.net/

11JTestCase 
JTestCase 使用XML文件来组织多测试案例数据，声明条件（操作和期望的结果），提供了一套易于使用的方法来检索XML中的测试案例，按照数据文件的定义来声明结果。

http://jtestcase.sourceforge.net/

12SQLUnit 
SQLUnit是一个单元测试框架，用于对数据库存储过程进行回归测试。用 Java/JUnit/XML开发。

http://sqlunit.sourceforge.net

13 JTR 
JTR (Java Test Runner)是一个开源的基于反转控制(IOC)的J2EE测试框架。它允许你构建复杂的J2EE测试套件(Test Suites)并连到应用服务器执行测试,可以包括多个测试实例。JTR的licensed是GPL协议。

http://jtrunner.sourceforge.net/

14 Marathon 
Marathon是一个针对使用Java/Swing开发GUI应用程序的测试框架，它由recorder, runner 和 editor组成，测试脚本是python代码。Marathon的焦点是放在最终用户的测试上。

http://marathonman.sourceforge.net

15 TestNG 
TestNG是根据JUnit 和 NUnit思想而构建的一个测试框架，但是TestNG增加了许多新的功能使得它变得更加强大与容易使用比如：
*支持JSR 175注释（JDK 1.4利用JavaDoc注释同样也支持）
*灵活的Test配置
*支持默认的runtime和logging JDK功能
*强大的执行模型（不再TestSuite）
*支持独立的测试方法。

http://testng.org/

16 Surrogate Test framework 
Surrogate Test framework是一个值得称赞单元测试框架，特别适合于大型，复杂Java系统的单元测试。这个框架能与JUnit,MockEJB和各种支持模拟对象（mock object ）的测试工具无缝给合。这个框架基于AspectJ技术。
http://surrogate.sourceforge.net

17 MockCreator 
MockCreator可以为给定的interface或class生成模拟对象（Mock object）的源码。

http://mockcreator.sourceforge.net/

18 jMock 
jMock利用mock objects思想来对Java code进行测试。jMock具有以下特点:容易扩展，让你快速简单地定义mock objects,因此不必打破程序间的关联，让你定义灵活的超越对象之间交互作用而带来测试局限，减少你测试地脆弱性。

http://www.jmock.org/

19 EasyMock 
EasyMock为Mock Objects提供接口并在JUnit测试中利用Java的proxy设计模式生成它们的实例。EasyMock最适合于测试驱动开发。

http://www.easymock.org/

20 The Grinder 
The Grinder是一个负载测试框架。在BSD开源协议下免费使用。

http://grinder.sourceforge.net/

21 XMLUnit 
XMLUnit不仅有Java版本的还有.Net版本的。Java开发的XMLUnit提供了两个JUnit 扩展类XMLAssert和XMLTestCase,和一组支持的类。这些类可以用来比较两张XML之间的不同之处，展示XML利用XSLT来,校验XML,求得XPath表达式在XML中的值,遍历XML中的某一节点利DOM展开,

http://xmlunit.sourceforge.net/

22        Jameleon 
Jameleon一个自动化测试工具。它被用来测试各种各样的应用程序，所以它被设计成插件模式。为了使整个测试过程变得简单Jameleon提供了一个GUI,因此Jameleon实现了一个Swing 插件。

http://jameleon.sourceforge.net/index.html

23        J2MEUnit 
J2MEUnit是应用在J2ME应用程序的一个单元测试框架。它基于JUnit.

http://j2meunit.sourceforge.net/

24        Jetif 
Jetif是一个用纯Java实现的回归测试框架。它为Java程序单元测试以及功能测试提供了一个简单而且可 伸缩的架构，可以用于个人开发或企业级开发的测试。它容易使用，功能强大，而且拥有一些企业级测试的重要功能。Jetif来源于JUnit, JTestCase以及TestNG的启发，有几个基本的概念直接来自于JUnit， 比如说断言机制，Test Listener的概念，因此从JUnit转到Jetif是非常容易的。
http://jetif.sourceforge.net/

25        GroboUtils 
GroboUtils使得扩展Java测试变得可能。它包括用在Java不同方面测试的多个子项目。在GroboUtils中最常被到的工具是:多线程测试(multi-threaded tests),整体单元测试(hierarchial unit tests),代码覆盖工具(code coverage tool)。
http://groboutils.sourceforge.net/

26        Testare 
TESTARE是用来简化分布式应用程序(比如:在SERVLETS,JMS listeners, CORBA ORBs或RMI环境下)测试开发过程的一个测试框架.
https://testare.dev.java.net/

系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是2000个，那么这个数量，就是系统用户数

同时在线用户数：在一定的时间范围内，最大的同时在线用户数量

平均并发用户数的计算：

C=nL /T

其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算：

C^约等于C + 3*根号C  

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论

我们在用LR录制web页面http请求脚本时，会生成脚本中存在乱码，一般是LR的参数没有设置正确，下面分享下设置步骤。

录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced高级标签，先勾选‘Support charse’，然后再选中支持UTF-8。再次录制脚本时，就不会出现中文乱码问题了。你不妨试试看，^_^

  经过一中午的努力，pclint终于在我的努力下可以发现代码中的一些错误！虽然发现了几个错误被经理给否定了，但是还是很高兴！经过自己两天的努力，这个工具终于可以使用了！特高兴！

对于OPTION.LNT的修改和自定义可以使你关闭很多不必要的错误

如：-wlib(0) 可以关闭系统头文件的一些错误的提示。

-e***(某某错误的代号)可以关闭写你不想要提示的错误！

粘贴几个有用的信息：

比较详细的pclint说明：http://blog.chinaunix.net/u/30686/showart_408389.html

-i和-u的说明：http://www.cnblogs.com/tuantuan/archive/2007/10/28/940752.html

如何不检查头文件说明：http://topic.csdn.net/t/20050714/18/4145126.html

pclint的编译错误解决的方法: http://forum.ubuntu.org.cn/ntopic68474.html

 

 

这次的冒烟纯粹是因为公司停电,然后数据库服务器和我这两天测试的程序都被突然关闭.本来自己这两天正在怎么琢磨测试数据库这块呢,正好异常出现.再次打开电脑和被测程序时候,发现竟然无法登录,!!!!直觉告诉我,肯定有问题,然后问旁边的老大,他说忘了启动数据库服务器了.哈哈,就这样发现了一个严重bug,在数据库未启动的情况下,程序的启动出现异常.可能这个bug是大家经常见到的,可是有时候自己测试的时候就可能将这个遗忘.

 

软件测试停止标准
1. 简介
1.1 目的
本文档的目的是为软件单元测试、集成测试、系统测试提供停止标准。
1.2 范围
本文档适用于使用RUP 的软件项目的测试活动。
1.3 文档结构
第一部分：
简介，介绍软件停止标准的目的，本标准的适用范围，以及在本文档中使用的词汇的解释。
第二部分：
描述软件单元测试、集成测试、系统测试停止标准。
第三部分：
列出本标准使用的参考文献。
第四部分：
附录
1.4 词汇表
缺陷（Defect）
缺陷是对软件产品预期属性的偏离现象。
覆盖率（Coverage rate）
语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。
2. 软件测试停止标准
2.1 软件测试停止标准
1) 软件系统经过单元、集成、系统测试，分别达到单元、集成、系统测试停止标准。
2) 软件系统通过验收测试，并已得出验收测试结论。
3) 软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
4) 软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或
终止，并备份暂停或终止点数据。
2.2 单元测试停止标准
1) 单元测试用例设计已经通过评审
2) 按照单元测试计划完成了所有规定单元的测试
3) 达到了测试计划中关于单元测试所规定的覆盖率的要求
4) 被测试的单元每千行代码必须发现至少3 个错误
5) 软件单元功能与设计一致
6) 在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准
软件测试停止标准.doc
2
2.3 集成测试停止标准
1) 集成测试用例设计已经通过评审
2) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
3) 达到了测试计划中关于集成测试所规定的覆盖率的要求
4) 被测试的集成工作版本每千行代码必须发现2 个错误
5) 集成工作版本满足设计定义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
2.4 系统测试停止标准
1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 达到了测试计划中关于系统测试所规定的覆盖率的要求
4) 被测试的系统每千行代码必须发现1 个错误
5) 系统满足需求规格说明书的要求
6) 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准
2.5 缺陷修复率标准
1) 一、二级错误修复率应达到100%（是否应该对一、二、三级错误进行定义？）
2) 三、四级错误修复率应达到80%以上
3) 五级错误修复率应达到60%以上
2.6 覆盖率标准
语句覆盖率最低不能小于80%
测试用例执行覆盖率应达到100%
测试需求覆盖率应达到100%

一、测试种类

功能测试：针对产品需求说明书的测试，主要是验证功能是否符合需求，包括原定功能的检测、是否有冗余功能、遗漏功能。这类测试应该有测试人员完成，这并不意味着程序员在发布前不检查他们的代码能否工作。

健壮性测试（容错能力/恢复能力测试）：侧重于程序容错能力测试。本测试在单元测试阶段和系统测试阶段都要进行。如数据边界测试、非法数据测试、异常中断测试等等，主要是验证程序对各种异常情况是否进行正确的处理。为了执行方便，建议健壮性的大部分测试用例尽量编写在功能测试用例中。

接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。

强度测试：检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，1 当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；2定量地测试数据输入率，检查输入子功能的反映能力；3 运行需要最大存储空间的测试用例；4 运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例。

压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。

性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常说的强度、压力/负荷测试有密切关系。所以压力和强度应该与性能测试一同进行。举例说明，针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。压力测试注重的是外界不断施压，强度测试注重的是极限或者异常情况下系统的测试。

用户界面测试：对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题。

安全测试：主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员可以学习一些黑客技术，来对系统攻击。

可靠性测试：这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个统计，在实际工作中如果没有条件可以不必特意去做。重点做好与之相关的功能测试、健壮性测试就可以了。

安装/反安装测试：安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否影响原系统等。

文档测试：主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主。检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。

二、测试阶段

单元测试：单元测试是针对软件设计的最小单位——程序模块进行正确性检验的测试工作，由开发人员进行，其目的在于发现每个程序模块内部可能存在的缺陷，实际程序员编码过程中已经进行了。单元测试基本不需要编写测试用例，开发人员自己调试通过、符合设计要求就可以了。

集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目标是发现与接口有关的问题，由于在产品提交到测试部门前，产品开发小组都要进行联合调试，所以大部分企业是由开发人员来完成集成测试的，但也可以到了测试部门后再次进行集成测试。主要测试模块之间数据传输是否正确、模块集成后的功能是否实现、模块接口功能与设计需求是否一致。集成测试紧接在单元测试之后，当单元测试通过后，便可开始配置集成测试环境。集成测试是最关键的一步，如果问题较多就把产品送到测试部，会造成反复测试，从而浪费人力、物力资源，延误了工期。

系统测试：系统测试是在集成测试通过后进行，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。系统测试的主要内容有：功能测试、健壮性测试、性能－效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等。这个测试需要编写大量的测试用例，投入大量的资源来完成。

验收测试：根据需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际运行环境。对于实际项目可以和客户共同进行，对于产品实际就是最后一次的系统测试。测试内容为对功能模块的全面测试, 尤其要进行文档测试。

三、测试种类、阶段和用例关系

功能测试用例：包含功能测试、健壮性测试、可靠性测试，
性能测试用例：包含性能测试、压力测试、强度测试
集成测试用例：包含接口测试、健壮性测试、可靠性测试
安全测试用例：安全测试用例
用户界面测试用例：用户界面测试用例、少量功能测试用例。
安装/反安装测试用例：安装/反安装测试用例

                                       

测试阶段	测试类型	执行人员
单元测试	模块功能测试，包含部分接口测试、路径测试	开发人员
集成测试	接口测试、路径测试，含部分功能测试	开发人员，如果测试人员水平较高可以由测试人员执行
系统测试	功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试	测试人员
验收测试	对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档	测试人员，可能包含用户

四、以测试一部电梯为例

功能测试：开门，关门，铃声提示，报警电话，上楼，下楼，不同楼层同时呼叫，选择多个楼层停留。

健壮性测试：同时按上下，不按关门键直接选择楼层，不选择楼层，选择全部楼层，准载人数测试，超载人数测试，突然停电，运行中开门，用物体挡住门，本楼层选择（如5楼选5）。

1.白箱测试和黑箱测试是什么?什么是回归测试?
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试包括两部分：函数本身的测试、其他代码的测试。

2.单元测试、集成测试、系统测试的侧重点是什么？
    单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。

3.设计用例的方法、依据有那些？
    白盒测试：逻辑覆盖法，主要包括语句覆盖，判断覆盖，条件覆盖，判断-条件覆盖，路径覆盖
黑盒测试：等价划分类，边界值分析，错误推测法。

5.集成测试通常都有那些策略？
1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

7.一个缺陷测试报告的组成
缺陷的标题，缺陷的基本信息，复现缺陷的操作步骤，缺陷的实际结果描述，期望的正确结果描述，注释文字和截取的缺陷图象。

8.基于WEB信息管理系统测试时应考虑的因素有哪些？

9.软件本地化测试比功能测试都有哪些方面需要注意？
软件本地化测试的目的：
软件本地化测试的测试策略：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。

11.需求测试注意事项有哪些？
一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。

13.测试分析测试用例注意（事项）？

本文出自云层的51Testing软件测试博客，转载请保留出处及链接：http://www.51testing.com/?104

在咬人功能即将完成的前提下，无聊中看了一眼停车功能，突然发现咬人搞定了，停车真是太简单了。。。

几乎在业务上没什么区别，停车的时候只需要提交以下信息

"Name=verify", "Value=", ENDITEM,
  "Name=park_uid", "Value=", ENDITEM,
  "Name=parkid", "Value=", ENDITEM,
  "Name=carid", "Value=", ENDITEM,
  "Name=neighbor", "Value=0", ENDITEM,
  "Name=acc", "Value=-goodness-0cce", ENDITEM,
  "Name=first_fee_parking", "Value=0", ENDITEM,

neighbor和first_fee_parking还没看到底干嘛的，其它的属性应该很容易可以猜到作用，下次看看。