设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

测试程式的心理与经济效益观点

文档类型：

Adobe Acrobat PDF 文档文档大小：271.96KB

第二章CHAPTER2测试程式的心理与经济效益观点The Psychology and Economics ofProgram Testing对於测试,你可以从许多不同的角度切入,但我想最重要的就是经济性(economics)观点、以及人性心理(human psychology)的观点、其议题包括了进行「完整」测试的可能性,该由谁来进行测试较为适合,以及该以什0样的心态来进行测试才较容易成功,而不是蒙著头完全只从技术性的观点来考量.所以,本章先不讨论技术,而是先讨论心理与经济效益的观点.首先,有一件事情相当重要、我必须花一些功夫来加以说明,一旦这件事弄清楚之後、随之而来的讨论都将会变得自然而简单.这件事就是对「测试」的定义.这里特别强调定义的重要性,是因为失败的测试往往肇因於大部份的人对测试的认知完全错误,例如:「测试就是用来验证我们的程式没有错误」、「测试的目的就是用来看看程式有没有正确地执行」、「测试就是一种过程,使我们有信心说程式真的执行了我们要它做的事」.
以上对测试的想法是不正确的,它们甚至与正确的想法完全相反.想想看,测试是为了增进程式的价值(也就是说,测试是要耗费成本的,我们付出了代价当然要得到更棒的程式),这价值可能指的是程式的品质或是可靠度,增进可靠度意指我们要尽可能地找到程式的错误并剔除错误,根据这个想法,我们不应该只是验证程式有正确执行、相反的,在心理上,我们应该一开始就假设程式里头就隐藏著错误(对绝大部分的程式来说,这根本不只是假设,而是事实),以这个假设为出发点、你才会尽可能地找出更多的错误.据此,一个合适的「测试」定
义是:为找出错误而执行程式的过程.Testing is the process of with the intent of finding errors.
听起来有点微妙难懂,但这对於是否能进行一项成功的测试却有著深远的影响、人类的心理通常是高度目标导向的(goal oriented),一旦在内心里选择了一个目标,就会在潜意识里满足并达成这个目标,所以,如果我们的目标是去验证程式有正确执行、那0我们所选择的测试资料在潜意识里就会倾向於使程式执行成功,因此找到错误的机率将不高,相反地,如果心理上已经认定程式必定有错误,那0我们所设计出来的测试资料就比较会有高度的机率来发现错误.後者的心态对测试而言、显然是比较有价值的.我们在上面对测试所做的定义、其实还隐含了许多的观念,这些观念遍布在
这本书中、例如:这样的定义意指测试是种毁灭性(destructive)的行为、甚至是一种程式的程序,以使程式执行失败,这可以解释出发现错误为何是如此困难,因为这与一般的人性倾向於建设性(constructive)相违背.另外,这项定义也暗示了测试样本该如何设计,以及应该由谁来测试程式.还有一个方法可以加强我们对测试的正确观念,就是,我们来探讨一下什0是「成功的」测试,以及什0是「失败的」测试,这两个字眼是专案管理者常常用来判定测试好坏的字眼,按照字面上的意义、「成功」代表一切OK,而「失败」代表不符期望、有问题,於是,绝大部分的专案管理者都会把一切运作良好的测试归类为「成功的测试」、而把发现到错误的测试归类为「失败的测试」、这就是用错测试定义的结果.想想看,浪费了大笔的时间和金钱却什0错误都找不到的测试真的能归类为「成功」吗成功的测试应该是能找到错误的测试.就好像病人给医生看病、医生也是先诊断、後医疗,而诊断就是一连串的测试,如果测试都正常、不知病因,便无从对症下药,但病人感到不适却是事实,因此我们说这个医生诊断失败,病人得向更好的医生求诊.好的医生会一下子找到病人的毛病.那0,我们通常把程式当病人还是当健康的人来看待呢另外,对於「测试就是用来验证我们的程式没有错误」这种说法,相信我,这是不可能的事情(这个问题即将在後面探讨),即使是一支小程式都不可能,糟的是,对於不可能的事情、我们通常都不会有把这件事情努力做好的心、这种现象可以举一个例子来说明,如果我们要求一个人要在15分钟之内解出一个字谜游戏(crossword puzzle),在前10分钟,你通常可以观察到这个人意兴阑珊解不了多少字谜,因为反正他怎0努力似乎也不可能在15分钟之内完成,如果,我们一开始就给他4个小时,那0你可能看到的是个充满斗志的人、甚至在前10分钟就解出了大部分的字谜.所以,测试是必须定义清楚所需要做到的程度的,使它成为可行且务实的行动,这样在心理上才会有正面效果.还有、把测试视为「验证程式执行了我们所预期它执行的行为」也是不恰当的,因为、程式也有可能执行了我们并不预期它执行的行为.例如第一章的三角形判断程式,纵使在我们所能想得到的情况中、它都能正确地判断不等边三角形,等腰三角形,或是正三角形,但是我们没有想到的情况呢恐怕还是有错误
的可能(例如:它可能判断1,2,3为不等边三角形,或是判断0,0,0为正三角形),这种错误往往藏在我们意想不到的地方、如果我们将测试的目标视为找到错误,而不只是验证我们所预期的情况,就比较不会让这种错误溜掉.简而言之,测试就是尝试找到错误的毁灭性过程,成功的测试就是要想办法让程式当掉.当然,经由测试,最终的目的是建立对程式的信心、保证它会做该做的事,也绝不做它不该做的事,但这都必须从努力地发现错误开始,如果你想要信心十足地拍胸脯大声保证「我的程式真的是完美无缺(error free)」、最好的方式就是找到不完美之处,而不是只输入一些资料来确定程式有正确执行.
测试的经济效益观点(THE ECONOMICS OF TESTING)根据对测试所下的定义、我们接著要问,可能找得到所有的错误吗答案是否定的,即使是支小程式,这通常也是不切实际的,事实上,其实在大部分的情况下都不可能做得到,因为、测试是得花费成本的,你得考虑到经济效益.我们依以下两种测试方法来探讨经济效益的问题.黑箱测试(Black-Box Testing)黑箱测试(black-box)也叫资料驱动(data-driven)或输入输出驱动测试.测试员完全不理会程式内部的结构与行为、只关心寻找程式未按规格运作的情况,因此测试资料纯粹是根据规格所衍生出来的.
如果要用黑箱测试来找出所有的错误,方法就是普测所有可能的输入(exhaustive input testing),也就是将每一种可能输入的情况都视为测试样本.举例来说,或许你用了三个正三角形的测试样本,程式也做出了正确的判断、但并不保证其他你没有使用到的测试样本它都能做出正确的判断、天知道它会不会判断成不等边三角形,所以把程式当作是黑箱,除非你测过所有的情形,否则你无从证明起这样的情况不会发生,你也无法断定说程式已经没有任何错误.於是,你将发现,即使测试样本的数目多到是个天文数字,还是不可能全测,更何况测试样本还不仅只是局限於合理的输入,它应该是泛指所有可能的输入,比如说3,4,5算是个合理的三角形,程式判定它是不等边三角形,但是如果输入的不是数字呢像是2,A,2,它不是个三角形,但是这种输入却是有可能的,程式是不是会将它判定成等腰三角形呢你无从证明起,也无法一网打尽所有的类似情况.听起来实在很糟,测一个判断三角形的小程式已这般棘手,如果要测一个编译器呢那岂不是要把所有可能的程式都要当作测试样本了吗不单是合理正常的程式要测,以确保它能执行编译的功能,甚至连不是程式的东西也要拿来测,才能确保这个编译器不会做出不该做的事-例如,对一个不是程式的东西加以编译.有「记忆」功能的程式更糟糕(例如:作业系统,资料库系统,飞航记录系统),这些程式所执行的事情多半是前後具有关联性的,於是,不只是单独一项功能的合理输入要测,不合理输入要测,他们前前後後参杂在一起的所有情况也都要测.
说了一大堆,所要表达的就是这两点:(1)保证程式绝无错误(error-free)是不可能的.(2)测试是要考虑到经济效益层面的.也就是说,普测所有可能的情况是不切实际的,务实的做法应是尽可能在有限数目的测试样本下来找到最多的错误.於是,我们可能会基於一些合理的假设来作测试(例如:如果程式会将2,2,2判定成正三角形,那我们便假设它也会将3,3,3判定成正三角形),这也是在第四章探讨测试样本设计时所采取的一部份策略.白箱测试(White-Box Testing)白箱测试(white-box)又称逻辑驱动(logic-driven)测试,测试人员必须检测程式内部的结构与行为、测试资料则是根据程式的逻辑来设计(很不幸、我们通常却是根据规格).如果要用白箱测试来找出所有的错误,要用什0方法呢你可能会说将每一行程式都让它执行至少一遍、但很容易说明这0做仍然是不够的,原因将会在第四章深入讨论.唯一的方法就是普测所有可能的执行路径(exhaustive pathtesting),也就是将每一种程式可能执行的路径流向都视为测试样本.
於是,与黑箱测试类似,白箱测试的测试样本数目也很可能多到是个天文数字,也几乎不可能全测.举一个例子来说明,如图2.1所示、每一个圆圈代表一段循序性的程式码(亦即其路径仅有一种、中间不包含其他分支路径),箭头代表控制路径流向的转移,如果程式由A到B是一个可能会执行1到20次的回圈,像这样的小程式会有多少可能的路径呢大约是100兆,算法是事实上,绝大多数的程式都远比图2.1复杂得多,所以普测所有可能的路径就算可能,也不实际.更糟的是,即使你能普测所有可能的路径,测完了也不能保证程式没有错B>20times图2.1 一个小程式的控制流程图
误,这可从三方面来解释:第一、程式本身的设计就不符规格,例如规格是要求一个由小到大的排序,结果程式误设计成由大到小的排序;第二、程式本身在逻辑上就忽略掉某些该设计出来的路径;第三、源於资料敏感的错误,例如我们要利用比较两个数字的值来做收敛(convergence)的运算,也就是去判断这两个数字的差距是否小於某一个值,程式写的像是这样:但如果事实上(A-B)是误写的,应写成ABS(A-B),也就是忘了加上绝对值.以上三种错误,即使最完整的白箱测试也无能为力.结论是,无论是何种普测都是不切实际的,但是,也许、将黑箱与白箱测试两者合并使用,则设计出一种符合经济效益的测试策略应是可行的方向,这些策略将在第四章仔细探讨.测试原则(TESTING PRINCIPLES)依据心理观点、以下列出一些极为重要的测试原则,这些原则多半显而易
见、但却常常被忽略:每个测试样本都必须定义所预期的输出或结果.A necessary part ofatest case isadefinition of the expected output orresult.人都有选择性知觉、也就是倾向於只看他想看的东西(the eye seeing what itwants to see),而人都希望看到正确的结果,所以,如果测试样本的结果没有定义清楚,一些似是而非,看起来好像正确的错误很容易就会忽略过去.为此,测
试样本应明确包含两个部分:输入资料和与之对应的预期输出结果.理则学家Copi曾对这种人类的本性做过探讨[1:人们往往不能接受无法迎合自己期望或偏见的事实,所以,对於那些似是而非的事情、抱持一些信念是必要的.程式设计师应避免测试他自己写的程式.A programmer should avoid attempting to test his or her own program.
这是因为测试是种毁灭性的行为、但是写程式却是建设性的,你叫程式设计师的心态马上从建设性切换成毁灭性是很困难的.还有一个问题是,有的错误是源自於程式设计师本身对规格或解决方式的认知错误,由他自测程式,这项认知错误仍然存在.此外,测试报告是属於批评性的,程式设计师刚写好他的程式後想办法证明他写的程式有一大堆错误,自己批评自己,这是违反人性的.当然,并不表示程式设计师不可能自测程式,只是,如果由别人来测的话通常会比较有效也比较容易成功.但是如果是除错,程式设计师当然是自己程式的最佳除错者.程式设计团队不应测试自己产出的程式.A programming organization should not test its own programs.
理由同上一个原则,另外就是通常程式设计团队的绩效是根据程式的完成日期与所花费的金钱,很难用程式的品质或可靠度来评估绩效,而测试是要耗费时间与金钱的,所以程式设计团队很可能为了绩效而不重视测试.同样地,也并不表示程式设计团队不可能自测程式,只是由别的团队来测的话会比较有效.彻底检视每一个测试结果.Thoroughly inspect the results of each test.
经验显示、有不少比例到最後才发现的错误是在老早的测试报告上就可以轻易发现的,只因之前的测试结果并没有好好审视,才让错误溜过.设计测试样本时,不合理,不被预期的输入情况,与合理,被预期的输入情况同样重要.Test cases must be written for invalid and unexpected, as well as valid andexpected, input conditions.通常我们测试都倾向於输入合理,被预期的资料,例如一个要输入三角形三边长来对三角形作分类的程式,很少人会输入1,2,5来作测试.然而许多与众不同的输入情况却往往比一般性的输入更能发现错误.不要只看看程式是否做了它该做的事,更要看看程式是否做了它不该做的事 to see if it does not do what it is supported to do isonly half of the battle. The other half is seeing whether the program doeswhat it is not supported to do.
这个原则是针对边际效应(side effect)的问题,也就是程式在做完该做的事的同时,是否也造成了一些不该有的影响.例如一个发薪程式,除了产生正常的薪资资料,是否也为不存在的员工产生了薪资资料.除非你要丢弃程式,否则这个程式使用过的测试样本不要丢弃.Avoid throw-away test cases unless the program is 常见的情形是,测试员坐在终端机前天马行空地输入资料来测试程式,即使其中的测试样本有了重大发现,却没有为後来的测试(例如修正错误後或程式改版後的测试)保留这些测试样本,结果到时又必须重新建立一组测试样本,然而这种重复性工作通常人们都倾向於避免它、於是後来的测试往往不及之前的测试来的严谨.不要基於程式没有错误的假设来作测试.Do not planatesting effort under the tacit assumption that no errors willbe found.这是弄错测试定义的结果.还存在於程式里的错误和已发现的错误数目成正比.The probability of the existence of more errors inasection ofaprogramis proportional to the number of errors already found in that section.
这个违反常理的现象可用图2.2来表示、比如说程式中包含A和B两个模组,经过测试,在A模组中发现了五个错误,B模组只发现了一个,这个原则告诉我们A模组将比B模组有更高的机率隐藏著尚未发现到的错误,因此,A模组事实上是非常值得更进一步去进行更严格的测试.换句话说,错误有群聚的特性,虽然目前尚无人为此现象提供一个良好的解释,但实务上却是如此,例如在IBM S370的作业系统中、被使用者发现的错误有47%是落在4%的程式码之
中. 这个现象为我们的测试过程提供了一个很好的指引,如果先前的测试在某些程式码所发现的错误特别多,那0之後的测试则应采取更严谨的态度来对待这些程式码.测试,是一个极度需要创造力并发挥高度智慧的挑战性工作.Testing is an extremely creative and intellectually challenging task.
测试一个大程式很可能比设计一个大程式需要更多的创造力.要侦测出所有的错误是不可能的,之後我们会探讨许多实务上可行的测试方法,不过,它们都需要发挥创造力才能落实於软体专案之中.为了再强化这个章节所强调的概念,在此浓缩了最最最重要的三个原则来作
为结论:测试是为找出错误而执行程式的过程.Testing is the process of with the intent of findingerrors.最有可能找出新错误的测试样本才是好的测试样本.A good test case is one that hasahigh probability of detecting an error.图2.2 仍然隐藏在程式中的错误与已发现错误的关系已发现到的错误数目程式还有错误的机率已找出新错误的测试样本才是成功的测试样本.A successful test case is one that detects an as-yet undiscovered error.
参考资料(REFERENCES)
[1.I.M. Copi, Introduction to Logic. New York: Macmillan, 1968.

pdf文档的标签：测试经济效益心理程式观点

更多推荐标签：鲜花销售餐饮消费调查幼儿园档案数字式转速表论文赵树理商业保险法会议纪要模版红与黑读后感化工安全感想入住宾馆英语中科软笔试项目部门规范糖厂实习总结总量指标保障制度和谐社会建设劳动安全案例演讲稿开头焊接技术课件废水处理系统创新学分制银行结算幼儿园会计论文格式范文移植规范出差总结报告合作函申请承包工程流程图国际热门