2026年上半年软考高级系统分析师论文回忆重构
说明：本卷根据回忆资料整理而成。由于原始材料是回忆题，以下为“同考点重构版”，不声明为官方原题逐字复刻。论文题按系统分析师论文常见命题样式整理为论题、写作要求和解析。
第1题
论题： 论大模型语言辅助软件测试
随着人工智能技术的发展，大模型语言技术正在逐步应用于软件工程实践。软件测试作为保障软件质量的重要活动，长期面临测试需求理解难、测试用例设计工作量大、缺陷复现信息不完整、测试资产复用不足等问题。大模型语言技术具备自然语言理解、文本生成、代码理解和知识归纳能力，可在需求分析、测试用例生成、测试脚本辅助编写、缺陷分析和测试报告生成等环节发挥作用。但与此同时，大模型生成内容也可能存在不准确、不可验证、泄露敏感信息、依赖上下文质量等问题。因此，在实际项目中合理引入大模型语言辅助测试，需要结合测试流程、人工评审机制和安全合规要求进行系统设计。
请围绕“论大模型语言辅助软件测试”这一主题，依次从以下三个方面进行论述：
一、概要叙述你参与开发或管理的软件项目以及你在其中所担任的主要工作。
二、请详细说明在生成测试用例的过程中，大模型语言技术可以有哪些具体实现方式。
三、结合你参与的项目，分析在测试过程中使用大模型语言技术的优势、问题及局限性，并说明针对这些问题采取的措施。
解析：
本题重点考查考生对大模型语言技术在软件测试活动中落地应用的理解。论文不能只泛泛介绍“大模型很智能”，而应围绕测试场景展开，说明其在需求理解、测试点提取、测试用例生成、边界条件补充、异常场景设计、接口测试脚本生成、缺陷描述归纳等方面的作用。
第二部分是全文技术核心。可以从以下角度展开：将需求规格说明书、用户故事、接口文档、业务规则作为输入，由大模型提取测试项；根据等价类、边界值、判定表、场景法生成测试用例；结合接口文档生成 API 测试脚本或测试数据；对已有缺陷和历史用例进行相似用例推荐；对需求变更影响范围进行分析，生成回归测试建议。写作时要强调“辅助”而非完全替代人工。
第三部分应体现工程实践意识。优势包括提高用例设计效率、补充遗漏场景、降低文档编写成本、提升测试资产复用；问题包括幻觉、生成用例与真实业务不一致、覆盖率不可证明、敏感数据泄露、提示词质量影响输出结果等。应对措施可包括：建立标准提示词模板、限制输入敏感信息、人工评审与基线确认、用规则和测试管理平台校验输出、引入脱敏数据、保留测试设计责任人审批、通过覆盖率指标和缺陷发现率评估效果。
第2题
论题： 论需求评审技术及应用
需求分析是系统分析师工作的核心内容之一。需求质量直接影响后续系统设计、开发、测试和验收。如果需求存在歧义、遗漏、冲突或不可验证等问题，往往会在后期造成返工、延期甚至项目失败。需求评审是发现和修正需求问题的重要手段，常见形式包括走查、评审会议和检查等。不同评审形式在参与人员、组织方式、正式程度和适用阶段上各有差异。系统分析师需要根据项目特点选择合适的需求评审方式，并将评审活动贯穿需求获取、需求分析、需求规格说明书编写和需求变更管理过程。
请围绕“论需求评审技术及应用”这一主题，依次从以下三个方面进行论述：
一、概要叙述你参与开发的软件项目以及你在其中所担任的主要工作。
二、请说明需求评审的主要形式，包括走查、评审会议、检查等，并比较其特点和适用场景。
三、结合你参与的项目，说明需求评审、评审会议、检查、走查在项目中的具体应用过程和效果。
解析：
本题要求考生结合需求工程实践展开。第一部分应简要交代项目背景、业务范围、系统规模、用户角色、需求来源和本人职责，如需求调研、需求建模、SRS 编写、评审组织、需求变更控制等。
第二部分应准确区分几种评审形式。走查通常由需求编写者主导，面向相关人员逐条讲解需求内容，适合早期发现理解偏差；评审会议由业务代表、开发、测试、架构、运维等干系人共同参与，适合对需求范围、优先级、冲突和可行性形成共识；检查更正式，通常依据检查表对需求规格说明书进行系统审查，重点关注完整性、一致性、可验证性、可追踪性、无二义性等质量属性。
第三部分应写出项目中的实际流程。例如：需求初稿完成后组织内部走查，先消除明显表达问题；形成 SRS 后召开多方评审会议，确认业务规则、流程边界、异常处理和优先级；在基线发布前使用检查表检查需求编号、来源、验收标准、非功能需求和追踪关系；需求变更时重新评审影响范围。效果可从减少返工、降低需求歧义、提高测试可验证性、提升用户确认效率等方面说明。
第3题
论题： 论信息系统安全技术及应用
随着信息系统与业务流程深度融合，系统安全已经成为系统分析与设计中必须重点考虑的问题。信息系统不仅需要满足功能需求，还必须在数据安全、身份认证、权限控制、密码技术、容灾备份和业务连续性等方面提供保障。尤其在涉及用户隐私、交易数据、医疗数据、政务数据或企业核心业务数据的系统中，安全设计需要贯穿需求分析、架构设计、开发测试、部署运维全过程。系统分析师应根据业务风险和安全目标，综合运用多种安全技术，并通过制度、流程和监控机制保证安全措施有效落地。
请围绕“论信息系统安全技术及应用”这一主题，依次从以下三个方面进行论述：
一、概要叙述你参与开发的软件项目以及你在其中所担任的主要工作。
二、请说明数据安全和密码技术、权限控制、容灾与业务连续性三类技术的主要内容和作用。
三、结合你参与的项目，说明如何应用上述三类技术，以及实施后的效果。
解析：
本题可围绕一个具备真实安全需求的信息系统展开，如在线教育平台、医院信息系统、电子商务系统、政务服务平台、企业管理系统等。第一部分要说明系统处理的数据类型、用户角色、业务连续性要求和本人在安全需求分析、方案设计或落地协调中的职责。
第二部分应分别展开三类技术。数据安全和密码技术包括数据分类分级、传输加密、存储加密、摘要校验、数字签名、密钥管理、数据脱敏和日志审计等；权限控制包括身份认证、基于角色的访问控制 RBAC、最小权限原则、权限审批、会话控制和操作审计；容灾与业务连续性包括备份策略、主备切换、异地容灾、RPO/RTO 指标、应急预案和定期演练。
第三部分应体现“技术与业务结合”。例如：对用户密码使用加盐哈希，对敏感字段加密存储，对接口采用 HTTPS；将管理员、业务人员、审计人员配置不同角色权限；对关键操作记录审计日志；对核心数据库采用主从复制和定期备份，对关键业务配置热备或双活，对普通业务采用冷备。效果可从降低越权访问风险、保障敏感数据安全、提升故障恢复能力、满足合规审计要求等方面说明。
第4题
论题： 论软件架构风格
软件架构风格是对一类系统结构组织方式的抽象，规定了系统中构件和连接件的类型、约束及其交互方式。合理的软件架构风格能够指导系统分解、职责划分、通信机制设计和质量属性实现。不同架构风格适用于不同业务场景，例如分层架构适合职责清晰的信息系统，管道-过滤器适合数据流处理，事件驱动架构适合异步通知和解耦，微服务架构适合大型复杂系统的独立部署和弹性扩展。系统分析师在项目中需要根据业务复杂度、性能、可维护性、可扩展性、可靠性和团队能力等因素选择合适的架构风格。
请围绕“论软件架构风格”这一主题，依次从以下三个方面进行论述：
一、概要叙述你参与开发的软件项目以及你在其中所担任的主要工作。
二、请描述软件架构风格的含义，列举常见软件架构风格，并结合例子说明其特点。
三、结合你参与的项目，说明如何选择和使用软件架构风格，以及该选择对系统质量属性的影响。
解析：
本题考查架构风格的概念和工程选择能力。第一部分应选择一个适合展开架构设计的项目，如工单管理系统、在线教育平台、远程诊断系统、企业销售管理系统等，说明系统规模、主要模块、外部接口、用户数量和本人承担的架构分析或方案设计工作。
第二部分应说明架构风格是“构件、连接件和约束”的复用性结构模式。常见风格包括：分层架构，将系统划分为表示层、业务层、数据层，利于职责分离；客户端/服务器架构，适合集中数据管理和多终端访问；管道-过滤器架构，适合编译、日志处理、ETL 等数据流场景；事件驱动架构，通过事件发布订阅降低耦合，适合通知、预警和异步处理；微服务架构，将系统拆分为可独立部署的服务，适合复杂业务和弹性扩展。
第三部分要避免只罗列风格，应说明选择依据。例如，在企业工单系统中采用分层架构组织前端、业务服务和数据访问；对工单提交、流转、评价等核心业务采用同步调用保障一致性；对通知、预警、统计采用事件驱动和消息队列提升解耦性；在业务规模扩大后将工单、用户、通知、报表等拆分为微服务。效果可从可维护性、可扩展性、性能、可靠性和部署灵活性等方面论述，同时指出引入微服务和事件驱动会增加运维、监控和数据一致性复杂度。