搜索
软件测试技术介绍上海创景计算机系统有限公司内容•1.软件测试基本概念–1.1为何软件测试–1.2什么是软件测试–1.3软件测试的作用–1.4软件测试公理•2.软件测试技术介绍–2.1静态测试技术–2.2静态分析–2.3动态测试技术•3.软件生命周期中的软件测试–3.1软件测试过程模型–3.2软件开发过程–3.3单元测试–3.4集成测试–3.5系统测试–3.6测试进入条件•4.软件测试管理•随着软件功能越来越强、复杂程度越来越高，导致致命故障越来越多。1.1为何软件测试？•“Thedaythesoftwarecrashed”-福布斯杂志–Tandem-金融交易系统宕机；–AT&T-电话系统；–Chemicalbank-双倍借贷给客户；–IRS向纳税人征收680亿美金税金；–Patriots&Scuds-爱国者导弹故障；–BankofNewYork-236亿美金；–Ariana5-火箭故障；–DSCCommunications-电话系统故障；–…•软件错误开销：–美国航空公司•储运损耗每分钟损失2万美金；–1989-12小时储运损耗–1994-5小时储运损耗–飞行系统故障-$50,000,000损失；–Boeing-每分钟损失5万美金；–美国联邦快递-每分钟损失16.7万美金。1.1为何软件测试？2020年7月16日5•历史上：–1973年W.Hetzel指出测试是对程序或系统能否完成特定任务建立信心的过程。–异议：我们不应该只是为了对一个程序建立信心或显示信心而去作测试。1.2什么是软件测试？•修正观点：–测试目的在于鉴定程序或系统的属性或能力的各种活动，它是软件质量的一种度量。•1983年IEEE：–使用人工或自动手段来运行某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清结果与实际结果之间的差别。2020年7月16日6•软件测试的重要性软件设计与编码过程是引入错误的过程，而软件测试是排除软件错误的过程。1.3软件测试的作用2020年7月16日7确定需求设计编码测试排除故障隔离故障分类改正故障故障故障故障故障等级失效通过测试排除软件故障1.3软件测试的作用2020年7月16日8序号缺陷百分比1需求产生的缺陷20％2设计产生的缺陷30％3编码产生的缺陷35％4软件集成产生的缺陷10％5文档缺陷5％1.3软件测试的作用通过测试排除软件故障2020年7月16日91.测试只能证明错误的存在，而不能表明程序中没有错误。1.4软件测试公理2.测试的两个作用是：确定程序中缺陷的存在；有助于判断该程序在实际上是否可用。3.软件测试最困难的问题之一是知道何时停止测试(Whentostoptesting?)4.自己测试自己的程序是不可能的。5.当一个软件被测出的缺陷数目增加时，更多的未被发现的缺陷存在的概率也随之增加。2020年7月16日106.一个好的测试用例应当是一个对以前未被发现的缺陷有高发现率的用例，而不是一个表明程序工作正确的用例。1.4软件测试公理7.要对有效的和无效的输入状况写测试用例。（测试用例要兼顾有效与无效的输入）8.每个测试用例必备的部分是描述预期的输出。9.像做其它事情一样，测试在其一开始就必须要有一个目标。测试技术静态测试代码审查代码走查桌面检查技术评审静态分析控制流分析数据流分析接口分析表达式分析动态测试黑盒测试技术白盒测试技术2.软件测试技术介绍动态测试控制流覆盖数据流覆盖黑盒测试技术白盒测试技术功能测试等价类划分边值分析因果图随机测试猜错法2.软件测试技术介绍语句覆盖分支覆盖路径覆盖错误处理路径全定义使用路径全使用路径全定义路径数据流异常状态图2020年7月16日13•不执行程序代码，通过审查文档、代码的方式查找软件中的缺陷。2.1静态测试技术–76%以上错误；–不需特别条件，容易开展；–在发现了错误的同时也就定位错误，不需额外的工作定位错误；–对评审人员要求高；–可借助于工具进行。2020年7月16日14•静态测试方法–技术评审•软件需求分析与设计；•对需求规格文档、设计文档进行非二义性、平衡性、一致性检查。–代码走查（Walkthrough）•设计测试数据人工方式执行代码。–代码审查（CodeInspection）2.1静态测试技术2020年7月16日15•代码审查（CodeInspection）2.1静态测试技术–代码审查测试内容：•代码与设计的一致性；•代码对标准的遵循性；•代码的逻辑表达的正确性；•代码结构的合理性。–代码审查实施•审查会•代码审查单2020年7月16日16•静态分析–静态分析是对被测软件进行特性分析的一些方法的总称；–静态分析的查错功能是编译系统所不能替代的；2.2静态分析•静态分析可辅助代码评审人员：–发现可能的程序欠缺；–找到潜伏着问题的根源；–提供间接涉及程序欠缺的信息；–...2020年7月16日17•静态分析方法2.2静态分析–编码规则检查–控制流分析–数据流分析–软件度量分析2020年7月16日18•改善代码质量–避免编程语言本身在使用过程中容易造成的误用；•提高开发速度：–开发人员不需要总是从一些基本原则出发进行决策；•增进团队精神：–有助于减少团队内部在一些小事情上的不必要的争论，使团队成员更易于阅读和维护其他成员的代码；•在正确的方向上取得一致：–使开发人员放开手脚，在有意义的方向上发挥创造力；2.2.1为什么进行编码规则检查2020年7月16日19•C语言本身容易出错的问题–词法”陷阱“–语法”陷阱“–语义”陷阱“–连接–库函数–预处理器–可移植性缺陷2.2.1编码规则检查－改善代码质量2020年7月16日20•＝容易和＝＝混淆；•&和|容易和&&和||混淆；•词法分析中的“贪心法”–y=x/*p/*p指向除数*/–会被编译器理解为/*p/*p指向除数*/为注释•字符与字符串–C语言中的单引号和双引号含义不同，易错用带来问题；–‘s’表示一个整数；–“s”表示一个字符指针；2.2.1编码规则检查－词法“陷阱”2020年7月16日21•运算符的优先级问题；•注意作为语句结束标注的分号–If（ab）big＝a；–If（ab）;big＝a；•“悬挂”else的问题；•switch语句遗漏break；2.2.1编码规则检查－语法“陷阱”2020年7月16日22•指针与数组；•非数组的指针；•作为参数的数组声明；•空指针并非空字符串；•边界计算与不对称边界；•求值顺序；•运算符&&、||和！•整数溢出2.2.1编码规则检查－语义“陷阱”2020年7月16日23•在循环语句中使用“break”语句。#includec_standards.h/*********************************************************Standard31S:Useofbreakstatementinloop********************************************************/voidstatic_31(void){SINT_32i=10;while(i-1){if(i==0){break;}i=i-1;}}2.2.1编码规则检查－典型规则举例2020年7月16日24#includec_standards.h/*********************************************************Standard56S:Equalitycomparisonoffloatingpoint.********************************************************/voidstatic_56(void){FLOAT_32fl,f2;fl=1.01f;f2=2.01f;if(fl==f2){/*...*/}if(fl==0.0f){fl=fl+0.01f;}}2.2.1编码规则检查－典型规则举例•浮点数比较。2020年7月16日25•功能函数无返回值。#includec_standards.h/*********************************************************Standard36S:Functionhasnoreturnstatement.********************************************************/UINT_32static_36(UINT_32p_1,UINT_16p_2){UINT_32y=p_1;/*Notreturningavalue*/}2.2.1编码规则检查－典型规则举例2020年7月16日26•MISRAC/MISRA-C：2004–MISRA国际发动机工业软件可靠性协会组织制定了“汽车软件C语言使用指南”的标准。这份标准的产生在自动化行业极大地推动了使用“安全的C”进行编程。这份标准在汽车行业被广泛接受，同时它也被其它行业所广泛借鉴。•ISO9126–ISO国际标准化组织•IEC61508–IEC国际电工委员会•DERAC–DERA英国防护评估和研究机构2.2.1编码规则2020年7月16日27•在语言的底层面上，前面列出的C语言存在的隐患，在C＋＋中基本都存在，所以从这个角度来看，C语言的大多数规则同样适用于C＋＋；•C＋＋应用比较广泛的编程规则–EllemtelCodingStandards–C＋＋CodeingStandards–MoreEffectiveC++2.2.1关于c++编码规则2020年7月16日28•编码规则主要是针对语言使用本身的；•编程风格主要是针对代码书写风格的；•对于质量“苛刻性”系统，执行严格的编码规则后，弱化了对于编程风格的要求；–规则约束很全面很严格，很大程度上已经完成了编程风格检测所要达到的效果；•对于非质量“苛刻性”系统，执行宽松的编码规则，编程风格的作用就显得比较重要；2.2.1关于编码规则与编程风格2020年7月16日29•编码规则检查实施–项目之初制定编码规则可提高软件产品质量，做到“有法可依”；–培训软件编程人员理解规则；–加强管理，项目进行过程中需严格按编码规则检查，做到“执法必严”；–有效的编码规则检查工具支持；2.2.1编码规则检查的实施•控制流分析–使用控制流程图系统检查程序的控制流程结构；–结构化验证；–分析不合理的控制流程结构：•无条件跳转指令（GOTO语句）使用；•不适当的循环嵌套、分支嵌套；•多重入口、出口；•不允许的递归调用等。2.2.2控制流分析•数据流分析–在控制流基础上分析数据使用情况；•静态数据流分析可帮助查找典型的程序错误：–用错的局域变量和全局变量；–不匹配的参数；–未使用过的变量或标号；–未定义的变量；–不允许的递归；•静态数据流分析包括：–过程函数参数及调用信息分析；–数据流反常分析；–全局变量分析。2.2.3数据流分析•过程或函数调用信息分析:–参数；–全局变量；–函数返回值。•过程或函数调用信息分析用途：–编写程序接口文档；–检测错误。•查找错误时，下列两种情况需特别关注：–存在ClearPath使得输出参数或变量不能正常取值；–存在ClearPath使得过程或函数不能正常返回值。过程或函数参数参数全局变量全局变量全局变量2.2.3数据流分析•典型数据流异常–UR•声明后没有初始化就被引用；•真实错误（genuineerror)–DU•初始化后没有被引用；•可疑错误（suspiciouserror)–DD•两次初始化之间没有被引用；•可疑错误（suspiciouserror)1voidproc()2{3intx,y,z,t;4x=1;5if(y0)6x=2;7/*endif*/8z=x+1;9}102.2.3数据流分析2.2.3数据流分析•一般编译器会进行简单的数据流分析，并且会有相应的警告或者报错信息；•相对于编译器的数据流分析，专业工具的数据流分析更全面更彻底–专业工具是全路径的数据流分析，而编