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