系统可测性规范

汇总了各种资源，总结了一份系统可测性需求。制定可测性需求时，应结合当前组织的技术基础和项目特点，以下内容并不适用于所有组织和项目。
欢迎大家拍砖讨论。

1. 可观察性

1.1 更容易观察到测试结果

1.1.1 交易记录是否完整

清晰完整的交易日志能够提升问题分析和定位的效率和准确率，并能够用于复现问题。交易日志记录应满足如下要求：在测试环境通过调整日志记录的级别，实现记录包括系统内及系统间接口调用的输入、返回报文，及请求数据库的SQL和存储过程（包括传参）。系统记录的交易全链路日志必须完整，建议在应用开发设计过程中，根据交易重要程度、交易调用链复杂度和便于问题跟踪排查等因素综合考虑，将交易日志写入数据库日志表或者交易日志文件中。

如果系统面向互联网开放，用户访问和操作存在较大不确定性，因此建议对用户操作行为和路径进行埋点统计，便于持续迭代过程中系统功能设计与测试案例的设计。系统埋点应覆盖客户端操作界面的主要业务操作所涉及的页面和交互控件，并在相关设计文档中体现埋点的覆盖范围，以及埋点统计信息的保存方式和访问方式，便于通过接口或数据库对埋点统计数据进行分析。

1.1.2 交易异常是否有明确输出

遵守开发规范，将系统或交易异常写入日志文件。

1.2 版本状态可查

应用系统各个节点中应记录当前版本号和版本更新实践（例如应用节点操作系统的文件、数据库表），并将更新版本状态标志的操作集成进版本实体中，在版本安装过程中实现自动更新。

1.3 交易路径可查

1.3.1 业务执行状态和过程可观察

通过获取业务执行的过程状态，并配合相关系统功能设计文档，可以准确的判断交易的各类过程状态与功能设计是否一致。对于业务状态的记录需要满足以下要求：对于交易的当前状态和终态结果有明确的记录（包括状态标志、更新时间、操作用户），并且能够记录在日志或数据库表中。

1.3.2 调用链可查

如果系统交易为长流程交易，通过调用链监控可以准确的识别系统内和系统间调用链，提升问题分析定位效率，辅助测试案例设计与执行。对于全链路调用链监控，主要有以下三种实现方案，取得的效果也不尽相同，项目组可以结合自身技术架构进行参考。具体如下：

对于分布式架构的系统，可以通过在日志中记录交易唯一流水号实现分布式架构系统内调用链的展现。
对于跨系统交易，通过系统间全局交易流水号或利用APM技术在报文头中打入序列号实现系统间调用链的展现。
利用商用或开源APM技术，通过埋点或字节码增强技术，实现测试环境系统内和系统间的全链路调用链展现。

2 可控制性

2.1 适于自动化测试

2.1.1 测试数据准备

测试过程中需要大量测试数据支持，尤其对于消费型测试数据，需要持续补充可用的测试数据。通过手工模拟真实业务交易准备测试数据效率较低，而且受限于各类交易控制，难以满足所有测试数据需求，因此需要支持通过自动化交易或后台数据库方案完成各类测试数据准备的需求。

2.1.2 界面稳定性

为了保证补丁频繁迭代下的测试环境稳定性和持续回归测试的需求，需要对核心业务流程通过自动化的方式进行验证。自动化测试方法主要通过UI和接口两种方式发起，对于UI发起的自动化测试，实施步骤首先定位页面元素/控件，然后操作元素/控件，通过模拟手工操作的过程完成业务流程的测试。因此前端页面元素的稳定性和标准化对于自动化测试脚本的稳定性和可用性至关重要。因此在页面组件属性、布局等发生变动后，即便是不影响业务功能也需告知测试，便于测试人员相应调整自动化测试脚本，保证测试脚本的可用性。

2.1.3 组件标准化

同模块开发时使用统一标准的组件，避免出现不同模块相同类型的组件（例如输入框、级联下拉框等）开发方式不同的情况，开发过程应遵守统一的组件设计规范。通过上述策略，可以尽可能保证前端功能的正确性和可操作性，减少UI层面的缺陷。

2.1.4 验证码开关控制

出于系统安全的需求，系统在登录或资金操作环节都会设计动态或图形验证码。在自动化测试和性能测试过程中难以有效从UI层面模拟验证码的操作，需要应用设计时同步考虑，主要有以下几种解决方案：

通过临时替换程序的方式，屏蔽验证码的功能。替换临时程序的步骤可以集成在启动脚本中，将需替换的程序（包含程序相对路径）先放到系统临时目录下，在启动时先判断临时目录是否存在文件，如果存在则将替换成copy到对应的目录，再启动服务。
通过系统后台开关的方式，屏蔽验证码的功能。建议通过数据库参数开关进行控制，避免每次装版后都需要手工修改应用配置。
能够从后台数据库或接口服务获取验证码实际校验值。

2.1.5 前后台调用记录可查

对于利用C/S架构开发的客户端程序，能够有方法获取前后台接口调用情况，同时可以通过调试工具或端口捕获前后台调用中出现的错误和异常信息，用于发现和定位问题。

2.2 适于功能测试

2.2.1 支持测试环境跳日期场景

为了模拟生产环境特殊日的验证需求（如月末、年初、年末、闰年2月29日等），测试环境日期无法与自然日期保持一致，且有可能存在多个自然日保持同一个系统日期的情况。因此在系统需要支持测试环境日期不连续的特点，比如跳过某段时间的日终批量，对于无法支持跳日期的功能要有记录。

2.2.2 配置参数实时生效

主要业务配置参数重新调整后，不需要重启应用即可生效。

2.2.3 KEY开关控制

对于需要外设KEY（类似U盾）验证的业务操作，有开关控制、程序模拟或单独的不插KEY校验的客户端等方法跳过验证。

2.2.4 报文模拟器

对于涉及第三方联调的接口，对于第三方返回接口内容定义清晰，可以通过模拟第三方发起和返回报文在测试环境完成相关交易流程，无需第三方的真实接入。

3 可分解性

3.1 投产风险可控

应用面向互联网接入，应用架构设计时应具有灰度发布的能力，控制应用投产对客户使用引入的风险。
生产系统应具有投产后的专用测试验证用户，用于在系统投产后第一时间在生产环境验证项目修改的内容。

3.2 配置分级原则

应对版本安装过程中需要客户化的参数进行统一管理。
应用外部划分出全局级变量，在顶层进行管理。
在应用内部划分应用级、服务群组级、环境级3层变量，每层都遵循统一的命名前缀和规则。
环境级支持对变量进行应用服务节点级和应用服务节点实例级（IP级）的管理，进行特定值的维护。

4 稳定性

4.1 准入测试案例及标准

集成测试、SIT测试、UAT测试复用核心测试案例，保证各个阶段的测试工作对于需求和测试对象理解的一致性。

4.2 各阶段测试质量门禁

在项目的开发、测试阶段应有每个阶段明确的准入和准出标准：
开发阶段：

代码检查覆盖率；
单元测试代码覆盖率；
集成测试&上下游联调测试案例通过率；
集成测试缺陷修复率；

系统测试阶段：

系统测试准入案例通过率；
核心功能测试覆盖率；
系统测试案例执行通过率；
系统测试缺陷修复率；

对于以上各个阶段的质量标准应有明确的定义，以项目质量管理文档和测试总体方案为准。

4.3 问题及缺陷管理流程

4.3.1 问题及缺陷管理

缺陷类型明确，不存在交叉；
缺陷责任人明确，谁处理谁答复；
缺陷状态明确，尽量减少搁置类的状态；
提高缺陷提交质量，对于严重缺陷和疑似环境问题，需要经乙方测试组长和甲方测试经理把关；
建立缺陷升级机制，每周设瓶颈&争议缺陷推动会。

4.3.2 补丁管理

缺陷管理与补丁管理应能够联动，或具备缺陷与补丁信息关联的方法，能够通过版本补丁部署获取到缺陷的修复信息，并能够同步更新缺陷状态。

4.4 需求变更可控

4.4.1 体验测试

在SIT阶段，当系统核心功能稳定后，尽可能提前安排一轮体验测试，邀请业务验收测试人员参与体验测试，用于验证系统功能实现与业务实际需求的一致性，提前暴露需求层面的风险和用户体验方面的问题，减少测试中后期的业务需求变更。

4.4.2 需求变更

对于测试期间的需求变更，应有严格的需求变更管控机制和审批流程，并提供需求变更影响性分析说明，相关信息能够同步至研发、测试干系人，用于需规和案例的调整。

5 易理解性

5.1 文档完备性

5.1.1 系统功能清单

建议建立程序实体与业务功能的映射关系，包含功能名称、所属系统（例如登记、客户管理、结算等）、性质（新增或修改）、功能类型（联机程序、批量程序、接口、作业等）、负责开发人员等信息，通过上述信息构建测试用例与程序实体间的联系，便于后续分析定位问题原因和精准测试，同时便于测试规划分工和与开发人员的日常沟通。

5.1.2 系统操作说明

提供系统使用手册，在测试过程中进行参考，并针对手册中的问题反馈应用开发组进行修改。

5.1.3 项目文档

《业务需求说明书》：确认客户需求或产品的质量需求都是明确的、可预见的并被描述在文档中，将来可以用于某种方法来判断、验证这种需求或特性是否已经得到了实现；需求描述足够的清楚和明确，可以作为开发设计说明书和功能性测试数据的基础；系统的非功能需求（如性能、可用性等）有明确的定义和标准；各种故障模式和错误类型都有明确的处理方式。
《系统用例设计》：用例能够在业务需求中找到相关方法、模板、输入输出等要求；按照模板要求填写系统用例描述表中的各项内容；按要求描述用例的基本事件流；按要求描述系统用例的备选流和异常流；引入业务建模4级任务定义中的业务规则定义；根据《错误信息编写规范》定义系统用例执行中可能抛出的错误；按标准输出完整的用例场景图；描述系统用例中所需调用的交易服务、本地构建、应用批处理等服务的名称、服务版本及服务提供方等相关信息。

5.1.4 接口文档

接口文档应明确以下内容：

功能明确；
参数有意义，遵循新一代接口设计规范；
提供完整的接口调用方清单（不仅限于当前项目）。对于微服务或服务化接口，建议被调用方接口对调用方应用进行白名单配置，避免未知情况下的调用引发的接口服务性能容量的风险。