以下是 GB/T 25000.51-2016 标准中维护性下条款各方面的测试方法及关注内容：
模块化
- 测试方法
- 组件停止与替换测试：在系统运行时，尝试停止或替换某个组件，观察其他组件能否正常独立运行及处理任务1。
- 接口调用测试：检查模块之间的接口调用是否规范、稳定，是否存在不必要的耦合。
- 关注内容
- 模块职责清晰度：每个模块是否有明确、单一的职责，不与其他模块产生职责混淆。
- 内聚性：模块内部的元素是否紧密相关，是否为了完成一个共同的功能而组合在一起。
可重用性
- 测试方法
- 跨项目复用测试：查看软件资产在不同项目或系统中的实际复用情况，统计复用的次数、范围等1。
- 可配置性测试：对可重用资产进行不同配置参数的设置，观察其在不同场景下的适应性。
- 关注内容
- 资产通用性：代码、设计、文档等资产是否具有广泛的通用性，是否能适用于多种不同的业务场景和系统需求1。
- 复用的便利性：复用资产时，是否需要进行大量的修改和调整，是否有清晰的复用指南和接口说明。
易分析性
- 测试方法
- 故障注入测试：人为地向系统注入故障或异常，观察系统的反应和输出的错误信息。
- 日志审查测试：审查系统在正常运行和出现故障时的日志记录，检查日志的详细程度、准确性和规范性1。
- 关注内容
- 错误定位准确性：根据系统提供的信息和诊断工具，能否快速、准确地定位到问题所在的模块、代码行或业务流程环节。
- 影响分析全面性：对于预期的变更，系统是否能够提供全面的影响分析，包括对其他模块、业务功能、性能等方面的影响。
易修改性
- 测试方法
- 功能扩展测试：对系统进行功能扩展，如增加新的业务功能、数据字段等，观察系统的适应能力和修改的难易程度。
- 代码修改测试：直接对系统的代码进行修改，然后进行编译、测试，检查是否会引发其他模块的错误或系统整体的不稳定。
- 关注内容
- 修改成本：包括修改所花费的时间、人力成本以及对系统其他部分的影响程度等，如果修改一个功能需要对大量的代码和配置进行调整，说明易修改性较差。
- 稳定性保持：修改后系统是否能够保持稳定运行，不会出现新的漏洞、错误或性能下降等问题。
易测试性
- 测试方法
- 测试用例编写测试：根据需求文档、设计文档等，尝试编写测试用例，评估编写的难易程度和测试用例的覆盖范围1。
- 测试环境搭建测试：搭建不同的测试环境，包括不同的操作系统、数据库、硬件设备等，观察系统在不同环境下的测试执行情况。
- 关注内容
- 测试接口友好性：系统是否提供了方便的测试接口，如 API 接口、测试工具接口等，便于测试人员进行自动化测试和数据输入输出。
- 测试数据准备：是否容易准备各种测试数据，包括正常数据、异常数据、边界数据等，以满足不同测试场景的需求。
依从性
- 测试方法
- 文档审查：审查产品说明书、用户文档、技术文档等，检查其中关于维护性的描述是否符合相关标准、约定或法规1。
- 行业规范比对：将系统与行业内通用的维护性标准、规范进行详细比对，检查是否存在不符合的地方1。
- 关注内容
- 法规遵循的完整性：是否全面遵循了所有相关的法规、标准和规范，不存在任何遗漏或违反的情况。
- 证明材料的有效性：如果有相关的认证证书、测试报告等证明材料，要检查其真实性、有效性和时效性。