软件测试4.docx
- 文档编号:29186564
- 上传时间:2023-07-21
- 格式:DOCX
- 页数:75
- 大小:70.85KB
软件测试4.docx
《软件测试4.docx》由会员分享,可在线阅读,更多相关《软件测试4.docx(75页珍藏版)》请在冰豆网上搜索。
软件测试4
做好测试计划和测试用例工作
测试的流程中,测试计划是对整个测试活动的安排,而测试用例则是测试执行的指导,但是,现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性,在项目时间比较紧张的情况下,计划和用例往往成了形式上的东西,甚至有些测试人员脱离用例,完全凭借自己的经验在执行测试活动,对此,你有什么样的看法?
个人认为做好测试计划的编写工作应该从以下几个方面考虑问题:
1、要充分考虑测试计划的实用性,即,测试计划与实际之间的接近程度和可操作性。
编写测试计划的目的在于充分考虑执行测试时的各种资源,包括测试内容、测试标准、时间资源、人力资源等等,准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制,可能受到的各种影响。
说的再明确一点就是要“计划”“如何”去做“测试工作”,而不是“如何编写测试计划”。
2、要坚持“5W1H”的原则,明确测试内容与过程。
明确测试的范围和内容(WHAT);
明确测试的目的(WHY);
明确测试的开始和结束日期(WHEN);
明确给出测试文档和软件册存放位置(WHERE);
明确测试人员的任务分配(WHO);
明确指出测试的方法和测试工具(HOW)。
3、采用评审和更新机制,确保测试计划满足实际需求。
因为软件项目是一个渐进的过程,中间不可避免地会发生需求变化,为满足需求变化,测试计划也需要及时地进行变更。
之所以采取相应的评审制度,就是要对测试计划的完整性、正确性、可行性进行评估,以保证测试的质量。
4、测试策略要作为测试的重点进行描述。
测试策略是测试计划中的重要组成部分,测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素,而测试策略则是说明世纪的测试过程中,应该怎样具体实施。
因此,测试策略一定要描述详尽并且重点突出。
打个不太恰当的比喻,你可以认为测试计划就是测试工作的预期输出,而测试执行是测试工作的实际输出,在预期输出!
=实际输出的情况下,您会认为这样的测试合格么?
至于测试用例工作,我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。
个人认为,测试用例在整个测试工作中的地位和作用主要体现在以下几个方面:
1、测试用例是测试执行的实体,是测试方法、测试质量、测试覆盖率的重要依据和表现形式;
2、测试用例是团队内部交流以及交叉测试的依据;
3、在回归测试中,测试用例的存在可以大大的降低测试的工作量,从而提高测试的工作效率;
4、测试用例便于测试工作的跟踪管理,包括测试执行的进度跟踪,测试质量的跟踪,以及测试人员的工作量的跟踪和考核;
5、在测试工作开展前完成测试用例的编写,可以避免测试工作开展的盲目性;
6、测试用例是说服用户相信产品质量的最佳依据,同时也可以提供给客户作为项目验收的依据。
当我们认识到测试用例在政工测试工作中的地位及其作用之后,相信大家都已经认识到了测试用例对测试工作的重要性和必要性,那么,我们就来讨论一下如何有效的保证测试用例的质量。
1、做好测试人员的项目培训(主要指对需求分析、软件设计、测试计划的认知程度)工作。
要想发挥团队中每一个成员的所有能力,最好的办法就是让他们每一个人都清楚这个项目中的所有细节,以及自己要在这个项目中所承担的责任。
2、尽可能的利用以往其他项目的测试用例;并将该项目中类似模块进行归类,按类编写测试用例,再根据每个模块的特点进行修改,要充分利用测试用例的可重用性。
3、在时间资源紧张的情况下,可以按照测试的关键路径编写测试用例,针对关键路径的测试用例一定要详尽,其他边缘模块的测试用例可以考虑仅通过性测试(既仅证真测试)。
4、采用针对测试用例的模块化编写。
个人建议将测试用例和测试数据分开,测试用例中的操作步骤应主要体现于业务流程的检验,而测试数据主要体现于针对系统的数据处理结果的检验。
考虑到软件项目的需求变更问题,建议将这两项分开,通过测试用例编号进行关联,以应对需求变化造成的测试用例的修改,从而减少测试用例的修改量,缩短项目周期,提高工作效率。
以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解,如有不同意见,请大家及时指出和补充。
自制性能测试类
商业软件包往往价格昂贵,并且需要一个过程之后才能有效地使用它们。
针对这一点,本文拟实现一个简单有效的类,它能自动计算并报告函数、循环和代码块执行的时间。
自动化与简易性设计
利用类对象构造函数和析构函数的执行特性(它们分别在声明和销毁时执行),性能测试类的计时是在构造函数开始的,计算与报告某个操作的执行时间是在析构函数中进行的。
测试仪提供毫秒级的结果。
实现过程中将使用clock()返回程序开始后的处理器时钟时间(与平台相关的时间单位)。
宏CLK_TCK表示特定机器每秒时钟数。
性能测试类定义如下:
#include
classstopwatch
{
public:
stopwatch():
start(clock()){}//开始计时
~stopwatch();
private:
clock_tstart;
};
构造函数将成员start初始化为当前的时钟。
除了析构函数外没有定义其它的成员函数。
析构函数再次调用clock(),计算构造对象后经过的时间并显示结果:
#include
usingnamespacestd;
stopwatch:
:
~stopwatch()
{
clock_ttotal=clock()-start;//获得所用时间
cout<<"此操作所用时间:
"<
cout<<"转换成秒数:
"< } 注意clock_t和CLK_TCK是整数。 因此在进行除法操作前必须将它们转换成double类型。 为了延时屏幕输出,在析构函数中可以加上下列代码: chardummy; cin>>dummy;//延时屏幕输出 另外也可以将不同性能侧面的结果写入性能日志文件。 用所创建的类测试性能 为了对代码块进行测试,先在代码块的开始创建一个本地类实例,假设要测试的代码是下列循环: string*pstr[5000];//指针数组 for(inti=0;i<5000;i++) { pstr[i]=newstring; } 此循环在堆中分配5000个串对象。 用大括弧将上面的代码块括起来并在代码块开始声明类对象实例: { stopwatchwatch;//开始计时 string*pstr[5000]; for(inti=0;i<5000;i++) { pstr[i]=newstring; } }//摧毁计时器并报告结果 根据上面的代码段,当代码开始执行时,计时也开始,当代码退出时,析构函数便显示结果: 此操作所用时间: 27 转换成秒数: 0.027 循环在运行这段代码的机器上耗时27毫秒。 现在对上面的代码段稍做改动,使用栈动态分配内存会得到什么样的性能数据呢? { stopwatchwatch; for(inti=0;i<5000;i++) { strings;//创建并销毁本地的自动创建的串 } } 这段代码运行结果为: 此操作所用时间: 14 转换成秒数: 0.014 可以看出,用栈代替堆分配内存速度提高了50%。 而且使用堆内存的代码还不包括销毁5000个串所用的时间。 使用栈内存的代码不存在这个问题。 由此很容易看出性能差别。 另外,使用堆内存的代码还有5000个赋值操作: pstr[i]=newstring; 将代码改动一下: { stopwatchwatch; for(inti=0;i<5000;i++) { newstring;//不用赋值的堆内存分配 } } 通常的代码是不能这样写的-原因是这样的代码造成严重的内存溢出。 但它把分配操作与其它的变量隔离开了。 这段代码不是以赋值方式进行堆内存分配,这是性能调整时常用的方法,其运行结果如下: 此操作所用时间: 27 转换成秒数: 0.027 也就是说赋值不影响性能。 性能测试常常需要一些技术实践。 开发人员的直觉常会令人误入歧途-直观上开销很大的操作往往对性能影响不大,而一些表面上无所谓的操作象动态内存分配证明了在内存开销上对CPU的依赖。 所以说如果没有可靠的性能测试作为手段,我们是很难发现性能事实的。 自动化测试工具TestComplete7 Automated公司的TestComplete7发布了,展现了很多令人激动的新特性,TestComplete7的口号是: TheEasiestTestCompleteEver. Script-freetestingfornewusers. Power-packedfeaturesforsavvytesters. Easeofuseandlowpriceforall. 誓要改变大众对其一贯的印象,把自己打造成“物美价廉”,功能强大而又简单易用的自动化测试工具形象。 关键字驱动测试 TestComplete一直缺少像QTP一样的关键字测试功能,这让很多初学者感觉其使用的难度较高。 现在好了,TestComplete7增加了关键字测试功能,实现其“Script-freetestingfornewusers”的诺言。 美中不足的是关键字测试与脚本代码不能互相转换,这多少有点让人跌眼镜,看来Automated公司还需要努力加强这方面的功能。 作为弥补,TestComplete7支持在脚本代码中调用关键字测试,例如: SubMain ’Enteryourcodehere. KeywordTests.Test1.Run EndSub 同时也支持在关键字测试视图中调用脚本里定义的过程,例如,对于如下脚本: SubTestCase1 Msgbox"thisisTestCase1" EndSub 可以在关键字视图中通过“RunScriptRoutine”进行调用。 调用函数也是同样的做法,例如对于如下函数: FunctionAdd(a,b) c=a+b Add=c EndFunction 同样可以在关键字测试中调用,调用时输入参数值即可。 在关键字视图的左侧,提供了各种通过关键字编写测试脚本的工具,例如插入条件判断、循环等。 支持PDA测试 对PDA测试的支持是TestComplete7的另外一大亮点。 在TestComplete7中,有专门的扩展用于支持PDA应用程序的测试。 支持的版本包括: WindowsPocketPC2003,WindowsMobile5.0和WindowsMobile6.0。 在ObjectBrowser中,可以查看远程PDA上的进程和对象。 不容忽视的RIA 新版本的TestComplete对RIA应用程序的支持进一步增强,现在,你可以用TestComplete测试Flash、Flex、Silverlight的程序。 TestComplete7支持运行于IE(v5~8)、Firefox(v1.5~3.0)上的Flash和Flex程序。 需要注意的是,对于Firefox,要求FlashPlayer插件的版本是9.0.124.0或以后的版本。 TestComplete7支持Silverlight2的应用程序测试。 通过UIAutomation接口访问Silverlight界面控件。 在这方面,TestComplete比QTP等其他自动化测试工具领先不少(QTP仅支持Flex程序的测试,而且是通过Adobe的FlexBuilder提供的插件来完成的)。 在RIA应用日趋流行的今天,对RIA应用程序的支持是自动化测试工具不容忽视的一项内容。 第三方控件 在TestComplete7中,添加了很多第三方控件的支持,例如DeveloperExpressXtraEditors和XtraBars、InfragisticsNetAdvantage、SyncfusionEssentialStudio、MFCFeaturePackforVisualC++2008、TelerikRadControlsforASP.NET等。 第三方控件是自动化测试过程中碰到问题比较多的地方,TestComplete对众多第三方控件的支持无疑为其增色不少。 在Grid类型的控件方面,TestComplete现在又添加了对以下控件的支持: BorlandTStringGrid DeveloperExpressXtraVerticalGrid、PropertyGridControl和XtraTreeList MicrosoftMFCPropertyGrid RogueWaveStingrayObjectiveGrid.NET SyncfusionGridControl和ScheduleGrid XceedGridfor.NET 尤其值得注意的是,TestComplete7现在支持采用Qt和wxWidgets框架构建的跨平台应用程序。 TestComplete支持MinGW、MicrosoftVisualStudio.NET2003,MicrosoftVisualStudio2005和MicrosoftVisualStudio2008编译的Qt4.5程序。 另外,如果碰到一些自定义的.NET和WPF控件,还可以使用TestComplete提供的SDK来开发插件,这些插件可以大大提供TestComplete与自定义控件的交互能力。 测试命令行应用程序 正当大家在为TestComplete对新技术的支持如此神速而惊叹的时候,TestComplete7还不失时机地添加了对命令行程序的扩展支持。 这对于大家测试一些遗留的骨灰级程序,或者是一些后台服务器上的一些应用程序会比较有用。 TestComplete7为我们提供了一种比较特别的命令行应用程序测试的方式,可通过类似于如下所示的代码来访问命令行应用程序的窗口: Setp=Sys.Process("MyApp") Setw=p.Window("ConsoleWindowClass","*") ... 然后,可以通过如下方式向命令行应用程序发送字符串,就像在命令行中敲入命令一样: Setp=Sys.Process("MyApp") Setw=p.Window("ConsoleWindowClass","*") Callw.Keys("MyString[Enter]"); ... 下一步就是获取命令行应用程序的响应了,在TestComplete中可以通过wText来获取,下面代码展示了一个完整的小例子: SubMyTest Dimp,w,txt,cnt,i,s Setp=Sys.Process("MyApp") Setw=p.Window("ConsoleWindowClass","*") Callw.Keys("MyString[Enter]") ’获取命令行窗口的文本 txt=w.wText ’指定分割符 aqString.ListSeparator=vbNewLine ’获取文本列表的长度 cnt=aqString.GetListLength(txt) Fori=0Tocnt-1 ’获取一行文本的字符串 s=aqString.GetListItem(txt,i) ’把字符串写入日志 CallLog.Message(s) Next EndSub 自动化测试的成功经验分享 FIT(FrameworkforIntegratedTests)是一种通用的开放框架,是由WardCunningham开发的,可以帮助我们进行自动化的确认测试。 自动化测试是轻型开发模式(XP、Crystal等)测试活动的另一个优秀思路也是采取轻型开发模式的必要条件之一。 在只有测试实现了自动化,回归测试才能实现,重构(采取轻型开发模式另外的一个必要条件)才能够贯彻,而迭代也才能够进行。 FIT利用JUnit并扩展了JUnit的测试功能。 长期以来,在软件开发中我们一直关心着两个主要问题: 第一,业务如何通过应用程序与其所需内容通信; 第二,工程师如何验证他们是否正在构建满足业务需要的正确软件。 多年来,为了解决这些关心的问题,已探索了许多方法和框架,但直到出现FrameworkforIntegratedTests(FIT)以后,才找到了解决这些问题的简便而直观的方法。 使用FIT我们可以编写出可以自动运行的确认测试用例,可以用来确认我们所开发出来的软件是否满足了用户所需的功能,可以作为持续构建过程的一部分来确保所构建出来的版本是正确的。 但是,FIT还有另外一个更为重要的功能,那就是在软件开发中增强协作,尤其是开发团队和客户、领域专家之间的协作。 这种协作可以有效地降低软件开发中的不必要的复杂性,加速反馈,并确保最大程度地为客户提供最高的价值。 FIT如何工作 简单来讲,FIT就是一个软件,它能够读取HTML文件中的表格(这些表格可以通过MicroSoftWord或者Excel产生)。 针对每个表格,都会由一个程序员编写的"fixture"(装置)来解释。 该fixture会驱动“被测系统(SUT? SystemUnderTest)”来对表格中给出的测试用例进行检验。 Fixture充当Fit表格和要测试系统间的媒介,起协调作用,完成表格中给出的测试。 FIT中提供了好几种类型的Fixture,它们分别用于处理不同的情形。 Fixture的形式有3种: ColumnFixture(对应于“列”表),“列”表的形式如下所示: CalculateScholarship ScoreScholarship() 10000 19990 2000500 2050500 21001000 22001500 23002000 23502000 24002500 RowFixture(对应于“行”表),“行”表的形式: DiscountGroupOrderedList orderfuturevaluemaxowingminpurchasediscountpercent 1low0.000.000 2low0.002000.003 3medium500.00600.003 4medium0.00500.005 5high2000.002000.0010 ActionFixture,表明以表格给出的测试用例的一系列的操作步骤。 见表1。 表1 fit.ActionFixture startcstc.fitexam.coffeemaker.AddInventory enterunitscoffee3 enterunitsmilk5 enterunitssugar6 enterunitschocolate7 checkcoffeeinventory18 checkmilkinventory20 checksugarinventory21 checkchocolateinventory22 在表1中,第1列给出了执行的命令,这里共有3个命令,但是其它的命令可以根据实际情况在ActionFixture.的子类中进行创建。 上述的3个命令是 Start: 与该Fixture相关联的类的名称 Enter: 该类的一个方法(带有一个变量) Check: 该类的一个方法的返回值(不带变量) 为该表格创建一个ActionFixture类如下: packagecstc.fitexam.coffeemaker; importfit.ActionFixture; publicclassAddInventoryextendsActionFixture{ privateCoffeeMakercm=newCoffeeMaker(); privateInventoryi=cm.checkInventory(); publicvoidunitsCoffee(intcoffee){ cm.addInventory(coffee,0,0,0); } publicvoidunitsMilk(intmilk){ cm.addInventory(0,milk,0,0); } publicvoidunitsSugar(intsugar){ cm.addInventory(0,0,sugar,0); } publicvoidunitsChocolate(intchocolate){ cm.addInventory(0,0,0,chocolate); } publicintcoffeeInventory(){ returni.getCoffee(); } publicintmilkInventory(){ returni.getMilk(); } publicintsugarInventory(){ returni.getSugar(); } publicintchocolateInventory(){ returni.getChocolate(); } } 此fixture将调用下面清单中显示的SUT(被测对象)CoffeeMaker类,然后调用该类上的相关方法。 packagecstc.fitexam.ffeemaker; publicclassCoffeeMaker{ /** *Arrayofrecipesincoffeemaker */ privateRecipe[]recipeArray; /**Numberofrecipesincoffeemaker*/ privatefinalintNUM_RECIPES=4; /**Arraydescribingifthearrayisfull*/ privateboolean[]recipeFull; /**Inventoryofthecoffeemaker*/ privateInventoryinventory; /** *Constructorforthecoffeemaker * */ publicCoffeeMaker(){ recipeArray=newRecipe[NUM_RECIPES]; recipeFull=newboolean[NUM_RECIPES]; for(inti=0;i recipeArray[i]=newRecipe(); recipeFull[i]=false; } inventory=newInventory(); } /** *Returnstrueifarecipeissuccessfullyaddedtothe *coffeemaker *@paramr *@return
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试