说一说《证券期货业软件测试规范》中的若干问题

近日，证监会发布并实施了《证券期货业软件测试规范》行业标准（JR/T 0175-2019，本文后面附有获取/下载方法）。该标准描述了证券期货业信息系统建设过程中的总体要求、单元测试、集成测试、系统测试、系统集成测试、验收测试等测试活动的内容。标准的发布实施旨在明确证券期货业软件测试工作的要求，增强对测试活动过程和结束的约束，提高行业软件测试过程的规范化程度。

正如证券软件测试从业人员评论道：

有比没有好（Better than none）
这是证券期货行业第一个测试标准，意义还是挺大的
有"行业测试规范"的，至少体现重视质量。还没看其他行业呢，对质量态度简直就是"无所谓"
......

的确，软件测试是软件质量保证的重要手段之一，需要对过程及其相关文档规范化。我国于2008年颁布了《GB/T 15532-2008 计算机软件测试规范》（本文后面附有获取/下载方法），2013年我国颁布了《银行业软件测试文档规范》（JR/T 0101-2013）。证券行业的IT水平相对落后，之前主要依赖采购和第三方服务，但最近几年加强自身建设，有明显进步，他们不仅颁布了标准，还办了杂志《测试技术与质量管理》（季刊，本文后面附有最新一期获取/下载方法。帮他们做一个广告：欢迎投稿，稿酬相当优厚），开发了完整的自动化测试系统和测试管理系统，输出给证券公司和交易所。今天上午快速看了这个《证券期货业软件测试规范》，内容还比较完整，覆盖了测试的不同类型、层次，还覆盖了测试流程、方法、技术、文档规范、准入/准出要求等。但还是发现了不少问题，虽然仅仅用了2-3个小时（不够细致）。当然，每个规范有其建设的特定背景，我不是特别清楚其上下文，所以提的问题也不一定对，算是抛砖引玉，欢迎大家讨论、批评指正。
先总体说一下问题，再指出一些细节的问题。

总体上看，主要问题有：

因为从其所列的业务类型（见附录表 E.1 业务分类），涵盖了证券期货业的各类系统，所以这个标准是不是需要考虑敏捷开发模式？今天发布这个规范，不能仅仅指考虑瀑布模型之下的传统测试，应该覆盖金融行业所提的“双态”——稳态（瀑布模型）和敏态（敏捷开发模式）之下的当今测试形态，可以参考《测试敏捷化白皮书》发布了(附下载地址)。
今天我们谈软件测试，一定是全生命周期的测试，包括测试左移和测试右移。这个规范缺乏对“需求评审、设计评审、代码评审”的具体要求，缺失了很重要的一部分内容。
测试类型定义不正确，根据新的国家标准GB/T 25000，软件产品质量特性分为八个特性：功能适应性、效率、兼容性、易用性、可靠性、安全性、可移植性、可维护性。本规范虽然在涉及到功能测试、可移植性测试中提到易用性、兼容性，相当于把它们降低了一个层次，所以还是不正确的。

GB/T 25000.10-2016 系统与软件工程系统与软件质量要求和评价（系统与软件质量模型）
GB_T 25000.51-2016_系统与软件工程系统与软件质量要求和评价(就绪可用软件产品质量要求和测试细则) ；

4.测试准入/准出要求应该针对阶段，只有阶段才有准入和准出，不能针对测试类型。功能测试作为一种类型，可以贯穿整个测试生命周期，包括在单元测试/集成测试、系统测试、验收测试等不同阶段都要进行功能测试。 5.慎重使用一些术语。例如，“集成测试”就包括不同层次的集成：单元与单元之间、子系统与子系统之间、软件与硬件之间、系统与系统之间等，该规范却分为“集成测试”和“系统集成测试”，是错误的。即使不考虑上面四个层次，“集成测试”就涵盖了“系统集成测试” 。又比如，“验收测试”在敏捷、瀑布模型下其解释（含义）有很大不同，今天在谈到这个术语时，必须加以限定。

一些细节问题：

“Specification for securities and futures industry software test” 英文翻译不够好，更好的翻译“Software testing specifications for securities and futures industry”
“单元测试是动态测试的最早期阶段”，今天这种提法不妥，今天这个阶段不存在，单元测试/集成测试（单元与单元这个层次）和编码是同步进行的，是持续编程、持续单元测试、持续集成测试。
“由编码人员在实现相应的模块后进行测试执行” ，不允许搞TDD吗？
“测试用例/方案”不能并列，我知道，金融业喜欢用“测试案例”代替“测试用例”，但“测试方案”绝不是“测试案例”，测试方案应是“测试解决方案”，近似测试计划，至少是测试计划中的一部分，回答“如何测”。
“此测试流程分为测试估计、测试计划、测试设计、测试执行、测试报告五个阶段”、“估计工作量时，测试策略选择合理、有效;” 测试估算（即这里的“测试估计”）为何不是测试计划的一部分工作呢？更何况涉及“测试策略”。而且测试策略不一定是可选择的（之前已有的），很有可能是全新的测试策略，所以应该说“制定有效的测试策略”。测试工作量不仅和测试策略相关，还会与质量要求、需求/设计/代码质量以及选择的测试方法、测试方式、测试工具等相关。
表1 工作要求中测试计划要求缺失：明确测试目标、明确质量要求和业务需求（虽然表2 文档中提到测试目标）
测试设计中对“测试需求”提出要求是不合理的，“测试需求”来自测试计划，更准确地说来自“测试分析”。整个规范在“测试分析”上是缺失的。另外“应 100%覆盖业务需求”这种提法就不合理，这取决于不同的测试目标（不同类型A/B/C的软件）和质量要求、测试策略，有时会忽视一些次要要求而为了交付时间。正确提法是“根据测试策略，达到测试目标所要求的业务需求覆盖，在测试核心业务系统时，尽可能做到100%覆盖业务需求”。
“b) 测试用例: 应 100%覆盖测试需求或按照测试级别不同 100%覆盖相关设计、需求文档，如单元测试、集成测试覆盖相关开发设计文档，系统测试覆盖系统需求规格说明书等;”提法也是有问题。
“c) 非功能测试场景的设计中充分考虑可能产生影响的业务数据量，且在真实生产环境下有效、在测试环境下可测。 ”提法不妥，对性能测试有效，还有其它非功能性测试，如兼容性测试、易用性测试、安全性测试呢？
“4.3.1 功能测试以黑盒测试技术为主，灰盒测试技术为辅。”这种提法也不妥，单元测试中的功能测试很可能是纯的白盒测试。按照新的国际测试标准（ISO 29119），建议不要使用白盒测试方法、黑盒测试方法，最好使用结构化方法或基于需求验证的方法。但我建议使用：逻辑覆盖、基于输入域方法、故障注入方法等更明确、更科学的分类方法。
性能测试：分为“负载测试、压力测试、容量测试和业务响应时间测试”四种类型也不合理，负载测试、压力测试是性能测试的方法/手段，而不是类型，测试类型可以分为：性能验证测试、性能基准测试、容量测试、性能规划测试等。况且“业务响应时间”只是性能测试的指标，那么“每秒业务交易量、交易成功率.....”等其它性能指标呢？
可靠性的确进一步分为“成熟度、可用性、容错性、可恢复性”，但标准中却是“成熟性测试”，一是这里的“成熟性”不等于标准的“成熟度”，二是这里描述的“成熟性测试”，基本等同于“容错性测试”。还有“可用性”验证呢？最后，规范也没有回答：如何综合性评估系统的可靠性呢？
可维护性包括“模块化、可复用、易分析、易修改、易测试”等，不是本规范中“表 5 测试级别与测试类型的对应关系”中所提到的：在系统测试、验收测试中进行“软件系统具有错误的易分析性、软件系统具有使指定的修改可被实现的能力”验证能做到的，居然还有“技术测试法、用户调查法”维护性测试技术，而应该强调如何在设计评审、代码评审中做好“可维护性”的评估工作。
“表 3 各测试类型的测试内容”不够完整、不够准确，安全性测试应包含业务规则验证，有业务安全风险；可靠性测试应包含应急方案、数据迁移、运维管理；可移植性测试：应包含数据迁移。
表 5 测试级别与测试类型的对应关系也不够准确，理论上，每个测试层次（级别）上可以进行所有测试类型的测试。
“4.5.1 准入条件：测试用例已完全100%覆盖测试需求”要求也不合理，在测试执行中可以适当完善测试用例，因为只有测试不断深入下去，对业务和产品的理解越来越深，会发现之前遗漏的测试点。如果“测试用例已完全100%覆盖测试需求”前提存在，测试人员执行时就会成为“机器”、“工具”，不会去思考。
“表 7 测试级别参与团队”有问题，在敏态下，开发团队也可以承担“系统测试”工作。
质量管理没有关注开发团队所承担的测试工作质量，4.6.2 主要提“在测试项目实施过程中”，并强调“测试经理向所有干系人汇报测试进展情况”。
表12 D 无须跟踪，而不是每月跟踪。
“系统组件单元之间的所有调用宜达到100%测试覆盖率。” 含糊或做到100%调用很容易，但是没提“参数及其组合的覆盖率”
“对于高质量的简单的系统来说，通常采用一次性的集成方法，快捷有效；对于相对复杂的系统来说，应根据软件的特点和工程的进度，选用适当的测试策略，可混合使用两种策略，上层模块用自顶向下的方法，下层模块用自底向上的方法。”这种提法，10年前还可以将就，但今天就很不适宜。
“8 系统集成测试测试对象” 、“9 验收测试测试对象”这样低级错误也不应该犯，应该是：“8 系统集成（换行）8.1测试测试对象” 、“9 验收测试（换行）9.1 测试对象”
因果图方法不能代替决策表方法
图 F.1缺陷管理流程缺陷不一定由“测试人员”报出，人人可以报缺陷，而且为什么不直接分配/指向开发人员，为什么要经过“测试经理”、“开发经理”？他们会是瓶颈。
表 F.2缺陷状态转换矩阵没必要，流程清楚了，就决定了状态转换，而且无需做出要求。
“测试报告：明确功能及非功能的测试范围”，这不是测试计划的内容吗？这里应该说“明确说明所执行的功能及非功能的测试范围”
“测试流程 test process：一个完整的测试任务按顺序经历的过程。” 测试流程不能仅仅限于“任务”，它有不同的层次：组织、项目、任务。
......

要获取《证券期货业软件测试规范》、《GB/T 15532-2008 计算机软件测试规范》和《测试技术与质量管理》最新一期季刊，
请关注本公众号，输入“测试规范”获取。

参考：