![软件工程 第7章:实现1编码风格与测试基础_第1页](http://file4.renrendoc.com/view11/M01/2B/22/wKhkGWWA2dCAO9gJAADo6hfjt9A715.jpg)
![软件工程 第7章:实现1编码风格与测试基础_第2页](http://file4.renrendoc.com/view11/M01/2B/22/wKhkGWWA2dCAO9gJAADo6hfjt9A7152.jpg)
![软件工程 第7章:实现1编码风格与测试基础_第3页](http://file4.renrendoc.com/view11/M01/2B/22/wKhkGWWA2dCAO9gJAADo6hfjt9A7153.jpg)
![软件工程 第7章:实现1编码风格与测试基础_第4页](http://file4.renrendoc.com/view11/M01/2B/22/wKhkGWWA2dCAO9gJAADo6hfjt9A7154.jpg)
![软件工程 第7章:实现1编码风格与测试基础_第5页](http://file4.renrendoc.com/view11/M01/2B/22/wKhkGWWA2dCAO9gJAADo6hfjt9A7155.jpg)
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
第7章:实现编码和测试统称为实现编码:把软件设计结果翻译成程序测试:检测程序并改正错误的过程7.1编码机器语言——几乎不使用汇编语言——特殊场合使用高级语言——优势明显、普遍使用1.选择程序设计语言(1)程序设计语言的划代划代语言特点级别1GL机器语言不直观,出错率高、运行效率高低级2GL汇编语言比较直观,出错率较小与机器码一样长特殊情况下使用3GLBASICPASCALC、C++等利用类英语的语句和命令一条语句相当于5-10条机器码要规定详细的算法过程高级4GL数据库查询语言程序生成器图形语言与自然语言接近一条语句相当于30-50条机器码非过程化问题定义运行开销大,效率低有理想的模块化机制可读性好的控制结构和数据结构便于调试和提高软件可靠性编译时发现错误能力强有良好的独立编译机制(2)选择编程语言的理论标准系统用户的要求可以使用的编译程序可以得到的软件工具工程规模程序员的知识软件可移植性要求软件的应用领域(3)主要的实用标准良好的编码风格:程序代码逻辑清晰,易读、易理解、易维护,能高效利用系统资源等方面。2.编码风格编码风格:又称程序设计风格,是程序设计者在创作中喜欢或习惯使用的表达自己作品的方式。清晰第一、强调效率内部文档、数据说明、语句构造、输入输出、效率恰当的标识符适当的注解程序的视觉组织(1)程序内部的文档数据说明的次序应该标准化多个变量时,应按字母顺序排列复杂的数据结构,应用注明数据结构的方法和特点(2)数据说明不要为了节省空间而把多个语句写在同一行尽量避免复杂的条件测试尽量减少对“非”条件的测试避免大量使用循环嵌套和条件嵌套利用括号使逻辑表达式或算术表达式的运算次序清晰直观(3)语句构造输入数据的检验输入项组合的合法性检查输入格式要简单使用数据结束标记输入要求明确(可选项、边界值)输入格式一致性良好的输出报表给所有输出数据加标志(4)输入输出效率的三个基本原则效率是性能要求(需求分析阶段确定)良好的设计能有效的提高效率不能牺牲清晰性和可读性来提高效率(5)效率运行效率输入输出效率存储器效率简化算术和逻辑的表达式;减小嵌套循环的深度;避免使用多维数组;避免使用指针和复杂的表;使用执行时间短的算术运算;不要混合使用不同的数据类型;尽量使用整数运算和布尔表达式;使用有良好优化特性的编译程序。提高运行效率途径控制结构的功能域明确固定;尽量使用高级语言(硬件要求苛刻时使用紧缩存储器特性的编译程序以及汇编语言);提高执行效率的技术通常也能提高存储器效率。提高存储效率途径关键——简单用户向计算机提供可理解的输入信息计算机向用户提供可理解的输出信息提高输入输出的效率措施良好的人机交互关键——简单输入/输出有缓冲(减少通信次数);简单的辅存访问方法;辅存的输入/输出以块为单位;考虑终端外设的特性,以提高的质量和速度;不采用难以理解的超高效的输入/输出。19例1:注释/*addamounttototal*/TOTAL=AMOUNT+TOTAL/*addmonthly-salestoannual-total*/TOTAL=AMOUNT+TOTAL例2:视觉组织——空格(A<-17)ANDNOT(B<=49)ORC(A<-17)ANDNOT(B<=49)ORC例3:视觉组织——移行与缩进IF(…)THENIF(…)THEN……ELSE……ENDIF……ELSE……ENDIF例4:数据说明标准化INTEGERsize,length,width,cost,priceINTEGERcost,length,price,size,width例5:一行一条语句FORI:=1TON-1DOBEGINT:=I;FORJ:=I+1TONDOIFA[J]<A[T]THENT:=J;IFT<>ITHENBEGINWORK:=A[T];A[T]:=A[I];A[I]:=WORK;ENDEND;FORI:=1TON-1DOBEGINT:=I;FORJ:=I+1TONDOIFA[J]<A[T]THENT:=J;IFT<>ITHENBEGINWORK:=A[T];A[T]:=A[I];A[I]:=WORK;ENDEND;例6:清晰性a1=a1+a2;a2=a1-a2;a1=a1-a2;a0=a2;a2=a1;a1=a0;例7:避免使用空ELSE和IF…THENIF…语句if(char>=’a’)if(char<=’z’)cout<<“Thisisaletter.”;elsecout<<“Thisisnotaletter.”;if(char>=’a’&&char<=’z’)cout<<“Thisisaletter.”;elsecout<<“Thisisnotaletter.”;例8:少用否定条件if(!(char<’0’||char>’9’))if(char>=‘0’&&char<=‘9’)病人生病打喷嚏、发高烧、流鼻涕医生诊断测血压、量体温,是否存在数据异常医生确定症状根源确定病人感冒治疗与处方处方三天后复诊测血压、量心跳发现失效观察错误定位缺陷处理缺陷回归测试测试:为了发现程序中的错误而执行程序的过程1.软件测试的目标7.2软件测试基础成功的测试:发现了以前未发现的错误好的测试方案:有可能发现尚未发现的错误2.软件测试准则测试应能追溯到用户需求;在测试前就制定出测试计划;把Pareto原理应用到软件测试中;从“小规模”测试开始,逐步进行;第三方测试,效果更佳;有用户参与的测试,更完美。测试只能证明缺陷的存在,但绝不能证明缺陷不存在——不可能做穷尽测试3.软件测试的基本原理Dijkstra定律:
假设一段接受六个字符密码的程序,并保证第一个字符必须是数字,其余的是字符数字型。如果我们的目标是穷尽测试,那么需要测试多少个输入数据的组合呢?共有10×(625)=9161328320假设每个组合测试时间10秒,测试这些组合将用2905年。早测试,早发现,早解决目标——在用户发现缺陷之前找到缺陷需求阶段设计阶段编码阶段测试阶段已发现的缺陷正确的需求正确的设计正确的编码需求中的缺陷需求中的缺陷需求中的缺陷需求中的缺陷设计中的缺陷设计中的缺陷设计中的缺陷代码中的缺陷代码中的缺陷没有发现的缺陷早期阶段产生的缺陷传递过程缺陷对软件成本的综合作用10×100×1000×需求设计编码测试交付后代价3W1H(Why、What、Where、How)同样重要!有缺陷的测试用例比有缺陷的产品更危险!测试用例需要逐步完善;缺陷的集群中效应已发现的缺陷尚未发现的缺陷缺陷对软件成本的综合作用缺陷预防和缺陷检测间的精心平衡——钟摆的终结关注缺陷预防关注缺陷检测最后一分钟匆忙质量更依赖测试人员测试者是“英雄”、“对手”占用资源但可得到好的回报质量制度化使质量对用户可见不是一个健康的状态!没有标准,缺陷滋生缺少检测,缺陷到达用户双刃剑过度注重过程缺少检测,缺陷到达用户自信的团队、信任的团队——为“测试”而自豪,就会处理好“所有的一切”DeMarco、Lister《人件》——黑衣团队
职业测试的最大瓶颈是缺乏自信自动化综合症——自动化失败的例子比成功的多重复的劳动必然导致自动化,对自动化缺乏了解必然导致测试的失败根据现有的软件测试知识,以下哪种产品可以认为是高质量的?对自己的答案进行说明。请思考:A产品连续三个版本分别发现0、79和21个缺陷。B产品连续三个版本分别发现85、90和79个缺陷。(1)定义缺陷(Faults)错误(Errors)失效(Failures)4.软件缺陷(Bug)计算机系统或程序中存在的任何破坏正常运行能力的问题、错误,或者隐藏的功能缺陷、瑕疵,导致软件产品在某种程度上不能满足用户的需要。技术问题软件本身团队协作问题(2)缺陷的产生的因素(3)缺陷的构成功能理解特性描述需求变化重视不够沟通不够(4)缺陷的修复代价13-61020-7040-1000Boehm《SoftwareEngineeringEconomic》(5)测试阶段的信息流测试评价调试可靠性模型软件配置测试配置测试结果预期结果错误错误率数据正确可靠性预测测试阶段的信息流7.3软件测试类型软件测试是否运行程序静态测试动态测试功能测试性能测试逻辑功能测试界面测试易用性测试安装测试兼容性测试一般性能测试稳定性测试负载测试压力测试2413其它回归测试冒烟测试随机测试本地化测试ALAC测试阶段单元测试集成测试系统测试验收测试α测试β测试是否查看源代码白盒测试黑盒测试灰盒测试1.黑盒测试和白盒测试功能测试/基于规格说明的测试/数据驱动测试(1)黑盒测试观点:任何程序都可以看作是从输入定义域到输出值域的映射,把被测程序看作一个打不开的黑盒,黑盒里面的内容(实现)是完全不知道的,只知道软件要做什么(功能)。黑盒测试的内容不正确或遗漏了的功能正确地接受输入数据并产生正确地输出界面出错和界面美观问题安装中的出现的问题初始化和终止错误问题操作逻辑问题①测试用例重用——不关心软件实现②缩短项目开发时间——用例设计与软件实现同时进行常用方法:等价类划分、边界值分析、因果图法、错误推测法、状态转换测试、功能图法等。优点(2)白盒测试观点:透明的盒子,能够了解程序的内部结构。测试人员利用程序的内部逻辑结构和相关信息,对程序的内部结构和路径进行测试。研究程序的内部结构,从大量的测试用例中挑选尽可能少的测试用例,来覆盖程序的内部结构。结构测试/透明盒子测试优点:易于定位错误的原因和位置局限性即使白盒测试覆盖了程序中的所有路径,仍不一定能发现程序中的全部错误。这是因为:不能查出程序中的设计缺陷不能查出程序是否遗漏了功能或路径可能发现不了一些与数据相关的错误静态方法代码检查法静态结构分析法代码质量度量法白盒测试方法动态方法逻辑覆盖法基本路径法方法静态结构分析法函数调用图模块控制流图内部文件调用图子程序表宏参数表函数参数表……系统结构数据结构数据接口控制逻辑……代码质量度量法根据ISO/IEC9126国际标准的定义:功能性(Functionality)可靠性(Reliability)可用性(Usability)效率(Efficiency)可维护性(Maintainability)可移植性(Portability)
构造软件的静态质量度量模型,通过量化的数据评估被测程序的质量。(3)灰盒测试1999年,美国洛克希德-马丁公司发表了灰盒测试法的论文,提出了灰盒测试法。单纯从名称上来看,灰盒测试是介于黑盒测试与白盒测试之间的一种测试方式。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例。52灰盒测试与黑盒测试的区别黑盒只要关心系统的边界,不关心模块间协作;灰盒既关心系统的边界,更关心模块间协作。灰盒测试与白盒测试的区别白盒需要深入地了解内部模块的实现细节;灰盒对内部模块依然把它当成一个黑盒来看待。53优点能够进行基于需求的覆盖测试和基于程序路径覆盖的测试;能够保证设计的黑盒测试用例的完整性,防止遗漏软件的一些不常用的功能或功能组合;能够避免由于需求不详细或设计不完整对测试造成的影响。缺点投入的时间比黑盒测试大概多20-40%的时间;对测试人员的要求比黑盒测试高;不如白盒测试深入;不适用于简单的系统。阶段软件测试是否运行程序是否查看源代码其它单元测试集成测试系统测试验收测试静态测试动态测试白盒测试黑盒测试回归测试冒烟测试随机测试功能测试性能测试逻辑功能测试界面测试易用性测试安装测试兼容性测试一般性能测试稳定性测试负载测试压力测试2本地化测试ALAC测试α测试β测试灰盒测试单元测试阶段测试系统测试集成测试验收测试α测试β测试2、阶段测试(1)单元测试方法:白盒测试方法内容:运行结果正确性、容错处理、边界值处理等。测试用例设计:白盒测试工程师或开发人员测试对象:程序(包括注释)、文档单元测试的通过标准程序必须通过所有单元测试用例语句的覆盖率达到100%分支的覆盖率达到85%(2)集成测试将通过测试的单元模块组装成系统或子系统,再进行测试方法:白盒测试方法、黑盒测试方法内容:模块间的接口,单元模块间的协同配合对象:单元测试的模块、《概要设计》文档(3)系统测试系统测试是测试的重点方法:黑盒测试方法内容:软件的功能、性能、运行的软硬件环境。对象:《系统需求规格说明书》、文档、系统(4)验收测试验收测试是指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,用户决定是接收或拒收系统。验收测试又分为α测试和β测试α测试指的是由用户、测试人员、开发人员等共同参与的内部测试。β测试指的是内测后的公测,即完全交给最终用户测试。阶段软件测试是否运行程序是否查看源代码其它单元测试集成测试系统测试验收测试静态测试动态测试白盒测试黑盒测试回归测试冒烟测试随机测试功能测试性能测试逻辑功能测试界面测试易用性测试安装测试兼容性测试一般性能测试稳定性测试负载测试压力测试3本地化测试ALAC测试α测试β测试灰盒测试定义:通过自动化测试工具模拟正常、峰值、异常负载等条件对系统各项性能进行测试。目的:验证用户提出的性能指标,发现系统存在的性能瓶颈,优化系统。3、性能测试一般性能测试性能测试稳定性测试负载测试压力测试压力负载测试响应时间吞吐量并发用户数资源利用率并发性能测试疲劳强度测试大数据量测试客户端发出请求到得到响应的整个过程所经历的时间(1)一般性能测试响应时间响应时间=网络传输时间×2+服务器处理时间+客户端显示时间单位时间内流经被测系统的数据流量(b/s);单位时间内系统处理的客户请求的数量;吞吐量软件系统的性能承载能力并发:指在某一给定时间内,某个特定点上进行会话操作的用户数(陆续交替执行)。并行:用户同时运行,操作步骤相同。并发并行与并发的模拟?指系统各种资源的使用程度如:服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。资源利用率(2)负载测试满足系统的性能指标情况下,系统所能够承受的最大负载量。(3)压力测试通常是指持续不断的给被测系统增加压力,直到将被测系统压垮为止。系统所能承受的最大压力(4)压力负载测试并发性能测试逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析来确定系统并发性能的过程。目的:考察客户端应用性能入口:客户端负载测试+压力测试疲劳强度测试在系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析各项指标来确定系统处理最大工作量强度性能的过程。原则:系统长期不间断运行大数据量测试独立的数据量测试针对某些系统存储、传输、统计、查询等业务进行大数据量测试。综合数据量测试压力测试负载测试相结合的综合测试方案。阶段软件测试是否运行程序是否查看源代码其它单元测试集成测试系统测试验收测试静态测试动态测试白盒测试黑盒测试回归测试冒烟测试随机测试功能测试性能测试逻辑功能测试界面测试易用性测试安装测试兼容性测试一般性能测试稳定性测试负载测试压力测试4本地化测试ALAC测试α测试β测试灰盒测试回归测试其它测试冒烟测试随机测试本
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 2025年汽车行业零部件采购供应合同
- 2025年锂亚电池项目申请报告模稿
- 2025年个人借条合同样本
- 2025年设备租赁与物流协调合同范本
- 2025年个人消费贷款合同简化版
- 2025年医疗物联网平台运营策划协议
- 2025年临时停车楼建设施工合同
- 2025年云计算服务协议样本(电子版)
- 2025年全球企业家保密协议指南
- 2025年供货与采购合作合同
- 贵州省贵阳市2023-2024学年五年级上学期语文期末试卷(含答案)
- 规划课题申报范例:俄罗斯教育改革研究(附可修改技术路线图)
- 运输企业安全事故报告调查处理制度(简单版5篇)
- SAP导出科目余额表和凭证表操作说明及截图可编辑范本
- 仓库货物安全管理
- 服务质量、保证措施
- 端午做香囊课件
- 2024年部编版九年级语文上册电子课本(高清版)
- 墨香里的年味儿(2023年辽宁沈阳中考语文试卷记叙文阅读题及答案)
- 外研版小学五年级上册英语阅读理解专项习题
- 2024-2030年市政工程行业发展分析及投资战略研究报告
评论
0/150
提交评论