软件测试和VSTS 测试工具.docx
- 文档编号:2825327
- 上传时间:2023-05-04
- 格式:DOCX
- 页数:12
- 大小:29.78KB
软件测试和VSTS 测试工具.docx
《软件测试和VSTS 测试工具.docx》由会员分享,可在线阅读,更多相关《软件测试和VSTS 测试工具.docx(12页珍藏版)》请在冰点文库上搜索。
软件测试和VSTS测试工具
软件测试和VSTS测试工具
阅读:
0评论:
0作者:
无宝落凤发表于2010-04-2211:
49原文链接
软件测试和VSTS测试工具收藏在从word拷贝到blog中出现不少排版问题,特此致歉.所有内容均属个人意见,没有任何担保或授权,以"现状"提供。
版权所有]1软件测试和VSTS测试工具本部分介绍各种测试类型,以及它们在VSTS2005中的应用。
在学习讨论之前,阿彪问大家:
我有一个闷在心里好久的问题–bug到底翻译成什么最好?
杂曰:
臭虫,缺陷,错误,地雷,应用程序异常,就用bug好了,大家都理解!
小强!
小强!
大家回头一看,阿毛红着脸说:
我们宿舍里有不少小强,每晚自习回去都要打小强。
众大笑。
阿彪:
我倒是不反对用"小强"。
阿超:
好是好,VSTS也支持改工作项的名字。
就怕我们以后招进来名字中有"强"的同学。
阿彪:
我觉得我可以为"小强"花一颗银弹,我们以后就把"小强"当作bug的同义词.小飞:
那我们怎么翻译"bugfix"?
翻译成"针对缺陷的修改"也太绕口了。
阿毛:
我们是用拖鞋来打小强,所以不妨称之为"拖鞋"。
(大笑)国栋:
我反对把软件工程的术语生活化。
阿超:
说到测试,大家肯定有不少了解,也保不准有一些误解,我们这个讨论就是要去伪存真,把大家的理解统一到一个水平上。
大家知道的"测试方法"有多少?
杂曰:
BlackboxTest,WhiteboxTestCodeCoverage,TestUnitTestFunctionalTest,StructuralTestSystemTest,PerformanceTestStressTest,LoadTestAcceptanceTest,RegressionTestAdhocTest,IntegrationTestAlpha/betaTest,Localization/GlobalizationTestSecurityTest,AccessibilityTest,ScenarioTest,UsabilityTest,SmokeTest二柱:
这么多!
把我都忽悠得有点晕了。
看来我国软件测试人才真是大有用武之地了。
小飞:
这么多名词,是得学几年的,写程序的方法怎么没有这么多花头?
阿超:
咱们还是一个一个来吧。
这么多名词只不过是从各个方面描述了软件测试,并不是说有这么多独立的测试方法,我们把它们分类处理就不难了。
1.1从测试设计的方法分类从测试设计的方法来看,我们知道有两类方法:
Blackbox(黑箱)Whitebox(白箱)这是每个接触过软件测试的人都会给出的答案。
但是这只是整个软件测试的入门。
我们可以跳过去,直接讨论下面的内容。
问:
我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础,还有那一个更难,那一个更有前途,等等。
据说李村数码在搞"灰箱测试",是不是更高级?
能不能简单讲一讲?
阿超:
大家都有这些问题么?
杂曰:
[略去对此问题热烈的争论500字]阿超:
听了大家的争论,看来我们的确得花不少时间统一认识.第一个要注意的问题是,所谓黑箱/白箱,是软件测试设计的方法,不是软件测试的方法!
注意"设计"二字。
黑箱:
在设计测试的过程中,把软件系统当作一个"黑箱",无法了解或使用系统的内部结构及知识。
一个更准确的说法是"BehavioralTestDesign",从软件的行为,而不是内部结构出发来设计测试。
白箱:
在设计测试的过程中,设计者可以"看到"软件系统的的内部结构,并且使用软件的内部知识来指导测试数据及方法的选择。
"白箱"并不是一个精确的说法,因为把箱子涂成白色,同样也看不见箱子里的东西。
有人建议用"玻璃箱"来表示。
在实际工作中,我们不应画地为牢,严格只用某一种方法来设计测试方法。
在实际的测试中,当然是对系统了解的越多越好。
所谓"灰箱"的提法,正是这一反映。
有些人甚至希望我们全部忘记"箱子"和它们的颜色。
我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计,只不过我们在设计时有意不考虑软件的内部结构。
例如:
在测试程序内部基本模块的时候(单元测试),我们通常是要求对程序结构非常了解的程序员来设计,这是因为内部模块的"行为"和程序的外部功能并没有直接的关系,而且内部基本模块的"行为"通常没有明确的定义。
另一个例子是"可用性测试",在设计此类测试的时候,我们没必要纠缠于程序的内部结构,而是着重于软件的界面和行为。
但是软件可用性测试也需要很多专业知识。
这也从一个侧面表明"黑箱"和"白箱"没有简单的高低之分。
一旦测试用例写出来之后,我们大可以忘了它们是从那种颜色的箱子里出来的,用它就可以了。
1.2功能测试以下的测试术语都是主要测试软件的功能。
在下表所列的测试中,测试的范围有小到大,测试者也由内到外–从程序开发人员(单元测试)到测试人员,到一般用户(Alpha/Beta测试)。
测试名称测试内容UnitTest单元测试–在最低的功能/参数上验证程序的正确性FunctionalTest功能测试–验证模块的功能IntegrationTest集成测试–验证几个互相有依赖关系的模块的功能ScenarioTest场景测试–验证几个模块是否能够完成一个用户场景SystemTest系统测试–对于整个系统功能的测试Alpha/BetaTest外部软件测试人员(Alpha/Beta测试员)在实际用户环境中对软件进行全面的测试。
1.3非功能测试一个软件除了基本功能之外,还有很多功能之外的特性,这些叫"non-functionalrequirement",或者"qualityofservicerequirement"-服务质量需求。
没有软件的功能,这些特性都无从表现出来,我们要在软件开发的适当阶段做这些测试。
比如:
测试名称测试内容Stress/loadtest测试软件在负载情况下能否正常工作Performancetest测试软件的效能Accessibilitytest测试软件辅助功能测试–测试软件是否向残疾用户提供足够的辅助功能Localization/GlobalizationTest本地化/全球化测试CompatibilityTest兼容性测试ConfigurationTest配置测试–测试软件在各种配置下能否正常工作UsabilityTest可用性测试–测试软件是否好用SecurityTest软件安全性测试
1.4UnitTest单元测试二柱:
我们也试过用单元测试来保证质量,要求每人都要写,在签入代码前必须通过单元测试。
但是搞了几个星期就不了了之。
大家七嘴八舌的列举了单元测试的问题:
-有时单元测试报了错,再运行一次就好了,后来大家就不想花时间改错,多运行几次,有一次通过就行了。
-单元测试中好多错都和环境有关,在别人的机器都运行不成功。
-花在单元测试上的时间要比写代码的时间还多-单元测试中我们还要测试效能和压力,花了很多时间-我们都这么费劲地测了,那还要测试人员干什么?
1.4.1用VSTS写单元测试单元测试的基本构成Setup//设置好环境,准备测试Test//测试Teardown//打扫战场例子:
我们要写一个银行账户的类,那么它的单元测试应该怎么写?
谁自告奋勇上来表演一下写代码?
小飞,好请上台。
小飞写了下面的代码:
定义interfaceIAccount实现publicclassAccount:
IAccount{}每个函数都使用临时代码好,现在右键按住Account,就可以看到"CreateUnitTests"的菜单,选中之后,会出来新建UnitTests的对话框:
每个函数都可以选中是否产生单元测试。
//解释单元测试的结构//一个缺省的单元测试//修改过的单元测试//运行单元测试//单元测试的结果//代码覆盖率1.4.2好的单元测试的标准单元测试应该准确,快速地保证程序基本模块的正确性。
下面是验证单元测试好坏的一系列标准:
1.4.2.1单元测试应该在最低的功能/参数上验证程序的正确性单元测试应该测试程序中最基本的单元–如在C++/C#/Java中的类,在此基础上,可以测试一些系统中最基本的功能点(这些功能点由几个基本类组成),从面向对象的设计原理出发,系统中最基本的功能点也应该由一个类及其方法来表现。
单元测试要测试API中的每一个方法,及其每一个参数。
1.4.2.2单元测试必须由最熟悉代码的人(程序的作者)来写代码的作者最了解代码的目的,特点,和实现的局限性。
所以,没有比作者适合的人选。
问:
如果我很忙,能不能让别人代劳单元测试?
答:
如果忙到连单元测试都没有时间做,那么你也没有时间写好这个功能。
在一些极限编程的方法中,是可以考虑让别人来做单元测试,但是,程序的作者还是要对单元测试负责。
最好是在设计的时候就写好单元测试,这样单元测试就能体现API的语义,如果没有单元测试,语义的准确性就不能得到保障,以后会产生歧义。
1.4.2.3单元测试过后,机器状态保持不变这样就可以不断地运行单元测试,如果单元测试创建了临时的文件或目录,应该在Teardown阶段把这些临时的文件或目录删除。
如果单元测试在数据库中创建或修改了记录,那么也许要删除这些记录,或者每一个单元测试使用一个新的数据库,这样保证单元测试不受以前单元测试实例的干扰。
1.4.2.4单元测试要快(一个测试运行时间是几秒钟,而不是几分钟)快,才能保证效率。
因为一个软件中有几十个基本模块(类),每个模块又有几个方法,基本上我们要求一个类的测试要在几秒钟内完成。
如果软件有相互独立的几个层次,那么在测试组中可以分类,如数据库层次,网络通信层次,客户逻辑层次,和用户界面层次,可以分类运行测试,比如我只修改了"用户界面"的代码,我只需运行"用户界面"的单元测试。
1.4.2.5单元测试应该产生可重复,一致的结果如果单元测试的结果是错的,那一定是程序出了问题,而且这个错误一定是可以重复的。
问:
如果用随机数以增加测试的真实性,好么?
答:
一般情况下不好,如果某个随机数导致程序出错,但是下一次运行又不能重复这一错误,于事无补。
要注意我们还是要用随机数等办法"增加测试的真实性",但是不是在单元测试中。
单元测试不能解决所有问题,所以也不必期望它会发现所有的缺陷。
1.4.2.6独立性,单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。
程序中的各个模块都是互相依赖的,否则它们就不会出现在一个程序中。
一般情况下,单元测试中的模块可以直接引用其它的模块,并期待其它的模块能返回正确的结果。
如果其它的模块很不稳定,或者其他模块运行比较费时(如进行网络操作),而且对于本模块的正确性并不起关键的作用。
这时可以人为地构造数据以保证这个单元测试的独立性。
NewObjectNewuserGetuserpermission//gothrutheservertogetthecorrectpermission,youcanalsomockthepermissionobject.Object.Test(user)1.4.2.7单元测试应该覆盖所有代码路径,包括错误处理路径,为了保证单元测试的代码覆盖率,单元测试必须测试公开的和私有的函数/方法。
单元测试必须覆盖所测单元的所有代码路径。
问:
啊!
这样岂不是要写很多啰里啰唆的测试方法?
答:
对,因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。
如果你的模块中某个错误处理路径很难到达,那你也许要想想是否可以把这个错误处理拿掉。
[大栓:
这对于那些爱写复杂代码的人是一个很好的惩罚,不对,是一个很好的锻炼。
][阿超:
对,把单元测试的责任和代码作者绑定在一起后,代码作者就能更真切地体会到复杂代码的副作用,因为验证复杂代码的正确性要困难得多。
要注意的一点是:
100%的代码覆盖率并不等同于100%的正确性,请看下列例子]e.g.didn'tcheckreturnvalue.e.g.memoryleak1.4.2.8单元测试应该集成到自动测试的框架中另一个重要的措施是要把单元测试自动化,这样每个人都能很容易地运行,并且单元测试每天都可以运行。
每个人都可以随时在自己机器上运行。
团队一般是在每日构建中运行单元测试,这样每个单元测试的错误就能及时发现并得到修改。
1.4.2.9单元测试必须和产品代码一起保存和维护单元测试必须和代码一起进行版本维护。
如果不是这样,过了一阵,代码和单元测试就会出现不一致,而且所有代码的作者要花时间来确认哪些是程序出现的错误,哪些是由于单元测试更新滞后造成的错误。
这样就失去了单元测试的意义,同时又给大家增加了负担,折腾多次以后,大家就会觉得维护单元测试是一件很费时费力的事。
1.5BVT构建验证测试(BuildVerificationTest)望文生义,构建验证测试是指在一个构建完成之后,团队自动运行的一套验证系统的基本功能的测试。
大多数情况下,这一套系统都是在自动构建成功后自动运行的,有些情况下也会手工运行,但是由于构建是自动生成的,我们也要努力让BVT自动运行。
问:
一个系统有这么多功能点,什么是基本,什么是不基本的?
答:
第一,必须能安装;第二,必须能够实现一组核心场景(例如:
对于字处理软件来说,必须能打开/编辑/保存一个文档文件,但是一些高级功能,如:
文本自动纠错,则不在其中;又如,网站系统,用户可以注册/上载/下载信息,但是一些高级功能,如删除用户,列出用户参与的所有讨论,则不在其中。
在运行BVT之前,可以运行所有的单元测试,这样可以保证系统的单元测试和程序员的单元测试版本保持一致。
不少情况下,开发人员修改了程序和单元测试,但是忘了把更新的单元测试也同时签入源代码库中。
通过BVT的构建可以称为:
可测(self-test),意思是说团队可以用这一版本进行各种测试–因为它的基本功能都是可用的。
通不过BVT的构建称为"不可测"(self-hosed)如果构建测试不能通过,那么自动测试框架会自动对每一个失败的测试产生一个bug(小强)。
一般的做法这些小强都是有最高优先级,是开发人员要首先修改这些小强。
大家知道维持每日构建,并产生一个可测的版本是软件开发过程质量控制的基础。
对于导致问题的小强,我们该怎么办?
1.找到导致失败的原因,如果原因很简单,程序员可以马上修改,然后直接提交。
2.找到导致失败的原因的修改集,把此修改集剔出此版本(程序员必须修改好后再重新提交到源代码库中)。
3.程序员必须在下一个构建开始前把此小强修理好。
方法1/2都可以使今天的构建成为"可测",但是有时各方面的修改互相依赖,不能在短时间内解决所有问题,只能采用第三个办法。
问:
有人提到一种"smoketest",冒烟测试,是什么回事?
答:
这事实上是一种基本验证测试,据说是从硬件设计行业流传过来的说法–当年设计电路板的时候,很多情况下,新的电路板一插上电源就冒起白烟,烧坏了,如果插上电源后没有冒烟,那就是通过了"冒烟测试",可以进一步测试电路板的功能了。
我们正在讨论的BVT也是一种冒烟测试。
1.6功能测试(functionaltest)测试团队拿到一个"可测"等级的构建,他们就会按照测试计划,测试各自负责的模块和功能,这个过程可能会产生总共10来个bug,也可能产生100个以上的bug,那么如何保证我们有效地测试了软件,同时我们在这一步怎样衡量构建的质量?
在MSF敏捷模式中,我们建议还是采用场景来规划测试工作在"基本场景"的基础上,我们把所有系统目前理论上支持的场景都列出来,然后按功能分类测试,如果测试成功,就在此场景中标明"成功",否则,就标明"失败",并且把失败的情况用一个(或几个)"小强"/bug来表示。
当所有的测试人员完成对场景的测试,我们自然地就得出了一个表:
场景ID场景名测试结果Bug/小强id3024用户登录成功3026用户按价格排序失败50323027用户按名字搜索失败5033…………
这样我们就能很快地报告"功能测试56%通过"等等。
如果所有场景都能通过,(有些情况下可以把此标准从100%降低到90%左右)则这个构建的质量是"可用",意味着这一个版本可以给用户使用。
这种情况下,客户,合作伙伴可以得到这样的版本–这也是所谓"技术预览版",或"社区预览版"的由来。
但是,有一个重要的问题要大家注意"可用",并不是指软件都没有bug,而是指在目前的用户场景中,按照场景的要求进行的操作,都能得到预期的效果。
1.目前还没有定义的用户场景中,程序质量如何,还未得而知。
a.场景中没有考虑到多种语言设置2.不按照场景的要求进行的操作,结果如何,还未得而知。
a.如:
在某一场景中,场景规定用户可以在最后付款前取消操作,回到上一步,如果一个测试人员发现在反复提交/取消同一访问多次,然后网页出现问题,这并不能说明用户场景失败,当然这个极端的bug也必须找出原因并在适当的时间改正。
这种测试有时也被称为"acceptancetest",因为如果构建通过了这样的测试,这一个构建就被测试团队"接受了"。
同时,还有对系统各个方面进行的"接收"测试,如测试系统的全球化,或者针对某一语言环境做的测试。
1.7AdhocTest,ExploratoryTest"探索式"的测试"AdHoc"原意是指"特定的,一次性的"。
什么叫"特定"测试?
或者"探索式"的测试?
就是为了某一个特定目的进行的测试,就这一次,以后一般也不会重复测试。
在软件工程的实践中,"adhoc"大部分是指随机进行的,探索性的测试。
比如:
测试人员阿毛拿到了一个新的构建,按计划是进行模块A的功能测试,但是他灵机一动,想看看另一个功能B做得如何,或者想看看模块A在某种边界条件下会出现什么问题,于是他就"adhoc"一把,居然在这一功能模块中发现了不少小强。
"adhoc"也意味着测试是尝试性的,"我来试试,在这个对话框中一通乱按,然后随意改变窗口大小,看看会出什么问题…",如果没问题,那么以后也不会再这么做了。
一般情况下,测试人员不会花很多时间进行特定测试,但是在一些缺乏管理的团队中,很多时候测试人员不知道自己此时应该做什么,只好做一些看似"adhoc"的测试,比如随机测试各个功能的各个方面。
这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例中。
在一个团队中,"adhoc"太多是一个管理不好的标志,因为"adhoc"是指那些一时想到要做,但是以后也没有计划经常重复的测试计划。
问:
我听说有人是"adhoc"测试的高手,这是什么意思?
答:
有很多测试人员会按部就班地进行测试,但是还有一些人头脑比较灵活,喜欢另辟蹊径,测试一些一般人不会想到的场景,这些人往往会发现更多的小强。
开发人员对这样的"adhoc"高手是又爱又恨。
问:
同时看问题要分两方面,有些"adhoc"发现的小强在正常使用软件中几乎不会出现,我们要不要花时间"adhoc"?
答:
现在一些成功的通用软件的用户以百万计,按部就班的测试计划很难包括很多实际的场景,这时,"adhoc"测试能够发现重要的问题;另外一些风险很大的领域,例如安全性,一旦出了问题,威胁就会相当大,这时要多鼓励一些"adhoc"测试,以弥补普通测试的不足。
从这个意义上说,"adhoc"测试可以用来衡量当前测试用例的完备性,如果你探索了半天,都没有发现什么在现有测试用例之外的问题,那就说明现有的测试用例是比较完备的。
"adhoc"测试的测试流程是不可重复的,因为它的测试都是"特定"测试,没法重复。
由于这一原因,"adhoc"测试不能自动化,就这一点而言,还达不到CMM的第二级–可重复级。
作为管理人员来说,如果太多小强是在"adhoc"出来的,那我们就要看看测试计划是否基于实际的场景,开发人员的代码逻辑是否完善,等等。
同时,要善于把看似"adhoc"的测试用例抽象出来,包括到以后的测试计划中。
1.8RegressionTest回归测试问:
我听说不少关于RegressionTest的介绍,但是它到底是怎么"回归"法?
回归到哪里去?
我还是没搞懂。
答:
Regress的英语定义是:
returntoaworseorlessdevelopedstate.是倒退,退化,退步的意思。
在软件工程中,如果一个模块或功能以前是正常工作的,但是在一个新的构建中出了问题,那这个模块就出现了一个"退步"-regression,从正常工作的稳定状态退化到不正常工作的不稳定状态。
在一个模块的功能逐步完成的同时,和此功能有关的测试用例也同样在完善中。
一旦有关的测试用例通过,我们就得到此模块的功能基准(baseline).在某某版本,某某模块的某某测试用例是通过的!
如果测试人员发现了在新的构建版本某个测试用例失败了,这就是一个"倒退",在新版本上运行所有已通过的测试用例以验证没有"退化"情况发生,这个过程就是一个"regressiontest".如果这样的"倒退"是由于模块的功能发生了正常变化(由于设计变更的原因),那么测试用例的基准就要修改,以和新的功能保持一致。
针对一个bugfix(拖鞋),我们也要作RegressionTest,a)验证新的代码的确把缺陷改正了,b)同时要验证新的代码没有把模块的现有功能破坏,没有regression。
所以我不也知道"回归测试"是如何的"回归",我们可以理解为"回归到以前不正常的状态"。
回归测试最好要自动化,因为对于每一个构建都要运行所有回归测试,以保证尽早发现问题。
1.9Scenario/integration/SystemTest场景/集成/系统测试在软件开发的一定阶段,我们要对一个软件进行全面和系统的测试,以保证软件的各个模块都能共同工作,在各方面都能满足用户的要求。
这时的测试叫系统/集成测试。
问:
什么时候做系统测试?
是不是越快越好?
答:
原则上是当一个模块稳定的时候,就可以把它集成到系统中,和整个系统一起进行测试,通常在软件产品需要阶段性发布的时候。
问:
有一种叫ScenarioTest,是什么意思?
答:
就是以场景为驱动的集成测试,关于"场景",大家可以看专门的介绍。
这一方法的核心思想是:
当用户使用一个软件的时候,他/她并不会独立使用各个模块,而是把软件做为一个整体来使用的。
我们在做场景测试的时候,就需要考虑在现实环境中用户使用软件的流程是什么样,然后模拟这个流程,看看软件能不能达到用户的需求。
这样,能使软件符合用户使用的实际需求。
用一个数字照片编辑软件为例,这个软件的各个模块都是独立开发的,可是用户有一定的典型流程,如果这个流程走得不好,哪怕某个模块的质量再高,用户也不会满意。
1.把照相机的储存卡插入电脑2.程序会跳出窗口提示用户导入照片3.导入照片4.对照片进行快速编辑a.调整颜色b.调整亮度,对比度c.修改红眼5.把其中几幅照片用email发送这里面每一步出了问题,都会影响用户对这一产品的使用,同时这里面各个模块的用户界面如果很不一致(即使是ok/cancel按钮的次序不同),用户使用起来也很不方便。
这些问题都是在单独模块的测试中不容易发现的。
1.10PerformanceTest效能测试用户使用软件,不光是希望软件能够提供一定的服务,而且还要求服务的质量要达到一定的水平,软件的效能,是这些"非功能需求",或者说"服务质量需求"的一部分。
效能测试要验证的问题是:
软件在设计负载内能够提供令用户满意的服务质量。
1.在设计负载内–我们要定义什么是正常的设计负载2.令用户满意的服务质量–我们要定义什么样的质量是令用户满意的设计负载–从需求说明出发,得出系统的正常负载。
例如,一个购物网站,客户认为正常负载是每分钟20次客户请求。
用户满意的质量–同一个购物网站,如果客户定义满意为:
每个用户的请求都能在2秒钟内返回结果。
我们可以逐步细化–设计负载的细化,上面我们只提到"20次客户请求",那这些客户请求到底是什么,我们可以按照请求发生的频率来分类:
1.用户登录(10%)2.用户查看某商品详情(50%)3.用户比较两种商品(10%)4.用户查看关于商品的反馈(20%)5.用户购买商品(5%)6.所有其他请求(5%)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件测试和VSTS 测试工具 软件 测试 VSTS 工具
![提示](https://static.bingdoc.com/images/bang_tan.gif)