-
loadrunner对事务状态的跟踪 (转)
2009-02-13 17:16:37
本篇日志中我将介绍LOADRUNNER对事务操作的几个函数,并通过一个例子,说明LOADRUNNER中事务是否成功是如何判断的,同时也介绍如何判断在脚本执行过程中脚本是否真实的执行成功。1.先问个问题,我们带着问题继续
录制一个登陆脚本,对登陆用户和密码进行参数化,使前2个用户名正确,第三个用户名错误,设置脚本迭代3次,分别使用第一个、第二个、第三个用户登陆,此时在脚本中对登陆的提交操作加一个事务TR_LOGIN,现在提出问题:运行脚本时
第一个用户登陆成功,事务TR_LOGIN是否成功?
第二个用户登陆成功,事务TR_LOGIN是否成功?
第三个用户登陆失败,事务TR_LOGIN是否成功?
答案是:TR_LOGIN事务三次执行时均成功
那有人会问,登陆失败为什么事务成功?我们一起来看下面的例子,相信在做过例子后就会得到答案!
我这个例子录制的是LOADRUNNER自带的mercuryWebTours
录制方法在这里就不介绍了,录制完成并对用户名和密码参数化后的脚本如下:(参数化时其中第三个用户名是错误的)
Action()
{
double trans_time;int status;
web_url("mercuryWebTours",
"URL=http://127.0.0.1:1080/mercuryWebTours/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);
lr_start_transaction("tr_login");
trans_time=lr_get_transaction_duration( "tr_login" );//lr_get_transaction_duration这个函数可以得到事务执行所消耗的时间
web_reg_find("Text=Error",
"SaveCount=login_Count", LAST);//web_reg_find这个函数可以在相应的范围内找到要找的内容,和检查点类似,但这个函数被WEB_FIND多一个参数返回结果,那就是savecount这个值可以记录在指定范围内找到指定内容的个数,这个例子中我们就是通过这个值来判断用户是否真正的登陆成功
//说明:在登陆失败后,登陆页面会有一个“ERROR”的字符串,所以我们认为如果出现该字符串代表登陆失败,这个判断登陆成功或失败的条件,根据具体的项目不同而不同,根据实际情况而定
status = web_submit_form("login.pl",
"Snapshot=t2.inf",
ITEMDATA,
"Name=username", "Value={name}", ENDITEM,
"Name=password", "Value={password}", ENDITEM,
"Name=login.x", "Value=51", ENDITEM,
"Name=login.y", "Value=12", ENDITEM,
LAST);//我们把web_submit_form函数执行的结果赋给status这个变量,如果成功返回0,不成功返回大于0的数
if (status == 0) //如果成功
lr_end_transaction("tr_login", LR_PASS);//如果提交成功,设置事务状态为PASS
else
lr_end_transaction("tr_login", LR_FAIL);//如果提交失败,设置事务状态为FAILif (trans_time) //如果该事务消耗了时间输出该时间
lr_output_message("tr_login事务耗时 %f 秒", trans_time);
else //如果该事务没有消耗时间,那么输出时间不确定lr_output_message("The duration cannot be determined.");
if (atoi(lr_eval_string("{login_Count}")) > 0){
//如果在登陆后的页面中找到“ERROR”这个字符串,我们认为登陆失败
lr_error_message("Login failed");
}
else{//否则登陆成功
lr_output_message("Login successful.");
return(0);
}
return 0;
}好了,
执行这个脚本,得到的结果是:
第一次迭代时:(在这里只粘贴了一部分关键的日志)
Action.c(15): Notify: Transaction "tr_login" started.
Action.c(17): Registering web_reg_find was successful [MsgId: MMSG-26390]
Action.c(20): Notify: Parameter Substitution: parameter "name" = "huruihai"
Action.c(20): Notify: Parameter Substitution: parameter "password" = "huruihai"
Action.c(20): Registered web_reg_find successful for "Text=Error" [MsgId: MMSG-26362]
Action.c(20): Notify: Saving Parameter "login_Count = 0"
Action.c(20): web_submit_form("login.pl") was successful, 32673 body bytes, 1652 header bytes [MsgId: MMSG-26386]
Action.c(30): Notify: Transaction "tr_login" ended with "Pass" status
Action.c(35): login事务耗时 0.002523 秒
Action.c(39): Notify: Parameter Substitution: parameter "login_Count" = "0"
Action.c(44): Login successful.
第二次迭代时:Action.c(15): Notify: Transaction "tr_login" started.
Action.c(17): Registering web_reg_find was successful [MsgId: MMSG-26390]
Action.c(20): Notify: Parameter Substitution: parameter "name" = "wangjin"
Action.c(20): Notify: Parameter Substitution: parameter "password" = "wangjin"
Action.c(20): Registered web_reg_find successful for "Text=Error" [MsgId: MMSG-26362]
Action.c(20): Notify: Saving Parameter "login_Count = 0"
Action.c(20): web_submit_form("login.pl") was successful, 32673 body bytes, 1652 header bytes [MsgId: MMSG-26386]
Action.c(30): Notify: Transaction "tr_login" ended with "Pass" status
Action.c(35): login事务耗时 0.006644 秒
Action.c(39): Notify: Parameter Substitution: parameter "login_Count" = "0"
Action.c(44): Login successful.第三次迭代时:
Action.c(15): Notify: Transaction "tr_login" started.
Action.c(17): Registering web_reg_find was successful [MsgId: MMSG-26390]
Action.c(20): Notify: Parameter Substitution: parameter "name" = "errorname"
Action.c(20): Notify: Parameter Substitution: parameter "password" = "errorpd"
Action.c(20): Registered web_reg_find successful for "Text=Error" (count=3) [MsgId: MMSG-26364]
Action.c(20): Notify: Saving Parameter "login_Count = 3"
Action.c(20): web_submit_form("login.pl") was successful, 29263 body bytes, 821 header bytes [MsgId: MMSG-26386]
Action.c(30): Notify: Transaction "tr_login" ended with "Pass" status (Duration: 0.6840 Wasted Time: 0.0010).
Action.c(35): login事务耗时 0.005852 秒
Action.c(39): Notify: Parameter Substitution: parameter "login_Count" = "3"
Action.c(40): Error: Login failedEnding action Action.
大家可以看到,事务执行结果总是成功的,但最后一次的登陆确是失败的我又把最后一次事务提交的请求地址做了错误的参数化,得到的结果是,事务执行失败
好了得出结论:
事务是否执行成功,是根据服务器是否有正确的回应,而与业务逻辑本身没有关系
本人对LOADRUNNER也是在摸索中,如果文章有写的不对,或理解错误的地方请指出,不甚感激
-
07年软件评测师考试心得(转载)
2009-02-03 16:19:49
刚参加完软件评测师考试,考下来感觉还不错,就此写下自己这段时间的复习与备考心得。本人现在是在读研究生,虽然专业是计算机软件方面的,但对软件测试还是由于这次报考的原因才得以了解和学习的。
用的资料就是清华大学出的那本指定考试参考书和张友生主编的真题与详解,个人感觉前者对于刚涉足的人而言全看懂有点难度,看第一遍的时候有点崩溃(但可以给你一个总体关于软件测试的轮廓)。今年四月初网购了一本真题与详解,讲的没有参考书详细,但是对于备考可以节省很多时间,毕竟是针对考点的,不过感觉配套的题不多。
下面就谈一谈我的复习体会和心得:
首先,得把参考书大致看上一遍,对于一些基础知识必须要识记:像白盒测试的方法、黑盒测试的方法等。
然后,买一本真题与详解之类的书,但据我了解,现在市面上关于评测师考试的用书少之又少(反正我是只找到了张友生的那本),对照着参考书将课本再过一遍。这时要多做题,尤其是关于计算机基础知识方面的题。
最后,将历年真题研究透,测评师考试是从05年上半年才有的,并且每年一次。到我今年参加考试也就仅有两年的真题。但是要明白,不管什么考试,研究一份真题比你做十套模拟题有用。下午题我就是从真题上总结出规律的。
自己认为,下午题的题型一般都有如下几类:
一.给你一段程序(C或C++)或PDL写的伪码,让你用基本路径覆盖方法来设计测试用例(并画控制流图,计算圈复杂度);
二.负载压力测试方面的,有关性能分析。一般是比较集群与单机环境下,分析系统性能瓶颈。主要从带宽和CPU资源利用率方面考虑;
三.用户文档测试和易用性测试的要点和测试内容。
四.案例分析,前两年都没有,今年出了一道关于用黑盒测试中的因果图分析法对企业ERP系统进行测试案例设计。可能这也是以后考试的趋势。后来才发现参考书上的案例分析中有原题,可惜时间太紧没看到,不过大体上还是对的。
最后再说一句:看到网上很多人说今年的上午题出得很偏,个人不太赞同,考的都是参考书上的基础知识,所以考前一定要识记一些重要的知识,做到考简答题都能够答全答对,相信出选择题的话也不在话下。
我是初涉软件测试的新手,参加软测考试只是我迈出的第一步,以后的路还很长。不过我会坚定的一直走下去。希望能得到大家的帮助与支持。
-
网站测试流程、要求及测试报告
2009-02-02 15:37:48
网站测试流程、要求及测试报告
一个网站基本完工后,需要通过下面三步测试才可以交活。
一、 制作者测试,包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。
a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等
b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确
二、 全面测试 根据交工标准和客户要求,由专人进行全面测试
也是包括页面和程序两方面,而且要结合起来测,保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字,文字内容是否有常识错误。
三、 发布测试 网站发布到主服务器之后的测试,主要是防止环境不同导致的错误
软件缺陷的原则
软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
软件未达到产品说明书标明的功能。
软件出现了产品说明书指明不会出现的错误。
软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
测试的主要方面:
一、功能测试
对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。
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自带的测试数据库性能的工具,能够测试多种数据库的性能。 -
(转)测试用例-搜索功能
2009-01-12 14:04:27
测试用例分解 对被测试点进行分解,把测试用例分解为多个测试场景 场景编号 场景描述 预期结果 场景一 页面检查 正确 场景二 默认条件搜索 查询结果正确 场景三 修改可选条件搜索 查询结果正确 场景四 修改输入条件搜索 查询结果正确 场景五 修改区间条件搜索 查询结果正确 场景六 组合可选、输入条件搜索 查询结果正确 场景七 操作后检查搜索条件及查询结果 查询结果正确 场景八 错误、空记录搜索 查询结果为空
测试步骤描述 按照已经分解的测试场景顺序,逐个描述测试场景的测试步骤 测试场景一: 步骤编号 具体描述 1 进入搜索(高级搜索)页面 2 界面共性测试 3 退出 测试场景二: 步骤编号 具体描述 1 进入搜索(高级搜索)页面 2 点击“搜索”按钮,显示查询结果列表 3 检查查询结果列表,每页显示记录条数正确、文字折行显示正确、页面布局美观 4 检查查询结果列表,列标题项、列显示内容、排序方式符合需求定义 5 检查查询结果列表,符合默认查询条件结果集 6 点击查询结果列表链接、复选框、全选框响应正确 7 退出 测试场景三: 步骤编号 具体描述 1 进入搜索(高级搜索)页面 2 逐一选择各个查 测试搜索功能时,文本框中可以输入:
1、空格+合法关键字
2、合法关键字+空格
3、数据源中存在的关键字
4、数据源中不存在的关键字,如:任意输入的到达边界的字符串
5、输入单个特殊符号,如:% ? @ # 空格等
6、输入的关键字两边加双引号
7、文本框:空白,什么也不输 -
登陆界面测试的主要内容
2009-01-05 12:42:17
登陆界面测试的主要内容
请问,你为自己写过的用例怀疑过吗?
前两天听一个朋友说他同事写了100个用例,结果有92个是无效的,差点被公司开了,本人以前也写过不少用例,但现在忽然怀疑我的用例了,觉得越来越糊涂了,拿登陆框来说吧,我写了7个用例,但总感觉不好,在网上找了篇文章,分享下,希望对大家有帮助。
快捷键的使用是否正常。
1. TAB 键的使用是否正确
2.上下左右键是否正确
3.界面如果支持 ESC键 看是否正常的工作
3.ENTER 键的使用是否正确切换时是否正常。
布局美感
界面的布局是否符合人的审美的标准
具体因人而依
输入框的功能
输入合法的用户名和密码可以成功进入、
输入合法的用户名和不合法密码不可以进入,并给出合理的提示
输入不合法的用户名和正确密码不可以进入,并给出合理的提示
输入不合法的用户名和不正确的密码不可以进入,并给出合理的提示
不合法的用户名有:不正确的用户名,,使用了字符大于用户名的限制
正常用户名不允许的特殊字符 空的用户名,系统(操作系统和应用系统)的保留字符
不合法的密码有:空密码(除有特殊规定的),错误的密码,字符大于密码的限制
正常密码不允许的特殊字符,系统(操作系统和应用系统)的保留字符
界面的链接:
对于界面有链接的界面,要测试界面上的所有的链接都正常或者给出合理的提示
补充
输入框是否支持 复制和黏贴 和移动
密码框显示的不要是具体的字符,要是一些密码的字符
验证用户名前有空格是否可以进入,一般情况可以。
验证用户名是否区分大小写。(有的软件是区分大小写的)
验证必填项为空,是否允许进入。
验证登录的次数是否有限制。从安全角度考虑,有些安全级别高的软件会考虑这方面的限制。 -
负面测试用例
2008-12-30 17:31:30
负面测试用例(转)
负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。
正面测试主要根据需求,功能说明书,设计文档等相关参考文档来执行测试,而负面测试则主要根据错误猜测,逆向思维来测试系统,从一定程度上依赖于测试人员的经验积累。
执行负面测试时,不单单要测试系统是否处理了用户的异常操作,还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
简言之负面测试的三部曲就是:
1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;
2、测试系统是否处理了用户的异常操作;
3、检查系统的错误提示是否清晰且充分。
以下是Steve Miller的《Top 10 Negative Test Cases》,概括性的提到了一些做负面测试时经常需要注意的测试。
负面测试用例被设计于用软件未意欲被使用的方式测试软件,它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。
1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题,例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
【补充】其实不只是单引号,基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号,逗号,/,<,>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符,然后在处理用户的输入时套用这个函数就可以避免此类错误了。
2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
【补充】对于强制输入的字段,在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致,错误信息提示是否正确,强制输入的字段是否真的必须输入。
3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求(日期字段,数字字段,电话号码,邮编等等)的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据(数字型字段应该不允许字符或特殊字符,日期型的字段应该允许输入一个正确的日期等等)
【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求,这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)以及系统是否正确识别输入的格式。有些字段对字段的内容有限制,如常见的用户名,不能包含特殊字符,首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)还有不符合内容要求的数据输入时系统是否正确的处理。
4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数(例如,first name必须是50个或更少的字符)。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
【补充】一般对于限制长度的字段,现在开发大多采用限制输入的方法(设置字段的长度)来处理。所以测试时需要测试限制的长度是否合理(和功能说明书或其他参考文档相一致),对于没有限制长度的字段,要测试无穷输入时是否出错,有问题报bug时建议开发人员根据需要限制长度。
5、数字型的边界测试。对于数字型的字段,测试上下边界是非常重要的。例如,如果你正在计算某个账户的利息时,你永远不会输入一个负的利息数给应该赢取利息的账户。因此,你应该尝试用负数测试。同样,如果功能说明书上要求字段在某一个特定的范围(如从10~50),你就应该尝试输入9或51,它应该给出一个得体的信息表示失败。
6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常,整数的范围是从-32,767~32,767,长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目,用这些限制测试以确保不会出现数字的溢出错误。
【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段,尝试输入负整数,负小数,0,正整数,正小数进行测试。
不管是哪种数据库系统,对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
7、日期边界测试。对于日期型的字段,测试上下边界是很重要的。例如,如果你正在检查一个出生日期的字段,很大可能出生日期不能早于150年前。同样,出生日期应该不是将来的某一天。
【补充】一般来说,每种数据库系统的日期都有个范围,如SQL Server最小日期是1753年1月1日,所以如果是输入型的日期字段同样也应该测试早于1753的日期。
8、日期的有效性。对于日期字段,确保不允许无效的日期是很重要的(04/31/2007是一个无效的日期)。测试用例也应该检查闰年(每个第4年和第400年是一个闰年)。
9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户,应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
10、性能的改变。当发布产品的最新版本时,应该有一套运行于识别屏幕(列出信息的屏幕,add/update/delete数据的屏幕等等)速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
【补充】从第一条到第八条是我们在测试字段时常常需要做的测试,一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中,一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里,很少去做这样的比较,除了一些有针对性的性能测试。 -
如何使用QC远程启动QTP
2008-12-18 15:29:25
使用QC远程启动QTP
随着测试团队不断扩大,QTP测试脚本不断增多,我们需要用多台电脑来运行QTP脚本,如果大家要登录到每台机器上去跑脚本,就太不方便了,而且各个机器上的脚本版本还有是否统一的问题。
如果我们能用一台电脑,指挥多台装了QTP的电脑运行脚本,岂不爽哉。
Mercury公司开发的Quanlity Center(简称QC),就可以实现这个功能。
要使用QC远程调用QTP,需要进行一系列的设置才能实现。在这篇文章里,我们把部署了QTP的电脑叫做“测试机”,把远程控制测试机的电脑叫做“控制台”,方便说明。
在测试机装完QTP后,还要安装一个插件:TDPlugin。这个插件的安装程序在安装盘的TDPlugin目录下面,安装后重启。
下面的设置非常重要,在QTP的安装指南中有详细的描述,我这里把几个重点说明一下。安装指南文件名是:QT_Install_Guide.pdf。具体内容在“Modifying DCOM Permissions Manually to Enable Remote QuickTest Execution”这一章。
先要设置windows登录用户的权限,指南文件的说明是假定测试机和控制台都已经加入域,其实不加入域也一样可行,只是设置有些不同。我们这里先讲没有加入域的情况。比如我们用ctrlUser这个用户登录控制台的windows,那么,就必须在测试机里也增加一个同名并且密码也相同的ctrlUser用户,并且把这个用户添加到系统管理员组。
如果两台机器都加入域,就更好办了,比如控制台的登录域用户是ctrlDomainUser,那么只要在测试机的系统管理员组里,添加这个用户即可,也就是说,登录控制台的用户拥有测试机的管理员权限。
下一步是设置测试机的防火墙,主要是开放135端口和添加AQTRmtAgent.exe代理程序到防火墙的例外列表中。
然后是设置DCOM的权限,这里的设置步骤比较多,在安装指南文档里面说的比较清楚,主要是把一些用户和组添加到允许访问的列表中。
设置完DCOM以后,我们打开QTP,在option中的Run分页,把“Allow other Mercury products to run tests and components”选中。
好,现在打开一个Test,然后将QTP和QC连接,把这个Test保存到QC上面。在控制台上登录QC,新建一个测试集,把刚才那个Test加入这个测试集。然后在“主机管理器”里面,把测试机的ip添加进来。回到测试集窗口,把这个Test的“计划主机名”指定为测试机的IP,好,现在运行测试集就大功告成了。
这时测试机的QTP会自动启动,run这个Test,run结束以后,测试结果会自动保存在QC服务器上,我们可以在任意电脑上查看测试结果。 -
如何去测试一个网站?
2008-11-22 10:45:27
现在给你一个网站去测试,
你首先想到的什么?
比如http://www.uuuso.com 这个网站,
希望有人给我点建议,就是我要先考虑哪?
对它的测试包括哪些方面?如果我想自动化的话,我可以录制那些地方?
谢谢先啦!
-
测试视频教程03QTP自动化测试视频
2008-11-04 13:33:53
QTP 学习视频汇总(摘自播布客上的一个帖子)
为了自己查看比较方便,对BOOBOOKE内所有的QTP视频做个汇总贴.你可以下载到本地电脑上观看,方法:每个链接后面加.zip即可
================================================================================
[V] QTP 9的新特性 1 - 英文视频
http://www.boobooke.com/v/bbk1050
是QTP 9软件中自带的视频讲座,英语讲座
[V] QTP 9的新特性 2 - 英文视频
http://www.boobooke.com/v/bbk1051
QTP 9软件中自带的视频讲座,英语发音
[V] QTP 9的新特性 3 - 英文视频
http://www.boobooke.com/v/bbk1052
QTP 9软件自带的视频讲座,英语发音,希望大家喜欢。
这些视频都在QTP 9的安装目录的help目录下面。
help目录包括了QTP全部的联机文档和帮助。
================================================================================
[V] 小布老师QTP系列培训视频 - 1
http://www.boobooke.com/v/bbk1043
本讲讲了QTP的概述,希望大家喜欢。
[V] 小布老师QTP系列培训视频 - 2
http://www.boobooke.com/v/bbk1044
本讲讲了测试规划,希望大家喜欢。
[V] 小布老师QTP系列培训视频 - 3
http://www.boobooke.com/v/bbk1045
本讲讲了录制测试脚本,是使用QTP的第一步,希望大家喜欢。
================================================================================
小强作品-零基础学习软件测试-qtp-目录
1 qtp目录分析
2 qtp界面分析
3 qtp示例程序分析
4 qtp学习指南
5 qtp基本操作录制与回放
6 qtp的三种录制方式
7 增强help步骤
8 checkpoint
9 参数化
10 Tools下的工具介绍
11 qtp插件分析
12 qtp测试用例设计考题
13 vbs
14 recovery Scenarios
15 虚拟对象
16 专家视图测试脚本开发
17 qtp描述性编程
18 qtp测试脚本编写规范
[V] 小强老师系列作品:QTP的安装目录分析
http://www.boobooke.com/v/bbk1590
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP安装后的各个目录,重点介绍了大家需要关注的东西,希望对大家有帮助。
[V] 小强老师系列作品:QTP界面剖析
http://www.boobooke.com/v/bbk1594
本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP的常用界面和菜单选项,希望对大家有帮助。
[V] 小强老师系列作品:QTP示例程序之研究
http://www.boobooke.com/v/bbk1598
本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP自带的示例程序-飞机订票系统,别小看这个示例程序,小程序里面有大文章,且听小强老师给你道来, 希望对大家有帮助。
[V] 小强老师系列作品:QTP学习指南
http://www.boobooke.com/v/bbk1515
在本集中,小强老师根据自己的经验和体会,向刚刚接触QTP的朋友介绍了如何学习QTP的一些方法和经验,希望对大家有帮助。
[V] 小强老师系列作品:QTP脚本的录制和回放
http://www.boobooke.com/v/bbk1591
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP最基本的脚本录制回放的功能,希望对大家有帮助。
[V] 小强老师系列作品:QTP三种录制方式
http://www.boobooke.com/v/bbk1516
这是该系列讲座的第三集。在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP录制脚本的三种模式,希望对大家有帮助。
[V] 小强老师系列作品:QTP检查点之研究
http://www.boobooke.com/v/bbk1595
本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP的重要功能 - 检查点,希望对大家有帮助。
[V] 小强老师系列作品:QTP参数化之研究
http://www.boobooke.com/v/bbk1599
本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP重要的功能-参数化, 希望对大家有帮助。
[V] 小强老师系列作品:QTP的常用工具阐释
http://www.boobooke.com/v/bbk1589
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP附带的常用工具,希望对大家有帮助。
[V] 小强老师系列作品:QTP插件分析
http://www.boobooke.com/v/bbk1689
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP插件的基本知识,希望对大家有帮助。
[V] 小强老师系列作品:QTP认证考试试题分析一则
http://www.boobooke.com/v/bbk1575
小强老师针对想入行软件测试行业的菜鸟级别的朋友,推出了零基础学习软件测试系列培训视频。
在本集中,小强老师根据自己的经验和体会,向刚刚接触QTP的朋友介绍了如何QTP认证考试的一道典型题目的分析.
[V] 小强老师系列作品:QTP中VBS介绍
http://www.boobooke.com/v/bbk1621
在本集中,小强老师给大家介绍了QTP脚本语言VBS的基本知识,希望大家喜欢。
[V] 小强老师系列作品:QTP之场景恢复(Recovery Scenarios)
http://www.boobooke.com/v/bbk1692
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的场景恢复(Recovery Scenarios)的基本知识,希望对大家有帮助。
[V] 小强老师系列作品:QTP中的虚拟对象入门
http://www.boobooke.com/v/bbk1695
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP中虚拟对象的基本知识,希望对大家有帮助。
[V] 小强老师系列作品:QTP之专家视图和测试脚本开发
http://www.boobooke.com/v/bbk1690
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的专家视图,并介绍了脚本开发的几个重要对象,希望对大家有帮助。
[V] 小强老师系列作品:QTP之描述性编程
http://www.boobooke.com/v/bbk1691
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的描述性编程的基本知识,希望对大家有帮助。
[V] 小强老师系列作品:QTP之测试脚本开发规范
http://www.boobooke.com/v/bbk1693
在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP脚本开发的基本规范,希望对大家有帮助。
[V] 小强老师系列作品:QTP脚本的增强一则
http://www.boobooke.com/v/bbk1592
本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了如何对录制的脚本进行增强,希望对大家有帮助。添加一个测试用例!
设计测试用例的常见误区:http://www.boobooke.com/v/bbk1576
小强老师系列作品:测试用例设计 http://www.boobooke.com/v/bbk1527 -
安装QC时出现的两个问题总结
2008-11-03 13:39:07
QC9.0安装时出现的问题及解决办法
前两天老板让我找个合适点的缺陷管理软件,经人介绍我下载了QC9.0,准备自己动手安装。下面是我当时遇到的几个问题:
一、 数据库连接不上的问题
我选择的数据库是SQLserver2000,按着安装指南,一步步走下去,安装到最后一步提示如下图(一)所示:
图(一)
*解决办法:
前提是数据库用户sa和密码确保这个是正确的。
SQL企业管理器中,设置登录的地方,其实这一步在SQL安装的时候是有选项的,如果你选择的是混合模式的话就不会出现这样的问题了,在如下图(二)所示处修改:
图(二)
修改后如图(三)所示:
图(三)
修改成功后,在刚才出错的页面处返回到上一页,然后下一步,填完下一步,OK!
二、 别人无法登录我的主机问题
我QC安装好了后,局域网内的其他同事没法用,链接找不到服务器,很是郁闷,整整弄了一天,卸载重装,等等,都无济于事……最后在群里问了好多人,很多办法但都不好使,最后偶然听人说,把你的windows防火墙给关了,一切问题就解决了!哎,事情原来是这么的简单!搞的我觉都不想睡。
以上的都是我安装的时候出现的问题以及解决的办法,很希望能对你们有用!如果还是安装不成功的话,多去网上搜,对于刚学习这个的你问题出的越多你学会的东西就会越多,加油,一起测试吧!
王者风范,大家闺秀!
标题搜索
我的存档
数据统计
- 访问量: 19076
- 日志数: 21
- 建立时间: 2008-11-03
- 更新时间: 2012-06-11