测量管理信息系统建设方案doc.docx
- 文档编号:30773265
- 上传时间:2023-08-23
- 格式:DOCX
- 页数:8
- 大小:18.21KB
测量管理信息系统建设方案doc.docx
《测量管理信息系统建设方案doc.docx》由会员分享,可在线阅读,更多相关《测量管理信息系统建设方案doc.docx(8页珍藏版)》请在冰豆网上搜索。
测量管理信息系统建设方案doc
测量管理信息系统建设方案1
测量管理信息系统
建设方案
测量管理信息系统建设方案
◆产品概述
测量管理信息系统(MMIS)以ISO10012:
2003测量管理体系要求为设计指导思想、以测量设备管理为核心基础应用、以计量要求管理为贯穿整体计量业务的主线,在规范、科学的进行测量设备管理的基础上,帮助企业向测量过程管理进行提升。
MMIS系统经过多年的客户应用,融合了烟草、钢铁、有色金属、港口、机械制造、生物化工等多行业的领先企业的最佳业务实践,是市场上得到广泛应用的成熟产品。
系统涵盖测量设备管理、设备检定、证书管理、测量过程管理、计量要求导出、体系文件管理、测量管理体系分析改进、数据智能分析等一系列与企业计量实际业务深度融合的业务流程。
MMIS不仅仅是一套软件系统,更是一个管理辅助工具,使我们的计量管理工作更加规范化、流程化、精细化地高效运作,全面提高企业计量管理工作的整体效率,最大限度地提升产品质量。
当然MMIS系统本身也包含了很多代表行业最佳实践的管理理念、运作模式和操作流程,能够更加快速地让企业站在更高的层面开展计量管理工作,为企业建立产品质量回溯体系提供完善的数据支撑。
◆测量管理信息系统功能概览
系统上线应用后的价值及应用效果
(1)系统应用价值
测量管理信息系统涵盖计量要求导出、测量过程管理、设备管理、体系分析
改进、外部供方、数据分析等全方位的计量管理业务,改变了企业计量管理及设
备检定管理的四维局限,让更多的企业按照国际标准来重新审视计量管理工作,
从根本上提升企业的计量管理意识和计量管理水平;
系统的应用,统一了集团/企业整体的计量管理模式,规范了流程,集团/企
业可以通过系统直接管控下属分子公司/车间的计量业务;
实施过程中,可以帮企业重新梳理员工的岗位职责,固化部门间的业务流程,加速了企业内部业务的流转效率;
系统成功应用后减少了员工数据统计的工作量,所有业务数据分析系统实时汇总,不仅提高效率、而且保证了工作成果反馈全面性、真实性;
系统为企业搭建了一个知识积累、传播、共享的平台,很好的将测量管理体系的管理方法、工作流程、岗位职责进行了固化、传播;
计量管理水平的提升虽然没有给企业带来直接的利润增长,但是,可以大大降低企业的损耗,提升产品质量;
系统都能够为测量管理体系、质量管理体系等体系外审提供所需的业务数据。
(2)系统运行效果
(系统登录首页展示企业计量管理概况、并且实时弹出相关业务提醒)设备管理
设备到期自动提醒——避免设备漏检;
清晰地设备状态管理——在用、停用、限用、重新启用、维修、报废、转移、检定、待确认、封存等全部状态管理;
设备历史信息追溯——检定、计量确认、维修、重新启用、转移、报废、停用各阶段的历史信息追溯;
批量生成检定计划——可以按照部门批量的生成检定计划;
检定计划自动分发——各部门可以自己查询本部门需要送检的设
备;
检定完成的设备批量翻帐——检定合格的设备,可以批量填写
检定信息;
自动调整有效日期——系统会自动计算设备有效日期、并且自动调
整检定提醒时间;
全面的数据统计分析——周检率、合格率、受控率、ABC分类统计
等;
检定费用统计及预测——对设备历史发生的检定费用进行统计分
析,并且可以根据未来的设备检定计划预测未来的费用发生情况;
。
。
。
。
。
。
(测量设备配备率柱状图展示形式)
测试管理实施方案V2[1][1].01
测试管理实施方案
1.引言
软件测试是发现软件中错误和缺陷的主要手段。
在一般情况下,软件测试过程与整个软件开发过程基本上是平行进行的。
当然,测试计划应该在需求分析阶段就已经开始制定了。
随后的工作则会伴随着软件开发的过程逐步展开。
2.测试计划
2.1启动准则
●软件项目计划完成
●系统设计文档已经完成
2.2主要步骤
Step1:
制定测试计划
●首先根据软件项目计划和需求文档确定测试需求、测试策略、资源和进度,
并建立测试通过准则。
●制定《测试计划》。
●对《测试计划》进行评审。
Step2:
设计测试
●根据测试计划和系统设计文档为每一个测试需求设计测试用例和驱动程
序,并开发执行测试用例的测试过程。
Step3:
实施测试
●根据测试过程创建可重用的测试脚本。
●根据设计编写测试需要的测试驱动程序,并且实施测试驱动程序。
Step4:
执行单元测试
●按照测试过程和测试用例手工执行单元测试或运行测试脚本自动执行单
元测试,以验证单元的内部结构和单元实现的功能。
●将单元测试的结果作详细记录(测试报告)。
●及时消除已经发现的缺陷。
●消除缺陷之后应当进行回归测试,以确认不会引发新的缺陷。
Step5:
执行集成测试
●按照测试过程和测试用例手工执行集成测试或运行测试脚本自动执行集
成测试,以验证单元之间的接口和集成工作版本的功能、性能等。
●将集成测试的结果作详细记录(测试报告)。
●及时消除已经发现的缺陷。
●消除缺陷之后应当进行回归测试,以确认不会引发新的缺陷。
Step6:
执行系统测试
●测试组长按照指定的模板起草《系统测试计划》。
●项目经理审批《系统测试计划》。
该计划被批准后,设计系统测试用例。
●测试组长邀请开发人员和同行专家,对系统测试用例进行技术评审。
●待测试用例通过技术评审后,按照测试过程和测试用例手工执行系统测试
或运行测试脚本自动执行系统测试,以确认软件系统版本是否满足需求。
●将系统测试的结果作详细记录(测试报告)。
●及时消除已经发现的缺陷。
●对修改后的软件系统版本进行回归测试,以确认不会引发新的缺陷。
Step7:
评估测试
●对每一次测试结果进行分析评估,并提出变更请求或其他处理意见。
●在每一个测试阶段提交《测试分析报告》。
●对《测试分析报告》进行评审。
评审通过后,验收测试。
Step8:
测试工作总结
●对本项目的测试工作做出总结。
2.3结束准则
●项目所有文档已经完成
●满足项目的测试
4.测试用例编写注意事项
●测试用例必须考滤无效和预期之外、有效和预期内的输入条件。
●测试用例必须能生成理想的输出条件。
●明确测试用例的覆盖程度(涉及、利用、执行),必须确保在每一层次上都
用足够的测试。
●明确测试用例的原材料(被测产品)。
即判断测试是基于需求的测试、功能
的测试还是基于内部的测试。
●测试用例必须明确测试策略。
即是编写基于黑盒测试的测试用例还是编写
基于白盒测试的测试用例。
●穷举测试是不可能的,任何程序的测试都应该是不完整的,通过从所有可
能的测试用例中确定最有可能检测出最多错误的子集,将这种不完整性的负面影响降到最底水平。
这样,我们可以通过有限的测试,发现尽可能多的错误。
●在基于功能测试的黑盒方法中的等价类划分法中:
编写为每一EC(等价类)赋一个唯一的数字的测试用例。
编写新的测试用例,尽可能多的覆盖还没有覆盖的EC,直到测试用例
覆盖了所有的有效的EC。
如果在同一个测试用例中测试了多个无效EC,那么可能永远不会执行
有些测试,因为第一个测试会屏蔽其他的测试或终止测试用例的执行。
●在基于功能测试的黑盒方法中的边值分析法中,不是在EC中选择一个元
素作为代表,而是在挑选元素时应当使得EC的边界数据受到测试,故应编写基于边界数据测试的测试用例。
●在基于内部测试的白盒方法中的高层测试法中:
可用性测试:
确定产品用户界面与用户的人类工程需求之间的差异,
其特征包括:
可访问性:
用户可以较为容易的进入、浏览并退出吗?
反应性:
用户可以在需要的时候,以一种明确的方式做他们想做的事情吗?
有效性:
用户可以以最少的步骤和时间做他们想做的事情吗?
可理解性:
用户理解产品结构,求助系统和文档吗?
功能测试:
是发现程序的功能规格说明与实际行为之间的差异的过
程。
系统测试:
是表明程序或系统没有满足需求规格说明所确定的原有
需求和目标的过程。
其特征包括:
容量测试:
判断程序是否能处理所要求的数据,请求等容量。
负载/强度测试:
确定负载峰值条件,此条件下程序不能在要求的时间间隔内处理要求的负载。
安全测试:
显示程序的安全性要求是否被破坏。
性能测试:
确定程序是否满足性能要求。
资源应用测试:
确定程序使用资源(存储器,磁盘空间等)的水平是否会超过需求。
配置测试:
确定按需求配置软件或硬件时程序是否运行正常。
可安装性测试:
确定安装过程中会导致不正确结果的方式。
恢复性测试:
确定系统或程序出现故障之后是否满足恢复性需求。
可靠性/可获得性测试:
确定系统是否满足可靠性和可获得性要求。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测量 管理信息系统 建设 方案 doc