模块测试 百度百科doc.docx
- 文档编号:9492997
- 上传时间:2023-02-04
- 格式:DOCX
- 页数:13
- 大小:29.17KB
模块测试 百度百科doc.docx
《模块测试 百度百科doc.docx》由会员分享,可在线阅读,更多相关《模块测试 百度百科doc.docx(13页珍藏版)》请在冰豆网上搜索。
模块测试XX百科doc
模块测试XX百科
模块测试
百科名片
模块测试是针对概要设计中的一个一个模块来进行测试的,他的重点就是测module与module之间的关系。
Module就是"模块"的意思,ModuleTesting是模块[组件]测试ModuleTesting(模块测试)isconcernedwiththetestingofthesmallestpieceofsoftwareforwhichaseparatespecificationexists.ModuleTesing(模块测试)和UnitTesting(单元测试)ModuleTesting和UnitTesting有相同也有不同,Unittesting属于白盒测试范畴,是针对详细设计中的组成程序的最小的单元所进行的测试。
ModuleTesting属于IntegrationTesting(集成测试)的范围,测试内容是被集成部分之间的关系。
不过在某些环境下IntegrationTesting与Unittesting差别已经不是很大。
模块测试的目的是保证每个模块作为一个单元能正确运行,所以模块测试通常又被称为单元测试。
在这个测试步骤中所发现的往往是编码和详细设计的错误。
单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。
通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
例如,你可能把一个很大的值放入一个有序list中去,然后确认该值出现在list的尾部。
或者,你可能会从字符串中删除匹配某种模式的字符,然后确认字符串确实不再包含这些字符了。
单元测试(模块测试)是由程序员自己来完成,最终受益的也是程序员自己。
可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。
执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
工厂在组装一台电视机之前,会对每个元件都进行测试,这,就是单元测试。
其实我们每天都在做单元测试。
你写了一个函数,除了极简单的外,总是要执行一下,看看功能是否正常,有时还要想办法输出些数据,如弹出信息窗口什么的,这,也是单元测试,老纳把这种单元测试称为临时单元测试。
只进行了临时单元测试的软件,针对代码的测试很不完整,代码覆盖率要超过70%都很困难,未覆盖的代码可能遗留大量的细小的错误,这些错误还会互相影响,当BUG暴露出来的时候难于调试,大幅度提高后期测试和维护成本,也降低了开发商的竞争力。
可以说,进行充分的单元测试,是提高软件质量,降低开发成本的必由之路。
对于程序员来说,如果养成了对自己写的代码进行单元测试的习惯,不但可以写出高质量的代码,而且还能提高编程水平。
要进行充分的单元测试,应专门编写测试代码,并与产品代码隔离。
老纳认为,比较简单的办法是为产品工程建立对应的测试工程,为每个类建立对应的测试类,为每个函数(很简单的除外)建立测试函数。
首先就几个概念谈谈老纳的看法。
一般认为,在结构化程序时代,单元测试所说的单元是指函数,在当今的面向对象时代,单元测试所说的单元是指类。
以老纳的实践来看,以类作为测试单位,复杂度高,可操作性较差,因此仍然主张以函数作为单元测试的测试单位,但可以用一个测试类来组织某个类的所有测试函数。
单元测试不应过分强调面向对象,因为局部代码依然是结构化的。
单元测试的工作量较大,简单实用高效才是硬道理。
有一种看法是,只测试类的接口(公有函数),不测试其他函数,从面向对象角度来看,确实有其道理,但是,测试的目的是找错并最终排错,因此,只要是包含错误的可能性较大的函数都要测试,跟函数是否私有没有关系。
对于C++来说,可以用一种简单的方法区隔需测试的函数:
简单的函数如数据读写函数的实现在头文件中编写(inline函数),所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
我们编写代码时,一定会反复调试保证它能够编译通过。
如果是编译没有通过的代码,没有任何人会愿意交付给自己的老板。
但代码通过编译,只是说明了它的语法正确;我们却无法保证它的语义也一定正确,没有任何人可以轻易承诺这段代码的行为一定是正确的。
幸运,单元测试会为我们的承诺做保证。
编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。
有了单元测试,我们可以自信的交付自己的代码,而没有任何的后顾之忧。
什么时候测试?
单元测试越早越好,早到什么程度?
XP开发理论讲究TDD,即测试驱动开发,先编写测试代码,再进行开发。
在实际的工作中,可以不必过分强调先什么后什么,重要的是高效和感觉舒适。
从老纳的经验来看,先编写产品函数的框架,然后编写测试函数,针对产品函数的功能编写测试用例,然后编写产品函数的代码,每写一个功能点都运行测试,随时补充测试用例。
所谓先编写产品函数的框架,是指先编写函数空的实现,有返回值的随便返回一个值,编译通过后再编写测试代码,这时,函数名、参数表、返回类型都应该确定下来了,所编写的测试代码以后需修改的可能性比较小。
由谁测试?
单元测试与其他测试不同,单元测试可看作是编码?
过了单元测试的代码才是已完成的代码,提交产品代码时也要同时提交测试代码。
测试部门可以作一定程度的审核。
关于桩代码,老纳认为,单元测试应避免编写桩代码。
桩代码就是用来代替某些代码的代码,例如,产品函数或测试函数调用了一个未编写的函数,可以编写桩函数来代替该被调用的函数,桩代码也用于实现测试隔离。
采用由底向上的方式进行开发,底层的代码先开发并先测试,可以避免编写桩代码,这样做的好处有:
减少了工作量;测试上层函数时,也是对下层函数的间接测试;当下层函数修改时,通过回归测试可以确认修改是否导致上层函数产生错误。
在一种传统的结构化编程语言中,比如C,要进行测试的单元一般是函数或子过程。
在象C++这样的面向对象的语言中,要进行测试的基本单元是类。
对Ada语言来说,开发人员可以选择是在独立的过程和函数,还是在Ada包的级别上进行单元测试。
单元测试的原则同样被扩展到第四代语言(4GL)的开发中,在这里基本单元被典型地划分为一个菜单或显示界面。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用,单元测试必须是可重复的,无论是在软件修改,或是移植到新的运行环境的过程中。
因此,所有的测试都必须在整个软件系统的生命周期中进行维护。
经常与单元测试联系起来的另外一些开发活动包括代码走读(Codereview),静态分析(Staticanalysis)和动态分析(Dynamicanalysis)。
静态分析就是对软件的源代码进行研读,查找错误或收集一些度量数据,并不需要对代码进行编译和执行。
动态分析就是通过观察软件运行时的动作,来提供执行跟踪,时间分析,以及测试覆盖度方面的信息。
在明确了什么是单元测试以后,我们可以进行"反调论证"了。
在下面的章节里,我们列出了一些反对单元测试的普遍的论点。
然后用充分的理由来证明这些论点是不足取的。
一旦编码完成,开发人员总是会迫切希望进行软件的集成工作,这样他们就能够看到实际的系统开始启动工作了。
这在外表上看来是一项明显的进步,而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍,推迟了对整个系统进行联调这种真正有意思的工作启动的时间。
在这种开发步骤中,真实意义上的进步被外表上的进步取代了。
系统能够正常工作的可能性是很小的,更多的情况是充满了各式各样的Bug。
在实践中,这样一种开发步骤常常会导致这样的结果:
软件甚至无法运行。
更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面,在个别情况下,这些Bug也许是琐碎和微不足道的,但是总的来说,他们会导致在软件集成为一个系统时增加额外的工期,而且当这个系统投入使用时也无法确保它能够可靠运行。
在实践工作中,进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。
一旦完成了这些单元测试工作,很多Bug将被纠正,在确信他们手头拥有稳定可靠的部件的情况下,开发人员能够进行更高效的系统集成工作。
这才是真实意义上的进步,所以说完整计划下的单元测试是对时间的更高效的利用。
而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。
但这不是必须的,单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。
它仅仅是证明这些代码做了什么这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨,当编码完成以后并且面临代码测试任务的时候,他们就阅读这些代码并找出它实际上做了什么,把他们的测试工作基于已经写好的代码的基础上。
当然,他们无法证明任何事情。
所有的这些测试工作能够表明的事情就是编译器工作正常。
是的,他们也许能够抓住(希望能够)罕见的编译器Bug,但是他们能够做的仅仅是这些。
如果他们首先写好一个详细的规格说明,测试能够以规格说明为基础。
代码就能够针对它的规格说明,而不是针对自身进行测试。
这样的测试仍然能够抓住编译器的Bug,同时也能找到更多的编码错误,甚至是一些规格说明中的错误。
好的规格说明可以使测试的质量更高,所以最后的结论是高质量的测试需要高质量的规格说明。
在实践中会出现这样的情况:
一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。
你怎样做才会有更多的收获,而不仅仅是发现编译器的Bug?
第一步是理解这个单元原本要做什么,---不是它实际上做了什么。
比较有效的方法是倒推出一个概要的规格说明。
这个过程的主要输入条件是要阅读那些程序代码和注释,主要针对这个单元,及调用它和被它调用的相关代码。
画出流程图是非常有帮助的,你可以用手工或使用某种工具。
可以组织对这个概要规格说明的走读(Review),以确保对这个单元的说明没有基本的错误,有了这种最小程度的代码深层说明,就可以用它来设计单元测试了。
我是个很棒的程序员,我是不是可以不进行单元测试?
在每个开发组织中都至少有一个这样的开发人员,他非常擅长于编程,他们开发的软件总是在第一时间就可以正常运行,因此不需要进行测试。
你是否经常听到这样的借口?
在真实世界里,每个人都会犯错误。
即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。
但真正的软件系统是非常复杂的。
真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。
编码不是一个可以一次性通过的过程。
在真实世界中,软件产品必须进行维护以对操作需求的改变作出反应,并且要对最初的开发工作遗留下来的Bug进行修改。
你希望依靠那些原始作者进行修改吗?
这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。
在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。
不管怎样,集成测试将会抓住所有的Bug我们已经在前面的讨论中从一个侧面对这个问题进行了部分的阐述。
这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。
如果软件的单元没有事先进行测试,开发人员很可能会花费大量的时间仅仅是为了使软件能够运行,而任何实际的测试方案都无法执行。
一旦软件可以运行了,开发人员又要面对每个单元进行全面的测试。
这是一件非常困难的事情,甚至在创造一种单元调用的测试条件的时候,要全面的考虑单元的被调用时的各种入口参数。
在软件集成阶段,对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。
最后的结果是测试将无法达到它所应该有的全面性。
一些缺陷将被遗漏,并且很多Bug将被忽略过去。
让我们类比一下,假设我们要清洗一台已经完全装配好的食物加工机器!
无论你喷了多少水和清洁剂,一些食物的小碎片还是会粘在机器的死角位置,只有任其腐烂并等待以后再想办法。
但我们换个角度想想,如果这台机器是拆开的,这些死角也许就不存在或者更容易接触到了,并且每一部分都可以毫不费力的进行清洗。
一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。
这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。
这种后果可能常常会被软件的开发人员所忽视(但是用户可不会这样),这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉,并且会导致对未来的市场产生负面的影响。
相反地,一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。
很多研究成果表明,无论什么时候作出修改都要进行完整的回归测试,在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。
Bug发现的越晚,修改它所需的费用就越高,因此从经济角度来看,应该尽可能早的查找和修改Bug。
在修改费用变的过高之前,单元测试是一个在早期抓住Bug的机会。
相比后阶段的测试,单元测试的创建更简单,维护更容易,并且可以更方便的进行重复。
从全程的费用来考虑,相比起那些复杂且旷日持久的集成测试,或是不稳定的软件系统来说,单元测试所需的费用是很低的。
这些图表摘自实用软件度量(CapersJones,McGraw-Hill1991),它列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍系统测试的三倍(参见条形图)。
(术语域测试(Fieldtest)意思是在软件投入使用以后,针对某个领域所作的所有测试活动)这个图表并不表示开发人员不应该进行后阶段的测试活动,这次测试活动仍然是必须的。
它的真正意思是尽可能早的排除尽可能多的Bug可以减少后阶段测试的费用。
其他的一些图表显示高达50%的维护工作量被花在那些总是会有的Bug的修改上面。
如果这些Bug在开发阶段被排除掉的话,这些工作量就可以节省下来。
当考虑到软件维护费用可能会比最初的开发费用高出数倍的时候,这种潜在的对50%软件维护费用的节省将对整个软件生命周期费用产生重大的影响。
经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug,并且修改它们的成本也很低。
在软件开发的后期阶段,Bug的发现并修改将会变得更加困难,并要消耗大量的时间和开发费用。
无论什么时候作出修改都要进行完整的回归测试,在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。
在提供了经过测试的单元的情况下,系统集成过程将会大大地简化。
开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上,而不是陷入充满很多Bug的单元之中不能自拔。
使测试工作的效力发挥到最大化的关键在于选择正确的测试策略,这其中包含了完全的单元测试的概念,以及对测试过程的良好的管理,还有适当地使用象AdaTEST和Cantata这样的工具来支持测试过程。
这些活动可以产生这样的结果:
在花费更低的开发费用的情况下得到更稳定的软件。
更进一步的好处是简化了维护过程并降低了生命周期的费用。
有效的单元测试是推行全局质量文化的一部分,而这种质量文化将会为软件开发者带来无限的商机。
程序中的每一项功能都是测试来验证它的正确性。
它为以后的开发提供支缓。
就算是开发后期,我们也可以轻松的增加功能或更改程序结构,而不用担心这个过程中会破坏重要的东西。
而且它为代码的重构提供了保障。
这样,我们就可以更自由的对程序进行改进。
编写单元测试将使我们从调用者观察、思考。
特别是先写测试(test-first),迫使我们把程序设计成易于调用和可测试的,即迫使我们解除软件中的耦合。
单元测试是一种无价的文档,它是展示函数或类如何使用的最佳文档。
这份文档是可编译、可运行的,并且它保持最新,永远与代码同步。
自动化的单元测试避免了代码出现回归,编写完成之后,可以随时随地的快速运行测试。
如果要给单元测试定义一个明确的范畴,指出哪些功能是属于单元测试,这似乎很难。
但下面讨论的四个问题,基本上可以说明单元测试的范畴,单元测试所要做的工作。
1、它的行为和我期望的一致吗?
这是单元测试最根本的目的,我们就是用单元测试的代码来证明它所做的就是我们所期望的。
2、它的行为一直和我期望的一致吗?
编写单元测试,如果只测试代码的一条正确路径,让它正确走一遍,并不算是真正的完成。
软件开发是一个项复杂的工程,在测试某段代码的行为是否和你的期望一致时,你需要确认:
在任何情况下,这段代码是否都和你的期望一致;譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。
3、我可以依赖单元测试吗?
不能依赖的代码是没有多大用处的。
既然单元测试是用来保证代码的正确性,那么单元测试也一定要值得依赖。
4、单元测试说明我的意图了吗?
单元测试能够帮我们充分了解代码的用法,从效果上而言,单元测试就像是能执行的文档,说明了在你用各种条件调用代码时,你所能期望这段代码完成的功能。
到这里,我们已经列举了使用单元测试的种种理由。
也许,每个人都同意,是的,该做更多的测试。
这种人人同意的事情还多着呢,是的,该多吃蔬菜,该戒烟,该多休息,该多锻炼…这并不意味着我们中的所有人都会这么去做,不是吗bsp;我们知道,在开发时越早发现BUG,就能节省更多的时间,降低更多的风险。
下图表摘自实用软件度量(CapersJones,McGraw-Hill1991),它列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍,是系统测试的三倍(参见条形图)。
术语:
域测试(Fieldtest)意思是在软件投入使用以后,针对某个领域所作的所有测试活动。
如果你仍然认为在编写产品代码的时候,还是没有时间编写测试代码,那么请先考虑下面这些问题:
1)、对于所编写的代码,你在调试上面花了多少时间。
2)、对于以前你自认为正确的代码,而实际上这些代码却存在重大的bug,你花了多少时间在重新确认这些代码上面。
3)、对于一个别人报告的bug,你花了多少时间才找出导致这个bug的源码位置。
回答完这些问题,你一定不再以"太花时间"作为拒绝单元测试的借口。
2、运行测试的时间太长了。
合适的测试是不会让这种情况发生的。
实际上,大多数测试的执行都是非常快的,因此你在几秒之内就可以运行成千上万个测试。
但是有时某些测试会花费很长的时间。
这时,需要把这些耗时的测试和其他测试分开。
通常可以每天运行这种测试一次,或者几天一次。
3、测试代码并不是我的工作。
你的工作就是保证代码能够正确的完成你的行为,恰恰相反,测试代码正是你不可缺少的工作。
4、我并不清楚代码的行为,所以也就无从测试。
如果你实在不清楚代码的行为,那么估计现在并不是编码的时候。
如果你并不知道代码的行为,那么你又如何知道你编写的代码是正确的呢?
5、但是这些代码都能够编译通过。
我们前面已经说过,代码通过编译只是验证它的语法通过。
但并不能保证它的行为就一定正确。
6、公司请我来是为了写代码,而不是写测试。
公司付给你薪水是为了让你编写产品代码,而单元测试大体上是一个工具,是一个和编辑器、开发环境、编译器等处于同一位置的工具。
7、如果我让测试员或者QA(QualityAssurance)人员没有工作,那么我会觉得很内疚。
你并不需要担心这些。
请记住,我们在此只是谈论单元测试,而它只是一种针对源码的、低层次的,为程序员而设计的测试。
在整个项目中,还有其他的很多测试需要这些人来完成,如:
功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。
8、我的公司并不会让我在真实系统中运行单元测试。
我们所讨论的只是针对开发者的单元测试。
也就是说,如果你可以在其他的环境下(例如在正式的产品系统中)运行这些测试的话,那么它们就不再是单元测试,而是其他类型的测试了。
实际上,你可以在你的本机运行单元测试,使用你自己的数据库,或者使用mock对象。
多数讲述单元测试的文章都是以Java为例,本文以C++为例,后半部分所介绍的单元测试工具也只介绍C++单元测试工具。
下面的示例代码的开发环境是VC6.0。
产品类:
classCMyClass{public:
intAdd(inti,intj);CMyClass();virtual~CMyClass();private:
intmAge;//年龄CStringmPhase;//年龄阶段,如"少年","青年"};建立对应的测试类CMyClassTester,为了节约编幅,只列出源文件的代码:
voidCMyClassTester:
CaseBegin(){//pObj是CMyClassTester类的成员变量,是被测试类的对象的指针,//为求简单,所有的测试类都可以用pObj命名被测试对象的指针。
pObj=newCMyClass();}voidCMyClassTester:
CaseEnd(){deletepObj;}测试类的函数CaseBegin()和CaseEnd()建立和销毁被测试对象,每个测试用例的开头都要调用CaseBegin(),结尾都要调用CaseEnd()。
接下来,我们建立示例的产品函数:
intCMyClass:
Add(inti,intj){returni+j;}和对应的测试函数:
voidCMyClassTester:
Add_int_int(){}把参数表作为函数名的一部分,这样当出现重载的被测试函数时,测试函数不会产生命名冲突。
下面添加测试用例:
voidCMyClassTester:
Add_int_int(){//第一个测试用例CaseBegin();{//1inti=0;//2intj=0;//3intret=pObj-Add(i,j);//4ASSERT(ret==0);//5}CaseEnd();//6}第1和第6行建立和销毁被测试对象,所加的{}是为了让每个测试用例的代码有一个独立的域,以便多个测试用例使用相同的变量名。
第2和第3行是定义输入数据,第4行是调用被测试函数,这些容易理解,不作进一步解释。
第5行是预期输出?
错,ASSERT是VC的断言宏,也可以使用其他类似功能的宏,使用测试工具进行单元测试时,可以使用该工具定义的断言宏。
示例中的格式显得很不简洁,2、3、4、5行可以合写为一行:
ASSERT(pObj-Add(0,0)==0);但这种不简洁的格式却是老纳极力推荐的,因为它一目了然,易于建立多个测试用例,并且具有很好的适应性,同时,也是极佳的代码文档,总之,老纳建议:
输入数据和预期输出要自成一块。
建立了第一个测试用例后,应编译并运行测试,以排除语法错误,然后,使用拷贝/修改的办法建立其他测试用例。
由于各个测试用例之间的差别往往很小,通常只需修改一两个数据,拷贝/修改是建立多个测试用例的最快捷办法。
下面说说测试用例、输入数据及预期输出。
输入数据是测试用例的核心,老纳对输入数据的定义是:
被测试函数所读取的外部数据及这些数据的初始值。
外部数据是对于被测试函数来说的,实际上就是除了局部变量以外的其他数据,老纳把这些数据分为几类:
参数、成员变量、全局变量、IO媒体。
IO媒体是指文件、数据库或其他储存或传输数据的媒体,例如,被测试函数要从文件或数据库读取数据,那么,文件或数据库中的原始数据也属于输入数据。
一个函数无论多复杂,都无非是对这几类数据的读取、计算和写入。
预期输出是指:
返回值及被测试函数所写入的外部数据的结果值。
返回值就不用说了,被测试函数进行了写操作的参数(输出参数)、成员变量、全局变量、IO媒体,它们的预期的结果值都是预期输出。
一个测试用例,就是设定输入数据,运行被测试函数,然后判断实际输出是否符合预期。
下面举一个与成员变量有关的例子:
voidCMyClass:
Grow(intyears){mAge+=years;if(mAge10)mPhase="儿童";elseif(mAge20)mPhase="少年";elseif(mAge45)mPhase="青年";elseif(mAge60)mPhase="中年";elsemPhase="老年";}测试函数中的一个测试用例:
CaseBegin();{intyears=1;pObj-mAge=8;pObj-Grow(years);ASSERT(pObj-mAge==9);AS
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 模块测试 百度百科doc 模块 测试 百度 百科 doc