软件测试流程规范（质量度量）

1 软件测试流程

1.1 软件测试流程图

1.2 软件测试流程说明

需求分析：产品经理需要提前将需求文档提供给项目所有参与成员，分析阶段，需要仔细阅读和检查评审对象，以及评审相关的输入资料。根据职责要求和评审的目的，尽量发现评审对象中的缺陷，并根据缺陷分类和记录，以方便后续的缺陷分析和过程改进，是提高评审效率和覆盖率的有效手段之一。需求评审：讨论评审员提交的问题列表，并形成会议纪要。参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。检查缺陷是否已解决，收集度量数据，并评估出口准则（何时可以结束评审活动）。测试计划：制定测试计划、测试策略，有效控制项目进度，预估项目存在的风险。编写用例：根据产品需求、产品原型和测试点，编写全量测试用例。用例评审：项目所有参与人员，包括：产品、开发、测试人员。评审用例，保证用例的覆盖度达到最大。开发自测：测试提供冒烟用例（主流程测试用例），由开发自测。自测通过后交由测试验收，验收通过后，测试进行提测。用例执行：选择合适的测试策略，进行全量用例执行。Bug生命周期：bug提交、bug回验、bug重新打开、bug关闭。产品、UI验收：测试完成后，交由产品进行功能验收，UI验收界面样式。测试通过：产品、UI验收通过后。测试报告：测试通过后，编写测试报告，进行提交。线上验证：上线后，需要验证主流程功能是否正常。项目复盘：项目结束后，组织项目成员对现本阶段总结。

2 需求评审

2.1. 个人准备阶段

在个人准备阶段，需要仔细阅读和检查评审对象，以及评审相关的输入资料。根据职责要求和评审的目的，尽量发现评审对象中的缺陷，并根据缺陷分类和记录，以方便后续的缺陷分析和过程改进，是提高评审效率和覆盖率的有效手段之一。

2.2 需求评审阶段

讨论评审员提交的问题列表，并形成会议纪要。参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。需求评审过程，由专门人员做会议纪要，记录评审过程中产生新的的疑问、业务缺失和其他问题。

2.3 需求返工阶段（产品经理）

修复评审过程中发现的缺陷。

2.4 跟踪结果阶段

检查缺陷是否已解决，收集度量数据，并评估出口准则（何时可以结束评审活动）。

2.5 测试点整理

根据需求评审以及定稿的需求，提取罗列测试点。

采用思维脑图罗列测试点，梳理测试思路，如下图：

3 测试划分

根据迭代执行阶段，测试分类策略如下：

冒烟测试（提供冒烟用例，由开发进行测试）业务功能测试交叉测试（时间允许的情况）功能验收测试产品验收测试内部验收测试外部质检测试发布封装版本

4 测试用例规范

4.1 静态测试方法（开发自测，提高代码本身质量）

代码审查代码走查静态分析

4.2 编写测试方法

主干流程、分支流程，如需求未作变动，可复用上一迭代测试用例

标准数据异常数据边界值

4.3 测试用例分级

4.4 用例评审和修订

测试组内成员评审用例，检查用例的有效性和遗漏点测试用例评审人员：产品、UI、开发、测试修订测试用例：用例修订后，根据实际情况，判断是否需要进行二次评审

4.5 测试执行

4.5.1 测试执行优先级

测试优先级的确定可以来源于测试用例的风险级别，测试执行的先后顺序可以采用基于风险的深度优先策略或广度优先策略进行实施测试资源是否及时到位也会影响测试优先级的设置开发团队相关的因素也会影响测试优先级的设置

4.5.2 测试执行入口准则

系统测试设计规格说明、系统全量测试用例，经过评审并且通过测试所需资源，如测试人员、测试环境、测试数据等已经到位开发人员提交了版本说明，其中阐述了从开发角度建议的测试重点、测试建议、存在的缺陷和问题列表等开发提交了在测试环境中通过了冒烟测试

4.5.3 评估出口准则

测试结果满足所有的出口准则

5 软件缺陷管理

5.1 bug定义

5.2 流程说明

提交bug：提交bug后，及时和开发沟通，确保开发已知。Bug回验：开发修复后，进行回归测试。Bug已解决：开发修复bug后，指给测试人员。Bug重新打开：关闭的bug，测试过程中已关闭的bug又出现了，可以重新打开关闭的bug。Bug打回：回验已解决的bug，问题依然存在，重新指派给对应开发人员，备注复现步骤和相关信息。Bug关闭：已修复的bug，验证通过后，进行关闭（进行备注）。暂不修复bug：与开发、产品达成一致后，进行bug备注，且申请转出暂不修复bug，与产品不能达成一致，需报备给刘总，评估项目工期与现阶段迭代延误风险

5.3 提交软件缺陷准则：

单一准确：每个报告只针对一个软件缺陷，一个报告中若存在多个软件缺陷，避免导致只有其中一个软件缺陷得到注意和修复，其他缺陷没有得到修复。可以再现：缺陷操作步骤的准确描述是开发人员可以再现缺陷的重要保证。如果按照所描述的步骤不能再现缺陷，开发人员就会抱怨，浪费大家的时间。完整统一：提供完整的缺陷描述信息，以及所需的图片信息、视频文件等。短小简练：通过使用关键词，可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。特定条件：许多软件功能在通常情况下正常，而是在某种特定条件下会存在缺陷，例如网络繁忙时。所以，缺陷描述不要忽视看似细节的但又必要的特定条件，指引帮助开发人员找到原因的线索。不做评价：在软件缺陷描述不要带有个人观点，不要对开发人员进行评价。软件缺陷是针对产品、针对问题本身，将事实或现象客观的描述处理，不需要评价或议论。

5.4 临后（线上）bug解决方案：

归纳收集临后bug列表（专门人员），且划分版本、优先级别，进行分类，制定修复计划。不能因为是线上问题，就必须立刻解决和当天解决，可根据优先级的高低，确定具体的解决时间，避免大量临后bug堆积。按照修复计划，优先处理紧急程度高的临后bug应制定测试回验方案，在某个时间段进行回验。回验成功后，开发人员应提供修改方案，且可能受关联的其他功能模块，避免生成其他bug风险。回验临后bug，且需回归可能受关联的其他功能模块（开发提供）。回验通过（临后bug和受关联的其他功能），关闭临后bug，临后bug列表状态进行变更。

6 软件测试文档

6.1 测试计划

6.1.1 计划说明

测试的范围和目标对测试的各阶段所需要的时间、人力及其他资源进行评估，针对每个测试任务仔细分析到位，尽量做到客观、准确、留有余地（总时间的10%~15%）。制定测试项目的输入、输出和质量标准，并三方达成一致 建立变化处理的流程规则，预估潜在风险控制

6.2 测试用例

6.2.1 用例要素

用例编号：每个用例唯一的编号标识功能点：对应模块-子模块优先级：用例执行优先级别用例名称：每个用例应具有的唯一名称前置条件：包括前提条件和约束条件，若存在特别限制、参数偏差或异常处理，应标识处理，并说明它们对测试用例的影响用例步骤：指引执行测试的步骤，提高执行效率期望结果：用例执行期望的正确结果实际结果：与预期输出比较是否一致，若一致则测试通过，反正测试不通过测试结果：通过、不通过备注：用例的补充描述

6.2.2 测试用例质量要求

单个测试用例的质量要求

具有可操作性具备所需的各项信息各项信息描述准确、清楚测试目标针对性强验证点完备，而且没有太多的验证点（不超过3项）有太多的操作步骤，例如不超过7步符合正常业务惯例

整体测试用例的质量要求

覆盖率：尽可能覆盖所有的测试范围、功能特性和代码。易用性：设计思路清晰、组织结构层次合理，操作连贯性好，使单个模块的测试用例集执行顺畅。易维护性：以很少的时间来完成测试用例的维护工作，包括添加、修改和删除测试用例。颗粒度适中：既能覆盖各个特定的场景，保证测试效率；又能处理不同数据输入的测试要求，提高测试用例的可维护性。

6.2.3 测试用例维护

客户需求发生变更，应增加新的测试用例或修改已有的测试用例，删除不再适用的测试用例。测试过程中，发现一些隐藏相对较深的缺陷，而这些缺陷没有相关联的测试用例，应及时补充相应的测试用例。随着产品版本的不断升级，测试用例也需要及时维护，必要时进行重构（对测试用例的结构进行调整，包括用例模块的合并和分解），确保每个用例都是有效的，无效用例被置为无效或不可用状态。对于功能性测试用例，可以从产品特性的分类——功能模块来划分

功能模块来划分，如图：

6.2.4 测试用例与迭代任务关联

每次新增需求，需要增加相应的迭代任务，新增迭代测试用例本次迭代测试用例，仅用于本次迭代测试任务，与全量测试用例分开本次迭代任务结束后，用例需要维护到全量测试用例中本次迭代任务，若用例可复用，可将复用的测试用例和新增的迭代测试用例，统一放入到本次迭代测试用例集

6.2.5 测试报告要素

产品标识测试系统的系统配置使用的文档及标识产品描述、用户文档、程序和数据的测试结论与需求不符的清单针对建议的要求不符的清单，产品未作符合性测试的说明测试结束日期

7 测试流程质量管控

项目风险检查表

8 产品质量度量表

缺陷引入阶段矩阵表

缺陷移除率A、本阶段发现的缺陷数B、本阶段引入的缺陷数C、缺陷遗漏率D

公式：A=B/C*100%、D=1-A

例：需求阶段

1） A=5/92=5.43%

2） D=1-5.43%=94.57%

度量指标

9 项目时间节点

数字人民币多地同步试点：“连麦”测试、“全量”测试集体亮相 稳定性迎“大考”

财联社（北京，记者 姜樊）讯，苏州、长沙等地的数字人民币试点活动尚未结束，今日，北京、上海等地将继续接棒，数字人民币也将迎来多地同时试点的“盛宴”。

据财联社记者了解，本次多地同步试点中，部分地区和场景将尝试“连麦”式测试。其中，上海的数字人民币红包用户可跨区域在上海、苏州等试点城市使用。与此同时，部分数字人民币应用场景还将进行数字人民币白名单的“全量测试”，即使用场景将覆盖全部试点城市。

本轮试点的创新性尝试，对数字人民币稳定性、安全性测试的难度将有所增加，将对数字人民币瞬时最大支付的稳定性构成考验。

数字人民币场景快速扩容

今日起至6月20日，北京、上海将开启新一轮的数字人民币测试活动。而苏州此前的数字人民币“五五消费节”活动将持续至本月月底，成都数字人民币活动也将持续至本月月底，长沙数字人民币试点活动截止至6月15日。这意味着将有五城同时进行数字人民币测试，为数字人民币试点启动以来，同时测试地区数量最多的一次。

在各地试点次数不断增加的同时，数字人民币的使用场景也正在不断增加，新增场景更加贴近百姓生活。

记者注意到，在数字人民币app中，各家银行推送的数字钱包子钱包已至少涵盖了25个场景。东方航空、OPPO钱包、天天果园等场景新晋入围。数字钱包子钱包场景，目前已经覆盖了交通出行、购物消费、旅游消费、餐饮服务等多个领域。

相对于线上场景，更难布设和推动的线下场景数量也正在不断增长。据了解，围绕2022年冬奥会，北京正在加大数字人民币的推广力度，目前已在交通出行、餐饮住宿、购物消费、观光旅游、医疗卫生、票务娱乐等多个行业布局了数字人民币试点商户。上海日前也宣布了近700家数字人民币试点商户名单。

此外，越来越多的基础设施也陆续开始支持数字人民币的使用。近日，北京市丰台区政务服务管理局开设了数字人民币账户，并于2021年6月2日在区政务服务中心推出北京市首个政府信息公开数字人民币应用场景。而多个城市的地铁、公交等基础设施也正在陆续支持数字人民币的使用。

“数字人民币场景不断更新，且新的场景都是更加贴近百姓生活的场景，这让数字人民币的使用更接地气，更加符合数字人民币小额高频、主要在零售场景方面的使用特征。”一位业内人士对财联社记者表示，这将从一定程度上带动数字人民币app的活跃度，培养用户习惯，同时也进一步促进了国内消费。

“多点开花” 测试难度大幅增加

与以往不同的是，本轮数字人民币试点中，部分地区、部分场景开启了“连麦”测试。此次上海红包中签人员可在上海、苏州等试点城市已完成数字人民币受理终端改造的试点商户，以及已在数字人民币app中开通子钱包推送功能的线上平台，使用数字人民币红包进行无门槛消费支付。

数字人民币的应用场景还首次出现了“全量测试”。财联社记者发现，近期美团app上线了“数字人民币全场花”，并设置了骑车、买菜、餐饮等场景的使用入口，数字人民币白名单用户可以选择数字人民币支付。其中，骑车场景没有试点城市限制，买菜场景则支持北京、上海等地。

一位业内人士对财联社记者表示：“数字人民币之所以进行多轮测试，主要在于测试系统的稳定性与安全性。”该人士指出，定位于零售支付的数字人民币，在未来正式推出之后可能面临天量的瞬时支付峰值，如果数字人民币的运营能力不足以支撑，可能会带来巨额的经济损失。与此同时，数字人民币的实时性特点要求央行掌握较高的技术资源，系统技术故障、网络攻击和密码技术缺陷不仅会威胁个人信息安全，也会冲击金融体系稳定。

中国人民银行宏观审慎管理局局长李斌在2021年第一季度金融统计数据新闻发布会上也曾表示，下一阶段央行将根据试点参与各方的反馈，不断完善和优化数字人民币技术、业务和政策方案，深入探索数字人民币应用模式，强化数字人民币通用性和普惠性，完善产品功能和应用性，提升系统的安全性、稳定性。

多方共探数字人民币未来发展

业内人士普遍认为，尽管数字人民币试点越来越频繁，但距离其大面积推广仍有很长的路要走。而在这一过程中，数字人民币需要解决的不仅是安全性问题，也有监管框架的搭建、生态建设之下各类机构盈利模式的探索等问题，这均需要政府、企业等多方共同努力。

今年以来，数字人民币试点不断，多家在数字人民币领域布局的上市公司也收获了多轮股价上涨。随着数字人民币试点不断推进，天喻信息、优博讯、新开普等概念股也获得了多家机构的密集调研。

优博讯表示，数字人民币的推出给包括支付终端厂商在内的支付产业带来的市场机会和积极影响持乐观预期，公司在积极参与数字货币的支付应用场景设计与落地工作。新开普与联通支付进行了数字人民币的合作，但相关业务对当前公司收入影响较小。

“如果按照项目来划分，数字人民币的一些项目已经有所盈利。但不得不承认的是，目前整个行业对数字人民币未来模式、科技运用等方面的研究都处于初期阶段，预计后续仍会持续增加投入。”一位科技企业负责人对财联社记者表示，从目前来看，数字人民币基础建设目前已出现商机，但天花板较低，未来在智能合约等方面可能会出现更好的商业模式。同时，数字人民币跨境场景也可能会存在商机。

中央财经大学数字财经研究中心主任陈波表示，数字人民币目前尚未形成明确的商业模式，其核心在于数据归属等问题。预计未来随着数字人民币测试不断进行、应用场景的不断扩大与融合，以及数据归属权的明确、个人隐私保护的完善，相关各方将探索出一条可以多方共赢的商业模式。