一、判断题
1．软件测试的目的是尽可能多的找出软件的缺陷。（Y）
2．Beta 测试是验收测试的一种。（Y）
3．验收测试是由最终用户来实施的。（N）
4．项目立项前测试人员不需要提交任何工件。（Y）
5．单元测试能发现约80%的软件缺陷。（Y）
6．代码评审是检查源代码是否达到模块设计的要求。（N）
7．自底向上集成需要测试员编写驱动程序。（Y）
8．负载测试是验证要检验的系统的能力最高能达到什么程度。（N）
9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（N）
10．代码评审员一般由测试员担任。（N）
11．我们可以人为的使得软件不存在配置问题。（N）
12．集成测试计划在需求分析阶段末提交。（N）

QTP实现自动化原理

 

       以下为个人的一些理解，而要查看官方的请查看QTP帮助或网上查找。

 

       QTP主要采用的是使用GUI模拟人的操作。它在模拟人的操作时会记录操作的对象及所做的操作和顺序，然后在回放时按记录顺序操作这些对象。而在这个模拟的过程中，最重要的莫过于界面对象（控件）的识别，那QTP是怎么做的呢？下面就举一个小例子来说明：

比如我们要测试内网论坛http://172.16.1.3:8080/bbs/index.php用正确的用户名和密码是否能成功登录。登录界面如下：

测试步骤大概如下：

1.       要先识别用户名输入框、密码输入框、登录按钮控件

2.       在用户名输入框中输入正确的用户名

3.       在密码输入框中输入正确的密码

4.       点击登录按钮

5.       验证是否登录成功，要验证是否成功登录，那就得知道成功登录与失败登录的区别。成功登录后的页面如下：

我们可以通过验证红色框中的内容或验证绿色框中的内容来标识登录是否成功，然后记入测试报告。

       以上只是一个小例子，从中可以看出识别对象是一个很重要的问题也是一个很困难的问题，毕竟现在的控件类型越来越多（包括第三方插件或自己开发或定义的控件）。那QTP是怎么来识别对象的呢，下面通过讲解QTP识别以上小例子中的控件的方法来说明一下：

       首先，QTP是通过记录控件的属性来标识对象的（当然具体用哪一些属性，QTP是有默认的，也可以配置）。假设QTP使用“html tag”和“name”属性来识别对象，QTP是怎么处理的呢？请先看下图：

       在使用QTP录制时，QTP会把对象存储到对象库中。而对象是按如上图的方式存储于对象库中。即，QTP会默认给录制的对象取一个名字（这个名字可以自己改，只要在脚本中使用到此对象时保持和此名字一样就可以了），然后把识别此对象的属性和属性值存储到对象库中，我们可以先把识别对象的属性集合认为是一个属性包，接着就是把识别此对象的属性包与定义的对象名进行关联，也叫做对象映射。这样一个对象就存入对象库了。

       接着来说明QTP是如何调用这个对象的。例如，在“用户名输入框”中输入“a用户”，伪代码如下：

WebEdit(“用户名输入框”).Set “a用户”

现在分析一下这个语句：

       首先，QTP会通过“用户名输入框”这个名字到对象库的对象名中查找，会找到以下这个对象名：

       然后通过找到的对象名，找到对象名映射的属性包，如下图：

       接着QTP就会通过这个属性包来匹配页面上的控件的属性，如果在页面上找到一个唯一与此属性包匹配的控件，那QTP就会认为此控件为要找的控件。

       然后QTP根据“WebEdit”来确定控件的类型，并调用QTP对于此类控件内置的操作方法“Set”把“a用户”赋予了控件

       至于其他控件的识别和操作，基本原理和上面一样。检验登录是否成功，也是通过比对登录成功后的页面特有的控件的属性值来判断。

       QTP还提供描述性编程，从而可以不使用对象库，如在“用户名输入框”中输入“a用户”，可以使用以下伪代码：

WebEdit(“Html tag:=INPUT”,” Name=username”).Set “a用户”

       细心的朋友可能已经发现，上面只是把识别对象的属性包中的属性和属性值按一定规则直接写到了“WebEdit()”的括号内了。这时QTP将不通过对象库，而是直接使用括号内的属性和属性值到页面上去找匹配项。然后操作与使用对象库的操作一样。

       当然，QTP还提供了一些其他的功能，比如参数化，划分模块（Action）呀。但最重要的还是对象的识别。本次到此结束，希望对大家理解自动化能有所帮助。

 

 

   今天在《软件性能测试过程详解与案例剖析》中看到对几种性能测试常用方法的概念定义，觉得写的很清晰，特贴出来和大家共享：

性能测试（performance testing）方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。主要目的是验证系统是否有系统宣称具有的能力。

负载测试（load testing）方法通过在被测系统上不断增加压力，直到性能指标。主要目的是找到系统处理能力的极限。

压力测试（stress testing）方法测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。主要目的是检查系统处于压力情况下，应用的表现。

 

配置测试（configuration testing）方法通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。

 

并发测试（concurrency testing）方法通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否在死锁或者其他性能问题。主要目的时发现系统中可能隐藏的并发访问时的问题。

 

可靠性测试（reliability testing）方法通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。主要目的时验证系统是否支持长期稳定的运行。

 

失效恢复测试（failover testing）方法是针对有冗余备份和负载均衡的系统设计的。这种测试方法可以用来检验如果系统局部发生故障，用户是否能够继续使用系统;以及如果这种情况发生，用户将受到多大程度的影响。主要目的是验证在局部故障情况下，系统能否继续使用。

如果竞标成功，项目就开始要启动了。
　　华为方会提供一份CRS(客户需求)和SOW（工作任务书），华为方派人过来进行需求培训，这时该项目的测试组长也要参与到项目需求的培训和评审，也就是测试工作应该从需求开始介入。
　　项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
　　《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和华为方人员，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。
　　待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
　　《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和华为方；如果华为方不在公司，就需要测试组长把《测试方案》发送给华为进行评审，并返回评审结果。测试组长组织测试成员修改测试方案，直到华为方评审通过后才进入下个阶段――编写测试用例。
　　测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
　　这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
　　其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
　　同样，测试用例也需要通过开发人员，测试人员和华为方的评审，测试组长也需要组织测试人员对测试用例进行修改，直到华为方评审通过。
　　在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。华为的外包项目一般是一次性集成，所以软件转测试部后直接进行系统测试。
　　测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。
　　根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。
　　待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。
　　在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。
　　完成系统测试后，软件就开始转到华为进行验收测试，其中大概测试半个月，一般会要求测试部派人到华为方进行协助测试，并发回问题单给公司开发人员修改。
　　如果验收发现的缺陷率在SOW规定的范围内，那么验收成功，华为方付钱给公司，项目结束。
　　如果超过规定的缺陷率，那么公司可能要罚钱了，整个项目组的成员（包括开发和测试）都可能要罚了。
　　这种情况也会有，如果按照流程做事，概率不会很大。
　　测试流程的规范是很重要的，但是如果要成为优秀的测试人员只知道流程还是不够的，需要学习的东西还很多，包括熟悉相关测试业务，计算机专业知识（linux，oracle，tcp/ip等），开发的架构和语言，性能测试和系统瓶颈分析、调优等。还有性格（细心，耐心）和人际沟通能力也是很重要的决定条件。

测试如何更有效说服研发去修改bug？

问题描述：测试过程中一些bug会被研发认为是无效bug，但从用户角度出发，测试认为该bug需要更改，此时测试如何更有效的说服研发去修改bug？

精彩回答：

　　1. 扭转研发领导的思想，提高研发人员的响应速度：

　　a). 让研发团队的领导重视缺陷：

　　很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候，都是没有测试结束，功能开发的差不多就把产品卖掉了，后面再对版本不断升级，结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出 生的，明显对测试的质量要求就不一样，每次要求都特严，对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见，你说研发人员还愿意花大量的力 气去修改Bug吗？所以说，团队的领导的想法或意识，对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过，大家也可以 借鉴一下。

　　b). 采用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：

　　我们公司使用缺陷管理工具（QC9.0）,测试经理任管理员，给公司高层领导、项目经理、开发经理都分配了权限，自己可以登录系统查询相关信 息。在测试后期，特别是要发布版本前后，领导们一有空，也随时上去浏览一把，无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷，开 发人员自然不敢怠慢。

　　c). 把开发人员的修改缺陷的响应速度，记入绩效考核内容：

　　由于公司总监特别关注产品质量，我们公司对缺陷修改这一点做得比较好，每次都是递交缺陷以后，开发人员响应特别快。如果有疑问，就马上和测试人 员一对一交流，尽快修复或解决该缺陷。我们公司的口号是：“宁愿花出100倍的代价，也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候， 我们测试人员要给开发人员打分，很重要的一点就是：开发人员对测试缺陷的响应速度，如果这一项很低的话，老大要找你谈话的，问具体原因是什么？呵呵。所 以，我们公司很少有测试人员追着开发修改缺陷的情况，把修改缺陷的响应速度纳入个人绩效考核，我个人觉的是一种比较好的方式，值得借鉴或推广。

　　2. 组建一个合理的研发团队，规范测试规范：

　　a). 关键是建立一个完善的研发机制：

　　在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。毕 竟在国内软件的软件企业缺少这样的部门，所以说把修改缺陷相关的重任推到了测试人员的头上，其实对测试人员实在是太不公平了。要解决这个问题，最关键就是 建立一个完善的研发机制，让QA等相关部门督促解决这类问题，比较好。

　　b). 分清团队成员的具体责任：

　　对于研发团队中的每个成员，必须责任明确，否则像督促缺陷修改这样的事情本来不是测试人员的责任，现在都推到测试人员头上了。很郁闷！！

　　c). 完善测试规范，明确Bug管理制度：

　　大部分的公司，都没有单独的部门来单独管理督促缺陷是否修改，都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质，让他 们去处理这些琐事。经常碰到这样的情况，很多争议的缺陷都一直放到后面一个版本，一段时间下来，几个版本争议的缺陷就多于100个，弄得后面版本也不好发 布。我们的做法是，发布前几天，对每个争议的缺陷用邮件先发给项目组成员先看，后面在召开缺陷评审会议，如果通过，毫无疑问修改，否则关闭或保留到下一个 版本。

本文出自51Testing软件测试网，感谢会员sun_0910在每周一问（08-10-27）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　3. 从源头上杜绝无效缺陷的递交：

　　a). 测试前细化测试需求,避免递交歧义缺陷：

　　很多研发不愿意修改的缺陷，大部分都是由于需求不明确或者理解歧义引起的。所以，最好的做法是在测试以前，开个项目会议，细化一下测试需求，让 研发去确认或项目组成员集体Review，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。测试人 员无法说服研发，让研发去修复缺陷，长期这样，测试部的威信就大大降低了。

　　b). 把握不准的缺陷，递交以前最好讨论一下：

　　特别是在测试初期，由于测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。这个时候，往往测试认为自己 递交正确了，开发人员认为自己开发软件是对的，互不相让，如果处理不好，很容易弄僵关系，弄得大家都不是很愉快。要是项目中出现这样的Bug，是很难说服 研发去修改的，还有可能成为研发抓你的“小辫子”的有力证据，要是这样以后就更难做了。个人的一些做法：所有的测试缺陷相互审核后，才递交到缺陷系统上公 开，是最为保险的方法。

　　c). 清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug：

　　很多时候，测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反心里，这就 让开发人员对测试人员有看法，以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试，一定要保证递交的缺陷能够重复出现，最好要有截图、图片或者用 数码相机照下来，让开发人员认识到这个问题确实存在，并且更具说服力。

　　d). 做好版本配置管理工作，保证测试环境的准确性：

　　很多同事发现的缺陷，只有在测试环境下重现，而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的，他们很容易得出结论，说测试人员递 交无效的缺陷而被拒绝，大部分情况发现是版本弄错啦！！我们唯一能做的就是做好源代码的配置管理工作，保证测试环境版本的正确性和独立性，自己编译自己部 署测试环境。只有这样，才会减少无效缺陷的递交，避免“费劲周折”说服开发人员修改缺陷。

　　4. 正确分析测试中的软件缺陷：

　　a). 为递交的每个缺陷准备几条充足的理由：

　　一般情况下，我们提到一个Bug时，开发人员都会说出很多可以不修改缺陷的理由，尽量搪塞住我们的口，要求我们关掉缺陷或者置为无效或者延期到 下一个版本。如果你很牛，你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员；如果你不是太强，那就可以求助部门同事，集中测试部门团队的力量， 想一些好的、站得住脚理由，详细介绍给研发人员听，只要我们递交的Bug，每个都具说服力的话，我想他们也会尽快修改的。这种方法还真是不错，大家不妨试 一试。

　　b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险：

　　比如说，我们递交一个缺陷，如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪 种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信，当我们对缺陷分析的很详细时，研发人员一定会修改Bug的。

　　5. 做一个聪明的测试工程师：

　　a). 注意和研发人员的沟通技巧：

　　如果测试人员没有做过开发工作，理解也许就比较片面。有的测试人员，对待问题没有耐心，性情比较急，也是常有的事。如果没有较好的沟通技巧，也 许就是几句话的功夫，就和同事争吵了起来，弄得大家都比较尴尬。个人建议：谈话时，要注意沟通技巧，要有换位思维的方式，做事情对事不对人，处理事情一定 要有一颗宽容的心。只有这样，才能够很好的说服研发去修改Bug。

　　b). 和研发人员搞好私人关系，做研发的听众：

　　比较明智的测试人员，一定要学会倾听研发人员的心生。很多时候，开发人员碰到工作困难的时候，很希望和人倾述，如果测试人员是他的听众，那么你 们的关系一定会不错。搞好了私人关系，工作中你递交的缺陷，他们就不会那么斤斤计较了，毕竟关系是基础，关系好了好说话呀，在中国就是如此。如果私人关系 好了，说服研发修改Bug就是很容易的事情。不过得提醒一句：不能因为关系好就把Open的缺陷给关了。

　　6. 抓住时机，不要错过千载难逢的好机会：

　　a). 求助公司上层领导：

　　很多时候，测试到后期，开发人员把缺陷也修改的差不多了，公司领导（比如说老总、总监、项目经理或开发经理）就会随时来测试部门，找测试经理或 负责人了解项目测试的具体情况。如果有一些问题都是争议问题，作为测试Leader的你不妨给领导聊聊，把更高层的人拉进来为测试部门说话，为测试部门撑 腰，但是凡事都有一个度，不能太过分，否则很伤同事的和气。

　　b). 要求客户代表援助：

　　很多GUI的缺陷或可改可不该的缺陷，可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷，如果客户代表同意这样做，那没问题，可 以不修改；如果客户不同意，他自然会直接找项目经理或高层人员协调解决这个问题，这就不用我们测试人员操心了。因为客户就是上帝，这招不错吧！！！

　　我目前想到的就这么多，希望同行指正！！！

 

Linux实用命令全集之一 - 51Testing软件测试网-中国软件测试人的精神家园
http://www.51testing.com/html/88/n-108588.html

Linux实用命令全集之二 - 51Testing软件测试网-中国软件测试人的精神家园
http://www.51testing.com/html/89/n-108589.html

 

Linux实用命令全集之三 - 51Testing软件测试网-中国软件测试人的精神家园
http://www.51testing.com/html/76/n-110076.html

1. 响应时间

我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间。性能测试一般不关注“呈现时间”，因为呈现时间很大程度上取决于客户端的表现。在这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”，没有使用这种标准的原因是，可以使用一些编程技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间，对于HNDLZCGLXT的这个项目中，我们针对C/S系统采用前者标准，对于B/S我们依然采用后一种标准。

 

2. 并发用户数

我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数” 前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。

这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。

 

3. 吞吐量

我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：

（1） 用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。

（2） 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。

 

4. 性能计数器

性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使用率、进程时间等都是常见的计数器。

对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。

 

5. 思考时间

我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能测试方法论

1. SEI负载测试计划过程

目标：产生一个清晰、好理解、可验证的负载测试计划

内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景

工具：IBM、HP、OpenSource工具都支持。需有文档配合

 

2. RBI方法

目标：快速识别性能瓶颈

内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。

按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能

工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle

区别有专门的工具实现RBI。

 

3. 性能下降曲线分析法

目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上

下文。确定性能阀值。

内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。

工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。

 

4. HP（LoadRuner）性能分析法

特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。

缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述。方法局

限于LoadRuner产品的特性上。不能通用。

 

5. IBM（Rational UP）软件测试方法

特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意

测试环境及方法、工具。

缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质。

工具：涉及到IBM Rational 测试环境的所有软件、功能强大。

 

6. PTGM性能测试模型

内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范

化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测

试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计

划、测试设计与开发、测试执行与管理、测试分析。

工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以

使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定

制。个人倾向使用多个产品的整合、综合使用、扬长避短。

性能测试方法

1. 性能测试

性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点：

（1） 这种方法的目的是验证系统是否具有系统宣称具有的能力。

（2） 这种方法需要事先了解被测试系统典型场景、并确定性能目标。

（3） 这种方法要求在已确定的环境下运行

使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。

 

2. 负载测试

负载测试用来测定系统饱和状态、确定阀值。其特点有：

（1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“服务器平均CPU利用率低于65%”等指标。

（2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。

（3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该项目的Weblogic Server和Oracle数据库的性能调优。

3. 压力测试

压力测试方法测试目标系统在一定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session的能力，以及系统是否会出现错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：

（1） 该方法的目的是检查系统处于压力情况下的，应用的表现。如增加VU数量、节点数量、并发用户数量等使应用系统的资源使用保持一定的水平，这种方法的主要目的是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。

（2） 该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必须是有效的，我的经验是需要结合业务系统和软件架构来定制模拟指标、我测试过一些国内生产的压力测试工具、他们使用通用的指标来考量、造成很多信息反馈有很大的水分。需要考虑的层面如：Oracle I/O、JVM GC、Conn Pool等。

（3） 该方法还可以测试系统的稳定性。这里的技巧在于“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”

 

4. 配置测试

配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：

（1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。

（2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。同时也是HNDLZCGLXT考量性能测试服务供应商的关键。

 

5. 并发测试

该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：

（1） 可以发现应用系统的全局性性能问题。

（2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。

（3） 并发测试一般关注的问题是：

 

 

问 题 类 别

问 题 描 述

内存问题

是否有内存泄露（COM+，JAVA）

是否有太多的临时对象（JAVA）

是否有太多不合理声明的超过设计生命周期的对象

数据库问题

是否有数据库死锁

是否经常出现长事务

线程/进程问题

是否出现线程/进程同步失败

其他问题

是否出现资源争用导致的死锁

是否没有正确处理异常（如超时）导致的系统死锁

 

6. 可靠性测试

这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在80%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：

（1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。

（2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。

（3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。

 

7. 失效恢复测试

该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。该方法考量系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：

（1） 一般的关键业务都会采用双机热备或负载均衡方式来实现。

（2） 该方法回答两个问题：当问题发生的时候“能支持多少用户访问”，“有多少功能不能使用”

（3） 需要说明的是，对于HNDLZCGLXT的这个项目来说，负载均衡需要仔细考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用 IBM WebSphere Edge Server等商业版本的软件技术方式。否则单纯对EJB 容器Weblgoic Server作集群没有意义。
性能测试分析方法

该部分着重于PTGM方法论

1. 能力验证

能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：

（1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

（2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试

2. 规划性能

该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

3. 性能调优

一个标准的性能调优过程是：

（1） 确定基准环境、基准负载和基准性能指标。

（2） 调整系统运行环境和实现方法，执行测试。

（3） 记录测试结果、进行分析

在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。

我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

4. 发现缺陷

这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

软件测试是一项技术工作，测试者不是市场公关人员，之所以单独讨论软件测试的人际关系，是因为软件测试不是孤立的实施过程，软件测试的每个过程都要与软件开发人员（程序员）和软件测试人员相联系。另外，如果软件实行外包测试，则软件测试外包的人员还要与软件开发商的技术人员紧密联系。软件测试中处理好与不同人员的工作关系，建立彼此的信赖，可以提高测试的效率，减少测试失败的风险。因此，软件测试的人际关系不仅要讲，而且要找出行使有效的方式。

1. 测试人员与开发人员的人际关系

与软件开发具有天然的联系。软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。因此，软件测试与软件开发如影相随，互为服务对象。

软件测试人员和软件开发人员要多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发人员的沟通，让他清楚地认识到测试工作对开发工作的价值，发现的每一个Bug的重要性。

软件测试人员对于软件缺陷的报告要就事论事，只报告软件缺陷的客观事实，不对软件代码本身的质量优劣进行评判，不搞人身攻击。软件开发人员要理解软件测试的工作职责就是寻找软件缺陷，而不是故意和自己的代码“过不去”，也不要认为软件测试是动动鼠标，敲敲键盘的低水平工作，软件测试也是一门技术和艺术。测试和开发只是软件工作的分工不同，都是软件项目团队不可分割的成员，而且软件测试人员发现的Bug，可以帮助开发人员尽早修正，避免软件发布后造成更大损失。

2. 测试人员与质量保证人员的人际关系

不同的软件公司对质量保证（QA）人员的职责和功能存在不同的理解。有些公司QA人员等同于测试人员，负责具体的软件测试工作。也有的公司QA人员只负责软件项目的过程检测和跟踪，不参与具体的测试工作。

这里所说的QA人员是指对软件测试的质量和过程进行评估的人员。QA人员通过抽查测试用例的执行结果，或根据测试发现的软件缺陷数据信息对软件测试的质量和过程进行评估。QA人员一般需要熟练掌握软件测试的技能，熟悉软件产品。

软件测试人员与QA人员都是软件质量控制团队的成员，只是二者的职责不同，但是都是具有相同的工作目标，即一切行为都是为了提高和保证软件质量。软件测试人员可以从QA人员的测试评估报告，发现测试存在的不足和取得的成果，因此，需要理解和尊重QA人员，加强交流，相互信任和支持。QA人员要注意对软件测试的效果进行评估时，一切以客观数字为基础，对事不对人，关键是发现影响软件测试质量的问题，并且提出可行的改进建议。

3. 外包测试服务商与软件开发商的关系

软件测试外包成为新的软件测试形式，由于软件测试活动的复杂性和长期性，软件开发商与提供软件测试服务的服务商之间的交流变得非常重要，处理好测试外包服务商和开发商之间的关系将对软件测试具有决定性的影响。

软件外包测试是一种软件技术服务，外包测试服务商的价值在于通过提供专业的测试服务为客户创造附加价值。软件开发商通过测试外包，集中人力和物力从事软件核心技术的开发，增强产品的竞争力。因此，外包测试服务商与软件开发商之间是业务合作关系。

信任关系成为外包测试服务商和软件开发商最重要的内容。测试外包服务商要赢得软件开发商的信任，需要提供优质、高效、及时地软件测试服务，需要理解、达到甚至超过客户的期望，树立一切为客户服务的思想和意识，并且贯彻于整个软件外包测试的全过程。

软件开发商要选择符合项目需求的外包测试服务商，为他们提供充分的项目信息和必要的技术支持，因为只有软件开发商真正熟悉要测试的软件。通过对外包测试服务商测试项目的执行过程和结果，及时提出存在的问题，并且督促过程改进。

 负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。
        1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
        【Kiki补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。
 
        2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
        【Kiki补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。
 
        3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）
        【Kiki补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。
 
        4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
        【Kiki补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。
 
        5.数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。
 
        6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
        【Kiki补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。
        不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
 
        7.日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
        【Kiki补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。
 
        8。日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。
 
        9。web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
 
        10.性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
 
        【Kiki补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

转载请保留：本文出自louis_lu的51Testing软件测试博客：http://www.51testing.com/?75198

Bugzilla的安装配置,其实也没有传说中的那么困难,问题就在没有经验.刚刚完成bugzilla的配置,我想记录下来我的详细安装过程,一是留点记录进一步记忆理解,二是供朋友们参考. 好了言归正传!

(以下所列皆为本人安装配置过程中的所用资源,不同版本的文件,系统等参照本文安装不保证一定成功)

OS: Linux Red Hat Enterprise 5 (确保gcc编译器等都已安装上去,手工安装gcc比较麻烦)

DB: MySQL-server-community-5.0.67-0.rhel5.i386.rpm, MySQL-client-community-5.0.67-0.rhel5.i386.rpm, MySQL-devel-community-5.0.67-0.rhel5.i386.rpm, MySQL-share-compat-5.0.67-0.rhel5.i386.rpm, MySQL-share-community-5.0.67-0.rhel5.i386.rpm. (http://www.mysql.org)

Apache: httpd-2.2.3-6.el5 (http://www.apache.org)

Bugzilla： Bugzilla-3.2rc2(目前是最新的稳定版本, http://www.bugzilla.org)

开始安装:

前提Linux平台都已搭建完备,本文以此为基础,Linux安装不作赘述.

安装配置mysql

1.安装mysql,顺序：MySQL-server***.rpm, MySQL-client***.rpm, MySQL-share-community***.rpm, MySQL-devel***.rpm, MySQL-share-compat***.rpm.

2.初始化数据库: 输入如下命令为root添加密码, (真该死这个破blog不能方便贴图)!

输入:/usr/bin/mysqladmin -u root password '你的密码',如你使用123456作为密码，则输入:/usr/bin/mysqladmin -u root password 123456 即可.

3.创建bugs用户,并分配权限.(注:bugzilla-2.18rc1版本后已经不需要用户自己创建bugs数据库了,用户只需创建bugs用户即可)

进入mysql(输入命令:mysql -uroot -p, 回车后根据提示输入刚才你初始化的密码), 登入mysql后查看现有数据库情况,输入命令如下,

mysql>show databases;(别忘了这里的分号,该命令将显示所有database,初始默认有: information_schema, mysql, test)

输入如下创建bugs用户并分配权限:

mysql>GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, DROP, REFERENCES ON bugs.* TO bugs@localhost INDENTIFIED BY '$db_pass';

mysql>FLUSH PRIVILEGES;

注: '$db_pass'为bugs用户的密码,随你设定,但一定要紧记此密码,下面将会用到. 本人设为bugs,即输入 GRANT ... BY 'bugs';

至此数据库方面配置完毕!

转载请保留：本文出自louis_lu的51Testing软件测试博客：http://www.51testing.com/?75198

配置apache

关于apache的学习资料进apache官网：http://www.apache.org,查找学习,这里不做介绍.

最新版本的apache需要修改的地方不多,主要有3个地方要注意：(修改配置文件httpd.conf即可,该文件一般存在你安装路径的/conf/下,若使用Linux系统自带的apache,则可到/etc/httpd/conf/查找, vi编辑保存)

a.DocumentRoot,需要设置为你的bugzilla文件所在路径,以及<Diretory "你的bugzilla文件所在路径">

b.使用"./"找到AddHandler.cgi这行内容,去掉注释,如果已经去掉,保留即可.如果不添加该语句,会把cgi文件中的内容当成文本形式显示出来,而不是运行cgi程序.

c.创建一个目录的权限说明, 一般如下所示:本例中bugzilla所在路径为:/var/www/html/bugzilla

<Directory "/var/www/html/bugzilla">

  Options ExecCGI FollowSymLinks

  AllowOverride Limit

  Order allow,deny

  Allow from all

</Directory>

主要修改的内容是, 在Options中增加ExecCGI,该选项让该目录下的CGI脚本可以运行. 其次把AllowOverride的参数改为Limit, 这样修改可以让bugzilla通过生成.htaccess文件来控制目录的访问权限.

至此apache配置完毕!记得apache配置完毕后,要重启啊,这样你的配置才会生效!

配置bugzilla

bugzilla的运行还需要perl的一些模块的支持, 在这提供一个网站www.cpan.org, 该网站提供了perl所有的模块, 用户可以在这search所需的perl模块.好了,下面开始!

cd 到你bugzilla所在的目录, 如：cd /var/www/html/bugzilla/

执行./checksetup.pl文件,查看perl模块情况.直接在输入:./checksetup.pl,回车即可.接下来会给出很多信息,仔细看你会发现有些模块已经安装ok，并给出版本,如：CGI.pm (v3.21)   ok: found v3.42,但是初次安装会有很多模块缺失,会提示not found等信息.

转载请保留：本文出自louis_lu的51Testing软件测试博客：http://www.51testing.com/?75198

关于安装perl缺失模块,有2个方法:

1. 如果网络连接正常,可尝试网络安装,根据运行./checksetup.pl后的提示信息输入,即可自动下载安装缺失模块,此方法最为方便,运气好的话,可能一次性就OK.

此处以安装perl-Magick为例:输入 /usr/bin/perl install-module.pl Image::Magick, 即可.

2. 手动安装,需要到www.cpan.org下载相关模块,此过程较为复杂(因为模块间存在依赖关系,不是每个模块都是一次安装就OK的),但可加深理解.手动安装过程中,有以下几点需要注意:

a.一般情况下Linux自带的perl已经有了DBI模块,此时根据提示正常安装DBD-mysql即可.若perl的DBI模块还没有的话，又或是Linux没有安装perl,则到www.perl.org下载最新的perl模块安装。

b.perl模块的的安装方法多为:

perl Makefile.PL

make

make test

make install

到此应该知道为什么强调要安装gcc编译器了吧？

有些模块之间存在依赖性, 若make test过程中,产生异常可于make install后,重新执行perl Makefile.PL命令,此时可看到安装异常的原因.若存在模块依赖,则会提示需要安装相应模块.

当perl的必须模块以及数据库的DBD都安装成功后,再次执行./checksetup.pl文件,查看perl模块的安装情况,若必须的perl模块都安装成功后,则会提示编辑/bugzilla/目录下刚生成的的localconfig文件, 使用vi编辑该文件,修改该文件中的2个参数的值:

a. $index.html='0' 改为 $index.html='1', 这样会生成一个index.html文件,该文件指向index.cgi.

b. 把$db_pass=''的空字符改为你当初创建bugs用户时为其分配的密码.

保存修改后退出,再次执行./checksetup.pl文件,此时将创建bugs数据库以及数据库中的表格,同时提示输入管理员的用户名, 真实姓名, 口令是什么. 自此bugzilla的配置完成.

注:提示输入管理员的用户必须使用邮箱名称,如：test@163.com, 这是bugzilla的默认规定.

最后使用浏览器打开bugzilla地址,进入第一次登陆界面.

如果出现提示没有权限访问bugzilla的话，则说明bugzilla目录权限需要重新设置,可使用如下命令修改目录权限: chown -R apache.apche <Bugzilla目录名>,然后重新访问就可以了.

OK,终于总结完毕了,有问题留言吧,我会及时上来看的,谢谢!

转载请保留：本文出自louis_lu的51Testing软件测试博客：http://www.51testing.com/?75198

 

 

1、http://www.3atesting.com/bbs/thread-3188-1-2.html  LR8.14 ---IE7补丁
2、http://www.3atesting.com/bbs/thread-1001-1-3.html  LR8.0 --java1.5 patch下载
3、http://www.3atesting.com/bbs/thread-909-1-13.html LR8.1 ServicePatch4 下载
4、http://www.3atesting.com/bbs/thread-524-1-13.html LR9.0软件下载
5、http://www.3atesting.com/bbs/thread-1680-1-14.html LR install文件

破解方法，目前只对8.1的破解有经过测试，且有效：
将LR7.8或者LR8.0（安装包或者安装后目录中的都可以）中的
lm70.dll
mlr5lprg.dll
这两个文件复制并粘贴到LR8.1安装目录下的bin文件夹下,一般是C:\E:\Program Files\Mercury\LoadRunner\bin；
lm70.dll 文件的描述是 with conbined license support，是一个license的支持文件；
mlr5lprg.dll应该是一个保存license的文件。
大家可以试一试，其实不要替换mlr5lprg.dll也是可以的，只替换lm70.dll文件，老的license一样能注册通过，但是软件的试用的license还在。
3、运行LR8.1，打开license管理器，点击添加new license，将老license复制进去，OK，验证通过！
7.8、8.0通用的license有：
golba-100: AEAMAUIK-YAFEKEKJJKEEA-BCJGI
web-10000: AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB
此方法适用于英文原版8.1和中文版8.1

LR9.0下载地址：http://www.3atesting.com/filedown/LR9Download.exe

破解附件下载地址：http://bbs.51testing.com/attachment.php?aid=38182

破解方法：

1、过程和方法：
打开Loadrunner，发现以下几个dll可能和注册有关，mlr5lprg.dll、licensebundles.dll、lm50.dll、lm70.dll。
如果熟悉LR的朋友，LR7.8、8.0、8.1中都没有Licensebundles.dll，这是一个新的综合捆绑dll，所以我在之前的一些朋友的帖子里说破解难度大，也是这个原因。但是万幸的是，我在LR8.1.4.0中发现了licensebundles.dll，也就是LR8.1打上FP4补丁，并且用我以前的针对LR8.1的办法有效，因此，LR9.0的破解方案也就很快出现:用LR8.1.4.0中的lm50.dll、licensebundles.dll覆盖LR9.0安装目录下“bin”文件夹中的对应文件；用LR8.0中的mlr5lprg.dll、lm70.dll覆盖LR9.0安装目录下“bin”文件夹中的对应文件；然后使用老的注册码就可以使用了；
golba-100: AEAMAUIK-YAFEKEKJJKEEA-BCJGI
web-10000: AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

2、遇到的问题
在破解的过程中我还遇到了个问题，就是通过上述的方法注册时提示“License security violation……”，无法注册，后通过针对LR注册表删除的工具运行后再注册就通过了，文件见破解附件。

小歪作品：

LoadRunner关联函数---http://www.boobooke.com/v/bbk1586

LoadRunner参数化之研究---http://www.boobooke.com/v/bbk1617

 

 

雪鹰作品：

LoadRunner中Web检查点两个函数剖析(1/2)---  http://www.boobooke.com/v/bbk1333

LoadRunner中Web检查点两个函数剖析(2/2)--- http://www.boobooke.com/v/bbk1334

LoadRunner中编写ftp测试脚本---  http://www.boobooke.com/v/bbk1349

 

小强作品：

1 性能测试常见用语

http://www.boobooke.com/v/bbk1577/

2 lr常用术语

http://www.boobooke.com/v/bbk1620

3 lr目录分析

http://www.boobooke.com/v/bbk1574

3.1——3.3lr界面分析

http://www.boobooke.com/v/bbk1735  VuGen

http://www.boobooke.com/v/bbk1736  Controller

http://www.boobooke.com/v/bbk1737  Analysis

5 hp web tours网站分析

http://www.boobooke.com/v/bbk1762

6 lr录制测试脚本

http://www.boobooke.com/v/bbk1763/

7 lr回放测试脚本

http://www.boobooke.com/v/bbk1764/

8 html和url比较

http://www.boobooke.com/v/bbk1771

9 lr自动关联

http://www.boobooke.com/v/bbk1778

10 java虚拟用户

http://www.boobooke.com/v/bbk1901

11 初识lr动态链接库

http://www.boobooke.com/v/bbk1900/

12 lr录制sql脚本

http://www.boobooke.com/v/bbk1526/

13 性能分析基础知识

14.LoadRunner脚本编写规范---http://www.boobooke.com/v/bbk1781/

15.LoadRunner运行时刻设置---http://www.boobooke.com/v/bbk1782/

16.LoadRunner之错误处理---http://www.boobooke.com/v/bbk1776  lr_continue_on_error

17. LoadRunner之脚本调试---http://www.boobooke.com/v/bbk1777

18. LoadRunner测试脚本的增强方法---http://www.boobooke.com/v/bbk1772

 

 

一：想把BUG和测试用例给一一联系起来么?
思路是这样:
1.可以在BUG模块中添加一个按扭,点这个按扭就可以为这个BUG加上对应的测试用例名
2.然后对输入的用例名要做下验证,
3.验证通过就将测试用例和这个BUG关联起来了,否则就报错

二：

       很长时间以来，都在不断思考一个问题——如何成为一个合格的测试工程师？当然也经常会反省自己是否是一个合格的测试工程师。不断思考的过程中也有了一些自己的认识，把它写出来供大家讨论：

Part 1:
    以下所说的都应该是一些比较基础的方面，也是我在面试测试工程师时比较关注的方面：

1.是否有责任心；
       原本这一条是想写“是否热爱测试工作”，但是可能在很多人看来比较虚，养家糊口嘛，谈不上那么高尚。所以降低了要求，至少要有高度的责任心，其实做什么工作都会要求责任心，那为什么我会把它单独拿出来强调一下呢？主要
是因为目前行业内很多人对测试存在偏见，或者说是错误的认识，认为测试比较低级的工作，当然这是因为他们根本
不了解测试造成，不只是一些新人会有这样的认识，就连一些老的IT人也对测试存在着种种错误认识。基于这样的情
况，就不能不担心责任心的问题了。当你面对种种偏见，重重困难，你是否依然能够坚持自己的原则，认真负责的的
完成自己的工作？
2.认真细致；
       让一个粗心大意的人做质量控制方面的工作，无论如何都是让人不放心的，无论是测试方案制定，测试用例编写，还是测试执行，你是否能够尽量做到面面俱到，无遗漏？这很重要。
3.忌浮躁；
       如果你像很多开发人员一样自负，那么对不起，你不合格。“想当然”是要不得的，尤其是做QA的工作。不要总是说“应该没问题吧...”,“应该可以吧...”,"应该什么什么的 "...，喜欢这样说话的人，把项目交给你是无法让人放
心的。做为一个测试工程师，对于自己的工作应该是做到事无巨细都要认真对待的，“勿以善小而不为，勿以而小而
为之”。
4.条理性；
       我喜欢让来面试的同仁讲讲他之前做的项目，如果是应届生会让他讲讲他的毕业设计，毫无条理讲成一锅粥的，会让人很郁闷。反之，如果可以很有条理的把之前做过的项目讲清楚（主要是让面试官有一定的了解），那么会给面试官
留下不错的印象。条理性之所以如此被看重，主要是由于很多大型系统是相当复杂的，如果你是属于那种脑子里一团
浆糊的人，把测试工作交给你，存在较大风险。
5.主观能动性；
       首先，作为一名测试工程师，一名IT技术人员，日常应主动关注行业内出现的新技术，主动去了解各种新的测试技术
、测试理论等等，而不只是局限于手头的工作。其次，创新精神，不应该只是按部就班的完成分配给你的任务，而是
要对手头的工作多思考，如，考虑测试方案、测试用例的合理性，思考是否可以通过改进当前的工作模式提高工作质
量，是否可以引进新的测试框架、工具以提高效率等等。
6.快速学习能力
       测试工程师是一个比较通用的职位，即使常年在一个部门内，也会遇到不同种类的被测产品，它们的实现语言不同、应用的技术不同、搭建平台不同等等，因此想要针对不同产品的特性做有的放矢的测试，那么就必须了解此产品所用的各种技术，由于任何一个人不可能对这些技术都有预先的了解，而同时项目的紧迫程度又往往不会预留时间让你去
学习，这就需要你的快速学习能力了，要在尽可能短的时间获取足够的与测试相关的信息。
7.沟通能力
       这个就没必要说了，大家都知道它的重要性。
8.计算机基础知识
       没有扎实的计算机基础知识，是无法在测试道路上走的很远的。网络基础知识，操作系统原理，数据库原理，包括面向对象的概念等等都应该有一定掌握的。即使无法掌握的很全面，至少也应当具备能力当遇到问题的时候能够快速查
找到答案。

以上都是一些成为合格测试工程师的基本要素，还不是很全面，陆续补充中....

未完待续

    关于测试分析，可能不同的人有不同的分析方法，在这里只是将自己的分析记录下来，和大家一起探讨

 

一.角色以及入口：

角色：系统管理员，开发人员

入口：服务管理--新增服务

 

二.页面元素检查：

对页面初始化的检查,即页面打开后,对页面不做任何操作时的元素检查。（破页；js错；demo对比等）

 

进入到新增分发步骤页面，查看界面元素

  检查点：

    1. 页面标题显示为：新增分发服务

    2. 页面元素：

            元素名称         元素类型           元素初始值

            1）名称            文本框                 空

            2）代码            下拉列表              空

            3）类型            下拉列表              实时服务 

            4）审核标志        单选按钮              未审核

            5）业务类型        下拉列表               请选择

            6）开始时间         日期控件               空

            7）结束时间         日期控件                空

            8）备注              文本框                 空

      1）名称：文本框，默认为空，有必填标示。

      2）名称：文本框，默认为空，有必填标示。

      3）类型：下拉选择框，默认值实时服务，数据项为：实时服务，定时服务，有必填标示。

      4）审核标志：单选按钮，只有一个数据项，未审核，且不能修改，有必填标示。

      5）业务类型：下拉列表，默认值为请选择，数据项为分发业务类型数据表中的信息。

      6）开始时间：日期控件选择，选择起始时间后，联动选择出结束时间。

      7）结束时间：日期控件选择，选择起始时间后，联动选择出结束时间。  

      8）保存按钮：检查录入完整，点击保存按钮，提示保存成功。

      9）取消按钮：关闭当前页面。

      10）备注：文本框，默认为空。

 

三．页面控件检查

单个控件检查：

1.服务名称

  1）若没有填写，则提示必须填写。

  2）超过20个字，则提示字符超长。

  3）在文本输入框输入特殊字符，！,·#￥%$<>*（）@，检查系统对特殊字符有处理。

2.服务代码

  1）超过32个字符，则提示字符超长。

  2）在文本输入框输入特殊字符，！,·#￥%$<>*（）@，检查系统对特殊字符有处理。

3.审核标志

   只有一个数据项，未审核，且不能修改，有必填标示。

4. 业务类型

   数据项为分发业务类型数据表中的信息。

5. 开始时间，结束时间

   日期控件，结束时间必须大于等于开始时间

6.备注

  1）超过80个字，则提示字符超长。

  2）在文本输入框输入特殊字符，！,·#￥%$<>*（）@，检查系统对特殊字符有处理。

 

页面控件组合的功能矩阵：

1、服务类型

  如果选择服务类别为定时服务，显示出短信报警，邮件报警选项，报警方式必须选择一种，默认两种方式都选中"是"。

    

四.检查数据生成情况：

1. 保存时，若分发服务名称或者分发服务代码已经存在，则提示数据信息重复。

2. 新增服务保存成功后，在服务查询中，能够查询到新增加的服务。

3. 新增服务保存成功后，在操作日志中，能够查询到日志信息，日志类型为新增服务。

4. 数据库检查

1）操作日志表数据检查

2）分发策略表数据检查

         

五.相关业务模块影响点的检查：（可选）

1. 新增服务成功后，进入分发步骤页面，服务下拉列表中会显示新增加的服务名称

 

六.用例划分说明：

1. 页面元素检查

2. 页面元素数据校验

3. 保存功能验证

4. 取消功能验证

 

七.数据相关表

分发策略表rds_policy

操作日志表rds_logger

本文出自小刀的51Testing软件测试博客，转载请注明出处： http://www.51testing.com/?128005

Write a program to Dynamically adding to WebList ?

思路：html dom 技术

脚本代码：

    Dim objDoc
    Dim objElement
    Dim newNode

    Set ōbjDoc = Browser("Browser").Page("Page").Object
    Set ōbjElement = objDoc.GetElementByID("WebList")

   

    Set newNode = objDoc.createElement("option")
    newNode.Text = "Test——pcl"
    objElement.add newNode

    Set newNode = Nothing
    Set ōbjElement = Nothing
    Set ōbjDoc = Nothing

熟练掌握SQL是数据库用户的宝贵财 富。在本文中，我们将引导你掌握四条最基本的数据操作语句—SQL的核心功能—来依次介绍比较操作符、选择断言以及三值逻辑。当你完成这些学习后，显然你已经开始算是精通SQL了。



　　在我们开始之前，先使用CREATE TABLE语句来创建一个表（如图1所示）。DDL语句对数据库对象如表、列和视进行定义。它们并不对表中的行进行处理，这是因为DDL语句并不处理数据库中实际的数据。这些工作由另一类SQL语句—数据操作语言（DML）语句进行处理。



　　SQL中有四种基本的DML操作：INSERT，SELECT，UPDATE和DELETE。由于这是大多数SQL用户经常用到的，我们有必要在此对它们进行一一说明。在图1中我们给出了一个名为EMPLOYEES的表。其中的每一行对应一个特定的雇员记录。请熟悉这张表，我们在后面的例子中将要用到它。



　　INSERT语句



　　用户可以用INSERT语句将一行记录插入到指定的一个表中。例如，要将雇员John Smith的记录插入到本例的表中，可以使用如下语句：



　　INSERT INTO EMPLOYEES VALUES



　　 ('Smith','John','1980-06-10',



　　 'Los Angles',16,45000);



　　通过这样的INSERT语句，系统将试着将这些值填入到相应的列中。这些列按照我们创建表时定义的顺序排列。在本例中，第一个值“Smith”将填到第一个列LAST_NAME中；第二个值“John”将填到第二列FIRST_NAME中……以此类推。



　　我们说过系统会“试着”将值填入，除了执行规则之外它还要进行类型检查。如果类型不符（如将一个字符串填入到类型为数字的列中），系统将拒绝这一次操作并返回一个错误信息。



　　如果SQL拒绝了你所填入的一列值，语句中其他各列的值也不会填入。这是因为SQL提供对事务的支持。一次事务将数据库从一种一致性转移到另一种一致性。如果事务的某一部分失败，则整个事务都会失败，系统将会被恢复（或称之为回退）到此事务之前的状态。



　　 回到原来的INSERT的例子，请注意所有的整形十进制数都不需要用单引号引起来，而字符串和日期类型的值都要用单引号来区别。为了增加可读性而在数字间插入逗号将会引起错误。记住，在SQL中逗号是元素的分隔符。



　　同样要注意输入文字值时要使用单引号。双引号用来封装限界标识符。



　　对于日期类型，我们必须使用SQL标准日期格式（yyyy-mm-dd），但是在系统中可以进行定义，以接受其他的格式。当然，2000年临近，请你最好还是使用四位来表示年份。



　　既然你已经理解了INSERT语句是怎样工作的了，让我们转到EMPLOYEES表中的其他部分：



　　INSERT INTO EMPLOYEES VALUES



　　 ('Bunyan','Paul','1970-07-04',



　　 'Boston',12,70000);



　　INSERT INTO EMPLOYEES VALUES



　　 ('John','Adams','1992-01-21',



　　 'Boston',20,100000);



　　INSERT INTO EMPLOYEES VALUES



　　 ('Smith','Pocahontas','1976-04-06',



　　 'Los Angles',12,100000);



　　INSERT INTO EMPLOYEES VALUES



　　 ('Smith','Bessie','1940-05-02',



　　 'Boston',5,200000);



　　INSERT INTO EMPLOYEES VALUES



　　 ('Jones','Davy','1970-10-10',



　　 'Boston',8,45000);



　　INSERT INTO EMPLOYEES VALUES



　　 ('Jones','Indiana','1992-02-01',



　　 'Chicago',NULL,NULL);



　　在最后一项中，我们不知道Jones先生的工薪级别和年薪，所以我们输入NULL（不要引号）。NULL是SQL中的一种特殊情况，我们以后将进行详细的讨论。现在我们只需认为NULL表示一种未知的值。



　　有时，像我们刚才所讨论的情况，我们可能希望对某一些而不是全部的列进行赋值。除了对要省略的列输入NULL外，还可以采用另外一种INSERT语句，如下：



　　INSERT INTO EMPLOYEES(



　　 FIRST_NAME, LAST_NAME,



　　 HIRE_DATE, BRANCH_OFFICE)



　　VALUE(



　　 'Indiana','Jones',



　　 '1992-02-01','Indianapolis');



　　这样，我们先在表名之后列出一系列列名。未列出的列中将自动填入缺省值，如果没有设置缺省值则填入NULL。请注意我们改变了列的顺序，而值的顺序要对应新的列的顺序。如果该语句中省略了FIRST_NAME和LAST_NAME项（这两项规定不能为空），SQL操作将失败。



　　让我们来看一看上述INSERT语句的语法图：



　　INSERT INTO table



　　 [(column { ,column})]



　　VALUES



　　 (columnvalue [{,columnvalue}]);



　　和前一篇文章中一样，我们用方括号来表示可选项，大括号表示可以重复任意次数的项（不能在实际的SQL语句中使用这些特殊字符）。VALUE子句和可选的列名列表中必须使用圆括号。



　　SELECT语句



　　SELECT语句可以从一个或多个表中选取特定的行和列。因为查询和检索数据是数据库管理中最重要的功能，所以SELECT语句在SQL中是工作量最大的部分。实际上，仅仅是访问数据库来分析数据并生成报表的人可以对其他SQL语句一窍不通。



　　SELECT语句的结果通常是生成另外一个表。在执行过程中系统根据用户的标准从数据库中选出匹配的行和列，并将结果放到临时的表中。在直接SQL（direct SQL）中，它将结果显示在终端的显示屏上，或者将结果送到打印机或文件中。也可以结合其他SQL语句来将结果放到一个已知名称的表中。



　　SELECT语句功能强大。虽然表面上看来它只用来完成本文第一部分中提到的关系代数运算“选择”（或称“限制”），但实际上它也可以完成其他两种关系运算—“投影”和“连接”，SELECT语句还可以完成聚合计算并对数据进行排序。



　　SELECT语句最简单的语法如下：



　　SELECT columns FROM tables;



　　当我们以这种形式执行一条SELECT语句时，系统返回由所选择的列以及用户选择的表中所有指定的行组成的一个结果表。这就是实现关系投影运算的一个形式。



　　让我们看一下使用图1中EMPLOYEES表的一些例子（这个表是我们以后所有SELECT语句实例都要使用的。而我们在图2和图3中给出了查询的实际结果。我们将在其他的例子中使用这些结果）。



　　假设你想查看雇员工作部门的列表。那下面就是你所需要编写的SQL查询：



　　SELECT BRANCH_OFFICE FROM EMPLOYEES;



　　以上SELECT语句的执行将产生如图2中表2所示的结果。



　　由于我们在SELECT语句中只指定了一个列，所以我们的结果表中也只有一个列。注意结果表中具有重复的行，这是因为有多个雇员在同一部门工作（记住SQL从所选的所有行中将值返回）。要消除结果中的重复行，只要在SELECT语句中加上DISTINCT子句：



　　SELECT DISTINCT BRANCH_OFFICE



　　FROM EMPLOYEES;



　　这次查询的结果如表3所示。



　　现在已经消除了重复的行，但结果并不是按照顺序排列的。如果你希望以字母表顺序将结果列出又该怎么做呢？只要使用ORDER BY子句就可以按照升序或降序来排列结果：



　　SELECT DISTINCT BRANCH_OFFICE



　　FROM EMPLOYEES



　　ORDER BY BRANCH_OFFICE ASC;



　　这一查询的结果如表4所示。请注意在ORDER BY之后是如何放置列名BRANCH _OFFICE的，这就是我们想要对其进行排序的列。为什么即使是结果表中只有一个列时我们也必须指出列名呢？这是因为我们还能够按照表中其他列进行排序，即使它们并不显示出来。列名BRANCH_ OFFICE之后的关键字ASC表示按照升序排列。如果你希望以降序排列，那么可以用关键字DESC。



　　同样我们应该指出ORDER BY子句只将临时表中的结果进行排序；并不影响原来的表。



　　假设我们希望得到按部门排序并从工资最高的雇员到工资最低的雇员排列的列表。除了工资括号中的内容，我们还希望看到按照聘用时间从最近聘用的雇员开始列出的列表。以下是你将要用到的语句：



　　SELECT BRANCH_OFFICE,FIRST_NAME,



　　 LAST_NAME,SALARY,HIRE_DATE



　　FROM EMPLOYEES



　　ORDER BY SALARY DESC,



　　 HIRE_DATE DESC;



　　这里我们进行了多列的选择和排序。排序的优先级由语句中的列名顺序所决定。SQL将先对列出的第一个列进行排序。如果在第一个列中出现了重复的行时，这些行将被按照第二列进行排序，如果在第二列中又出现了重复的行时，这些行又将被按照第三列进行排序……如此类推。这次查询的结果如表5所示。



　　将一个很长的表中的所有列名写出来是一件相当麻烦的事，所以SQL允许在选择表中所有的列时使用*号：



　　SELECT * FROM EMPLOYEES;



　　这次查询返回整个EMPLOYEES表，如表1所示。



　　 下面我们对开始时给出的SELECT语句的语法进行一下更新（竖直线表示一个可选项，允许在其中选择一项。）：



　　SELECT [DISTINCT]



　　 (column [{, columns}])| *



　　FROM table [ {, table}]



　　[ORDER BY column [ASC] | DESC



　　 [ {, column [ASC] | DESC }]];



　　定义选择标准



　　在我们目前所介绍的SELECT语句中，我们对结果表中的列作出了选择但返回的是表中所有的行。让我们看一下如何对SELECT语句进行限制使得它只返回希望得到的行：



　　SELECT columns FROM tables [WHERE predicates];



　　WHERE子句对条件进行了设置，只有满足条件的行才被包括到结果表中。这些条件由断言（predicate）进行指定（断言指出了关于某件事情的一种可能的事实）。如果该断言对于某个给定的行成立，该行将被包括到结果表中，否则该行被忽略。在SQL语句中断言通常通过比较来表示。例如，假如你需要查询所有姓为Jones的职员，则可以使用以下SELECT语句：



　　SELECT * FROM EMPLOYEES



　　WHERE LAST_NAME = 'Jones';



　　LAST_NAME = 'Jones'部分就是断言。在执行该语句时，SQL将每一行的LAST_NAME列与“Jones”进行比较。如果某一职员的姓为“Jones”，即断言成立，该职员的信息将被包括到结果表中（见表6）。



　　使用最多的六种比较



　　我们上例中的断言包括一种基于“等值”的比较（LAST_NAME = 'Jones'），但是SQL断言还可以包含其他几种类型的比较。其中最常用的为：



　　等于 =



　　不等于



　　小于



　　小于或等于 =



　　下面给出了不是基于等值比较的一个例子：



　　SELECT * FROM EMPLOYEES



　　WHERE SALARY > 50000;



　　这一查询将返回年薪高于$50,000.00的职员（参见表7）。



　　逻辑连接符



　　有时我们需要定义一条不止一种断言的SELECT语句。举例来说，如果你仅仅想查看Davy Jones的信息的话，表6中的结果将是不正确的。为了进一步定义一个WHERE子句，用户可以使用逻辑连接符AND，OR和NOT。为了只得到职员Davy Jones的记录，用户可以输入如下语句：



　　SELECT * FROM EMPLOYEES



　　WHERE LAST_NAME = 'Jones' AND FIRST_NAME = 'Davy';



　　在本例中，我们通过逻辑连接符AND将两个断言连接起来。只有两个断言都满足时整个表达式才会满足。如果用户需要定义一个SELECT语句来使得当其中任何一项成立就满足条件时，可以使用OR连接符：



　　SELECT * FROM EMPLOYEES



　　WHERE LAST_NAME = 'Jones' OR LAST_NAME = 'Smith';



　　有时定义一个断言的最好方法是通过相反的描述来说明。如果你想要查看除了Boston办事处的职员以外的其他所有职员的信息时，你可以进行如下的查询：



　　SELECT * FROM EMPLOYEES



　　WHERE NOT(BRANCH_OFFICE = 'Boston');



　　关键字NOT后面跟着用圆括号括起来的比较表达式。其结果是对结果取否定。如果某一职员所在部门的办事处在Boston，括号内的表达式返回true，但是NOT操作符将该值取反，所以该行将不被选中。



　　断言可以与其他的断言嵌套使用。为了保证它们以正确的顺序进行求值，可以用括号将它们括起来：



　　SELECT * FROM EMPLOYEES



　　WHERE (LAST_NAME = 'Jones'



　　AND FIRST_NAME = 'Indiana')



　　OR (LAST_NAME = 'Smith'



　　AND FIRST_NAME = 'Bessie');



　　SQL沿用数学上标准的表达式求值的约定—圆括号内的表达式将最先进行求值，其他表达式将从左到右进行求值。



　　以上对逻辑连接符进行了说明，在对下面的内容进行说明之前，我们再一次对SELECT语句的语法进行更新：



　　SELECT [DISTINCT]



　　 (column [{, column } ] )| *



　　FROM table [ { , table} ]



　　[ORDER BY column [ASC] | [DESC



　　[{ , column [ASC] | [DESC } ] ]



　　WHERE predicate [ { logical-connector predicate } ];



　　NULL和三值逻辑



　　在SQL中NULL是一个复杂的话题，关于NULL的详细描述更适合于在SQL的高级教程而不是现在的入门教程中进行介绍。但由于NULL需要进行特殊处理，并且你也很可能会遇到它，所以我们还是简略地进行一下说明。



　　首先，在断言中进行NULL判断时需要特殊的语法。例如，如果用户需要显示所有年薪未知的职员的全部信息，用户可以使用如下SELECT语句：



　　SELECT * FROM EMPLOYEES



　　WHERE SALARY IS NULL;



　　相反，如果用户需要所有已知年薪数据的职员的信息，你可以使用以下语句：



　　SELECT * FROM EMPLOYEES



　　WHERE SALARY IS NOT NULL;



　　请注意我们在列名之后使用了关键字IS NULL或IS NOT NULL，而不是标准的比较形式：COLUMN = NULL、COLUMN <> NULL或是逻辑操作符NOT（NULL）。



　　这种形式相当简单。但当你不明确地测试NULL（而它们确实存在）时，事情会变得很混乱。



　　例如，回过头来看我们图1中的EM-PLOYEES表，可以看到Indiana Jones的工薪等级或年薪值都是未知的。这两个列都包含NULL。可以想象运行如下的查询：



　　SELECT * FROM EMPLOYEES



　　WHERE GRADE <= SALARY;



　　此时，Indiana Jones应该出现在结果表中。因为NULL都是相等的，所以可以想象它们是能够通过GRADE小于等于SALARY的检查的。这其实是一个毫无疑义的查询，但是并没有关系。SQL允许进行这样的比较，只要两个列都是数字类型的。然而，Indiana Jones并没有出现在查询的结果中，为什么？



　　正如我们早先提到过的，NULL表示未知的值（而不是象某些人所想象的那样表示一个为NULL的值）。对于SQL来说意味着这个值是未知的，而只要这个值为未知，就不能将其与其他值比较（即使其他值也是NULL）。所以SQL允许除了在true 和false之外还有第三种类型的真值，称之为“非确定”（unknown）值。



　　如果比较的两边都是NULL，整个断言就被认为是非确定的。将一个非确定断言取反或使用AND或OR与其他断言进行合并之后，其结果仍是非确定的。由于结果表中只包括断言值为“真”的行，所以NULL不可能满足该检查。从而需要使用特殊的操作符IS NULL和IS NOT NULL。



　　UPDATE语句



　　UPDATE语句允许用户在已知的表中对现有的行进行修改。



　　例如，我们刚刚发现Indiana Jones的等级为16，工资为$40,000.00，我们可以通过下面的SQL语句对数据库进行更新（并清除那些烦人的NULL）。



　　UPDATE EMPLOYEES



　　SET GRADE = 16, SALARY = 40000



　　WHERE FIRST_NAME = 'Indiana'



　　 AND LAST_NAME = 'Jones';



　　上面的例子说明了一个单行更新，但是UPDATE语句可以对多行进行操作。满足WHERE条件的所有行都将被更新。如果，你想让Boston办事处中的所有职员搬到New York，你可以使用如下语句：



　　UPDATE EMPLOYEES



　　SET BRANCH_OFFICE = 'New York'



　　WHERE BRANCH_OFFICE = 'Boston';



　　如果忽略WHERE子句,表中所有行中的部门值都将被更新为'New York'。



　　UPDATE语句的语法流图如下面所示：



　　UPDATE table



　　SET column = value [{, column = value}]



　　[ WHERE predicate [ { logical-connector predicate}]];



　　DELETE语句



　　DELETE语句用来删除已知表中的行。如同UPDATE语句中一样，所有满足WHERE子句中条件的行都将被删除。由于SQL中没有UNDO语句或是“你确认删除吗？”之类的警告，在执行这条语句时千万要小心。如果决定取消Los Angeles办事处并解雇办事处的所有职员，这一卑鄙的工作可以由以下这条语句来实现：



　　DELETE FROM EMPLOYEES



　　WHERE BRANCH_OFFICE = 'Los Angeles';



　　如同UPDATE语句中一样，省略WHERE子句将使得操作施加到表中所有的行。



　　DELETE语句的语法流图如下面所示：



　　DELETE FROM table



　　[WHERE predicate [ { logical-connector predicate} ] ];



　　现在我们完成了数据操作语言（DML）的主要语句的介绍。我们并没有对SQL能完成的所有功能进行说明。SQL还提供了许多的功能，如求平均值、求和以及其他对表中数据的计算，此外SQL还能完成从多个表中进行查询（多表查询，或称之为连接）的工作。这种语言还允许你使用GRANT和REVOKE命令控制使用者的数据访问权限。

  刚进公司的第一个项目就是做的QTP脚本的开发，而组长的第一个任务就是做一个QTP的培训，因为个人也是菜鸟级人物，QTP也是自学中，刚刚入门不久，所以做的培训稿仅仅适用于入门级别，而且拿来当例子的部分也是很简单的，不过也是我的劳动成果，而且我们组长看了之后说看完培训稿之后至少知道是怎么回事，怎么去简单应用了的，因此在这里拿出来和大家分享，希望大家能多提提建议。

  需要的朋友，留下邮箱地址，我发邮件给你们，这里好像不能上传附件...

----------------------------------------------------------

我已经很久没关注过自己这篇日志了。没想到还有这么多人找我要。
这样吧。我有空把这个以日志形式发到我自己的博客，大家自己看好了。我尽量在本周末加上。