您好,欢迎访问三七文档
当前位置:首页 > 建筑/环境 > 工程监理 > 第7章编码与测试-new.
1第七章实现第七章实现(编码与测试)•7.1编码•7.2软件测试基础•7.3单元测试•7.4集成测试•7.5确认测试•7.6白盒测试技术•7.7黑盒测试技术•7.8调试•7.9软件可靠性23第七章实现(编码与测试)7.1编码编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。1、选择程序设计语言程序设计语言是人和计算机通信的最基本的工具,它的特点必然会影响人的思维和解题方式,会影响人和计算机通信的方式和质量,也会影响其他人阅读和理解程序的难易程度。因此,编码之前的一项重要工作就是选择一种适当的程序设计语言。4选择程序设计语言的主要实用标准:(1)系统用户的要求。(2)可以使用的编译程序。(3)可以得到的软件工具。(4)工程规模。(5)程序员的知识。(6)软件可移植性要求。(7)软件的应用领域。52程序设计风格•程序实际上也是一种供人阅读的文章,有一个文章的风格问题。应该使程序具有良好的风格。–源程序文档化–数据说明–语句结构–输入/输出方法6(1)源程序文档化–标识符的命名–安排注释–程序的视觉组织7★符号名的命名•符号名即标识符,包括模块名、变量名、常量名、标号名、子程序名、、数据区名以及缓冲区名等。•这些名字应能反映它所代表的实际东西,应有一定实际意义。例如,表示次数的量用Times,表示总量的用Total,表示平均值的用Average,表示和的量用Sum等。•名字不是越长越好,应当选择精炼的意义明确的名字。必要时可使用缩写名字,但这时要注意缩写规则要一致,并且要给每一个名字加注释。同时,在一个程序中,一个变量只应用于一种用途。8★程序的注释•夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。•注释决不是可有可无的。•一些正规的程序文本中,注释行的数量占到整个源程序的1/3到1/2,甚至更多。•注释分为序言性注释和功能性注释。9序言性注释•通常置于每个程序模块的开头部分,它应当给出程序的整体说明,对于理解程序本身具有引导作用。•序言性注释包括:–程序标题;–有关本模块功能和目的的说明;–主要算法;–接口说明:包括调用形式,参数描述,子程序清单;–有关数据描述:重要的变量及其用途,约束或限制条件,以及其它有关信息;–模块位置:在哪一个源文件中,或隶属于哪一个软件包;–开发简历:模块设计者,复审者,复审日期,修改日期及有关说明等。10功能性注释•功能性注释嵌在源程序体中,用以描述其后的语句或程序段是在做什么工作,或是执行了下面的语句会怎么样,而不要解释下面怎么做。例如,/*ADDAMOUNTTOTOTAL*/TOTAL=AMOUNT+TOTAL上面注视不清楚,如果注明把月销售额计入年度总额,便使读者理解了下面语句的意图:/*ADDMONTHLY-SALESTOANNUAL-TOTAL*/TOTAL=AMOUNT+TOTAL•要点–描述一段程序,而不是每一个语句;–用缩进和空行,使程序与注释容易区别;–注释要正确。11★视觉组织空格、空行和移行•恰当地利用空格,可以突出运算的优先性,避免发生运算的错误。例如,将表达式(A<-17)ANDNOT(B<=49)ORC写成(A<-17)ANDNOT(B<=49)ORC•自然的程序段之间可用空行隔开;•移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐,都从第一格起排列。这样做使程序完全分不清层次关系。•对于选择语句和循环语句,把其中的程序段语句向右做阶梯式移行。使程序的逻辑结构更加清晰。例如,两重选择结构嵌套,写成下面的移行形式,层次就清楚得多。IF(…)THENIF(…)THEN……ELSE……ENDIF……ELSE……ENDIF12(2)数据说明•在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时,则需要注意数据说明的风格。•为了使程序中数据说明更易于理解和维护,必须注意以下几点:a.数据说明的次序应该标准化。有次序易查阅,能加速测试、调试和维护的过程。例如:数据说明数据类型说明①常量说明②简单变量类型说明③数组说明④公用数据块说明⑤所有的文件说明①整型量说明②实型量说明③字符量说明④逻辑量说明13b.当多个变量名在一个语句中说明时,应该按字母顺序排列这些变量。例如,把integersize,length,width,cost,price写成integercost,length,price,size,widthc.如果设计时使用了一个复杂的数据结构,则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。14(3)语句构造构造语句时应该遵循的原则是,每个语句都应该简单而直接,不能为了提高效率而使程序变得过分复杂;也不要刻意追求技巧性,使程序编写得过于紧凑。例如:A[I]=A[I]+A[T];A[T]=A[I]-A[T];A[I]=A[I]-A[T];WORK=A[T];A[T]=A[I];A[I]=WORK;•例如:inti,j;for(i=1;i=n;i++)for(j=1;j=n;j++)V[i][j]=(i/j)*(j/i)for(i=1;i=n;i++)for(j=1;j=n;j++)if(i==j)V[i][j]=1;elseV[i][j]=0;下述规则有助于使语句简单明了:不要为了节省空间而把多个语句写在同一行;尽量避免复杂的条件测试;尽量减少对“非”条件的测试;if(!(char<0||char>9))改成if(char=0&&char=9)不要让读者绕弯子想。避免大量使用循环嵌套和条件嵌套;利用括号使逻辑表达式或算术表达式的运算次序清晰直观。17(4)输入输出在设计和编写程序时应该考虑下述有关输入输出风格的规则:对所有的输入数据都要进行检验,识别错误的输入,以保证每个数据的有效性;检查输入项的各种重要组合的合法性,必要时报告输入状态信息;使得输入的步骤和操作尽可能简单,并保持简单的输入格式;输入数据时,应允许使用自由格式输入;应允许缺省值;18输入一批数据时,最好使用输入结束标志,而不要由用户指定输入数据数目;在交互式输入输入时,要在屏幕上使用提示符明确提示交互输入的请求,指明可使用选择项的种类和取值范围。同时,在数据输入的过程中和输入结束时,也要在屏幕上给出状态信息;当程序设计语言对输入/输出格式有严格要求时,应保持输入格式与输入语句的要求的一致性;给所有的输出加注解,并设计输出报表格式。输入/输出风格还受到许多其它因素的影响。如输入/输出设备(例如终端的类型,图形设备,数字化转换设备等)、用户的熟练程度、以及通信环境等。19(5)程序效率程序的效率是指程序的执行速度及程序所需占用的内存的存储空间。程序编码是最后提高运行速度和节省存储的机会,因此在此阶段不能不考虑程序的效率。20•让我们首先明确讨论程序效率的几条准则–效率是一个性能要求,应当在需求分析阶段给出。软件效率以需求为准,不应以人力所及为准。–好的设计可以提高效率。–程序的效率与程序的简单性相关,不要牺牲程序的清晰性和可读性来不必要地提高效率。21效率问题(1)程序运行时间(2)存储器效率(3)输入输出的效率22(1)程序运行时间•源程序的效率直接由详细设计阶段确定的算法的效率决定,但是,写程序的风格也能对程序的执行速度和存储器要求产生影响。•在把详细设计结果翻译成程序时,总可以应用下述规则:√写程序之前先简化算术的和逻辑的表达式;√仔细研究嵌套的循环,以确定是否有语句可以从内层往外移;√尽量避免使用多维数组;√尽量避免使用指针和复杂的表;√使用执行时间短的算术运算;√不要混合使用不同的数据类型;√尽量使用整数运算和布尔表达式。在效率是决定性因素的应用领域,尽量使用有良好优化特性的编译程序,以自动生成高效目标代码。23(2)存储器效率•在大中型计算机系统中,存储限制不再是主要问题。在这种环境下,对内存采取基于操作系统的分页功能的虚拟存储管理。存储效率与操作系统的分页功能直接有关。•采用结构化程序设计,将程序功能合理分块,使每个模块或一组密切相关模块的程序体积大小与每页的容量相匹配,可减少页面调度,减少内外存交换,提高存储效率。•在微型计算机系统中,存储器的容量对软件设计和编码的制约很大。因此要选择可生成较短目标代码且存储压缩性能优良的编译程序,有时需采用汇编程序。•提高存储器效率的关键是程序的简单性。24(3)输入输出的效率•输入/输出可分为两种类型:–面向人(操作员)的输入/输出–面向设备的输入/输出•如果操作员能够十分方便、简单地录入输入数据,或者能够十分直观、一目了然地了解输出信息,则可以说面向人的输入/输出是高效的。25•关于提高设备输入/输出效率的指导原则:–输入/输出的请求应当最小化;–对于所有的输入/输出操作,安排适当的缓冲区,以减少频繁的信息交换。–对辅助存储(例如磁盘),选择尽可能简单的,可接受的存取方法;对辅助存储的输入/输出,应当成块传送;–对终端或打印机的输入/输出,应考虑设备特性,尽可能改善输入/输出的质量和速度;–任何不易理解的,对改善输入/输出效果关系不大的措施都是不可取的;–任何不易理解的所谓“超高效”的输入/输出是毫无价值的;7.2.1、软件测试的目的1963年,美国,飞往火星的火箭爆炸,损失$10million。原因:FORTRAN循环:DO5I=1,3误写为DO5I=1.3软件测试的工作量约占整个项目工作量的40%左右,对于要求极高的系统测试工作量还要成倍增加。微软Exchange2000和Windows2000中的人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员/开发人员2:51:97.2软件测试基础为什么需要这么多人、花这么多代价进行测试?目的何在?“证明程序正确!”对吗?Myers对软件测试目的提出以下观点:(1)软件测试是为了发现错误而执行程序的过程。(2)一个好的测试用例能够发现至今尚未发现的错误。(3)一个成功的测试是发现了至今尚未发现的错误的测试。28•在测试阶段测试人员努力设计出一系列测试方案,目的却是为了“破坏”已经建造好的软件系统—竭力证明程序中有错误不能按照预定要求正确工作。•暴露问题并不是软件测试的最终目的,发现问题是为了解决问题,测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用。29•通常想象的“测试是为了表明程序是正确的”,“成功的测试是没有发现错误的测试”是不正确的。•测试的目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试,就会设计一些不易暴露错误的测试方案;相反,如果测试是为了发现程序中的错误,就会力求设计出最能暴露错误的测试方案。测试决不能证明软件是正确的,也不能证明错误的不存在,它只能证明错误的存在。30软件测试的问题•软件缺陷是什么?•谁执行测试?–开发者?–单独的测试人员?–两方面人员?•测试什么?–每个部分都测试?–测试软件中高风险部分?•什么时候测试?•怎样测试?•测试应进行到什么程度?31软件缺陷是什么---描述软件失败的术语•缺点(defect)•谬误(fault)•问题(problem)•错误(error)•异常(anomaly)•偏差(variance)•失败(failure)•缺陷(bug)32测试工具软件开发工程师(SoftwareDevelopmentEngineerinTest,简称SDE/T)软件测试人员软件测试工程师(SoftwareTestEngineer,简称STE)33SDE/T负责写测试工具代码,并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。负责理解产品的功能要求,然后对其进行测试,检查软件有没有错误(Bug),决定软件是否具有稳定性,并写出相应的测试规范和测试案例STE347.2.2软件测试准则(1)所有测试都应该能追溯到用户需求。正如上一小节讲过的,软件测试的目标是发现错误。从用户的角度看,最严重的错误是导致程序不能满足用户需求的
本文标题:第7章编码与测试-new.
链接地址:https://www.777doc.com/doc-2112100 .html