软件测试规范

版次：2022年11月21日 第 3 版
类型：程序文件
部门：软件部
上海维宏电子科技股份有限公司 版权所有

文件版本	修改前文件版本	主要修订内容和原因	修订人	修订日期
R1		新建	余晓霞	2022.03.1
R2	R1	1、3.2 测试计划章节，活动进行的条件从最后移至第一点，并修改文案描述。 2、 3.4 测试执行章节，“必须进行自动化测试” 改成 “应该进行自动化测试”；增加测试执行记录要求。 3、3.5 测试结束章节，添加测试报告内容限定。 4、4.1 测试用例设计总则章节，第4点添加案例分析 5、5.1 用例组织规范章节，修改第3点说明。 6、5.4 自动化运行规范章节，修改执行说明，指明自动化执行失败之后，应进行手工重测。 7、一些小的格式调整，和话术调整。	余晓霞	2022.09.26
R3	R2	测试报告内容去除缺陷总结。测试用例标题去除测试用例编号。	余晓霞	2022.11.21

1 目的和范围

本规范就公司的软件研发过程的测试过程做出规定和指导。

2 术语和定义

为了统一认识，此处给出公司内部关于测试过程中的相关术语的定义。

• HotFix： 也称为快速修复工程，是软件开发人员或程序员对已发布软件出现的 Bug 需进行紧急修复的术语。
• 项目测试： 新产品研发或被定义为项目类型的任务的测试，称为项目测试。
• 维护测试： 产品发布或交付之后，因修改（产品计划的特性改善（例如产品迭代计划发布）、纠正和紧急变更、操作环境的变更、软件升级以及缺陷和漏洞的补丁等）、迁移、退役而引起的测试，称为维护测试。
• 正例： 对此规则或原则给出的正确例子。
• 反例： 对此规则或原则给出的反面例子。
• 说明： 对活动、输入、输出、规则和原则等做必要的说明。
• 测试点： 根据测试范围以相对抽象的形式描述测试思路和预期。通常只有测试用例的标题，不要求提供详细的操作步骤或操作细节。
• 测试用例（Test Case）： 为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档。它通常包含测试标题、优先级、前置条件、测试步骤、预期输出、测试数据、标签等七个基本要素。
• 测试执行记录： 在被测对象上执行测试用例/测试点的结果记录，记录测试用例/测试点的执行情况（例如：准备运行、通过、失败、阻塞、故意跳过等）。
• 测试版本： 当被测对象是在非发布分支打包的组件/软件，称为测试版本。
• 发布版本： 当被测对象是在发布分支打包的组件/软件，称为发布版本。
• 通用必测： 即软件中常用/基本业务功能的正向操作测试，或典型异常操作测试，通常外发类软件版本都需要进行此类测试。
• 代码片段： 在代码区域出现中括号中带中文字的及符号…， 如：[代码片段]或…， 则一般表示代码片段。

3 测试活动规范

3.1 测试分析

1. 所有测试项目，都必须进行测试分析活动；

2. 必须对需求规格规格说明书或其它测试依据进行测试需求分析，解决需求疑问（例如：需求表述存在歧义或错误、缺少用户故事等），明确“测试什么”。

3.2 测试计划

1. 项目测试的过程应该进行测试计划活动；维护测试的过程应根据变更内容的风险程度和影响范围或其它实际情况决定是否需要进行测试计划活动；类似 HotFix 的测试过程可不进行测试计划活动。若进行测试计划活动，则必须输出测试计划文档。
2. 测试计划的评审人可以是程序经理、架构师、或经验丰富的测试。
3. 测试计划文档应该包含内容，但不仅限于如下：
   • 确定测试的范围、目标和风险。
   • 决定使用的质量度量指标和如何测量。
   • 安排测试分析、设计、执行和评估活动的进度表，可以按特定日期安排（例如，在顺序开发中）或以每次迭代的周境安排（例如，在迭代开发中）。
   • 确定相关交付成果和测试文档的详细程度和结构（例如，通过提供模板或示例文档）。

3.3 测试设计

1. 测试设计活动必须输出测试用例或测试点。内网研发的项目测试，必须输出测试用例。
2. 维护测试的测试设计活动应根据变更内容的风险程度、影响范围、是否已存在历史用例、和实际情况，决定是否输出用例。若变更内容属于通用必测、内网开发的产品或已存在历史用例，则必须输出新增或完善后的测试用例；若变更内容是客户定制类、配置类或外网开发类需求，则可输出测试点。
3. 在测试过程中，可不进行测试设计活动的情形有：产品从一个平台迁移到另一个平台、产品已退役、或 HotFix 。
4. 测试用例编制或完善之后，必须进行用例评审活动，评审人应该包含，但不仅限于：产品管理、开发、项目内经验丰富的测试、架构师。评审方式不做限制，可以是正式评审或非正式评审，对应影响范围广、难度高和测试要求高的项目，宜进行正式评审活动。

3.4 测试执行

1. 在产品提测前，应该创建测试执行所需的用例集。例如：冒烟测试用例集、功能测试用例集、回归测试用例集等。
2. 产品首次提测之后，必须 48 小时内进行冒烟测试，并给出冒烟测试结论。
3. 发布版本测试必须进行通用必测。
4. 当产品发布流程为：测试版本 -> 发布版本时，在发布版本测试时，应该对测试版本发现的严重级别为“致命”的 Bug 进行回归测试。
5. 冒烟测试和通用必测应该进行自动化测试。
6. 发布版本测试宜进行交叉测试（即测试之间相互交互测试）。
7. 缺陷记录和跟踪必须按《缺陷跟踪流程》执行。
8. 测试执行过程必须做测试执行记录，测试执行记录须客观真实，异常情况（例如：执行条件不足造成测试用例未执行、遗留缺陷等）须给出必要的说明。

3.5 测试结束

1. 检查测试用例是否 100% 执行，已解决的 Bug 是否都已关闭，未解决的 Bug 是否都已正确处理，若均回答“是”，则输出测试总结报告；测试总结报告必须包含如下内容，但不仅限于此：
   • 测试结论：测试通过/测试不通过；
   • 遗留问题说明；
   • 测试范围。
2. 必须对测试过程中产生的测试件进行归档，例如：把完善后的测试用例上传代码管理服务器（Git/TFS），测试报告和测试记录存放至指定的存储工具（例如：文件服务器、Confluence、TFS 等）。
3. 应该进行测试总结与改进，纳入测试团队知识库，从而推动测试工作的不断优化与改进。

3.6 测试监督和控制

1. 测试结束之后，必须进行测试评估活动，确定是否满足产品准出准则，若满足，则评估通过，发布产品。测试评估活动包括但不限于：用例执行完整性、缺陷处理合理性、测试记录和测试报告规范、满足测试的度量标准。评估人由程序经理或项目内经验丰富的测试负责。
2. 测试过程中，当测试实际进度与计划的进展差异较大，或存在其它风险时，宜向利益相关方发送测试进度报告。

4 测试用例设计规范

4.1 测试用例设计总则

1. 可以作为独立功能的需求，需编写基于该功能的测试用例。若一个需求里面包含多个功能，可以分解为多个功能，针对每个功能设计相关用例。
2. 设计应该优先考虑功能性、其次是可靠性、易用性和其它特性。其中功能性优先考虑正向测试（功能正常）、其次是负向测试（功能异常）。
3. 功能相关用例不仅仅考虑单一功能，也应该考虑功能和功能之间的交互影响。
4. 每条测试用例粒度合理，测试目的应该唯一，如：该条用例不能够既包含正向测试又包含负向测试；或者既包含功能测试，又包含可靠性测试。原则上测试点唯一，并不是说 UI 页面样式检查时，一个元素一个测试点，而是 UI 实现满足需求，这就是一个测试点；如果要测试的是一个流程，有很多步骤，还满足测试点唯一吗？思考方法同上面提及的 UI 页面样式检查，需要验证的点并不是流程中的某个步骤，提供用户价值的是整个流程，以验证流程的角度来思考，这个测试点的设计仍然是满足测试点唯一的。
5. 测试用例设计方法优先推荐场景分析法（基本流、备选流），优先保证默认或者常用参数、条件的正确性，再基于等价类、边界值等方法考虑多组数据的组合。
6. 测试步骤/预期结果具有普遍适应性，宜考虑先设计“共享用例”，再引用。
7. 功能的界面测试与业务逻辑测试应该分离设计。
8. 每个用例必须独立运行，用例间无依赖关系。
9. 描述使用的专有名词或术语应该与相关使用说明文档（例如：需求规格说明书）中的保持一致，用词应该规范、明确、量化、无二义性。

4.2 测试用例基本要素

4.2.1 用例标题

概述测试用例的主要内容，明确测试用例的意图。一个简单、清晰、有针对性的标题，能让人快速理解设计人的测试思路；精准的描述让测试点的理解不会因人而异。

规范：

• 用例标题必须使用格式：测试标题描述 。 正例： 直排换刀功能

  验证换刀功能基本流程正确    #功能正确性验
  验证换刀时若未检测到相关到位信号则换刀停止    #功能异常处理/异常测试
  验证非空闲状态时换刀操作无效      #异常测试
  

4.2.2 前置条件

测试用例执行的前提条件，如果不满足这些条件，则无法进行执行测试。

规范：

• 非必要的用例基本要素，当没有前置条件时，可忽略此要素。

• 在团队内（或业务领域内）约定的默认前置条件，无需填写到前置条件。 正例：数控系统（NcStudio）约定以下内容为默认前置条件

  启动 NcStudio 应用程序
  系统空闲状态
  软件未回机械原点
  参数设置为默认值
  仿真环境
  

4.2.3 测试步骤

如何执行这个测试用例，每步的操作是什么。

规范：

• 一条用例的测试步骤不宜超过 15 条。
• 测试数据和测试步骤要分离，步骤里面不应编写测试数据。
• 若存在共享步骤（重复使用率高和通用性较强的测试步骤，使用范围不受项目的限制。例如文本框的输入验证、参数默认值的验证、参数设置权限验证等），则应该直接引用共享步骤。
• 单个步骤描述时禁止包含多个不同类型的操作。

反例：

  装载刀路，打开图层设置对话框，切割参数-特殊工艺中勾选“无感穿孔”勾选项，设置穿孔类型为类型 3，穿孔高度 10mm

正例：

step1: 装载刀路
step2: 打开图层设置对话框
step3: 切割参数-特殊工艺中勾选“无感穿孔”勾选项
step4: 设置穿孔类型为类型 3，穿孔高度 10mm

4.2.4 预期结果

预期结果是和测试步骤对应起来，操作后希望程序或系统返回或特征。

规范：

• 为简化阅读和执行，保证结果的一致性，预期结果应尽可能具体和明确，特别是针对坐标、速度、状态和正确/错误信息的描述。

  正例: 回机械原点功能—— Z 轴回机械原点检测到精定位信号后，预期结果描述如下：

  1. 操作信息提示栏提示:Z 轴粗定位信号与精定位信号之间的距离是***（单位是直线或者角度标准单位）；
  2. Z 轴以 200mm/min 的速度回退 -2mm 后运动停止；
  3. Z 轴运动结束后，操作状态为空闲，操作状态附加信息为正常结束；
  4. 坐标显示区Z 轴名称前出现机械原点标志，Z 轴机械坐标为 0，Z 轴工件坐标为 0（前置条件是所有偏置设置为 0）
  

4.2.5 测试数据

测试时使用的测试数据。

规范：

• 测试数据要具体，比如具体刀路文件、具体偏置设置值。
• 若不同前置条件、不同的输入数据对于软件功能的影响不同，设计数据可以和前置条件进行组合设计。
• 测试数据可以不是一个实际的参数，例如：系统的状态、功能入口。
• 测试过程中使用的刀路文件，如客户刀路、特殊刀路等，归档至： \\172.16.10.123\01.安全内网文件夹\01.研发部文件\02.受限文件\01.软件部\03.测试\03.刀路文件

4.2.6 标签

标签为用例管理提供了一种灵活的管理方式，便于用例查找和复用。个用例可以包含多个标签，团队也可根据项目的实际情况自行定制。

规范：

• 用例优先级标签（必须）：P1~P4；优先级定义说明参考 4.2.7 章的用例优先级。
• 测试类型标签（必须），主要包括：功能、易用、性能、可靠、兼容；编写正例：测试类型=功能。
• 功能使用范围标签（可选），主要包括：通用功能、XXX 客户定制功能。
• 通用必测标签（可选），若用例属于通用必测，则添加标签：通用必测。
• 执行方式标签（可选），若实现自动化，可以添加标签：Auto。
• 机型标签（可选），例如：机型=十轴链式刀盘。
• 环境标签（可选），例如：环境=Lambda21B。

说明：“必须” 的标签，必须在测试用例的标签出标记有。

4.2.7 用例优先级

优先级即用例在该功能模块中的重要级别，通过功能的重要性和用户实际使用频率两个维度阐述用例的重要级别。用例优先级可以作为明确不同测试类型（开发自测、冒烟测试、全面测试（包括功能和非功能性测试）、回归测试、自动化覆盖等）的测试范围的重要依据。优先级定义四个等级 P1~P4 具体详述如下。

1. P1 ： 覆盖功能或业务的重要点部分，用户使用频繁。通常为关键业务流，此用例通常可以确认此版本是否可测。

   优先级和测试类型的关系：

   • 开发自测必测
   • 冒烟测试必测
   • 若功能属于通用功能，则其属于通用必测
   • 自动化测试应该覆盖
   • 版本兼容性测试应该执行此用例

2. P2 ： 覆盖功能或业务的次要部分，用户偶尔使用。一般为备选业务流、边界用例、常见的反向用例。

   优先级和测试类型的关系：

   • 单功能回归测试时必测
   • 自动化测试应该覆盖

3. P3： 覆盖功能或业务的次要部分，用户几乎不使用。一般为不常见的非法操作、异常场景。

   优先级和测试类型的关系：

   • 单功能回归测试时必测
   • 自动化测试应该覆盖
   • 可靠性测试应该覆盖

4. P4 ： 覆盖功能或业务的次要部分，用户不会如此操作。通常覆盖功能相关的易用性、性能、可靠性。

   优先级和测试类型的关系：

   • 性能测试或稳定性测试覆盖。

4.3 测试用例管理规范

1. 必须使用代码的方式管理测试用例（使用指导应参考《代码化测试用例管理指导书》），测试用例存放在版本管理服务器（Git/TFS）。
2. 当手工用例完全转换成自动化用例之后，应该作废手工用例或删除手工用例。
3. 当手工用例只有部分可以转换成自动化用例时，应该把此用例按照手工和自动化进行拆分。
4. 完善用例时，必须先确认是否已存在相同的用例，若已存在相同的用例，则完善用例，否则新增用例。若是自动化用例，则更新自动化脚本。

5 自动化测试管理规范

• 编程规范宜遵循软件部的软件编程规范（内网） 。
• 基于 Robot Framework 框架的自动化应按照《Robot Framework 自动化测试框架使用指导书》实施。
• UI 变化频繁的产品不宜实施 UI 自动化。功能逻辑变更频繁或尚不稳定的产品不宜实施自动化。
• 实施自动化前应该对产品的业务进行梳理。例如梳理业务流，分析并抽取出通用的操作。

5.1 用例组织规范

1. 用例设计规范应遵守第 4 章的测试用例设计规范。
2. 功能性的自动化测试用例必须包含有断言（即预期结果），否则属于无效用例。

3. UI 自动化测试脚本设计应该使用分层的思想，例如对产品的业务进行梳理和分析，抽取出通用的操作。

4. UI 自动化测试，当有对话框弹出或进入非首次进入的默认页时，必须在后置处理模块把对话框关闭或返回首次进入的默认页。避免在出现异常或执行失败时，影响后续用例的执行。

5. UI 对象的 xpath 应该使用相对路径。

5.2 自动化版本管理规范

1. 测试工具或测试库的版本管理应遵循如下规范：
   • 非 Hotfix 的修复禁止在主分支上直接修改，必须在开发分支上进行维护开发，待测试（维护人负责测试）通过之后，通知相关方（软件部），待其验收通过之后，才可合并到主分支上。
   • 开发分支合并主分支后，应该在其中一台测试执行机上进行发布测试（由变更人进行测试，软件部验收）通过之后，才可发布到各个测试执行机。
2. 提交或合并到主分支的测试脚本，必须经过自测，自测检查列表如下，但不仅限于：
   • 无语法错误。
   • 单个测试套件执行通过。
   • 持续集成环境执行通过，且不影响其他用例的执行。
3. 当自动化用例体量较大，或参与开发人员较多时，宜规划分支管理策略（团队内的自动化测试负责人），不宜在主分支上直接维护。

5.3 持续集成管理规范

1. Jenkins Job 名称或 TFS 生成定义的名称命名格式：部门名称_[产品名称]_测试环境_[其它标识或描述]，中括号“[ ]”的字段选填。

   正例：

   金属切屑_TZ820_NC300CX_RobotFramework
   金属切屑_TZ820_NC300CX_Lua
   激光加工_仿真环境(win10)_发版前回归测试
   

2. 必须保证自动化持续集成环境的稳定性，禁止出现 5 天以上的不可用情况。

5.4 自动化运行规范

1. 在持续集成环境，当自动化测试执行失败之后，如果是脚本问题，或无法定位的问题类型时，应进行手工重测，且告知相关人员（脚本编写人或自动化维护人员），相关人员知晓后应尽快对问题进行定位分析和修复。
2. 当自动化持续集成环境不可用时，可在测试环境上离线执行自动化测试。
3. 自动化测试发现的缺陷，登记时宜打上“自动化测试”标签。

6 参考文献

• 国际软件测试委员会的大纲《ISTQB 认证测试工程师_FL大纲- 2018版_V3_1》。
• 《微软软件研发的奥秘 MSF 精髓》。
• 软件产品质量模型标准 GB/T 16260 。

编制： 余晓霞 审核： 胡凯烽 批准： 郑之开

审批链接：