质量过程控制机制
| 密级：机密 | 生效日期：
| 状态：内部使用 | |||
| 总页数 |
| 正文 |
| 文件编号 |
|
| 编制：徐小东 | 审核： | 批准： | |||
目录
文件更改摘要
| 修订日期 | 版本号 | 修订说明及页码 | 修订人 | 审核人 | 批准人 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
清晰准确的功能、性能、行业要求是项目的基础资料，我们的工作从这从里开始进入评审阶段、动员阶段、功能设计阶段、编码设计阶段、测试阶段及质量控制的过程。
功能需求框架
| 序号 | 项目 | 大纲 | 备注 |
|
| 1 | 客户定制 |
|
|
|
| 2 | 硬件需求 |
|
|
|
| 3 | 软件需求 |
|
|
|
| 4 | 结构需求 |
|
|
|
| 5 | UI需求 |
|
|
|
| 6 | 测试需求 |
|
|
|
| 7 | 电磁需求 |
|
|
|
| 8 | 时间需求 |
|
|
|
| 9 | 资金人力成本需求 |
|
|
|
项目计划主要是客户、供应商或公司部门之间协调评审项目进度、功能优先级、完成目标的一个预估。
| 1 | 任务 | 责任人 | 工期 | 开始时间 | 结束时间 | 前置任务 | 进度 | 任务难点 |
| 2 |
|
|
|
|
|
|
| 是否有经验 |
| 3 |
|
|
|
|
|
|
| 是否有支持 |
| 4 |
|
|
|
|
|
|
| 是否要讨论 |
| 5 |
|
|
|
|
|
|
| 资源要到位 |
| 6 |
|
|
|
|
|
|
| 是否定协议 |
| 7 |
|
|
|
|
|
|
| 是否要学习 |
|
|
|
|
|
|
|
|
| 非标准逻辑 |
|
|
|
|
|
|
|
|
| 特殊实现功能 |
|
|
|
|
|
|
|
|
| 加急任务 |
功能明细我们主要注重的是对于项目或标准的关键功能、主要功能的细化工作，要一项一条的满足客户要求或某种行业标准。在此项阶段的评审过程中，质量控制必须开始运行。
| 序号 | 项目 | 一级功能 | 二级功能 | 参考标准 |
| 1 | 客户定制 |
|
|
|
| 2 | 硬件需求 |
|
|
|
| 3 | 软件需求 |
|
|
|
| 4 | 结构需求 |
|
|
|
| 5 | UI需求 |
|
|
|
| 6 | 测试需求 |
|
|
|
| 7 | 电磁需求 |
|
|
|
| 8 | 时间需求 |
|
|
|
| 9 | 资金人力需求 |
|
|
|
我们这里的研发管理主要考虑研发的流程及功能更改机制与质量控制的协调平衡，是否高效可行保质保量,现在主要考虑的问题，效率过程是否可控的问题
要求：
1.质量控制一定不影响开发进度
2.质量控制在开发中保持一种观察状态与梳理动作
3.质量控制辅助研发动作(手段包括但不限于，修改优先级的更改、INT问题重现规律、客户体验评估、Bug问题通过评估)
方法：
1.添加新UI时，请测试三个动作， a、程序启动 b、UI上下界面切换 c、开机进入程序
2.添加新功能时，请测试三个动作， a、功能确定 b、两个功能切换 c、开机进入程序
3.添加新协议时，请测试三个动作, a、确定协议逻辑正确 b、两个模块逻辑连接交叉测试 c、开机进入程序
4.不能修改问题的回复方法 a.客户要求NO b.评审要求NO c.修改时间与难度影响整个项目NO
5.INT问题解决流程
1.逻辑关系是否全面
2.逻辑关系测试365次
3.软件并发事件发生的统计表
4.时序问题
5.加载窗口初始化问题
a.1000次是否重现
b.是否在规定范围内重现
c.致命问题
d.不满足行业或客户要求
- 修改评审流程 a.15分钟内部会议确定是否修改 b.15分钟客户沟通是否修改
研发测试的过程定义、沟通方法、问题重现、INT问题分析与重现、问题点的阶段定位、关键问题的评估
另外：注重测试的优先顺序，a.必测功能是否实现 b.客户特殊功能 c.行业或公司必须功能 d.其余问题再测试
功能实现的阶段
客户、测试、研发、市场的功能定位会议
模块测试
逻辑测试
指标测试（内存、CPU、启动时间、程序切换）
版本控制与代码管理
代码管理的方法：
版本控制是软件里程碑的问题，进行还原点的记录与代码时间点的对应关系备份，是解决重要 问题的快速方法的关键因素.
研发测试回答问题，
- 上一版本是否出现
- 必然现象？
- 模块分类?
- 是否使用上一版软件验证？
- 样机是否是同一台？
f.必须是五台机器一同测试一个问题?
1.样机统一编号、重要模块统一编号
2.样机统一标签
| 平台 | |||||
| 客户名称 |
| 样机编号 |
| 硬件更新人 |
|
| 序号 |
|
| 序号 |
|
|
| 1 |
| 1 |
| ||
| 2 |
| 2 |
| ||
| 3 |
| 3 |
| ||
| 4 |
| 4 |
| ||
| 5 |
| 5 |
| ||
- 修改的详细记录
| 机型 |
| 工程师 |
| 时间 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 问题点 | 对策 | ||||
| TFT PCB | |||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
| MB PCB | |||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
|
|
| ||||
测试的完整性问题及准则
1.发布测试BUG之前，确定测试的基功功能已经测试完毕
2.临时性版本确定重点问题，浏览基本功能
3.专项测试确定专项问题，浏览基本功能
编写用例的流程--》实际使用环境模拟--》客户要求--》公司要求--》行业行规--》性能--》压力--》长期性测试
编写用例的时间要求 1.满足验证室实际操作时间 2.提高操作效率 3.定制操作效率的规范 4.流程化与产品化
功能更改的流程
影响框架否？
影响逻辑性？
影响项目进度吗？
客户、研发、市场沟通充分吗？
组织评审
评审流程
1.样机评审
2.软件架构评审
3.项目时间评审
4.评审表格
5.协议评审
6.功能优先级评审
时间与效率，主要考虑在一定时间内是否能保证质量与项目的进度
我想效率与时间就是要考虑保质保量、不乱、流程化的问题，
先完成三件事，
1.最紧急的事（必须做） 2.最重要的事(不能拖延) 3.最日常的事情(影响范围广泛)
缺陷更改及修改的流程
优先更改客户或市场必须使用的功能
修改系统死机或重启的现象
修改逻辑关系方面的问题
单独的平台问题暂时不用修改
INT问题1000次三台机器未出现暂时不用修改
研发及技术的创新、质量的控制可以说全心为了占领市场的制高点、巩固市场、开拓甚至打败对手，在研发过程中展示我们稳定的、有特色的产品是必然事件、关键事件，所以市场的版本必须可控、一目了然、一定要能拿得出手。
市场版本控制表格
| 版本号 | 软件1 | 软件2 | 软件3 | 软件4 | 软件5 | 配套样机 | 样机是否修改 | 版本是否备份 | 异常功能 | 是否可演示 |
| V1.0 | app | mcu | os | dvd | bin | 1# |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
波浪万丈--猛闯!
风光绚丽--欣赏!
2688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
