智能软件工程 课件 第6-10章 如何保障软件质量-智能化浪潮下软件工程的未来

智能软件工程第6章如何保障软件质量本教材拔高一层从测试上升到质量保障（Quality

Assurance）质量保证(QA)优于软件测试1.QA关注焦点：从“找问题”到“防问题”，软件测试聚焦针对软件产品进行缺陷检测，即找出代码、模块、系统中的的bug，而QA聚焦“全流程的质量控制与需求满足”，从源头预防质量问题；2.导向逻辑：从“产品”到“流程”，软件测试是以产品为导向，直接针对代码、界面、功能等开展测试活动，而QA是以流程为导向，通过科学、规范的流程让产品自然达标。3.策略方法：从“纠正”到“预防”，软件测试采用“纠正性方法”，通过测试“发现问题→修复问题”；而QA采用预防性方法，通过提前建立标准、流程检查点，阻止质量问题在早期阶段产生，从根源上减少缺陷的出现。4.质量目标：从“控制”到“确保”软件测试的目标是控制质量、属于事后把关（检测产品是否合格）；而QA的目标是“确保质量”——通过构建完整的质量保障体系（包括流程、标准、人员职责、工具链等）为产品质量达标提供全流程的机制性保障，是“事前建立保障体系”。6.1深入理解软件质量什么是“质量”？符合性质量是最初的质量观念，即能够满足国家或行业标准、产品规范的要求适用性质量的定义：让客户满意，不仅满足标准、规范的要求，而且满足客户的其他要求，包括隐含要求IEEE、ISO给出的定义：质量是系统、部件或过程满足1）明确需求；2）客户或用户需要或期望的程度不同质量=品牌=客户满意度软件质量的内涵软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO8492)软件质量：软件产品满足 使用要求的程度高质量软件标准体系产品质量是人们实践产物的属性和行为，是可认知、科学地描述的且能通过一些方法和人类活动来改进的之前的质量模型:McCall模型,Boehm模型,ISO9126模型过程质量:能力成熟度模型集成CMMI

国际标准过程模型ISO9000软件过程改进和能力决断SPICE、ASPICE、

商业环境质量:

培训、成品制作、宣传、发布日起、客户、风险、成本、业务等

流程产品商业环境最新质量标准：ISO25000系列ISO/IEC25000

SE-软件产品质量要求和评定(SQuaRE)内部质量

外部质量使用质量虽然新的标准不区分内部质量、外部质量，把它们合并为产品质量，但从实际工作角度看，区分内部质量和外部质量还是很有意义的内部质量外部质量使用质量内部度量外部度量在使用中度量影响影响依赖于依赖于使用语境内部度量产品质量模型/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en

GB/T25000:102016质量模型使用质量模型缺陷是质量的对立面要了解什么是缺陷(defect)，就必须清楚“质量(Quality)”概念，因为缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷用户要求/期望质量矛盾/对立发现Bug？软件测试评估质量模型第一个缺陷GraceHopper（1906-1992）缺陷–Defect,Bug缺点（defect）偏差（variance）谬误（fault）失败（failure）问题（problem）矛盾（inconsistency）错误（error）毛病（incident）异常（anomy）各种软件缺陷数组和变量初始化错误或赋值错误算法错误：在给定条件下没能给出正确或准确的结果语法错误：编译或运行时发现这类问题计算和精度问题：计算的结果没有满足所需要的精度系统结构不合理、算法不科学，造成系统性能低下接口参数传递不匹配，导致模块集成出现问题文字显示内容不正确或拼写错误输出格式不对或不美观等6.2

软件质量工程体系版权所有©️仅限于教学使用质量管理发展历程质量控制

质量保证

缺陷预防6.2.1传统的质量管理体系软件质量控制质量控制（QC）是一个设定标准（根据质量要求）、测量结果，判定是否达到了预期要求，对质量问题采取措施进行补救并防止再发生的过程，质量控制已不再仅仅是检验，而更多地倾向于确保生产出来的产品满足要求的过程控制。休哈特提出统计过程控制的概念与实施方法工具：控制图，StatisticalProcessControl－SPC

软件质量保证质量保证（QA）是质量管理的一部分，是为保护产品和服务充分满足消费者要求的质量而进行的有计划有组织的活动，致力于提供对满足质量要求的信任。

内部质量保证是组织向自己的管理者提供信任；

外部质量保证是组织向外部客户或其它方提供信任。

复审(Review)：用结束标准对该阶段生产出的软件配置成分进行严格的技术审查等活动；内审(Audit)：检查组织内部是否遵守已有的模板、规则、流程等。全面质量管理(TQM)质量管理的目的是充分满足客户的需求，包括利益相关者(stakeholder)的需求。产品质量形成于开发和维护的全过程，引进主动的、积极的思想和方法来提高质量管理的水平，如“以预防为主、质量第一、第一次就把事情做对”等产品质量应当是“最经济的水平”与“充分满足顾客需求”的平衡和统一TQM就是全面的、全过程的、全员的和科学的质量管理的指导思想缺陷预防（质量改进）质量改进是质量管理的一部分，是不断为改进软件开发过程、产品和服务的持续过程。同时，为确保有效性、效率或可追溯性，组织应注意识别需要改进的项目和关键质量要求，考虑改进所需的过程，以增强组织体系、改进过程和产品并提高满足要求的能力。在质量改进工作中，有许多模型，包括PDCA模型、PEIS模型、6Sigma模型的DMAIC、CMM模型、SPICE模型等。零缺陷管理思想质量是构建的，不产生缺陷才是硬道理缺陷预防质量大师克劳士比的“零缺陷管理”，强调预防为主——预防产生于企业经营过程中的缺陷，第一次就做对，为实现工作的完美无缺而努力6.2.2构建软件质量工程体系（SQES）我们参照质量管理体系，从工程的视角考虑软件开发流程、开发技术、项目管理等特点来构建软件质量工程体系（Software

Quality

Engineering

System，SQES），即将软件质量管理视作一个系统，关注系统的输入、输出和外部环境，借助技术与工具不断收集软件产品和过程的质量信息及其反馈，然后进行调控和优化QA主导的层次。在软件质量方针的指导下，组织应选择或参考国际和国内的软件质量标准和规范，建立其软件质量工程规范；

QC主导的层次，依据软件质量工程规范和质量模型，重点做好软件测试、质量风险控制和过程监控等工作QE基础设施相当于软件质量管理的平台，旨在优化软件质量的管理。软件质量工程体系的层次软件质量工程体系及其构成根据上下文定制SQES组织规模：大型、中小型企业；企业性质：国企、民企或外企等；研发流程，如敏捷开发、精益开发、瀑布模型等；产品类型，如性命/使命攸关系统、一般商业系统；团队能力、地域等上下文因素哪些因素会比较显著地影响软SQES哪些因素影响很弱？哪些因素会产生积极影响？哪些因素会产生负面影响？分析示例：IBM公司的软件质量工程体系示例：埃森哲公司的软件质量工程体系6.3

软件测试目标、原则和类型版权所有©️仅限于教学使用什么是软件测试？验证和确认（verification&validation，V&V），即验证软件产品需求、设计和实现的一致性，确认软件是否满足用户的实际需求；狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程之后的阶段，属于对软件测试比较落后的认知。广义的软件测试：动态测试+静态测试，将需求/设计/代码评审等也纳入软件测试工作之中。基于测试预言（TestOracle）的认知：软件测试是对已知的检测和对未知的试验；基于批判性思维，软件测试是测试人员不断质疑被测系统的过程，适合探索式测试场景；基于质量的认知：对软件产品质量的全面评估，并提供软件产品质量信息，适合验收测试场景；基于质量风险的认知：软件测试就是不断揭示软件产品的质量风险，适合敏捷研发环境；基于经济的认知，软件测试是通过投入较低的保障性成本来降低劣质成本，帮助企业获得利润。测试目标尽早识别软件产品或系统中的缺陷，以便开发人员能够及时修复，降低后期修复成本。保障软件质量：测试旨在确保软件在多个维度上达到高质量标准，以满足用户的需求和期望。满足用户需求：确保软件系统能够有效满足用户的需求，提供良好的用户体验，以而提升客户满意度。支持持续改进：通过测试结果的分析，识别改进机会，推动软件开发过程的优化，确保在未来的版本中进一步提升质量。降低风险：通过系统的测试活动，识别和控制潜在的质量风险，确保软件的稳定性和安全性。促进团队协作：提升大家对质量的认知和意识，以共同提升产品质量。软件测试的分类不同维度的分类按测试的对象或范围分类，如底层测试/单元测试、接口测试/集成测试、系统测试、业务层的验收测试等按测试目的分类（测试类型），如功能测试、性能测试、可靠性测试、安全性测试、兼容性测试、回归测试等根据测试过程中被测软件是否被执行，分为静态测试和动态测试根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试按测试方法分类：精准测试、变异测试、蜕变测试、MBT等软件测试方式静态测试vs.动态测试主动测试vs.被动测试手工测试vs.自动化测试基于脚本的测试vs.探索式测试测试宣言（体现了测试的价值观）测试宣言全程的测试介入胜于

孤立的测试阶段

测试驱动开发（TDD）

胜于

先开发再测试

高水平的测试人员

胜于

自动化测试工具持续性的精准自动化测试胜于

回归式的全量自动化测试

基于风险持续优化的测试过程

胜于

事先的测试计划6.3.3测试原则所有测试的标准都是建立在用户需求之上软件测试必须基于“质量第一”的思想去开展各项工作事先定义好产品的质量标准软件项目一启动，软件测试也就开始了穷举测试是不可能的6.3.3测试原则

–续第三方进行测试会更客观，更有效软件测试计划是做好软件测试工作的前提测试用例是设计出来的，不是写出来的不可将测试用例置之度外，排除随意性对发现错误较多的程序段，应进行更深入的测试GPT

5.1给出的Top

10测试原则1.以用户价值与业务风险为核心（Risk-basedTesting）一切测试决策，都要围绕“哪些问题对用户和业务伤害最大”来做取舍，例如在时间、人力、环境都受限的情况下，优先验证：资金安全、数据正确性、合规要求、核心业务流程。测试用例、回归范围等都有优先级，而且应由风险矩阵或业务价值来驱动。2.尽早并持续测试（ShiftLeft）越晚发现缺陷，修复成本越高，风险越大。测试越早介入，能越早暴露需求歧义和设计缺陷。3.测试证明缺陷“存在”，不能证明“没有缺陷”4.穷尽测试不可能——必须做有重点的测试只能通过风险优先，在有限用例中获得最大“缺陷发现率”。这一原则和“风险导向”是配套的。5.缺陷集中性原则（DefectClustering）通常20%的模块包含80%的缺陷（类80/20现象）。对“历史问题多”、“需求变更频繁”、“技术复杂度高”的区域，应加大测试深度与频率GPT

5.1给出的Top

10测试原则6.测试是上下文相关的（Context-dependent）制定测试策略时，必须先讲清：领域性质、交付节奏、质量目标、合规要求等上下文；其次，上下文是不断变化的7.测试设计要持续进化（“杀虫剂悖论”）长期重复同一批测试，用例的“杀虫效果”会越来越差，这就是“农药悖论”，所以要持续改进测试用例，并引入探索性测试，8.“无错误≠高质量”（Absence-of-errorsFallacy）可能需求本身就设计得很糟糕：难用、不符合真实场景，即使没有bug，用户照样不买账。9.独立测试与团队协作并重保持适度的独立性，以避免盲点；同时又要和开发、产品紧密协作。10.可测性、可观察性与自动化优先系统设计之初就要考虑：是否容易被测试、被监控、被自动化驱动。Top1:穷尽测试是不可能既然无法全测，就必须采用逆向思维，进行优先级排序和风险分析，尽可能将更有风险的缺陷找出来。测试的艺术在于“决定不测什么”，从而把精力集中在最高风险、最核心的业务功能上Gemini3+NanoBanana共同给出的Top10

软件测试原则Top2：测试证明缺陷存在，而非不存在测试只能证明软件“有错”（测试是样本实验），永远无法证明软件“无错”。有时测试数据好看，可能存在更大的风险。Gemini3+NanoBanana共同给出的Top10

软件测试原则Top3：缺陷具有群集效应通常80%的缺陷会集中在20%的核心模块或最复杂的代码区域中Gemini3+NanoBanana共同给出的Top10

软件测试原则Top4：尽早测试

缺陷发现得越晚，修复成本越高（指数级增长）；所以要推行“测试左移”，或者项目一启动，测试就开始了Gemini3+NanoBanana共同给出的Top10

软件测试原则Top5：杀虫剂悖论(ThePesticideParadox)测试用例必须定期评审、更新和修改。同时，要引入探索式测试（ExploratoryTesting），利用人的智慧去攻击那些自动化脚本覆盖不到的死角Gemini3+NanoBanana共同给出的Top10

软件测试原则Top6：测试依赖于上下文不要照搬别人的测试流程。必须根据业务类型、风险级别、合规要求来定制测试策略Gemini3+NanoBanana共同给出的Top10

软件测试原则Top7：“无错”谬论

测试不仅仅是验证（Verification，做正确的事），更是确认（Validation，做正确的事）。必须始终引入用户视角，进行验收测试（UAT）和可用性测试Gemini3+NanoBanana共同给出的Top10

软件测试原则Top8：自动化测试的金字塔原则建立合理的自动化分层。大量的单元测试（底层，快且稳）+适量的接口/集成测试（中层，高性价比）+少量的UI测试（顶层，模拟真实路径）。Gemini3+NanoBanana共同给出的Top10

软件测试原则Top9：独立的视角与全员质量意识并存测试人员保持思维的独立性，不要轻易被开发说服“这不是Bug”。同时，推动“质量是全团队的责任”，让开发参与写单元测试，让产品参与验收Gemini3+NanoBanana共同给出的Top10

软件测试原则Top10：所有的测试都应追溯到需求如果一个测试用例不能对应到具体的业务需求或技术指标，那么这个测试就是无效的浪费；反之，如果一个需求没有对应的测试用例，那就是风险敞口Gemini3+NanoBanana共同给出的Top10

软件测试原则6.4

智能测试分析与计划版权所有©️仅限于教学使用软件测试的自身工作环节

测试需求分析就是解决“测什么”的问题，即界定项目的测试边界，明确测试范围、测试项及其优先级、测试风险和测试策略测试计划是为了高效地、高质量地完成测试任务而做的准备工作，包括工作量的估算、测试资源和进度安排等测试设计是解决“如何测”的问题，可以分为测试方案的设计和测试用例的设计测试开发：基于测试设计的基础，开发自动化测试脚本。测试执行：包括回归测试、结果分析、缺陷报告等工作。测试评估：对测试结果和测试过程进行评估

测试策略基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。如何制定测试策略全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。这里只截取部分内容，可以参考本书的电子材料LLM驱动测试需求分析让LLM细化自己关注的部分风险类别风险描述风险等级应对策略需求不明确或变更最终导致开发与测试的返工，延长项目周期。High1.开展细致的需求研讨会，确保团队成员对核心需求及新增功能达成共识，形成明确的《需求规格说明书》；2.引入变更控制流程，对所有需求变更进行严格评估与审批，充分分析影响并及时更新设计文档、测试计划等相关资料；3.加强与业务方沟通，定期回顾需求，确保理解一致。安全漏洞及攻击TMS系统承载企业内部协作及敏感信息（如任务、项目、私聊内容），安全漏洞可能导致用户隐私泄露、数据篡改、系统被控制；国际化模块中，翻译内容或被植入恶意脚本。High1.对用户管理、任务创建、国际化翻译等模块进行白盒安全代码审计与黑盒渗透测试，排查SQL注入、XSS、CSRF等常见问题；2.引入Web应用防火墙（WAF）进行外部防御；3.定期开展安全漏洞扫描与渗透测试，及时修复隐患。数据同步与准确性TMS系统任务管理涉及任务状态、进度、负责人等信息，多用户协作及跨模块（任务、沟通、博文Wiki）交互时，可能出现数据不一致（如任务更新后沟通信息未同步、国际化翻译与原文版本不匹配）。Medium1.针对核心功能和关键数据流执行详细黑盒功能测试，重点验证任务创建/分配/状态流转、博文版本管理、聊天消息收发等场景；2.定期进行数据备份，并测试数据恢复流程，应对数据丢失风险。权限控制不当TMS系统含用户、角色及各类资源（项目、任务、文件等），权限设计或实现漏洞可能导致越权操作（如普通用户修改系统配置）、敏感信息泄露（如非项目成员查看内部资料）、关键数据被非授权修改/删除（如普通成员误删重要博文）。High1.针对用户管理、权限分配模块开展严格的安全测试，验证权限边界与访问控制逻辑；2.结合白盒审计与黑盒测试，排查权限绕过等漏洞，确保不同角色仅能访问对应权限范围内的资源。让大模型生成更详细的测试项让LLM细化某个功能的测试项生成测试计划书提示词请根据提供的文件，为团队协作系统（TMS）生成一份专业且标准的测试计划书。请以《附录B测试计划中文模板.doc》作为您的主要结构框架。在此基础上，请仔细阅读并充分理解《TMS测试需求分析报告.docx》中的所有内容，将其中的业务背景、详细功能需求、非功能性需求（如性能、安全、兼容性、易用性、国际化等）、系统架构概览、用户角色定义以及任何具体的测试关注点和考量，整合并扩充到模板的相应章节中。请在生成测试计划书时，务必做到以下几点：1）以模板为骨架，需求为血肉：严格遵循《附录B测试计划中文模板.doc》的章节结构和指导，将《TMS测试需求分析报告.docx》中的具体信息（如TMS系统的核心功能、业务流程、数据交互、国际化要求等）填充到这些章节中，使其成为一份针对TMS系统量身定制的测试计划。2）全面覆盖测试计划关键要素：详细阐述“测试范围、测试策略、测试资源、测试进度与里程碑、测试退出标准、测试风险与对策”以下重要章节，并融入TMS系统的具体内容。3）专业性和一致性：确保测试计划书的语言专业、严谨，格式规范，逻辑清晰，易于理解和执行。文档的整体排版和标题层级应与《附录B测试计划中文模板.doc》保持一致。4）请以完整的测试计划书文档形式输出。6.5

智能测试设计与开发版权所有©️仅限于教学使用软件测试设计方法上下文驱动方法基于需求验证的方法基于场景的测试方法基于模型的方法基于经验的方法方法分类具体方法/技术基于输入域的测试等价类、边界值、两两组合（pairwise）、随机测试基于代码的测试基于控制流的标准、基于数据流的标准、CBT参考模型基于故障模式的测试故障模型、错误猜测法、变异测试基于使用的测试操作配置（operational

profile）、用户观察启发基于模型的测试（MBT）决策表、有限状态机、形式化验证、TTCN3、工作流模型基于应用特性的测试OOS、web、real-time、SOA、embedded、safe-critical黑盒测试方法和白盒测试基于需求的测试数据驱动测试结构化测试逻辑驱动测试客户需求事件驱动输入输出具体的测试方法@黑盒/白盒等价类划分法边界值分析法判定表方法因果图法Pairwise方法正交试验法功能图法语句覆盖判定覆盖条件覆盖判定条件覆盖条件组合覆盖基本路径覆盖黑盒方法白盒方法基于需求的测试方法结构化测试方法基于直觉的测试方法ALAC，是Act-like-a-customer（象客户那样做）的简写，ALAC测试方法是一种基于客户使用产品的知识开发出来的测试方法，它的出发点是著名的Pareto80/20规律错误推测法是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试。发现程序经常出现的错误的方法：单元测试中发现的模块错误；产品的以前版本曾经发现的错误；输入数据为0或字符为空；当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键；…

…等价类划分方法等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的.将输入数据分成若干个等价类，从每个等价类选取一个代表性的数据作为测试用例等价类分为有效等价类（合理的数据）和无效等价类（异常的数据）allinputsi1i4i2i3边界值分析方法很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。设计方法：确定边界情况（输入或输出等价类的边界）选取正好等于、刚刚大于或小于边界值作为测试数据BVA–BoundaryValueAnalysisab（1,20]即1<x<=20（整型数据）按边界值方法测试数据：0，1，2，19，20，21判定表方法对于多因素，有时可以直接对输入条件（成立或不成立）进行组合设计，不需要进行因果分析，这时就采用判定表方法。判定表由“条件和活动”两部分组成，即列出一个测试活动执行所需的条件组合，所有可能的条件（输入）组合定义了一系列的选择，而测试活动（结果输出）需要考虑每一个选择。判定表方法条件桩：问题的所有条件动作桩：针对问题所采取的动作条件项：所列条件的具体赋值（输出）动作项：在条件项组合情况下应采取的动作（输出）规则：任何一个条件组合的特定取值及其相应的动作条件桩动作桩规则每一列需要设计一条测试用例覆盖，有几条规则（组合）就有几条测试用例当输入是由多个因素构成，而不是单一因素，这时就需要多因素组合测试，如判定表方法、因果图方法等判定表方法是多个条件组合测试因果图方法当问题更为复杂时，无法直接基于条件组合获得输出结果，这时会采用因果图方法，进行多种输入条件的分析与推理，找出原因与原因、原因与结果之间的对应关系，画出因果，再转换成决策表。ijijj

i1i2inj

i1i2in有因必有果非-关系或-关系与-关系b1bnE...b1bnI...b1bnO...abRabMabIR互斥包含唯一要求屏蔽无关Pairwise方法背景：大部分缺陷是在两个变量取值冲突的测试时被发现的处理的问题：多个变量、每个变量有多个取值的组合数太大（不再是条件成立、不成立两种情况）定义：确保某个变量取值和另一个变量取值成对出现都会被覆盖效果：可大幅度降低组合的数量（两两组合）Pairwise工具推荐:ACTS正交实验法处理的问题：和Pairwise类似依据与思想：依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（条件组合），从而合理地安排实验（测试）的一种科学实验设计方法确定影响功能的因子与状态选择一个合适的正交表利用正交表构造测试数据集正交实验法Orthogonalexperimental

design

https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

正交表状态图方法一个堆栈的状态图(statediagram)emptyfilledfullNameInitialandfinalstatestatetransitionstateinitdeletepushpop

[height=1]poppush[height=max-1]pop

[height>1]push

[height<max-1]toptop说明push*initpush

initialemptyempty

deleted

filled

filled

filledfullfullfilledfulldeletepushpushpoptoptoppush*poppop

ERRORpop

ERRORtop

ERRORdelete

filled

ERRORdelete事件流图作为承兑人，根据委托收款请求，签发承兑无条件支付？不得转让？已转让了吗？收款人清楚吗？收款人是否破产？金额超过上限？有条件支付已转让不得转让超过上限收款人破产不符合条件黑盒方法小结基于需求的测试方法静态动态其它多因素单因素等价类划分边界值分析因果分析法决策表正交试验法功能图有限状态机错误推测法（代码行）语句覆盖设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次3689IFIFENDIFENDIFfeicbad457jh程序源代码1. dima,basintegerdimcasdoubleif(a>0andb>0)thenc=c/aendifif(a>1orc>1)thenc=c+1endifc=b+c程序控制流图(a,b,c)=(1,1,2)覆盖判定/分支覆盖判定覆盖：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。一个判定代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。(a,b,c)=(1,1,2)(a,b,c)=(-1,1,0)修正条件/判定覆盖（MC/DC）每个判定的所有可能结果至少能取值一次判定中的每个条件的所有可能结果至少取值一次

一个判定中的每个条件独立地对结果产生影响每个入口和出口至少执行一次/wiki/Modified_Condition/Decision_Coverage.au/~sergiy/MCDC.html>=

n+1

testcasesforadecisionwithn

inputs.（a>0andb>0）会有多少条用例？

.T..T.(1,1).T..F.(1,-1).F..T.(-1,1)逻辑覆盖小结语句覆盖判定覆盖DC条件覆盖CC条件/判定覆盖CC/DC条件组合覆盖MCC基本路径覆盖BPCConditionCoverage(CC)DecisionCoverage(DC)MultipleConditionCoverage(MCC)ModifiedCondition/DecisionCoverage(MC/DC)MC/DC基于模型的测试（MBT）通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例并执行这些测试用例的过程为被测试系统（SUT）建模基于模型产生测试用例将抽象的测试具体化使测试用例具有可执行性执行测试分析测试结果常见的MBT方法有限状态机（finitestatemachines，FSM），包括扩展的有限状态机（EFSM）符号执行(SymbolicExecution)是指一种使用符号值代替数字值执行程序的程序分析技术定理证明（Theoremproving）通过一组能够明确定义系统行为的逻辑表达式（谓词）来完成模型构建模型检验（Modelchecking）对属性的测试，如果属性在模型中是有效的，模型检验能发现证据或反例随机／半随机模型（如模糊测试方法、变异测试、马尔科夫链）其它方法：基于UML的MBT、因果图方法等变异测试6.5.2

基于测试需求文档生成测试用例提示词有了TMS任务功能的测试需求分析，现在请为TMS任务功能的“任务状态与进度跟踪”设计测试用例，选择合适的测试用例设计方法来设计，并进行说明。6.5.3

基于业务流程图生成E2E测试用例端到端测试（End-to-EndTesting）

是从真实用户视角出发，模拟完整的业务流程，验证整个系统在真实环境下能否协同工作，最终完成业务目标的测试方法核心特征：完整的业务路径：不是测试单个功能点，而是测试一个完整的业务场景跨系统集成：涉及多个子系统、服务、数据库、外部接口的协同真实环境模拟：在尽可能接近生产环境的配置下进行测试用户视角驱动：从用户进入系统到达成目标的全过程E2E测试的关键要素尽可能接近生产的测试环境：数据库配置、网络拓扑、第三方服务（使用沙箱环境）；独立且稳定：避免多团队共享导致数据污染尽可能真实的测试数据：使用脱敏的生产数据或符合真实分布的测试数据关键路径优先的测试执行策略：先覆盖核心业务流程，自动化与探索性结合E2E测试失败时，定位问题比单元测试困难得多：需要完整的日志链路（分布式追踪）、截图/录屏机制、清晰的测试报告将业务流程图转换成JSON格式的数据即用代码先把BPMNXML转成JSON，再交给LLM处理多模态大模型可以直接理解流程图结合“图算法+LLM”的路径搜索用确定性的图搜索算法找到所有从Start到End的候选路径；再由LLM对路径进行语义分类和筛选：主路径、异常路径、特殊高风险路径等

分3步走路径枚举：读取JSON格式的流程图，使用DFS/BFS枚举所有合法路径然后给每条路径打标签，基本路径、扩展路径和异常路径，并估算业务优先级按优先级选择路径，生成E2E的测试用例如何写提示词？基于业务流程图，让大模型识别所有的关键节点、决策点、异常分支等；再识别测试路径，包括基本路径（HappyPath）、备选路径（AlternativePath）、异常路径（ExceptionPath）等。提取测试场景：每条路径对应一个或多个测试场景，并考虑路径的组合覆盖和边界条件生成测试用例，包含前置条件（如用户状态、系统状态、数据准备等）、操作步骤、预期结果（验证点）、后置处理（如数据清理、状态重置）等，优先级排序：高频高价值的路径优先覆盖提示词示例你是一个高级测试架构师。现在给你一个从业务流程图提取出来的完整业务路径，请你用用户视角，将其描述为一个单一的端到端业务场景，并说明这个场景对应的业务目标以及可能的关键风险点。流程路径JSON：

<粘贴上面那段pathJSON>输出格式：场景名称业务目标前置业务条件（非技术性的）关键成功步骤的自然语言说明关键风险点和需要重点验证的地方示例：基于业务流程图生成E2E测试用例进一步通过多智能体生成测试用例流程解析Agent：读取BPMN/XML/流程图，生成规范化的“流程图JSON+业务语义摘要”路径规划Agent：在流程图上做图遍历/路径搜索，按规则选出候选E2E路径（主路径+异常路径）测试设计Agent：对每条路径生成自然语言的E2E场景说明+结构化测试用例骨架数据与变体Agent：基于场景自动补充边界值、异常数据、组合变体质量评审/去重Agent：检查用例质量、覆盖率和冗余，给出优化后的用例集测试用例评审测试用例设计的整体思路是否清晰，是否清楚系统的结构和逻辑从而使测试用例的结构或层次清晰，测试的优先级或先后次序是否合理；测试用例设计的有效性，如果相应地方有缺陷，测试用例执行就必然能发现，说明测试用例是有效的，如果不能发现，就说明测试用例是无效的。所以我们常常用变异测试来检验单元测试的有效性。测试用例的覆盖面，有没有考虑到产品使用中一些特别场景（scenario）、考虑到一些边界和接口的地方；测试用例的描述，前提条件是否存在、步骤是否简明清楚、期望结果(Criteria)是否符合产品规格说明书或客户需要；测试环境是否准确，测试用例有没有正确定义测试所需要的条件或环境；测试用例的复用性、可维护性（如可读性）和可管理性（如通过独立的用例ID来识别、用例的版本号等）换一个LLM来评审测试用例生成功能测试脚本详见电子材料：TestTaskCreate.java

生成API测试脚本6.6

LLM驱动非功能性测试版权所有©️仅限于教学使用6.6.1

LLM驱动性能测试性能测试正从“工具驱动”向“意图驱动”转变传统痛点回顾：性能测试方案的设计需要非常丰富的经验，对业务理解深刻，有挑战脚本维护工作量大：协议变了，脚本全得改；关联参数（Correlation）又多又杂。分析更有挑战：压测跑完了，对着几十张图表（CPU、内存、TPS、RT），只有性能专家才能识别出是“数据库锁了”还是“代码死循环”等问题。LLM带来的改变：LLM不仅是性能测试脚本生成器，更是性能测试设计师、分析师。核心差异：以前我们告诉工具“怎么做”，现在我们要告诉LLM“做什么”需求与场景分析阶段目标：从众多的需求/接口说明中，快速提炼出性能测试关注点和场景。操作：把需求文档、接口列表、时序图等喂给LLM，让它：标注出高并发、高频调用的关键接口，推断出典型用户路径（登录→浏览→下单→支付…），并给出初版性能需求表，如接口A：TP99延时<200ms，目标QPS（每秒查询率）500Prompt：“根据以下业务和接口说明，列出系统中最有可能成为性能瓶颈的10个接口，并为每个接口给出建议的性能目标（如TP99延时、峰值QPS），以及对应的用户使用场景。”场景与工作负载建模目标：把“业务场景”翻译成“可执行的压测计划”。LLM可以帮我们：按不同时段（工作日、节假日）推理流量曲线依据业务描述推演“思考时间(thinktime)、并发用户数、场景占比”产出文字版工作负载模型+图示描述脚本生成与维护典型流程：提供接口Swagger文档/PostmanCollection/cURL示例提示LLM：目标压测工具（JMeter/Locust/k6…）LLM生成：基础请求脚本、参数化模板（从CSV/DB读取用户、商品等）、断言逻辑（响应码、响应时间阈值等）

Prompt示例：“根据以下SwaggerJSON，生成一个Locust压测脚本：1）包含登录、搜索、下单3个任务；2）用环境变量配置base_url和并发用户数；3）打印失败请求的响应内容。”结果分析与瓶颈定位这是LLM非常适合的地方，信息输入来源：性能压测结果（RT、TPS、ErrorRate、资源使用）APM/Trace/日志数据（如慢SQL、外部依赖耗时）版本差异信息（改了哪些模块）LLM可以做什么：自动用自然语言总结：本次压测与上次相比，指标变化情况；哪些接口、哪些时间段性能明显下降按“可疑原因”分类聚合日志与Trace：例如：“疑似数据库锁争用”、“外部依赖超时”、“GC频繁”等，并给出优先级排序的排查建议列表先从CPU100%的服务A入手，再看调用链上的B/C服务示例：LLM驱动性能测试示例：LLM驱动性能测试

-续更完整的内容见电子材料LLM驱动安全性测试更完整的内容见电子材料LLM驱动安全性测试LLM驱动安全性测试

–续

更完整的内容见电子材料6.7

智能测试评估版权所有©️仅限于教学使用6.7.1智能缺陷定位大模型可以对软件缺陷报告进行分析和理解，提取关键信息，如缺陷描述、出现位置、影响范围等。通过对大量缺陷报告的学习，大模型可以建立起缺陷模式和特征的知识库，从而更好地理解新的缺陷报告，并为开发人员提供更准确的缺陷定位建议大模型还可以根据代码的上下文信息，推断出缺陷的可能原因和影响范围，为开发人员提供更全面的缺陷定位信息

大模型在缺陷定位的优势提高定位准确性：能够高效处理数十万行代码的代码库，可以建立起更准确的缺陷模式和特征知识库，从而提高缺陷定位的准确性提高定位效率：大模型可以快速地对缺陷报告和源代码进行分析和理解，从而提高缺陷定位的效率提高定位的智能化水平：大模型可以通过不断地学习和优化，提高自身的智能化水平。示例SWE-bench是评估从GitHub收集的现实软件issue的大型语言模型的基准。给定代码库和问题，语言模型的任务是生成解决所描述问题的补丁。如果在修补（patch）编辑后所有单元测试都通过，则该示例被认为是成功的。真实github项目，文件多，代码长33%的caseoracle输入长度大于32k（90%大于8k），RAGcase更会大幅变长每个项目回归UT30~150+真实issue，项目中真实存在的问题，不是人为构建，难度很大Issue格式自由，有可能包含需求描述、缺陷描述、Trackback等。链路复杂，RAG，代码生成，gitapply，安装环境，编译，UT仅python版本就包含3.7、3.8、3.9等多个版本。SWE-bench榜单（by

2025.11.30）多智能体修复缺陷来源：/pdf/2404.17153

6.7.2评估测试覆盖率基于代码的测试覆盖评估，是对被测试的程序代码语句、分支（判定）或条件的覆盖率分析。基于需求的测试覆盖评估，通过对已执行/运行的测试用例所覆盖的业务需求、用户故事、功能和非功能性需求等进行核实和分析而获得。大模型助力基于代码的测试覆盖评估论文“HITS:High-coverageLLM-basedUnitTestGenerationviaMethodSlicing”

结果比较测试大模型助力测试覆盖评估目前已有企业通过领域数据和SFT（有监督微调）训练出企业内部测试大模型（简称：ET-LLM）ET-LLM能够动态适应这些变化，根据新的业务规则和功能调整测试用例通过对历史缺陷数据的深度分析，ET-LLM能够识别出常见的缺陷模式和高风险区域ET-LLM会生成直观的可视化报告，以图表、图形等形式展示测试覆盖率的情况6.7.3测试报告生成一个好的测试报告，是建立在正确的、足够的测试结果的基础之上，不仅要提供必要的测试结果的实际数据，同时要对结果进行分析，发现产品中问题的本质，对产品质量进行准确的评估为了让大模型生成测试报告，要提供测试需求分析书、测试计划书和测试执行结果，然后让大模型生成TMS系统测试报告，并要求以特定的文档格式示例本章小结现有测试平台已实现测试全流程数字化管理，涵盖用例、脚本、执行、结果呈现等核心环节；深度集成研发与运维流程，支持持续集成发布、在线测试及用户反馈收集；融合RAG、知识库与企业测试大模型，优化提示词构建与脚本生成准确率；基于LLM实现场景分析、用例生成、MBT建模等智能测试设计，提升覆盖率；具备测试数据自动化生成、接口规范校验与智能修复能力；构建多智能体协作与任务拆分机制，支持自主探索式测试，推动端到端智能化。提问、思考与练习广义的质量概念给质量管理带来了哪些益处？软件质量控制和软件质量保证之间有何区别？请结合软件质量工程体系，思考如何在敏捷开发环境中构建有效的缺陷预防机制，以及AI技术如何助力提前发现和预测潜在缺陷？在实际项目中，如何有效地结合AI与人工经验来制定测试策略？并分析在哪些情况下AI分析可能存在局限性，需要人工干预完善？学习资源推荐朱少民等，软件质量保证与管理（第2版），清华大学出版社，2019.4朱少民，全程软件测试（第3版），人民邮电出版社，2019.1朱少民，软件测试方法和技术（第4版），清华大学出版社，2022.11JunjieWang,YuchaoHuang,ChunyangChen,ZheLiu,SongWang,andQingWang.2024.Softwaretestingwithlargelanguagemodels:Survey,landscape,andvision.IEEETransactionsonSoftwareEngineering(2024)感

谢

聆

听智能软件工程第7章如何实现持续集成与持续交付软件交付的复杂性与挑战软件交付不是“一键完成”，而是整合与检验所有开发工作的过程常见问题：开发环境与生产环境不一致（如WindowsvsSolaris）文档不清晰、不完整，导致部署困难多团队（开发、测试、运维）沟通成本高紧迫的发布时间导致技术债累积缺乏变更记录与规范的配置管理软件交付阶段风险高、复杂度大，是软件生命周期的重要节点本章学习目标持续集成、持续测试与持续交付的原因、理念、具体过程与最佳实践低风险发布的概念，以及蓝绿部署、金丝雀发布等常见发布策略云原生软件的基本概念与基于云原生的CI/CD服务CI/CD部署流水线的组成，以及云原生软件的部署流水线实例7.1持续交付7.2持续集成7.3持续测试7.4部署与发布7.5部署流水线7.6云原生的CI/CD7.7智能化应用的CI/CD7.1

持续交付软件交付概述软件交付是将已开发完成的软件交付给最终用户的过程，标志着软件从开发到可用的“落地”主要环节：整合与构建全部代码代码检查与测试（质量验证）部署到生产环境并进行实测通过验证后正式发布给客户关键特征：连接需求实现与用户使用的关键阶段；涉及开发、测试、运维、客户多方协作不同团队与项目可采用不同交付方式被视为软件生命周期中最具挑战性与压力的阶段软件交付的反模式(Anti-patterns)开发完成之后才部署：导致临近交付才发现环境差异，基于错误假设进行开发。过度依赖手写文档：文档易错、不清晰、未及时更新，部署依赖手工操作。手工配置并管理环境：增加重复工作量，不利于环境重建，难以追溯和回滚问题。过度依赖少数员工：知识孤岛，使核心成员成为“singlepointoffailure”(单点故障)，影响团队稳定性持续交付持续交付是一种模式和实践，旨在有效解决传统交付中的问题。短周期：快速迭代和频繁交付，快速响应市场变化。高质量：通过自动化测试和质量保证，确保软件的稳定性和可靠性。低风险：降低变更风险和部署成本，通过监控机制快速识别和解决问题持续交付的核心理念自动化

(Automation)：持续交付的基石。自动化构建、测试、配置、部署，减少手动错误，实现更频繁交付。端到端(End-to-End)：整个流程从开发到部署是无缝、一体化的，可实现“一键式”发布。快速反馈(RapidFeedback)：在早期发现问题，降低修复成本；用户需求能迅速得到验证和反馈。全员参与(All-HandsParticipation)：交付是整个团队的共同责任，促进跨职能协作，打破交流壁垒。持续交付的具体实践版本控制：追踪变更、保障一致性自动化测试：提升验证速度与质量持续集成：每次提交触发构建与测试，保持软件可工作状态部署流水线：端到端自动化流程，实现低风险发布与快速反馈7.2

持续集成版权所有©️仅限于教学使用持续集成(CI)：历史起源：“每晚构建”(NightlyBuild)早在20世纪80年代，微软Office团队就开始使用“每晚构建”实践，指每晚定时自动执行一次软件构建工作，包括从版本控制系统提取最新代码，进行编译、构建和测试。目的：确保每天结束时，开发团队能够构建、运行并测试软件项目的最新版本，并及时发现和解决潜在问题。CI概念的提出在20世纪90年代初期的C3项目中，KentBeck及其团队发现项目代码的集成耗时且困难（通常需要一至两周）。团队通过提高集成频率，显著减少了每次集成的时间，并使得软件问题能够更早被发现和修复。1996年，KentBeck提出了持续集成的概念：“每天多次集成和生成系统，每次都完成一个构建任务”。随着敏捷开发与DevOps的发展，CI概念得到了不断的实践和推广。持续集成：定义持续集成（ContinuousIntegration，CI）是一种软件开发实践，指每次提交都会自动触发对整个软件的构建与测试。构建或测试中出现问题需要立即被修复。持续集成减少了每次集成的时间，使得团队能够尽早地发现并解决由代码集成引入的问题，从而使软件随时处于可工作、可运行的状态，加速软件交付过程。持续集成：准备工作版本控制：有开发相关内容（代码、配置、脚本、文档）均纳入版本控制。自动化构建：能够自动执行编译、测试、打包等任务，确保构建一致性。自动化质量验证：验证软件是否满足需求，并提供快速反馈（如静态检查、自动化测试）。自动化配置与部署：基础设施（如数据库脚本、部署脚本）纳入版本控制，支持自动化配置。团队共识：对集成频率、流程、标准等达成一致意见。持续集成：提交阶段持续集成：集成阶段持续集成服务器（ContinuousIntegrationServer，CI服务器）：CI服务器是持续集成流程的核心，负责监控版本控制系统中的代码更改，并触发整合和构建过程。流行的CI服务器包括Jenkins、Bamboo、CruiseControl、TeamCity等。版本控制平台:

用于管理和追踪代码的版本变更。目前常见的版本控制平台包括GitHub,GitLab等。构建工具：负责将源代码转换为可执行的软件，常见的构建工具包括Make,ANT,Maven,Ivy,Gradle等。代码规范检查工具：用于保持代码的一致性和规范性，如CheckStyle，PMD等。自动化测试框架：用于验证软件（的更新）符合需求。常见的测试框架包括JUnit,Selenium等。持续集成：集成阶段CI服务器通过轮询等方式，判断版本控制平台是否有符合触发的操作，比如新的提交。CI服务器将更新从版本控制平台拉取至专用服务器。当项目规模不大时，CI服务器也可以作为专用服务器。CI服务器自动运行团队预先定义好的持续集成脚本，对更新后的项目进行自动化编译、规范检查、测试、打包等操作。CI服务器将构建好的软件自动部署至指定的环境（如类生产环境），并自动向开发团队反馈结果。如果构建过程中发现任何问题，开发团队需要尽快修复。持续集成：最佳实践将所有开发相关内容纳入版本控制系统主分支：主分支应该能够提供构建和运行软件产品所需的一切内容。尽可能使用文本文件定义产品和环境：文本文件方便获取不同版本之间的差异，比二进制制品更容易进行版本控制和理解变化。提交应是频繁、且自包含（self-contained）的：每次完成一个逻辑意义上的任务就进行一次提交，这使得代码变化更容易理解，也更容易实施回滚操作，减少对其他代码的影响。构建或测试失败后立即着手修复，同时禁止提交新代码：如果提交代码后触发的构建或测试失败，开发者应立即着手修复，在此期间应禁止团队成员提交新代码，以避免引入其他问题或加深问题的复杂性。持续集成：智能化智能代码审查：AI可以在开发者提交代码前于本地进行，或在代码提交后的构建流程中进行。智能反馈：AI可以处理构建过程中产生的各类数据，整合、分析大量构建信息，并给出缺陷修复建议。AI辅助测试：单元测试代码可以由AI辅助生成；测试阶段可与智能反馈阶段联动：例如，当AI生成代码修复建议后，AI可以为该建议生成新的测试用例，以防止测试覆盖率降低。7.3

持续测试版权所有©️仅限于教学使用持续测试持续测试即支撑持续交付的测试，是实现自动质量验证的主要方法。核心理念：在流程一开始就将质量内嵌于软件产品之中，而不是在流程最后进行大量检查测试四象限测试四象限：第一象限面向对象：主要面向技术人员（开发者）。目的：支持编程，旨在帮助团队检查功能需求的开发情况。自动化程度：这一象限的测试可以全自动执行。测试四象限：第一象限单元测试

(UnitTesting)：对软件中最小的可测试单元（如函数、方法或类）进行测试。目标是验证每个单元功能是否按预期工作，并关注代码的局部性，尽量排除外部依赖（如不与外部数据库交互）。组件测试

(ComponentTesting)：对已经过单元测试的软件模块（组件）进行测试。目标是验证不同组件集成时是否按预期交互，以及组件间的接口是否正确。通常需要模拟或使用测试替身（mocks）来模拟外部依赖。集成测试

(IntegrationTesting)：对已通过组件测试的模块进行测试，以验证这些模块在整个系统中的协同工作。涉及组件间的接口、数据流、控制流等方面，确保模块间的交互不会导致问题。测试四象限：第二象限面向对象：主要面向业务人员。目的：从用户的角度验收软件功能。测试四象限：第二象限端到端测试(End-to-EndTesting,E2E)：用于验证整个应用程序的各个组件和系统之间的集成，以模拟真实用户场景。涵盖从用户界面到后端数据库的完整功能路径，确保系统在用户视角下的正常运行。测试通常在真实环境中进行，通过自动化工具执行，确保在不同环境中可以重复执行。用户故事测试(UserStoryTesting)：敏捷开发中的关键实践，用于验证软件功能是否满足用户故事（Userstory）中描述的需求。测试涵盖happypath（正常路径）、alternatepath（替代路径）和sadpath（异常路径）。Given-When-Then(GWT)模型：明确在特定前提条件下（Given），用户执行操作时（When），系统是否产生预期的结果（Then）。测试四象限：第三象限面向对象：主要面向技术人员。目的：评判项目并寻找缺陷。测试类型：划入这一象限的测试称为“非功能性测试”(non-functionaltesting)，侧重于确保系统在不同条件下表现出良好的特性，而非仅关注功能是否执行。自动化程度：部分测试可以自动化，但部分复杂的交互场景仍需要人工介入。测试四象限：第三象限性能测试(Performancetesting)：评估系统在各种工作负载和性能条件下的响应时间、吞吐量和资源利用率。子类型包括负载测试和压力测试。安全性测试(Securitytesting)：评估系统对未经授权访问、数据泄露和其他安全威胁的防护能力。可靠性测试(Reliabilitytesting)：评估系统在长时间运行和各种环境条件下的稳定性和可靠性，包括发生故障时的数据和功能的恢复能力。可扩展性测试(Scalabilitytesting)：评估系统在处理不断增长的数据量、用户数或交易时，保持良好性能的能力。测试四象限：第四象限面向对象：主要面向业务专家。目的：评判项目并寻找缺陷。自动化程度：这一象限的测试通常只能通过手工方式执行。测试四象限：第四象限用户验收测试(UserAcceptanceTest,UAT)：软件开发生命周期的最终测试之一，由最终用户或业务代表执行，以验证系统是否满足业务需求。目的是通过用户的参与，确保软件项目能够满足最终用户的期望，实现业务价值。可用性测试(Usabilitytesting)：评估软件系统或产品的用户界面。目的是确保系统在用户操作中的易用性和用户体验，通过观察最终用户执行特定任务的过程来发现潜在的用户界面问题。探索性测试(ExploratoryTesting)：一种软件测试风格，强调测试人员的思考能力和创造性。测试人员在没有明确预定计划的情况下，根据经验和直觉自由测试，适用于需要快速获得质量反馈或需求不清晰的情境。持续测试持续测试作为持续交付的重要支撑，需要满足“快速、便捷、及时、可信”四个衡量维度。“快速”要求测试的执行速度和反馈周期快，一般在10分钟之内，且不超过15分钟。“及时”要求测试必须对每一次系统改变都进行及时的验证与反馈。“便捷”指团队中的每个成员都可以随时随地轻松地执行测试。“可信”指测试结果需稳定、一致地反映出系统真实的问题。为了达到“快速、便捷、及时”的目标，研究者提出了“测试金字塔”理念测试金字塔结构：下层由快速、高度自动化的测试组成；上层由测试范围广、需手工进行的测试组成。比例要求：下层测试的数量比例应远多于上层，以高比例的底层测试（如单元测试）快速验证系统的基本功能逻辑，并降低成本。例如，Google依照测试金字塔理念，将小型、中型和大型测试按70%、20%与10%的比例划分。测试金字塔持续测试应贯穿整个持续交付工作流程。流程前期（提交时）执行金字塔底层的自动化单元测试，快速反馈问题。流程中期（构建阶段）执行金字塔中间的自动化组件测试与系统测试。流程后期（部署至类生产环境后）执行非功能性验收测试，如性能测试、可靠性测试等。系统正式上线前，在类生产环境或生产环境实施金字塔顶层的用户验收测试(UAT)。7.4

部署与发布版权所有©️仅限于教学使用概述部署与发布的区别：部署(Deployment)：指将软件在配置好的环境中运行起来。发布(Release)：指选择部署完成的软件版本并正式发布给客户。两者关系紧密，共同构成了软件交付的最后一个重要环节。部署与发布流程的关键目标：高效(HighEfficiency)：团队能够及时、高频发布重要的软件功能与更新，前提是对部署过程的自动化。低风险(LowRisk)：软件的更新发布不应对现有软件的功能性与可用性产生负面影响，即用户可以正常使用更新后的软件。部署环境开发环境(DevelopmentEnvironment)：位于开发者个人计算机上的工作环境，作为灵活的“沙盒”，用于代码更新、测试和调试，不影响终端用户。类生产环境(StagingEnvironment)：用于模拟生产环境的测试环境。它更接近真实的生产环境（相似的硬件、配置、数据），用于系统演示或作为从开发到生产的过渡。生产环境(ProductionEnvironment)：最终用户访问和使用软件的实际运行环境。部署流程准备操作系统层：安装操作系统，进行系统层面的配置（如网络、防火墙设置）。准备中间件层：安装应用程序运行所需的标准化软件，如Web服务器、数据库等。准备应用程序层：部署目标应用代码、数据，以及项目依赖的第三方库，通常包括代码拉取、数据初始化、配置与安装。部署流程

步骤1安装操作系统2安装JDK8，并进行相应的环境变量配置3安装mysql(>=5.6&&<8.0)4mysql准备工作，包括创建数据库等5tomcat8war包下载，并且将war包解压到tomcat的**webapps/ROOT/**下面(解压前清空ROOT目录下内容).6更新perties，修改包括数据库连接配置（如用户名、密码、端口号）等信息。另外，“博文导出pdf”功能需要服务端配置md2pdf服务支持,其调用路径配置在perties中，可以根据模块位置自行调整配置.7部署打好的部署war包8测试。以登录密码：super/88888888访问http://localhost:8090/#/homeTMS系统部署流程配置管理环境配置：对应操作系统层，涵盖操作系统版本、环境变量、网络配置等。应用配置：对应中间件层与应用程序层，包括数据库连接信息、服务器端口、日志级别等。业务配置：与具体业务逻辑相关，如促销配置、购物车最大额度调整等，通常在软件发布后的运营阶段使用。自动化部署关键原则将全部部署脚本与配置信息以非二进制形式创建并进行版本控制。这使得团队成员可以随时获取任何版本的脚本和配置，确保环境可重复搭建、可追溯，并在发生问题时很容易回滚。容器技术容器技术（如Docker）将应用程序及其依赖项打包为独立的容器，使得应用在不同环境中保持一致的运行状态。容器技术加速了应用程序的部署和扩展，是持续部署与云原生软件的核心技术。智能化部署AI可以将配置文件（如KubernetesYAML）视为代码，自动生成适配的部署脚本。AI能够根据项目代码和依赖文件，提供配置调整建议，并辅助开发者调试配置问题。软件发布发布计划：需要详尽制定，涉及首次部署、负责人、错误恢复、服务模式等，所有干系人（包括客户、用户、售后）都应参与制定。回滚策略(RollbackStrategy)：关键措施，用于在软件发布引入问题时（功能、兼容性、性能问题）快速有效地回到一个稳定、可用的状态。发布频率公司部署频率部署时间单位可靠性用户接受度Amazon23000/天分钟高高Google5500/天分钟高高Netflix500/天分钟高高Facebook1/天小时高高Twitter3/周小时高高传统企业每9个月月、季度中低中低发布频率瀑布模型(传统企业)：部署频率低，通常为数月甚至更久一次；可靠性与用户接受度处于中低水平。敏捷/DevOps(年轻互联网公司)：强调拥抱变化，发布频率显著提高。例如，Amazon部署频率可达每小时1000次左右；Netflix在2021年每天部署次数达到两万次。高频发布并未导致软件质量下降；对于以周、天、分钟为单位的部署，软件的可靠性与用户接受度都处于高水平状态。低风险发布策略：重新部署策略机制核心主要优势主要挑战1.重新部署(二进制回滚)重新部署旧的稳定版本覆盖问题版本。实施简单，利用已验证版本快速降低风险。需停机，数据库回滚导致数据丢失风险。2.代码升级(BinaryRoll-Forward)删除问题代码提交，部署代码修复后的新版本。避免数据回滚，问题修复纳入下一次计划。仍需停机，要求精确定位问题代码（实施难度高）。低风险发布策略：热部署核心概念一种软件部署方法，允许在系统运行时更新或替换应用程序的部分，无需停止整个应用程序或系统。优势：能够在不中断服务的情况下进行软件更新、修改或扩展。价值体现（以美团为例）本地自测：代码修改后可实现一键增量部署，“秒级”生效，大幅加快本地自测速度。联调效率：将内部测试环境部署时间从几十分钟降至2-10秒，几乎“瞬间”生效，极大地提升了工程师的效率。热部署：主要实现技术类加载器（ClassLoader）原理：通过新的类加载器加载更新后的类，避