激光加工产品部研发流程

版次：2021年11月9日 第2.1版
文件类型：程序文件
上海维宏电子科技股份有限公司 版权所有
修改历史
文件版本 修改前文件版本 主要修订内容和原因 修订人 修订日期
R1 新建 唐涛、穆冬华 2021-7-15
R1.1 R1 1. 需求分析阶段，建议测试、开发都参加 唐涛 2021-7-23
R2 R1.1 添加开发自测报告要求、添加测试具体测试记录要求 骆玲 2021-8-18
R2.1 R2 添加平面发布自动化要求 骆玲 2021-11-9

1 引言

1.1 编写目的

为指导和规范激光加工产品部在研发过程中的任务流转，特编写此流程。

1.2 读者对象

激光加工产品部应用、开发、测试。

1.3 参考文档

《TFS 工作项命名规范》

《TFS 工作项填写规范》

《长沙 Wiki 使用指南.md》

2 研发流程

根据软件研发和实际工作，研发流程分为如下阶段：

1） 需求分析

2） 需求审核

3） 规格制定

4） 规格评审

5） 功能设计

6） 设计评审

7） 实现、自测

8） 代码审核

9） 测试&回归

10） 合并

11） 文档整理

2.1 流程图

激光加工产品部研发流程图1

激光加工产品部研发流程图2

2.2 流程详解

2.2.1 需求分析

针对技术销售工程师、客户提出的功能需求，对初步的需求进行需求分析，了解需求的背景、要解决的问题，评估需求的合理性，并对需求从功能、性能方面进行全面的分析。针对需求进行竞品研究，了解行业中同类需求的解决办法。

需求的核心是：定义问题

  1. 需求分析之后，如果软件中已经具备功能，则不进入研发流程

  2. 需求分析完成之后，建立工作项，并通知产品总工

  3. 需求分析文档以附件的形式链接到工作项中

  4. 此阶段由应用工程师负责，必要时总工、开发工程师协助分析问题

需求分析完成，建立 TFS Task，关键内容：

完成时间：需要跟开发经理或总工协商；发行项所带任务完成时间要提前两个工作日

标题：要符合《激光加工产品部TFS工作项命名规范.md》

最佳实践：在讨论需求、进行需求分析时，将测试人员、开发人员一起拉入需求讨论组，这样需求的讨论会更加充分，最大限度减少返工的可能性。

2.2.2 需求审核

由产品总工负责对需求进行审核，从如下几个维度对需求进行审核：

  • 需求的合理性
  • 需求是否有价值
  • 是否是共性需求
  • 现有功能规格是否符合需求
  • 需求是否可以通过其他功能实现
  • 需求是否需要写功能规格、设计方案
  • Task 完成时间的合理性：如果不合理，需要跟应用、销售、客户协商确定好时间

需求审核：TFS 工作项审核字段改为“通过”；需求审核完成，需将 Task 告知开发经理（组长）、测试负责人、应用工程师

审核历史记录：

结论：通过 or 不通过

说明：是否需要写规格方案，工作项要注意的点，其他说明

2.2.3 规格制定

规格制定分为两种情况：

  1. 现有规格不满足需求：由系统工程师对原有规格进行扩展，并修改出完整的新规格。

  2. 制定全新规格：进行竞品分析，结合需求制定全新的规格

规格由系统工程师制定

规格文档必须包括：背景分析、竞品分析，功能规格，性能规格

功能规格产出文档：功能规格说明书

功能规格模板：http://172.16.1.7:9999/#!维宏研发/设计阶段/模板/[团队名称]-[功能名称]-功能规格-模板-R1.md

规格的核心：描述通过什么功能解决问题

2.2.4 规格评审

规格评审原则：

  1. 凡是规格的变化必须通过评审

  2. 规格评审必须有：开发、测试、应用参加

  3. 全新规格需要经过公司评审

  4. 评审完成，将评审记录，写入功能规格最后一章：评审记录中

  5. 评审通过，由总工负责，将功能规格放到三级规格中：http://yfmis.weihong.com/View

2.2.5 功能设计&测试用例设计

功能设计：由系统工程师执行

  1. 首先要评估自己的知识技能是否能够做出符合功能规格的设计；如果评估不够，先要及时反馈，并对缺失的内容进行弥补

  2. 接下来，要找出设计的核心问题；并判断出此次设计是增量式设计还是颠覆式设计，尽量避免重复造轮子

  3. 整理自己的思路，并说明核心设计内容

  4. 进行详细设计，以设计文档为主体；将对功能的设计清晰的表述到设计文档中

  5. 对于改动量大，设计复杂的方案，建议系统工程师与开发工程师一起写详细设计方案

功能设计的核心：如何实现功能

设计文档模板：设计方案模板：http://172.16.1.7:9999/#!维宏研发/设计阶段/模板/[团队名称]-[XXX方案设计]-模板-R1.md

测试用例设计：由用例设计负责人执行

  1. 首先接到需求后就开始进行需求分析，从专业角度对需求进行理解、纠错、补充。

需求分析中可咨询包括但不限于：需求责任人、开发负责人、测试主管、测试组长。

  1. 接到规格后开始进行测试分析，常用的测试分析法：质量模型分析法、场景分析法。

制定测试计划，主要从时间、人员、任务量、设备等方面着手，并进行适当的风险预估。

测试分析产出：测试分析文档。

推荐工具：OneNote、思维导图。

  1. 运用黑盒测试用例设计方法进行用例设计。

测试用例设计产出：测试用例。

注意：测试用例设计时需考虑用例的可重复利用性、自动化脚本编写便利性。

2.2.6 设计评审&测试用例评审

设计评审：由产品总工负责，系统工程师、开发工程师参与

  1. 首先按照《技术文档写作指南_内容-R1.1.md》对文档书写内容进行规范化

  2. 确定评审相关的人员，并组织评审会议

  3. 评审完成，将评审记录，写入方案设计最后一章：评审记录中

  4. 根据评审会议结果修改设计文档

  5. 评审决议要求复评，准备下一次评审

测试用例评审：由测试审核人负责

  1. 测试用例修改后必须进行审核

  2. 由测试主管/测试组长指定测试审核人

  3. 确定评审相关的人员，并组织评审

  4. 评审完成，根据评审结果修改测试用例

  5. 评审决议要求复评，准备下一次评审

2.2.7 实现、自测

  1. 根据设计文档进行代码模块的编写

  2. 需要对每一个功能分支进行调试

  3. 需要对每一行代码进行单步调试

  4. 自测需要写自测说明，如下：

【自测说明】

是否自测：是

测试方法：手工\自动化、以及其他测试方法

测试范围：工作项需要提交《自测报告》

建议测试范围：此处填写工作项影响范围，请根据代码修改情况充分评估影响范围，要求测试范围具体、准确，比如，影响哪些功能的哪些部分。

2.2.8 代码审核

代码审核原则：

  1. 每一行代码都必须评审

  2. 签入的每一行代码都必须通过编码规范审核

代码审核制度：

  1. 凡是代码签入，必须要经过评审；审核通过才能签入

  2. 审核发现三处编码规范问题，可直接退回，修改后重新提交评审；因此而产生的工作项延期，由被审核人承担

  3. 代码审核提交后，截图以 RTX 通知审核者

  4. 代码审核完成之后，截图以 RTX 通知申请人

  5. 多个审核人，有一个审核通过即可签入代码

  6. 对于代码改动量大，改动范围广的修改；建议开代码评审会议

以上所说的代码，指的是非 Dev 分支代码。

2.2.9 测试

测试工程师按照测试流程，以功能规格为样本，制定测试用例，执行测试。测试过程中发现的问题建立 bug 项。

准入准则：

  1. 开发已完成自测并提交自测报告到 TFS 工作项；

  2. 冒烟测试：功能基本流程实现符合需求；

  3. 冒烟测试：功能涉及到的参数、端口配置符合需求；

  4. 冒烟测试：无致命 Bug 比如内存泄漏、崩溃、卡死，影响系统稳定性或者影响加工安全性的问题；

注意：发现开发质量低，列出证据，拒绝进一步测试。

准出准则：

  1. 需完善的测试用例已完善；

  2. 确认需执行的测试用例，已 100% 完成测试执行；

  3. 确认需修改的 Bug 均已回归测试通过。

  4. 如果有本次发行没有解决的内部 BUG，需要把标题的内部测试改成 BUG 维护。

提交测试记录：

第*次测试情况说明：

测试结论：（通过）/（不通过）

自动化执行结果：（通过）/（不通过）（平面发布时需填写，且执行后的的测试报告与测试日志附在 TFS 的对应工作项）

测试环境：

测试版本：

测试范围：

是否检查开发自测说明：

是否检查 Checklist：

测试资料是否归档：归档了写地址，未归档写待归档，不需要写不需要原因

2.2.10 分支合并

分支合并由开发工程师负责：

  1. 开发工程师根据工作项的范围，确定要合并到的插件 or 集成项目分支

  2. 判断本次合并的范围，如果合并有较高风险，需要与测试沟通，发合并任务测试

  3. 所有合并完成之后，将工作项标签中的【未合并】删除

注意：合并的质量由开发工程师保证

2.2.11 整理文档

这一阶段功能已经测试通过，代码也已经提交；回过头去重新审视规格文档，设计文档，查找那些和代码实现不匹配的地方。主要工作：

  1. 根据代码修改设计文档，使之一致
  2. 对文档进行润色。一些模棱两可的叙述可能给今后的阅读者造成困惑，都应该做修改
  3. 明示方案的边界、局限性和缺陷
  4. 将工作项相关的文档最新版本都上传到工作项附录中
  5. 将文档整理好之后，规格文档上传三级规格，设计文档上传 Wiki 中
  6. 以功能二次开发、使用为目标，给团队中的成员做一次分享
  7. 将刀路、测试分析文档、测试用例归档到对应的库中。

3 附录

产品技术架构设计：http://172.16.1.7:9999/#!维宏研发/DesignPhase.md

长沙 Wiki 使用指南：http://172.16.1.7:85/#!ChangSha_tm/00.使用指南/Wiki使用指南.md

编制： 唐涛 审核： 批准：