不再问“软件是否可维护？”，而是问“为了执行一个标准的维护任务，需要多少时间、资源，并伴随多大风险？”
以下是符合CNAS要求的、可执行的可维护性测试用例设计方法。
一、 理解可维护性的主要子特性
首先，将“可维护性”分解为CNAS和ISO/IEC 25010标准中定义的可测量子特性：
模块化：软件组件是否分离良好？
可复用性：资产（代码、文档）能否在其它应用中复用？
易分析性：诊断缺陷或失效原因的难易程度。
易修改性：实现特定修改的难易程度。
易测试性：验证已修改软件的难易程度。
二、 设计具体、可测量的测试用例
为每个子特性设计可操作的测试场景和客观的通过/失败准则。
- 针对【易分析性】的用例
用例标题：LOG-MA-001 - 日志诊断缺陷根因的能力
测试步骤：
在测试环境中，通过修改配置或注入代码，触发一个已知的、特定的错误（例如：数据库连接失败）。
执行触发该错误的操作。
检查系统生成的日志文件（如应用日志、错误日志）。
预期结果/通过准则：
日志中必须包含 ERROR 或 WARN 级别的记录。
日志信息必须清晰指明错误类型（如“数据库连接异常”）。
日志必须包含准确的时间戳、产生错误的模块/组件名（如 com.xxx.UserService）。
日志必须包含关键上下文信息，如失败的操作ID、用户ID或请求参数。
（高级要求）日志应包含错误的堆栈跟踪，能直接定位到出错的代码文件和大致行号。
测试数据：记录下用于触发错误的特定参数和操作。
- 针对【易修改性 & 模块化】的用例
用例标题：MOD-MA-001 - 修改特定业务规则的隔离性
测试步骤：
选择一个独立的、非主要的业务规则（例如：“用户积分超过1000分时，自动升级为银卡会员”）。
要求一名未参与该模块原始开发的测试工程师，将此规则修改为新规则（例如：“用户积分超过1200分时，自动升级为银卡会员”）。
记录该工程师完成此任务所花费的总时间（从理解代码到修改验证完成）。
检查修改过程。
预期结果/通过准则：
修改仅涉及1个或少数几个（如≤3个） 代码文件。
修改过程未引发任何不相关的编译错误或功能回归。
完成修改的总时间低于预设阈值（例如：2人小时）。
测试数据：记录修改前后的代码、涉及的文件列表、总耗时。
- 针对【易测试性】的用例
用例标题：TEST-MA-001 - 主要业务组件的单元测试覆盖度与可执行性
测试步骤：
使用代码覆盖率工具（如JaCoCo for Java, Istanbul for JS）对选定的主要组件（如 PaymentService）运行其完整的单元测试套件。
生成覆盖率报告。
检查单元测试套件是否能在开发环境外独立、一键式运行（如通过 mvn test 或 npm test 命令）。
预期结果/通过准则：
该组件的行覆盖率 ≥ 80% （具体阈值可根据项目要求调整，但必须有）。
单元测试套件能够在不连接外部数据库或中间件的情况下运行（使用Mock/Stub）。
执行单一命令即可成功运行所有测试并生成报告。
测试数据：附上生成的覆盖率报告截图和执行日志。
- 针对【模块化 & 可复用性】的用例
用例标题：DOC-MA-001 - 架构文档与代码结构的一致性
测试步骤：
查阅软件设计文档中的架构图/模块图。
根据文档，选择一个被描述为“独立”的模块。
使用静态分析工具（如SonarQube，或依赖关系分析工具）分析该模块的代码。
预期结果/通过准则：
静态分析报告显示，该模块与系统其他部分的循环依赖数为0。
该模块的API接口（如公开的方法、REST端点）与设计文档的描述完全一致。
测试数据：附上静态分析报告的依赖关系部分截图。
三、 CNAS要求的特殊考虑
客观性与可重复性：每个用例必须像上面一样，有明确的、量化的通过准则（时间、数量、覆盖率），避免使用“易于”、“方便”等主观词汇。
追溯性：测试用例必须能够追溯到软件的质量需求或测试计划中对可维护性的要求。
记录完整性：执行测试后，必须详细记录原始数据，如日志文件片段、覆盖率报告、修改前后的代码差异、时间记录等，作为符合CNAS要求的客观证据。
人员能力：执行测试（尤其是易修改性测试）的人员，其能力应被确认，但最好不是原作者，以更真实地模拟维护场景。
：为CNAS准备的可维护性测试，本质上是将维护活动“场景化”和“指标化”。通过设计一系列标准化的维护任务，并客观地衡量其执行效率、风险和产出，来有力地证明软件在该质量特性上的符合性。
