软件工程原理与实践（硕士）课件 7 软件质量管理与测试

高级软件工程

SoftwareEngineering软件质量管理与测试软件灾难苏联导弹预警系统软件故障差点导致第三次世界大战（1983年）造价80亿美元的Ariane5型火箭因浮点数溢出，被迫引爆自毁。原因是5型的发射系统直接重用了4型的相应代码，而4型的飞行条件和5型的截然不同（1996年）由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生追尾事故，造成40人死亡，直接经济损失2亿元。原因是信号设备存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的信号机错误显示为绿灯（2011年）区块链业界最大的众筹项目TheDAO遭到攻击，导致300多万以太币资产被盗，原因是其智能合约中splitDAO函数有漏洞（2016年）印尼狮航一架波音737MAX8客机途中坠落，189人罹难，失事原因为软件设计缺陷，飞机的迎角传感器“数据错误”触发“防失速”自动操作，导致机头不断下压，最终坠海（2018年）2问题软件系统功能齐全是不是就是质量好？没有BUG是不是就是软件的质量好？什么是用户满意的软件项目？软件测试是不是软件质量的全部？那么，什么是软件的质量？如何保证软件的质量？302-软件质量管理01-基本概念03-软件评审404-软件测试软件质量的定义ANSI/IEEEStd729-1983定义“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher定义“所有描述计算机软件优秀程度的特性的组合”。5何谓软件质量好明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。软件需求是进行质量度量的基础，与需求不符就是质量不合格指定的标准定义了一组指导软件开发的准则，如果不能遵照这些准则，就极有可能导致质量不好通常有一组隐含需求是不被提及的，如易维护性，如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然值得怀疑6软件的质量属性质量的三种视角：内部、外部、和使用质量ISO/IEC25010:2011《软件工程产品质量》使用周境7ISO/IEC25010(SQuaRE)–Systemandsoftwarequalitymodels产品质量模型（外部质量和内部质量）8使用质量模型9质量与质量特性软件质量是各种质量特性的综合体现但具体产品中各质量特性的重要性与产品类型相关，例如关键任务系统(如银行)强调可靠性和安全性大众娱乐软件强调用户可用性广泛分发的软件服务(银行支付服务等)强调互操作性实时系统特别强调时间效率嵌入式系统特别强调资源效率具有一定用户面的特定领域产品强调可配置性和可维护性10质量特性之间的关系无关互补或依赖易理解性与易操作性可靠性与容错性：特性与子特性冲突安全性与性能可移植性与效率11质量成本12分类质量成本典型成分一致性成本预防成本质量管理体系建立和维持、软件过程改进、培训、工具、供应商评价等评价成本测试、评审、审核等非一致性成本内部故障成本重新设计、工期延期、BUG修复、返工、回归测试、纠错、资源闲置等外部故障成本客户投诉处理、故障处理、处罚及赔偿、市场影响、销售影响等02-软件质量管理01-基本概念03-软件评审1304-软件测试如何进行质量管理？ISO9000：质量计划、质量控制、质量保证、质量改进。ISO12207和SWEBOK

：软件质量保证、验证和确认、软件评审、软件审核、配置管理。SQuBOK：从组织级和项目级进行质量管理。14软件质量管理15项目级软件质量管理16软件质量计划是软件项目计划的子计划内容：质量目标开展质量活动的质量标准、方法、规程和工具验证、确认、评审、测试、审核、问题解决等质量活动和任务的安排开展质量活动的资源、日程和职责质量记录的标识、收集、归档、维护和处理的规程17验证和确认的定义V&V是一个用以分析、评价、测试系统和软件文档以及代码系统的过程，从而尽可能地确保质量、可靠性以及系统需求和目标满意度。

[IEEEStandardGlossary]验证(Verification)是“对系统或单元评价的过程，以确定一个给定的开发阶段的产品是否满足在此阶段开始时所给定的条件”确认(Validation)是“在软件开发过程期间或结束时评价系统或单元的过程，以确定它是否满足给定的需求”我们是否正确地完成了产品?我们是否完成了正确的产品？18质量评价在软件开发和运维过程中，收集与其执行过程、执行结果和成果相关的数据，进行质量评价。评价结果作为判定能否批准接收成果和进度状况的依据，并运用于过程改进。质量评价的对象软件产品（包括中间产品和最终产品）例如，项目在每个开发迭代结束时，都会以本次迭代的软件版本为对象，以软件需求规约为依据，遵循软件产品质量模型，进行正式的产品质量的评价，以确定项目是否进入下一个迭代？需求是否必须改动？软件开发是否需要更多的资源？等。软件过程例如，项目在每个开发迭代结束时，在产品质量评价的同时，对项目过程的质量进行评价，以确定是否要对过程进行修改。尤其当产品质量出现问题时，需分析是否由于过程的问题引起的。19软件质量管理技术20如何检测软件中的缺陷开发活动软件制品缺陷检测活动需求分析软件设计软件实现软件运行需求模型设计模型源代码可执行代码软件系统评审模拟形式化验证代码静态分析软件测试运行时监控静态方法动态方法21可靠性预测符号执行各种方法的缺陷检测效果来源：“美国国防部：软件技术进展”，2010年221)软件评审审查小组评审走查结对编程同级桌查轮查临时评审正式化程度23系统分析和设计需求分析设计编码系统方案评审需求规范评审设计文档评审单元测试集成测试确认测试系统测试2)软件测试验收测试ɑ

测试

ß

测试试运行内部外部项目产品243)代码静态分析不运行代码，通过词法分析、语法分析、控制流分析等技术，对代码进行检查，分析代码的结构，查找代码的问题（例如内存泄漏、安全漏洞、重复代码、未使用变量等），度量代码的质量（例如耦合度、内聚度、复杂度、重用度等）分析对象：源代码、bytecode或二进制代码可以由人工进行，也可以借助代码分析工具进行商用代码分析工具：Understand(多语言)、Sourceinsight(多语言)等开源代码分析工具：PMD和Checkstyle(Java)、flake8和pylint(Python)、SonarQube(多语言)等25常用的代码静态分析技术词法分析：从左至右一个字符一个字符的读入源程序，对构成源程序的字符流进行扫描，通过使用正则表达式匹配方法将源代码转换为等价的符号（Token）流，生成相关符号列表，Lex为常用分析工具。语法分析：判断源程序结构上是否正确，通过使用上下文无关语法将相关符号整理为语法树，Yacc为常用工具。抽象语法树分析：将程序组织成树形结构，树中相关节点代表了程序中的相关代码，目前已有javacc等抽象语法树生成工具。语义分析：对结构上正确的源程序进行上下文有关性质的审查。控制流分析：生成有向控制流图，用节点表示基本代码块，节点间的有向边代表控制流路径，反向边表示可能存在的循环；还可生成函数调用关系图，表示函数间的嵌套关系。数据流分析：对控制流图进行遍历，记录变量的初始化点和引用点，保存相关数据信息。污点分析：基于数据流图判断源代码中哪些变量可能受到攻击，是验证程序输入、识别代码表达缺陷的关键。

264)符号执行

符号执行（symbolicexecution）是指在不执行代码的前提下，用符号值表示代码中变量值，然后模拟程序执行来进行相关分析的技术，分析代码的语义信息。符号执行分为：过程内分析是指只对单个过程的代码进行分析；过程间分析（又称全局分析）指对整个软件代码进行上下文敏感的分析。27intm=M,n=N,q=Q;intx1=0,x2=0,x3=0;if(m!=0){x1=-2;}if(n<12){

if(!m&&q){x2=1;}

x3=2;}assert(x1+x2+x3!=3)分析什么样的输入向量<M,N,Q>的情况下，得到的三个输出变量的和等于35)形式化验证形式化验证用以验证软件是否满足其规约的要求，常用于验证关键软件的安全性主要技术：定理证明(Theoremproving)模型检验（modelchecking）286)模拟

模型的动态模拟用于需求分析与设计模型的质量控制例如：状态图与工作流的模拟运行等目的：更深入地看到需求和设计的完整性、正确性和合理性等，从而确保需求反映了用户的真实要求，设计能满足预期的需求。代码在宿主机/开发环境上的模拟运行模拟目标机/运行环境297)运行时监控系统监控是对运行时软件系统的性能和可靠性等进行实时监视的技术，记录和分析运行日志、轨迹和抛出异常，检查系统的在线服务质量，并及时发现问题。三种监控手段：日志（Logging）、指标（Metrics）、追踪（Tracing）工具举例：Actuator、Prometheus、Grafana、LogStash、APM等308)可靠性预测采用可靠性增长模型定量地评价软件可靠性。可靠性增长模型能根据测试阶段和运行阶段的数据推断出软件可靠性。因为随着测试及运行，缺陷被不断发现与排除，可靠性会随之增长，故称为可靠性增长模型。软件可靠性增长模型一般可分为：故障发生时间模型，如NHPP模型、马尔可夫过程模型等故障发现数量模型，如贝叶斯模型、危险率模型等31七种基本质量工具（7QC）32质量控制图33鱼骨图34Pareto图Pareto法则：80%的缺陷经常由于20%的原因引起的3502-软件质量管理01-基本概念03-软件评审3604-软件测试评审目的提高质量减少软件开发/维护的时间和费用提高生产率提高估算准确性培训EngineeringDocumentsRulesForwritingEng.Docs.软件评审Defects发现缺陷、预防缺陷37投资回报率从4:1到30:1Review:评审方法审查小组评审走查结对编程同级桌查轮查临时评审正式化程度从高到低38审查Inspection最系统化、最严密的评审技术被认为是软件工业中最实用的、最有效的评审方法严格定义的审查过程，明确的分工审查组长、读者、审查者作者、记录员39审查过程初始工件基线工件规划总体会议准备审查会议重写重审40受审查的工件初始工件基线工件规划总体会议准备评审会议重写重审项目计划需求规格说明书概要设计、详细设计系统测试计划、用例和报告代码

等41审查的规划初始工件基线工件规划总体会议准备审查会议重写重审审查组长判断是否已满足审查的进入标准作者和审查组长协同对审查进行规划，确定审查员和时间进度审查会议效率：每小时4~6页

审查人员不超过7人或者更少审查人员可以是开发人员、测试人员、项目经理、用户等42RelativeTeamEfficiency:MajorDefects/timeused(uniquetotal)2367CheckersonteamRelative

Effectiveness:MajorDefectsfoundperpage(totalbyteam).Source:SørenSkogstadNielsen,Denmark’sTechnologicalInstitute(DTI),Lyngby,Denmark(Switch+4543504350).MajorDefectsfoundperPage45MajordefectsfoundperHourNote:thischartisanapproximationandisnotexactEffectivenesspeaksataround5or6checkersEfficiencypeaksataround3to4checkers评审小组人数对效率的影响143审查的准备初始工件基线工件规划总体会议准备审查会议重写重审将需求说明书等到交给每位审查员每个审查员以审查清单为指导，检查文档可能出现的错误，并提出问题75%的错误是在准备阶段发现的44审查会议初始工件基线工件规划总体会议准备审查会议重写重审参加人员：审查组长、作者、记录员、审查人员（选其中一个为读者）每次会议不超过2小时审查目标：尽可能多地发现问题，而不是解决问题递交：会议记录（问题和缺陷）、审查结论45重写初始工件基线工件规划总体会议准备审查会议重写重审由作者根据审查发现的问题，重写文档46重审初始工件基线工件规划总体会议准备审查会议重写重审由审查组长或指派人单独重审由作者重写的文档，确保所有问题得到解决，所有错误得到修改。由审查组长判断：是否已满足审查的退出标准47小组评审TeamReview评审过程计划、准备、开会、返工作者或评审组长主持会议读者这个角色被省略了，改由评审组长询问其他评审者这一部分是否有问题使用记录员使用缺陷检查表48走查Walkthrough评审过程计划、开会、返工作者主持会议，起主导作用，陈述产品常用走查方法使用一些样品数据一步步执行一个模块，和同事一道检查以确保正确的逻辑和行为。使用交互式调试器按脚本执行，脚本描述了一项具体的任务或场景，用以说明系统如何在用户会话中发挥功能49结对编程PairProgramming极值编程XP中的一个实践两个开发者在一个工作站上同时编写同一个程序，进行实时的、持续的、非正式的评审。司机和搭档的角色还要不时地交换。由于搭档的实时评审，结对者可以迅速纠正错误。快速的迭代能使设计和程序更加强壮。结对编程技术除了能应用于编码，还能应用需求、设计、测试等文档。50同级桌查PeerDeskcheck在两次编译之间仔细地检查源代码以保证程序正确执行，这就是桌查。桌查是PSP的组成部分,是一种自评审，不属于同级评审。在同级桌查中，除作者外的一位评审者对工作产品进行检查。评审者可以和作者坐在一起讨论，也可以独立检查。评审完成后，评审者把错误表交给作者，或者两人一起坐下来共同准备错误表，或者简单地将做过标记的工作产品交给作者。要寻找一位足够专业且值得信赖的人担任评审者。51轮查Passaround轮查是由多人组成的并行同级桌查轮查有助于缓和同级桌查的两个主要风险评审者不能及时提供反馈评审效果太糟52选择合适的评审方法评审目标审查小组评审走查结对编程同级桌查轮查查找产品缺陷√√√√√√检查规范的一致性√√

√√检查是否符合标准√

√√检查完整性/正确性√

√

评估可理解性/可维护性√√

√

√证实关键构件的质量√

过程改进√√

测量文档质量√

培训其他组员熟悉产品

√√√

√对方法达成共识

√√√

确保修改和纠错正确

√√

√

寻找可替换的方法

√√

模拟执行程序

√

评审开销最小化

√

5302-软件质量管理01-基本概念03-软件评审5404-软件测试软件测试技术白盒测试黑盒测试基于直觉和经验即兴测试*探索式测试*基于代码控制流测试*基本路径测试*数据流测试基于规约等价类划分*边界值分析*随机测试*基于错误错误猜测*变异测试基于模型因果图/判定表基于有限状态机的测试基于形式化规约的测试专用测试技术（即基于应用类型）面向对象的测试基于构件的测试并发程序的测试基于Web的测试图形用户界面的测试协议一致性的测试实时系统的测试55软件测试的层次56单元测试（unittesting）又称为模块测试，是针对软件结构中独立的基本单元（如函数、子过程、类）进行的测试。单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试驱动开发（testdrivendevelopment）:在详细设计的时候就编写测试用例，然后再编写程序代码来满足这些测试用例。自动化的单元测试:目前最流行的单元测试工具是xUnit系列框架，如JUnit(Java)，CppUnit(C++)，Cunit(C)，Dunit(Delphi)，Nunit(.net)，PhpUnit(PHP)，PyUnit/unittest/pytest(Python)，Jest(Javascript)等等。57单元测试技术–白盒测试白盒测试：基于代码的测试控制流测试数据流测试基本路径测试581）语句覆盖2）判定覆盖（分支）3）条件覆盖4）判定/条件覆盖5）条件组合覆盖6）路径覆盖集成测试（integrationtesting）又称组装测试，根据设计将软件模块组装起来，进行有序的、递增的测试，并通过测试评价它们之间的交互。集成测试重点关注：在把各个软件单元连接起来的时候，穿越单元接口的数据是否会丢失；一个软件单元的功能是否会对另一个软件单元的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个软件单元的误差累积起来，是否会放大，从而达到不能接受的程度。集成测试工具：postman、APIfox、SoapUI等API测试工具；Spring后端应用的集成测试工具SpringBootTest；ReactNative集成测试工具Cavy等59集成测试技术–灰盒测试灰盒测试(白盒+黑盒):基于设计的测试举例：服务端的接口测试，采用Apifox测试工具白盒：API

signature;黑盒：根据API的输入和输出，采用黑盒测试技术进行测试60系统测试（systemtesting）对整个软件系统进行一系列测试，以验证系统是否满足需求规约功能测试性能测试可靠性测试易用性测试安全性测试兼容性测试……61系统测试技术–黑盒测试黑盒测试：基于需求规约的测试等价类划分边界值分析判定表法错误推测法62等价类划分边界值分析

1234条件儿童1100白天时段0110动作票价8折

票价9折

票价不打折

测试用例

TC1TC2TC3TC4判定表法功能测试功能测试（functionalitytesting），又称为正确性测试或一致性测试，其目的是用以确认软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。测试方法采用场景法测试所有用例的所有事件流采用等价类划分、边界值分析、判定表法、错误推测法等进行输入输出的测试人工测试或自动化测试自动化的功能测试工具，又称为回归测试工具，或UI测试工具，例如Web应用的开源Selenium工具App应用的开源Appium工具63性能测试性能测试（performancetesting）用来测试软件在规定条件下，相对于所用资源的数量，可提供适当性能的能力。压力测试（stresstesting），又称强度测试，是一种超常情况下的性能测试。它需要在超常数量、频率或资源的方式下执行系统，以获得系统对非正常情况下（如大数据量的输入、处理和输出，大并发数等）的承受程度。自动化的性能/压力测试工具：HP的Loadrunner开源的Jmeter……64可靠性测试软件可靠性测试（reliabilitytesting）用以测试在故障发生时，软件产品维持规定的绩效级别的能力。

广义的可靠性包括可靠性和可用性可靠性使用MTBF（MeanTimeBetweenFailure）度量。平均故障间隔时间，或称为平均无故障工作时间，指相邻两次故障之间的平均工作时长。易恢复性使用MTTR（MeanTimeToRecover）度量，即平均故障修复时间。可用性计算：MTBF/(MTBF+MTTR)可靠性测试方法：系统运行一段时间，观察正常工作的时间，以及故障发生的频率和修复时间以主动制造故障的方法来验证容灾和恢复能力65易用性测试易用性测试（usabilitytesting）用以评价用户学习和使用软件（包括用户文档）的难易程度、支持用户任务的有效程度、从用户的错误中恢复的能力。易用性测试可以采用模拟用户的方式进行，也可以通过观察用户的操作行为来执行。66易用性原则说明状态可见针对用户的操作，系统能及时反馈操作是否生效环境贴切用户常用操作和大部分系统设计保持一致，不应出现“反人类”的设计用户可控为了避免用户的误操作，系统应支持撤销的功能，并以方便的形式允许用户使用，从而使得用户能够方便地回退到之前的状态一致性系统中同一用语、功能、操作保持一致，同样的语言、同样的情景、操作应该出现同样的结果防错系统应防止用户的误操作易取系统应减少用户记忆负担，把需要记忆的内容放在可见界面上灵活高效系统应提供特定能力以使得用户在使用某些功能时更加灵活、操作更加高效优美简约系统界面上多余的信息会分散用户对有用或者相关信息的注意力，因此界面应贴合实际场景，突出重点，弱化和剔除无关信息容错系统应帮助用户从错误中恢复并将损失降到最低。如果无法自动挽回，则应提供详尽的说明文字和指示方向，而不应该使用代码人性化帮助系统应提供帮助性提示，包括一次性提示、常驻提示、帮助文档等安全性测试（SecurityTesting）

常见的面向Web应用的信息安全测试的测试内容67类型测试内容服务器信息测试运行账号测试；web服务器端口版本测试；HTTP方法测试文件目录测试目录遍历测试；文件归档测试；目录列表测试认证测试验证码测试；认证错误测试；找回、修改密码测试会话管理测试会话超时测试；会话固定测试；会话标识随机性测试授权管理测试横向越权测试；纵向越权测试；跨站伪造请求测试文件上传下载测试文件上传测试；文件下载测试信息泄露测试数据库账号密码测试；客户端源代码测试；异常处理测试输入数据测试SQL注入测试；XML注入测试；LDAP注入测试跨站脚本攻击测试反射型测试；存储型跨站测试；DOM型跨站测