软件测试与质量保证 课件全套 李克文 第1-12章 软件测试基础 - 验收测试

第1章软件测试基础本章内容2软件质量软件测试软件缺陷二三一本章内容3软件质量软件测试软件缺陷二三一软件的复杂性软件复杂性的主要三个方面：软件规模无限膨胀软件失效行为的复杂软件工程过程的复杂4软件的复杂性软件规模无限膨胀5大致时间软件名称代码规模/行20世纪90年代天基红外系统卫星软件2.5万2009年波音787飞机航空电控系统650万2010年通用公司的福特汽车车载计算软件1000万2015年F-35机载软件1200万2020年Linux内核代码2700万最著名的8大严重软件错误事件-1丰田（Toyota）的意外加速问题早在1992年，驾驶员就报告他们的丰田汽车出现意外的加速（UA）问题。从那时起，由于导致UA的硬件和软件问题的结合，最终有52人在丰田车祸中丧生。MichaelBarr和PhilipKoopman教授在2013年Bookout与Toyota的诉讼中担任专家证人。他们发现的软件问题包括缓冲区溢出、无效指针、竞争条件和堆栈溢出。6最著名的8大严重软件错误事件-2苹果的“gotofail”漏洞2014年2月，Apple发布了有关SSL/TLS的安全更新。罪魁祸首是“gotofail;”导致后面的语句无法访问的语句7最著名的8大严重软件错误事件-3火星气候轨道器（MarsClimateOrbiter）早在1999年，由美国国家航空航天局喷气推进实验室建造的耗资3.276亿美元的火星气候轨道器项目以错误的角度接近了红色星球，导致了航天器的灭亡。8什么地方出了错？发现工程团队的不同部分正在使用不同的度量单位。一组研究推进器的单位是英制磅秒；另一个使用公制牛顿秒。最著名的8大严重软件错误事件-4约克城号航空母舰（USSYorktown）1997年9月21日，Yorktown号上的“远程数据库管理器”中的除零错误使网络上的所有计算机瘫痪，导致船舶的推进系统出现故障。9一名乘务员在数据库中输入一个空白字段。空白被视为零，并导致数据库程序无法处理的“除以零”异常。它中止了MicrosoftWindowsNT4.0操作系统，该系统崩溃了，所有舰船的LAN控制台和远程终端都崩溃了。最著名的8大严重软件错误事件-5阿丽亚娜5火箭，航班501（Ariane5Rocket,Flight501）1996年6月，阿丽亚娜5号火箭进行了首次飞行，称为501航班。火箭发射后37秒自毁，导致任务失败，损失约3.7亿美元。失败是由于数据从64位浮点值转换为16位带符号整数值而导致整数溢出。10最著名的8大严重软件错误事件-6爱国者导弹系统（PatriotMissileSystem）爱国者导弹系统是旨在击落敌机的地对空导弹系统。1991年2月，一枚敌方导弹袭击了沙特阿拉伯的美国部队兵营，当时一连串爱国者导弹未能拦截进来的飞毛腿导弹。结果是有28名死亡士兵和100多名其他人员伤亡。11确定的原因是系统时钟中的软件错误——累积的时钟漂移使系统运行的时间越长，恶化的情况就越多。最著名的8大严重软件错误事件-7莫里斯蠕虫（TheMorrisWorm）1988年，小罗伯特·莫里斯（RobertMorris，Jr.）发布了Internet蠕虫，它雄辩地指出了Internet的脆弱性以及对更高安全性的需求。他使用gets()函数导致BerkeleyUnixfinger守护程序中的缓冲区溢出导致了数千台计算机的瘫痪。12最著名的8大严重软件错误事件-8放疗事故（Therac-25）在1985年6月至1987年1月之间，有六名患者因计算机控制的放射治疗机Therac25的大量过量辐射而严重受伤或丧生。检测到的软件问题包括竞争条件和算术溢出。13软件质量的内涵14软件质量是客户满意度的体现客户+质量?软件质量IEEE定义，软件质量是： 1.系统、部件或者过程满足规定需求的程度。 2.系统、部件或者过程满足顾客或者用户需要或期望的程度。另外的关于软件质量的定义:符合明确陈述的功能和性能需求,明确文档化了的开发标准和所有专业开发软件预期的隐含特征。15软件质量特征(ISO／IEC25010:2023)16质量特性子特性定义与示例功能适用性功能完整性、正确性、适当性确保功能覆盖用户需求性能效率时间特性、资源利用率、容量高并发系统的响应速度兼容性共存性、互操作性多系统共享资源互不干扰交互能力包容性、可学习性、用户粘性、容错性支持无障碍设计可靠性成熟性、容错性、易恢复性、可用性系统故障后快速恢复安全性保密性、完整性、不可抵赖性、真实性、可核查性数据加密与权限控制可维护性模块化、易分析性、可复用性代码低耦合设计灵活性适应性、易安装性、可扩展性跨平台兼容无害性风险识别、故障安全、安全集成高风险系统自动停机保护软件质量特征(ISO／IEC25010:2023)功能适应性：软件产品在规定条件下满足指定的或隐含的需求的程度17功能完备性functionalcompleteness与软件功能覆盖所指定任务和用户目标有关的属性功能正确性functionalcorrectness与软件按照所要求精度的提供正确结果有关的属性功能适合性appropriateness与软件提供的功能有助于完成指定的任务和目标有关的属性新增重点：强调功能需符合新兴技术场景（如人工智能）的需求适应性。软件质量特征(ISO／IEC25010:2023)性能效率：在规定条件下使用资源数量的程度18时间特性timebehaviour与软件执行其功能时响应和处理时间以及吞吐量有关的属性资源利用率resourceutilization与在软件执行其功能时所使用的资源数量及其使用时间有关的属性容量capacity与软件参数最大限度满足需求有关的属性更新：新增对能源消耗的关注（如绿色计算场景）。软件质量特征(ISO／IEC25010:2023)兼容性：软件在执行所需功能时，与其它软件、系统或组件共享相同硬件或软件环境，可以交互信息相关的属性19共存性co-existence软件在与其它软件共享相同的环境与资源时执行所需的功能，而未对其它软件产生不利影响的属性互操作性interoperability表示两个或多个软件或组件间交换信息与使用已交换信息相关的属性新增：支持跨平台技术（如容器化部署）的兼容性评估。软件质量特征(ISO／IEC25010:2023)交互能力：用户与软件之间交换信息的能力可辨识性用户能否快速识别功能适用性可学习性用户学习成本可操作性与用户为操作和运行控制所花努力有关的软件属性用户错误防止与软件保护用户不犯错误相关的属性用户粘性（用户界面美观度）界面设计对用户体验的持续吸引力包容性支持残障人士的无障碍访问软件质量特征(ISO／IEC25010:2023)可靠性：与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性21成熟性maturity与由软件故障引起失效的频度有关的软件属性可用性availability与软件在使用时可操作和可访问有关的属性容错性fault

tolerance与在软件故障或违反指定接口情况下，维持规定的性能水平的能力有关的软件属性易恢复性recoverability与在失效发生后，重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和努力有关的软件属性软件质量特征(ISO／IEC25010:2023)安全性：用户或其它软件在访问一个软件的信息和数据时，该软件是否按照他们的类型与授权级别对信息与数据保护的相关的一组属性保密性与软件确保数据只对具有访问权限用户访问有关的属性完整性与软件防止未授权访问或修改计算机程序或数据有关的属性不可否认性与当某种行为或事件发生后，能够确保该行为或事件不能否认有关的属性可核查性与一个实体的行为可以追溯到该实体有关的软件属性真实性与一个主体或资源可以被证明是所生成的身份有关的软件属性进不来

拿不走看不懂

改不了跑不掉新增：针对AI系统的数据隐私保护要求。软件质量特征(ISO／IEC25010:2023)维护性：与进行指定的修改所需的努力有关的一组属性模块性指程序由若干独立的组件构成，当修改一个模块时对其它模块的影响降到最低易修改性与进行修改、排除错误或适应环境变化所需努力有关的属性易测试性与确认已修改软件所需的努力有关的属性易重用性与软件的资产可被其它软件复用有关的属性易分析性与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的属性软件质量特征(ISO／IEC25010:2023)灵活性：与软件可从某一环境转移到另一环境的能力有关的一组属性24适应性adaptability与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的属性易安装性installability与应指定环境下安装软件所需努力的软件属性易替换性replaceability与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的属性可扩展性scalability支持横向或纵向扩展，如云原生架构软件质量特征(ISO／IEC25010:2023)无害性：确保软件产品在特定环境中不会导致不可接受的风险25操作限制设置安全边界，如工业机器人动作范围限制风险识别实时监控潜在危险（如自动驾驶的障碍物检测）故障安全失效时自动进入安全模式（如核电站紧急停机）危险警告异常状态预警（如医疗设备报警机制）。安全集成与外部安全系统联动（如消防系统与建筑管理平台集成）。软件质量模型——McCall模型26软件质量模型——Boehm软件质量模型27阐述性互用性数据公开性正确性可靠性效率完整性可用性可维护性可测试性灵活性可移植性重复性连贯性容错性执行效率/储存效率存取控制/存取检查可训练沟通良好简单性易操作的工具自我操作性扩展性一般性模块性软件系统独立性机器独立性通讯公开性正确性可操作性软件产品评价质量通过对质量特性和子特性的定义，软件质量体系构架了一个完整的软件质量描述框架，在整个软件项目的各个阶段都具有指导意义。测试实践中需要根据软件质量体系，在测试计划中确定项目质量标准、设计测试用例、制定测试策略；在测试执行中确定执行策略；在测试报告中全面总结评价软件的最终特性。28标准模型质量特性质量子特性关键进展ISO91266个21个奠定基础→

ISO25010:20239个40个更全面、更精准软件测试与质量29实践证明：对软件进行充分的测试 才能够有效的保证软件质量对软件产品进行充分测试，找出其中的缺陷(defect/bug),并进行修复(repair)。本章内容30软件质量软件测试软件缺陷二三一软件缺陷相关术语错误（error）通俗地说，错误是指某件做错的事。它是一种人类的失误行为。和错误有关的行为——忘记、疏忽、随意、臆测、误判、错想、误会、含混、轻信、无知…。（软件）缺陷（defect）缺陷是错误在软件中体现出来的结果。错误是潜伏在软件中的问题，如果永远不执行它们就不会出现缺陷。但是，如果没有条件引发这个缺陷，我们就可以认为没有缺陷吗？31软件缺陷相关术语故障（fault）当缺陷被引发时，它可能造成故障（失效）。故障是缺陷的表现形式，是软件的运行结果相对于软件预期行为的一种偏离。Bug是一种通俗的说法，通常用作缺陷的同义词。Bug的英文含义是“虫”，用在软件中，可以理解为人脑子里的“虫”，变成了系统中潜在的缺陷。失效（Failure）32测试与调试33错误缺陷缺陷缺陷软硬件环境与操作条件故障沿着故障返回的路径，对缺陷分析、定位和修正——调试发现系统失效，以证明缺陷的存在——测试发现系统失效，以证明缺陷的存在——测试软件缺陷产生的原因软件缺陷的不可避免性。1、软件本身：需求不清晰、结构复杂、运行环境复杂、采用新技术、系统扩展或兼容问题2、团队工作：需求理解、相互沟通、技术水平3、技术问题：算法错误、语法错误等4、项目管理：不重视质量、缺乏评审机制、风险估计不足等。34问题：软件缺陷可能存在于什么地方？仅出现在代码中？不是。它无处不在！其中，需求说明书是软件缺陷出现最多的地方。因此，我们必须提前测试，预防缺陷在后期大爆发35软件缺陷在开发周期的不同阶段的分布36修复软件缺陷的代价“老生常谈”，但仍未得到足够的重视！人们总是因追求进度和实现而忽略了对软件缺陷的及时排除。37软件缺陷的严重性38严重程度说明现象描述（部分例子）处理优先级紧急致命错误，会导致整个系统失效由于程序所引起的死机、非法退出死循环数据库发生死锁因错误操作导致的程序中断与数据库连接错误数据通信错误，从而导致测试无法继续执行可能影响其他模块功能立即处理或解决致命很严重错误，会造成系统的部分功能失效程序错误程序接口错误数据库的表、业务规则、缺省值未加完整性等约束条件关键功能完全不能实现程序运行不稳定，如出现不可继续进行操作的错误程序运行出现难以捕捉和不可再现的错误响应其他业务流程的错误在发现的几天内完成严重一般严重错误，影响用户的操作操作界面错误打印内容、格式错误简单的输入限制未放在前台进行控制删除/退出操作未给出提示数据库表中有过多的空字段功能不完整，如菜单、按钮不响应对错误没有处理信息系统上线前必须修复完成一般一般性错误，可能会影响用户操作界面不规范辅助说明描述不清楚输入输出不规范提示窗口文字未采用行业术语可输入区域和只读区域没有明显的区分标志正常排队等待修复或方便时修复建议较小错误，不影响用户的正常使用Tab键跳转不正常窗口控件的Z-Order不正确窗口中的按钮或者控件缺少快捷字母，或快捷字母冲突文字表述中有错别字或歧义测试人员所提出的建设性意见方便时再修复软件缺陷构成39缺陷分类表40序号类别主要表现1需求缺陷（1）需求有误；

（2）需求逻辑错误；（3）需求不完备；（4）需求文档描述有问题；

（5）需求更改2设计缺陷功能的使用对用户带来不便及不符合行业标准，表现：（1）设计不合理；

（2）设计文档描述有问题；（3）设计变更带来的问题3功能和性能缺陷功能没有达到要求或功能存在严重缺陷，系统在运行过程中存在性能瓶颈或存在对系统性能有影响的功能，表现：（1）功能或性能有误；

（2）性能不完全；（3）功能不完全；

（4）适应范围有问题；（5）用户信息和诊断信息有误；（6）异常情况处理有误；（7）其他功能错误4界面缺陷系统的图片、文字、按钮、翻页明显有错误5数据错误访问数据库时出错，得出的数据错误，表现：（1）数据定义、数据结构错误；（2）数据存取及数据操作错误；（3）其它数据问题6结构缺陷（1）控制流和控制顺序错误；（2）处理错误7实现与编码缺陷（1）编码错误；（2）违背编码风格或标准；（3）文档有误；（4）其它实现方面的问题8软件集成缺陷（1）内部接口错误（2）外部接口错误，时间、吞吐问题；（3）其他集成错误9系统结构缺陷（1）操作系统引用或使用错误；

（2）软件结构错误；（3）恢复错误；

（4）执行错误；

（5）诊断错误；（6）分割覆盖错误；（7）引用环境错误10测试设计与测试执行错误（1）测试设计错误；（2）测试执行错误；（3）测试文档错误；（4）测试用例不充分；

（5）其他测试错误11其它缺陷（1）数学结算错误；（2）测试者误操作却认为发现了问题；（3）所产生的问题与硬件设备直接有关本章内容41软件质量软件测试软件缺陷二三一软件测试IEEE对软件测试的定义：

正面测试：依据需求（功能）列表逐个验证，为了证明软件是工作的，如：正常值测试。该方法必须用，而且常用，但发现错误的效率较低。42使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的的需求，或是弄清预期结果与实际结果之间的差别软件测试G.J.Myers在《软件测试之艺术》书中描述：

反面测试：想方设法找出软件缺陷，为了证明软件是不工作的，发现Bug的效率较高，如：异常值测试。实际应用中，两种思维方式都要有。43程序测试是为了发现错误而执行程序的过程软件测试定义通俗地说：软件测试是一个找错的过程。软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例（TestCase）。测试用例的设计原则是尽可能暴露程序中的错误。一个成功的测试用例在于发现了至今尚未发现的缺陷。软件测试的目的测试的目的就是发现软件中的各种缺陷测试只能证明软件存在缺陷，不能证明软件不存在缺陷测试可以使软件中缺陷降低到一定程度，而不是彻底消灭以较少的测试用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量测试的目标最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正：确保软件完成了它所承诺或公布的功能确保软件满足性能的要求确保软件是健壮的和适应用户环境的为软件的质量评估提供依据为软件质量改进和管理提供帮助软件测试度量测试覆盖率有多少需求、代码已经被测试了软件测试度量缺陷发现率缺陷是何时被发现，并且有多少缺陷已经被发现。缺陷可以根据严重性来分类。需记录以下值：缺陷数目缺陷的严重性48软件测试度量测试成功率：有多少测试已经通过了，并且有多少是运行正常的？需记录以下值：已通过的测试用例的数目可利用的测试用例的数目软件的可测试性可测试性（Testability）是否容易测试影响软件质量的关键S.O.C.K原则50软件的可测试性Simplicity设计简洁功能模块化越简单，越容易测试51软件的可测试性52软件的可测试性Observability可观察性任何一项操作或输入都应该有预期的、明确的响应或输出运行时状态当前、过去的系统状态和变量应可见或可查询正确地验证更容易验证增加输出参数、增加断言等53软件的可测试性Control控制软件的运行提供适当的手段，在外界直接或间接的控制系统的状态及变量业务流程和场景易于分解，可以针对单独业务流程进行测试不同分支出错处理异常处理54软件的可测试性Knowledge了解模块的各个状态每个状态有清晰的定义验证状态排序的输出和随机的输出55软件测试的原则基本原则站在用户的角度，对产品进行全面测试。尽早、尽可能多地发现缺陷（bug），并负责跟踪和分析产品中的问题。对不足之处提出质疑和改进意见。争取零缺陷（zero-bug），做到足够好（good－enough）。进一步研究：在软件测试过程中，应注意和遵循的原则可以概括为10项。56值得学习的10项原则所有测试的标准都是建立在用户需求之上。软件测试必须基于“质量第一”的思想去开展各项工作。事先定义好产品的质量标准。软件项目一启动，软件测试也就开始，而不是等程序写完，才开始进行测试。穷举测试是不可能的。第三方进行测试会更客观，更有效。软件测试计划是做好软件测试工作的前提。测试用例是设计出来的，不是写出来的。对发现错误较多的程序段，应进行更深入的测试。重视文档，要善于保存一切测试过程文档。57软件测试的分类我们将概述软件测试类型，如：功能测试、性能测试、单元测试、集成测试、系统测试、验收测试；以及软件测试常用的方法，如：手工测试、自动化测试、静态测试、动态测试、白盒测试、黑盒测试、回归测试、冒烟测试、随机测试等。在某一类型的测试中，多种测试方法一般会被综合运用，以达到全面测试的目的。58软件测试的类型59软件测试类型按测试阶段划分功能测试单元测试验收测试系统测试集成测试按测试目的划分性能测试压力测试稳定性测试兼容性测试健壮性测试可维护性测试可用性测试软件测试方法60软件测试方法白盒测试静态测试其他动态测试按是否运行系统划分按是否查看源代码划分随机测试黑盒测试冒烟测试回归测试等价类划分法错误推测法因果图法边界值分析法组合分析法手工测试自动化测试按是否使用自动化工具划分逻辑覆盖法基本路径测试法测试阶段--单元测试单元模块集成后构成软件系统61系统程序的最小单元是什么？测试阶段--单元测试单元测试是对软件基本组成单元进行的测试。测试的对象是软件设计最小单位——模块。一个类、一个组件、一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。单元测试把软件的独立单元与程序的其他部分隔离开来进行的测试。常使用的方法是白盒测试（主要）与黑盒测试。62单元测试测试阶段--单元测试单元测试作为针对于编码工作的第一级测试，首次对编码实现的软件单元进行系统地测试。单元测试的结果是程序员阶段性成功的标志。完成单元测试的标志是：在单元测试中发现的错误已经得到修改，并且通过了再测试。达到了相关的覆盖率的要求。完成软件单元测试报告。63谁负责单元测试比较好？测试阶段—集成测试集成是把组件组合成更大部件的过程。集成测试不是单纯的测试，还是验证集成后的系统是否达到了既定的设计目标。集成测试是将已分别通过测试的单元（组件），按设计要求组合起来再进行的测试。集成测试的目的，是揭示接口以及模块间交互的缺陷。集成测试一般包括：逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查等。64测试阶段-系统测试系统测试是用于验证经测试的集成系统是否满足指定需求而进行的测试，是系统级别的测试。系统测试的被测对象是软件的特性——包括功能和非功能（主要）的特性。系统测试要检验软件的各种功能操作是否正常，并检验它的效率、强度、兼容性、可靠性、故障修复等一系列的性能指标。因此，系统测试是一个庞大的工程。系统测试是“整机”测试，故测试环境十分重要。要考虑软硬件设备和真正的使用环境。65测试阶段-验收测试验收测试是在系统测试通过，以及发现错误在修正之后才开始的测试，是整个确认测试的最后一个阶段。由用户在使用环境下测试。如同我们购买汽车时的“试车”一样，我们要验证预期的产品品质。如果是客户定制的软件，客户将根据合同执行验收测试；对于通用软件，会在一个公共的测试环境中进行验收测试。验收测试分为两个阶段：α测试：在模拟用户的环境中测试，由用户、测试人员、开发人员等参与的内部测试；β测试：在实际用户的环境中测试，完全交给最终用户。66单元测试、集成测试、系统测试的关系67系统子系统1子系统n模块1…模块n模块1模块m单元1单元n单元1单元m…………UTSTITIT系统分析设计过程系统测试过程测试目的--功能测试功能测试的目的验证和确认产品规格说明书规定的要求是否都得到了满足检查实际软件的功能是否符合用户需求功能测试包括验证系统输入输出行为的各种测试。经常以黑盒测试方法为主，并辅以白盒测试、回归测试等。功能测试的基础是功能需求，因此SRS是功能测试的重要依据。68测试目的--性能测试性能需求（非功能需求）：不描述功能，描述系统执行它的功能有“多好”或者性能如何,

分为时间性能(响应时间)和空间性能(系统资源)

性能测试一般包括：压力测试、容量测试、效率性测试、稳定性测试、健壮性测试、容错性测试、数据转换测试、易用性测试、可维护性检查、文档检查等。69是否使用工具—手工测试顾名思义，手工测试即测试人员在不借助工具的情况下，“亲力亲为”地进行测试。优势测试人员具有创造性，灵活性高，可以考虑到一些特殊用例和边界情况。对于复杂的逻辑判断、界面是否友好等方面的测试，手工测试有明显优势。发现缺陷的的比例较高，可达85%左右。局限性覆盖率较低、不具有可重复性；测试效率较低；不能进行如系统负载、可靠性等性能测试。70是否使用工具--自动化测试软件自动化测试是相对于手工测试而存在的，主要是利用自动化软件测试工具，通过编测写试脚本和输入测试数据，自动运行测试程序。软件测试工具主要包括功能测试工具、性能测试工具、测试管理工具。优点：可重复性、效率高、准确、可靠、覆盖率高等。缺点：灵活性差，发现缺陷的比例较低，只能达到15%。通常，手工测试和自动化测试结合使用，以互补的方式完成测试任务71是否运行系统--静态测试软件的功能在不被执行的时候，处于相对静止的状态——静态测试方法。静态测试的对象包括文档、代码、界面等。主要是根据用户的要求、及相关标准规范进行分析与检查。常用的手段是人工检测，依靠人工审查或评审软件，偏重于编码风格、质量的检验，除了审查编码还要对各阶段的软件文档进行检验。计算机辅助静态分析，是很有效的静态测试。72是否运行系统--动态测试当软件功能被执行的时候，软件的对应部分处于活动之中——动态测试方法。通过观察代码运行时的动作，来获取执行结果，并得到时间效率、系统可靠性等方面的信息。动态测试通过真正运行程序发现错误。通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。73是否查看源代码--白盒测试白盒测试：把被测软件看作一个盒子，在测试时，不仅要关心软件的输入数据和输出结果，还要把盒子打开，研究里面的源代码和程序结构。白盒测试常用的方法逻辑覆盖法基本路径测试法74Y=2*xX=2Y=4是否查看源代码--黑盒测试黑盒测试，指的是把被测软件看作一个盒子，我们不去关心盒子里面是什么样子，只关心软件的输入数据和输出结果。黑盒测试常用的方法等价类划分法边界值分析法因果图法错误推测法功能图法75X=2Y=4其它测试--回归测试为什么要进行回归测试？背景：系统功能繁多，产品的种类不断演变，产品升级比较频繁，将要发布的版本都会包括新增功能，经过测试的功能也可能在新版本中出现。需求：即使是已经测过的功能模块，在新的版本下依然需要测试，以确保该模块在新的环境中仍能正常运行——这就叫“回归测试”。回归测试的定义重复测试先前测试过的或修改过的程序，确认发生的更改是否给软件其他未改变的部分带来新的缺陷。76其它测试--冒烟测试冒烟测试，是指对一个新版本系统进行大规模的测试之前，先验证一下软件的基本功能能否实现，是否具备可测性。冒烟测试的由来：冒烟测试名字的由来与电路板的测试有关。人们在测试电路板质量时，先给它接上电，如果板子冒烟的话，说明板子的质量存在严重问题，就不用测试其它功能了，必须重新研制或生产。一般，先进行冒烟测试，再进行回归测试。77其它测试--随机测试随机测试，是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。随机测试又叫猴子测试。当软件发布后，就会有成千上万的人像猴子一样对软件乱点乱敲。这种方法尽量模拟软件在实际的使用环境中的随机操作，发现一些隐蔽的错误。随机测试的缺点：测试不规律、不系统，无法统计代码覆盖率和需求覆盖率，很难再进行回归测试。因此该方法一般用作辅助测试手段。78软件测试的生命周期79在软件测试生命周期的每个阶段都要完成一些确定的任务：在执行每个阶段的任务时，可以采用行之有效的结构分析设计技术和适当的辅助工具；2.在结束每个阶段的任务时，都进行严格的技术审查和管理复审。3.最后提交最终软件配置的一个或几个成分（文档或程序）。软件测试与开发的关系软件测试与开发的顺序关系80软件测试模型V模型在V模型中，描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中不同的阶段，清楚地描述了这些测试阶段和开发过程期间的对应关系。81V模型示意图

用户需求获取需求定义需求分析需求分析书概要设计概要设计书详细设计详细设计书编码程序软件产品可交付软件验收测试已确认软件系统测试已集成软件集成测试已测试模块单元测试需求分析评审评审评审评审评审评审评审评审必需在编码工作结束后才能进行测试！软件测试模型W模型由于各种原因，开发的每一个环节都可能产生错误，如果坚持各个阶段的技术评审,就能够尽早发现和预防错误。83每个开发活动后都可以执行相应的测试！W模型示意图W模型特点优点：测试贯穿于整个软件开发生命周期；测试对象不仅仅是程序，还包括需求和设计规格说明等；测试与开发同步；可以尽早、全面发现问题。缺点：为串行结构，需等上一阶段活动结束后才能开展下一活动。85H模型示意图86H模型RUP87软件测试模型H模型软件测试不仅仅指测试的执行,还包括很多其他的活动。软件测试是一个独立的流程,贯穿产品的整个开发周期,与其它流程并发进行。软件测试要尽早准备,尽早执行。软件测试根据被测物的不同是分层次的。不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的。88测试模型的使用X模型提出：针对单独的程序片段进行相互分离的编码和测试，然后经过频繁的交接，通过集成最终合成为可执行的程序。前置测试模型体现了开发与测试的结合，要求对每个交付的内容进行测试。这些模型都针对其他模型的缺点进行了一些修正，但本身仍然存在一些不足的地方，所以在软件测试过程中正确选取模型是一个很关键的问题。89测试模型的使用在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个测试级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该针对软件的需求和设计进行测试，而这一点在W模型中得到了补充。W模型强调测试计划等工作的先行和对系统需求和设计的测试，但W模型和V模型一样，没有专门对软件测试流程予以说明。因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发的一系列活动，就每个软件测试的细节而言，都有一个独立的操作流程。比如，现在的第三方测试就包含了从测试计划和测试用例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始测试。因此，在实际的工作中，要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立测试，同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。90软件测试的完整模型91项目规划项目需求分析项目概要分析项目详细分析代码编写测试代码编写测试需求分析系统测试计划集成测试计划单元测试计划产品发布系统测试集成测试单元测试软件测试与开发的关系软件测试与开发的并行关系92需求分析需求评审概要设计详细设计概要设计评审单元测试编码设计走查编码走查各子模块有效性测试集成测试测试计划测试过程测试评审…………**项目阶段任务的里程碑********测试在开发阶段的作用：项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。编码阶段：由开发人员进行自己负责部分的测试代码。在项目较大时，由专人进行编码阶段的测试任务。测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。93第2章软件质量标准本章内容95软件质量标准概述ISO/IEC软件质量标准CMM与CMMI标准二三一IEEE软件质量标准四标准优势对比五本章内容96软件质量标准概述ISO/IEC软件质量标准CMM与CMMI标准二三一IEEE软件质量标准四软件质量标准软件质量标准定义确保软件产品满足用户需求和期望的重要参考，它们分为多个层级，包括国际标准、国家标准、行业标准、企业标准、项目规范。97软件质量标准作用：提供系统性指导规范开发流程，确保高质量、稳定性和安全性98国际标准（ISO/IEC25010:2023）99国际标准（ISO/IEC25010:2023）功能适用性：软件在一定条件下须满足的明确及隐含的需求。100功能完备性functionalcompleteness软件提供的一套功能能够覆盖所有特定任务和预期用户目标的能力。功能正确性functionalcorrectness当预期用户使用该产品时，软件能够提供正确结果的能力。功能适当性functionalappropriateness软件能够提供功能以促进特定任务和目标完成的能力。国际标准（ISO/IEC25010:2023）性能效率：在特定条件下能够在规定的时间和吞吐量参数内执行其功能，且能够高效利用资源的能力。101时间特性timebehaviour软件在特定条件下执行其指定功能并满足响应时间和吞吐率要求的能力。资源利用率resourceutilization软件在特定条件下执行其功能时不使用超过指定数量资源的能力。容量capacity软件满足产品参数不超过最大限制的能力。国际标准（ISO/IEC25010:2023）交互性：软件通过用户接口与指定用户交互，来实现用户和系统之间的信息交换，并完成预期任务的能力。用户错误防止软件阻止操作错误发生的能力。可识别性被用户认识到符合他们需求的能力。易学习性让特定用户不用花费太多时间就能学会使用特定产品功能的能力。易操作性软件拥有的功能和属性让其操作和控制起来很轻松的能力。用户参与度软件以吸引人和激励人的方式展现自己的功能和信息，鼓励用户持续进行交互的能力。包容性软件被各种背景的人使用的能力。用户帮助在特定的使用场景下，让有各种各样特征和能力的人使用，以达成指定目标的能力。自描述性在用户需要的地方展示适当的信息，令软件功能和使用方法对用户显而易见，而不需要用户过度地与产品交互或依赖其他资源的能力。国际标准（ISO/IEC25010:2023）可靠性：是指软件在一定条件下连续一段时间执行特定功能而不发生中断和故障的能力。103无错性Faultlessness软件在正常操作下执行特定功能不产生故障的能力。可用性availability软件在使用时可操作和可访问的能力。容错性fault

tolerance软件在有故障或未使用指定接口的情况下，依然按预期运行的能力。易恢复性recoverability在发生一次中断或故障后，恢复被直接影响的数据，并重新建立期望的系统状态的能力。国际标准（ISO/IEC25010:2023）安全性：软件保护信息和数据，让个人或其他软件拥有的数据的访问程度符合其授权的类型和等级，同时抵御来自恶意攻击者的入侵的能力。104保密性保证数据只被有访问授权的请求获取的能力。完整性确保其系统状态和数据免受未经授权的修改或删除的能力，无论是由于恶意行为还是计算机错误。不可否认性在某种行为或事件发生后，确保该行为或事件不被否认的能力。可追踪性使一个实体的行为被唯一追溯到该实体的能力。真实性证明一个主体或资源的身份与其所声称的身份一致的能力。防御性当软件遭受恶意攻击时保证软件正常运行的能力。国际标准（ISO/IEC25010:2023）可维护性：软件被高效地修改的能力。105105易分析性软件高效地评定自身的一个或多个部分发生预期变更所产生的影响，以诊断故障的成因，进而识别出需要进行修改的部分的能力。可变更性软件被高效地修改，且不引入新的缺陷或降低现有产品质量的能力。可复用性软件的资产被其他软件复用的能力。模块性软件由若干独立的组件构成，修改一个模块对其他模块的影响被降到最低。易测试性软件允许客观可行的测试被设计和执行，以确定需求是否达到要求的能力。国际标准（ISO/IEC25010:2023）灵活性：软件适应其必要条件、使用环境、系统环境发生变化的能力。106适应性adaptability软件无须采用其他活动或手段就可适应不同环境的能力。易安装性installability软件在特定环境下高效安装或卸载的能力。易替换性replaceability软件在相同的目标和环境下替代其他特定产品的能力。可扩展性scalability软件处理增长或缩减的工作负载，或调整容量应对变化能力。国际标准（ISO/IEC25010:2023）保护性：软件在规定条件下避免人身安全、健康、财产或环境遭受危害的能力。107操作约束当遇到操作风险时，软件将其操作约束在安全的参数或状态范围内的能力。风险识别软件识别出可能导致人身安全、财产、环境暴露在不可接受风险下的一系列事件或操作的能力。故障安全发生故障时，软件自动将自身调整到安全运行模式，或恢复到安全状态的能力。危险警告软件向操作者或内部控制部门提供风险警告，使他们有足够的时间采取行动以维持软件正常运行的能力。安全集成软件在整合一个或多个组件期间或之后保持其保护性的能力。国家标准108中国软件工程国家标准：由各国政府或指定的标准化机构制定的标准，确保软件产品的质量和安全。标准分类：基础标准、开发标准、文档标准、管理标准。行业标准行业标准定义：为了满足特定行业需求而制定的技术要求，不同部门发布的标准适用于不同的行业。例如，针对代码质量与缺陷管理的行业标准:工业和信息化部SJ/T11681-2017《C#语言源代码缺陷控制与测试指南》、SJ/T11682-2017《C/C++语言源代码缺陷控制与测试规范》、SJ/T11683-2017《Java语言源代码缺陷控制与测试指南》。国防科学技术工业委员会国家军用标准GJB5369-2005《航天型号软件C语言安全子集》、GJB8114-2013《C/C++语言可靠性编程规范》。109企业标准企业标准定义：由单个公司或企业内部制定的规范和标准，确保其产品和服务的质量、安全性、效率和一致性。示例:华为软件开发标准：

包括编码规范、代码审查、开发流程等。项目管理标准：

华为使用敏捷开发与DevOps实践来提高项目管理效率。产品交付标准：

包括SLA和服务交付的具体要求。110本章内容111软件质量标准概述ISO/IEC软件质量标准CMM与CMMI标准二三一IEEE软件质量标准四CMM标准112CMM定义一种旨在改进软件开发过程的方法，它由美国国防部联合卡内基梅隆大学的软件工程研究所（SEI）在1980年代末期共同开发。它是对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述CMM的五个成熟度级别初始级可重复级定义级管理级优化级CMM标准113等级(Level)中文名称关键特征1初始级过程不可预测；成功依赖个人能力；项目管理混乱、以反应为主2可重复级建立关键过程（项目计划、需求管理等）；可管理类似项目，形成可重复经验3定义级组织层面标准化过程与方法；所有项目遵循统一标准流程4管理级以数据与统计方法度量/控制过程性能，确保项目按预期进行5优化级持续改进与优化流程；应用先进方法（如六西格玛）；快速响应变化CMM标准114

CMM初始级CMM标准115

CMM可重复级CMM标准116

CMM可重复级从CMM3级开始，将软件生命周期的各个阶段严格地划分出来，以保持软件工程活动和软件工作产品的一致性。CMM模型的已定义级的KPA：组织过程焦点(OPF，OrganizationProcessFocus)组织过程定义(OPD，OrganizationProcessDefinition)培训程序(TP，TrainingProgram)集成软件管理(ISM，IntergratedSoftwareManagement)软件产品工程(SPE，SoftwareProductEngineering)组间协调(IC，IntergroupCoordination)同级评审(PR，PeerReviews)CMM标准117CMM已管理级已管理是CMM的第4级。是建立在可重复级和已定义级的基础上的。4级组织的过程能力是定量的，已知的，可预测的过程。4级时要分析和使用所采集的数据，理解过去，控制现在，预测未来。CMM优化级缺陷预防：目的是鉴别缺陷的原因并防止它们再次出现。技术变更管理：识别出那些建立在最好的软件工程实践基础上的技术创新，并把它们推广到整个组织。过程变更管理：改进软件质量、提高生产率和缩短产品开发周期为目的持续不断地改进组织中所采用的软件过程。CMMI标准118CMMI定义CMMI在CMM的基础上，集成了多个领域的标准，不仅适用于软件开发，还包括产品、服务开发等。实施路径阶段式(Staged):组织成熟度分为五个级别，每个级别有特定的要求。连续式(Continuous):允许独立评估各个过程领域的成熟度。CMMI模型优势提升过程效率和可预测性降低成本与开发时间提高产品质量增强客户满意度提升竞争力本章内容119软件质量标准概述ISO/IEC软件质量标准CMM与CMMI标准二三一IEEE软件质量标准四ISO/IEC软件产品质量标准120定义ISO/IEC软件产品质量标准提供了一套用于评估和确保软件产品质量的框架，帮助组织评估与改进软件产品质量和性能。示例ISO/IEC9126为软件产品的质量提供了一个评估框架，帮助组织确保软件产品满足用户的需求和期望它定义了软件质量的六个特性，包括功能性、可靠性、可用性、效率、可维护性和可移植性。ISO/IEC软件产品质量标准121质量特性描述功能性软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。可靠性在特定条件下使用时，软件产品维持规定的性能级别能力。可用性用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。效率在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。通常，效率就是我们常说的产品性能。可维护性产品可被修改的能力。这里的修改是指纠正、改进软件产品和软件产品对环境、功能规格变化的适应性。可移植性软件产品从一种环境迁移到另外一种环境的能力。这里的环境，可以理解为硬件、软件或组织等不同的环境。ISO/IEC软件产品质量标准122演变历史ISO/IEC9126(1991年)：最早的软件质量评估标准，定义了6个质量特性。ISO/IEC25010：继承并扩展ISO/IEC9126，提供更详细的质量指导。标准编号改进内容ISO/IEC9126到ISO/IEC25010ISO/IEC25010（SQuaRE）系列标准继承并扩展了ISO/IEC9126，提供了更详细的指导，包括软件质量模型、质量测量、质量要求和评价方法。ISO/IEC29119定义了软件测试过程中的关键概念和活动，涵盖了从测试策略到测试执行的各个方面，旨在帮助组织有效地规划、设计、执行和评估软件测试。ISO/IEC/IEEE122072017版本与之前的版本相比，增加了软件系统架构建模和敏捷开发技术应用，并且结构和内容继续与ISO/IEC/IEEE15288:2015保持一致。ISO/IEC/IEEE29119ISO/IEC/IEEE29119-2（2021年第2版）取消了经过技术修订的第一版（ISO/IEC/IEEE29119-2:2013），并用"测试模型"取代了"测试条件"，简化了测试设计流程。ISO/IEC15504提供了一个软件过程评估的框架，用于软件的设计、管理、监督、控制，以及提高软件过程的能力。本章内容123软件质量标准概述ISO/IEC软件质量标准CMM与CMMI标准二三一IEEE软件质量标准四IEEE软件质量标准124定义：电气和电子工程师协会（InstituteofElectricalandElectronicsEngineers，IEEE）提供有关软件开发、测试、验证和维护活动的全面指导。常用IEEE软件质量标准：IEEE730™-2014：

质量保证过程标准，帮助组织进行软件开发的质量控制。IEEE/ISO/IEC12207-2017：

软件生命周期过程框架，定义了从获取到交付全过程中的各个活动。IEEEStd730系列：

质量保证计划，确保软件产品满足质量要求并通过适当的审查。标准优势对比125标准/模型优势CMM提供清晰的改进路径，提升开发成熟度；提高质量和效率CMMI集成多个领域，强调持续改进；降低成本，提升质量ISO/IEC国际认证，提升竞争力；提供全面的软件质量评估框架IEEE强调质量控制，支持生命周期管理；确保软件质量与可靠性第3章软件质量保证本章内容软件质量保证概述软件质量保证任务软件质量保证组织软件质量保证活动软件质量保证过程127本章内容软件质量保证概述软件质量保证任务软件质量保证组织软件质量保证活动软件质量保证过程128软件质量保证概述为什么软件质量保证如此重要？1292003年美国大停电因电力公司报警系统失效致5000万人受影响印尼狮航610航班因错误传感器触发自动下压机头，坠毁致189人遇难软件系统一旦失效，影响会成倍扩散，最后不只是“一个小bug”，而是公共安全事件、社会稳定事件。软件质量保证概述定义软件质量保证（SQA）是一个确保软件产品在其整个生命周期中满足或超越预定标准的活动。SQA目的对软件项目正在运行的过程和工作产品进行审查保证软件开发、验证过程符合批准的计划和标准对阶段工作产品进行了符合性评审，提出的问题得到解决将审查的结果通知到相关人员项目组内无法解决的问题可向高层反映130软件质量保证概述SQA意义缩小缺陷引入与发现之间的时间间隔，尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到后续活动作用于过程而不是最终产品，因此它有可能会带来广泛的影响与巨大的收益贯穿于所有的活动之中，而不是只集中于一点131本章内容软件质量保证概述软件质量保证任务软件质量保证组织软件质量保证活动软件质量保证过程132软件质量保证任务质量保证定义：软件质量保证任务是由质量保证的计划、审计、评审、记录、分析、报告等多项任务组成，这些任务统一交给独立的SQA小组执行。质量保证任务：SQA计划：质量活动、评审/审计要求、标准、缺陷报告流程审计与评审：产品/过程/工具合规性检查，文档/设计/代码核查记录与报告：问题、偏差、建议；面向项目团队与管理层跟踪与分析：不符合项闭环、度量数据收集与改进建议133本章内容软件质量保证概述软件质量保证任务软件质量保证组织软件质量保证活动软件质量保证过程134软件质量保证组织概述目的：确保开发过程与结果达到质量标准并满足用户需求方式：制定/执行质量计划、过程监控、质量评审与测试、最终交付把关135软件质量保证组织结构软件质量保证组织结构通常根据企业的规模、项目复杂度和质量管理需求而有所不同。SQA组织结构涉及不同的角色和职能部门，负责不同层次的质量保证任务。目前常用的SQA组织结构有三种：独立的SQA部门独立的SQA小组独立的SQA工程师136软件质量保证组织结构定义：企业内部专职的质量保证部门组织形态：完整部门，配备专职SQA人员汇报关系：直接向高层管理层汇报核心职责：制定企业级质量策略与标准；监督各项目质量执行适用场景：大型企业、复杂/多项目环境137独立的SQA部门软件质量保证组织结构定义：项目中专职负责质量保证的个人工作方式：与开发团队同频协作，并行介入开发过程核心职责：制定项目级质量计划；组织/执行测试；开展代码评审；监督流程符合标准适用场景：小型项目或资源有限的企业/团队138独立的SQA工程师软件质量保证组织结构定义：项目团队内相对独立的质量保证小组，专责项目层面的SQA定位与独立性：与开发团队紧密协作但保持独立判断，避免受研发进度干扰核心职责：制定并维护项目质量计划（QAP）组织/执行测试与缺陷跟踪开展质量审核/过程评审与风险控制建立度量与报告（缺陷密度、修复时效、覆盖率等）协作关系：对接产品/开发/测试/运维，推动问题闭环与持续改进适用场景：中型项目/企业，跨模块协作多、对过程一致性与交付质量要求高139独立的SQA小组软件质量保证组织结构模型类型特点适用场景独立SQA部门系统化、专业度高；面向企业级策略、标准与监督；直达高层大型企业、复杂/多项目环境独立SQA小组项目内独立、贴近交付；质量计划/审核/缺陷跟踪主导中型企业、中等复杂度项目独立SQA工程师个人负责项目质量；灵活高效、成本低小型企业、简单项目/质量要求较低场景140SQA组织结构对比角色分类和职能141高层管理：制定质量策略/目标，资源保障；监督质量活动与企业目标一致SQA经理：编制质量保证计划；跨部门协调；监控质量目标达成SQA工程师：过程审核、产品评审与测试；阶段性质量评估与问题解决配置管理人员：版本/变更管理、配置审计与可追溯性SQA组织中常见的角色分类与职能SQA人员要求142技术能力：熟悉软件开发生命周期、质量控制技术和测试工具分析能力：能够分析和评估软件过程和产品，识别质量问题并提出改进建议沟通能力：能够与开发团队、项目经理和其他利益相关者有效沟通，传达质量要求和发现的问题，推动质量改进，促进团队协作。持续学习：培训与认证，跟进行业标准/工具更新SQA人员要求六西格玛的角色和培训143方法：以数据为基础，消除缺陷、提升质量角色：领导者、绿带、黑带、大师黑带（分层赋能与指导）对象核心内容/目标高层管理者正确认知与战略引领；资源配置与文化推动绿带基础工具与DMAIC流程；在岗改进与数据分析入门黑带复杂问题求解；统计方法（假设检验/回归/方差分析等）；项目落地大师黑带战略规划/组织变革；培训/辅导黑带与绿带；多项目治理六西格玛人员培训本章内容软件质量保证概述软件质量保证任务软件质量保证组织软件质量保证活动软件质量保证过程144软件质量保证活动145质量保证是复审、开发方法、配置控制与程序测试的综合应用。质量保证既是技术活动，也是管理活动。质量保证的活动内容软件评审146同行评审：团队内部，早期发现问题，促知识共享正式评审：关键阶段；需求/设计/代码/测试评审（检查表驱动）管理评审：高层评估进度/风险/质量；确保战略一致性审计评审：独立第三方合规性评估；识别与纠正偏差验证与确认147验证：过程正确性

→

文档检查、代码审查、静态分析、单元测试流程：计划→执行→评估→改进（形成验证报告）确认：满足用户需求

→

系统/集成/验收测试流程：计划→执行→评估→发布（决定是否发布）纠正和预防措施148纠正：已发生问题

→

根因分析/修正实施/恢复运行预防：潜在问题

→

风险评估/过程改进/预防性培训目标：问题率下降、可靠性提升、客户满意度提高软件质量控制149测试：计划→设计→执行→缺陷管理→评估与报告审计：过程/产品审计（计划、准备、执行、报告、跟进）度量分析：定义指标→数据收集→统计分析→报告与反馈软件质量控制是一系列确保软件产品在开发过程中和最终交付时达到既定质量标准的一系列活动。如下：软件配置管理150软件配置管理，简称SCM，是一种“保护伞”活动，它用于整个软件工程过程。SCM活动的目标标识变更控制变更确保变更正确地实现向其他有关的人报告变更软件配置管理151按照ISO9000-3的说明，软件配置项可以是：与合同、过程、计划和产品有关的文档和数据；源代码、目标代码和可执行代码；相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。随着软件工程过程的进展，软件配置项(SCI)数目快速增加。软件配置管理152实施软件配置管理要做的事情至少有：制定配置管理计划

应考虑：配置标识的规则如何建立项目数据库如何将软件配置项置于配置管理之下配置管理人员的职责和配置管理活动采用什么样的配置管理工具、技术和方法软件配置管理153实施变更控制

许多软件工程项目没有变更控制措施导致出现混乱。实施版本管理和发行管理它应当解决下列问题：采用什么方式来标识和管理许多已存在程序(和它们的文档)的各种版本？在软件交付用户之前和之后如何控制变更？谁有权批准和对变更安排优先级？如何保证变更得以正确地实施？利用什么办法来估计变更可能引起的其他问题？这些问题归结到软件配置管理的5个任务，即配置标识、版本管理、变更控制、配置审核和配置报告。

软件配置管理154版本控制是SCM的基础，它管理并保护开发者的软件资源。版本控制管理在软件工程过程中建立起配置对象的不同版本。版本管理可以把一些属性结合到各个软件版本上。通过描述所希望的属性集合来确定（或构造）所想要的配置。使用演变图来表示系统的不同版本。版本控制软件配置管理155软件配置管理156图中的各个结点都是复合对象，是一个完全的软件版本。软件的每一版本都是SCI（源代码、文档、数据）的一个集合，且各个版本都可能由不同的变种组成。例如，一个简单的程序版本由1、2、3、4和5等部件组成。其中部件4在软件使用彩色显示器时使用，部件5在软件使用单色显示器时使用。因此，可以定义版本的两个变种。软件配置管理157变更控制软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息。变更控制包括建立控制点和建立报告与审查制度。软件配置管理158软件配置管理159配置状态报告为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。登录主要根据变更控制小组会议的记录，并产生配置状态报告。对于每一项变更，记录：发生了什么？为什么会发生？对谁做的？什么时侯发生的？会有什么影响？软件配置管理160软件配置管理161每次新分配一个SCI，或更新一个已有SCI的标识，或一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目。一旦进行了配置审计，其结果也应该写入报告之中。软件配置管理162配置状态报告可以放在一个联机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件工程师。配置状态报告对于大型软件开发项目的成功起着至关重要的作用。避免了可能出现的不一致和冲突。本章内容软件质量保证概述软件质量保证任务软件质量保证活动软件质量保证活动软件质量保证过程163软件质量保证过程的实施164Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。Plan：设定适合于被开发软件的评测检查项目(质量评价准则)。研讨实现质量目标的方法或手段。Do：制作高质量的规格说明和程序。在接受质量检查前先做自我检查。Check：以Plan阶段设定的质量评价准则进行评价。计算结果用质量图的形式表示出来。比较评价结果的质量得分和质量目标，看其是否合格。Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。软件质量保证过程的实施165软件过程质量保证方法166标准化流程（CMMI/ISO+内控流程）质量审计（独立检查与改进建议）同行评审（代码/设计/需求互审）统计过程控制（SPC：跟踪缺陷率/通过率等）阶段性评审（StageGate：达标方可过关）风险管理（识别/应对质量风险）第4章软件测试管理本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具168本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具169软件测试流程170软件测试管理1711任务书2测试计划3测试规范4问题报告5测试报告启动计划执行、控制收尾组建测试组制定测试计划测试设计开发测试执行测试结果处理软件测试管理的整体目标：跟踪、监测团队在整个软件开发工作中计划、开发、执行并评估所有的测试活动。软件测试管理有助于系统地、规范地管理各种测试资源和测试活动，以提高测试的效率和质量。172软件测试管理内容四类管理内容：测试计划的管理测试制品的管理测试过程的管理测试人员及组织的管理173测试计划测试计划通常写成文档，描述要进行的测试活动的范围、方法、资源和进度，确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。174TestCenter中的添加计划175本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具176软件测试制品常见测试制品（TestArtifact）：测试用例（TestCase）测试脚本（TestScript）测试套件（TestSuite）测试计划（TestPlan）测试评估总结（TestEvaluationSummary）177本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具178测试用例测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合，一般还规定测试的开始条件、测试过程的条件和结束条件。测试用例示例：179测试用例要素（1）标识符Identification，指编号，为整型。此项必须有，用于不同文档间的相互引用。（2）测试项TestItem，用来准确描述待测试的项目及其特征，为字符型。此项必须有，作用是指明具体的测试对象/具体测试特性要求。（3）测试环境要求TestEnvironment，指特殊的环境要求，为字符型。此项可选，在一般软硬件环境可以不必给出。（4）输入标准InputCriteria，准确描述输入需求，包括数据、文件或操作步骤，必要时罗列数据库和文件，为字符型。此项必须有，作用是指明执行测试时具体的数据及输入步骤。（5）输出标准OutputCriteria，指按照指定的环境和输入标准执行后所期望的输出结果，为字符型。此项必须有，要求描述清楚无异议，必要时尽量提供适当的系统规格说明来证明期望的结果。（6）测试用例之间的关联，用来表明本测试用例与其他测试用例之间的依赖关系，为字符型。180测试用例设计思想（1）设计测试用例的准备工作。（2）测试用例命名细则（3）测试用例编号规则。（4）测试用例划分（5）测试用例的设计原则（6）测试用例的粒度。181测试用例设计方法（1）常规的测试用例设计。（2）初始化的测试用例设计（3）边界的测试用例设计（4）空值的测试用例设计（5）格式错误的测试用例设计（6）溢出的测试用例设计（7）关联的测试用例设计（8）唯一值的测试用例设计（9）权限不足的测试用例设计（10）角色权限的测试用例182测试用例覆盖要求（1）正确性测试。输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证至少覆盖需求规格说明书中的各项功能,并且正常。（2）健壮性测