计算机软件管理制度|技术部软件研发管理制度( 五 )


第6条 测试计划的内容 。
1.产品概述 , 说明待测产品的名称、特征、用途以及测试产品的目的 。
2.测试策略 , 是测试依据的主要原则、理论、方法 , 以及测试时重点考虑的因素 , 等等 。
3.测试所采用的方法 。
4.测试区域 。
5.测试配置 。
6.测试周期 。
7.测试资源规划 。
8.风险分析及应急计划 。
第3章 测试用例设计
第7条 测试用例的设计原则 。
1.能够复用原则 。
2.易于分类原则 。
3.测试内容不重复原则 。
4.数据库管理归档所有测试用例原则 。
5.在研发测试过程中不断调整及增强原则 。
第8条 测试用例应满足的条件
1.测试用例应尽可能覆盖软件产品的功能特点和程序代码中的分支流程 , 并极有可能抓住Bug 。
2.测试用例应注重测试那些最特殊的输入组合 , 如对最大值、最小值等边界输入条件的测试 。
3.选择测试用例时应选用经实践证明最有效的测试用例 。
4.将复杂的测试用例分解成一组较简单的测试用例分别进行测试 。
第4章 Bug管理
第9条 Bug的界定 。
1.功能未实现 , 和规格说明书的描述不一致 。
2.不能工作 , 死机 , 没反应 。
3.对某种软、硬件配置不兼容 。
4.在设置边界条件时发生功能缺失或错误 。
5.界面、消息、提示不够准确 , 不友好 。
6.有时把未完成的工作也作为一个Bug 。
第10条 Bug的级别与后果
1.死机 , 导致死机或系统瘫痪 。
2.主要问题 , 可能引发严重问题 。
3.小问题 , 不太严重 。
4.微小问题 。
第11条 Bug的优先级 。
1.需要尽快修正的Bug 。
2.每个里程碑结束前必须修正的Bug 。
3.如果时间允许就修正的Bug 。
4.低优先级的Bug 。
第12条 Bug状态分类 。
1.活动的Bug 。
2.已经解决的Bug 。
3.关闭的Bug 。
第13条 Bug报告管理 。
在软件开发过程中 , 发现并报告Bug不仅是测试工程师的职责 , 也是所有研发参与人员的职责 , 所有人报告的Bug都被统一记录、跟踪和管理 。
第14条 Bug保存 。
Bug的每一次处理都被记录在数据库内 , 所有记录都无法删除 , 只能为记录添加新的内容 。
第15条 Bug报告与分析流程 。
1.测试工程师在发现或接收到Bug报告后 , 应立即建立一个新Bug记录 , 以备后续的跟踪和管理 , Bug记录应包含Bug的具体再现步骤、环境和Bug再现时的屏幕截图等 。
2.测试工程师应尽可能分析产生Bug的原因 , 并根据该Bug对于后续软件开发和发布的影响程度 , 设定合适的优先级和严重级别 。
3.在分析产生Bug原因的基础上 , 对Bug进行归类管理 。
4.设定好优先级和严重级别的Bug将被测试人员根据Bug出现的位置、Bug的可能成因等分派到相关的开发人员 , 由其专门负责解决 。
第16条 Bug的解决方法 。
1.已修正 。
2.推迟 。
3.设计问题 。
4.重复 。
5.不可再现 。
6.无需修正 。
第5章 测试过程管理
第17条 完整的测试循环过程工作内容 。
1.完整测试 , 按测试计划和测试用例的要求 , 将所有测试用例完整地执行一遍 。
2.随机测试 , 提高发现Bug的几率 。
3.Bug校验(回归测试) , 对所有已经改正的Bug进行再次测试 , 确保先前发现的Bug已完全解决 。
4.结束条件测试 。
第18条 各阶段的测试 。
各测试阶段的测试内容与测试后的技术状态如下表所示 。
计算机软件管理制度|技术部软件研发管理制度



第19条 测试质量要求
质量是由产品的可靠性、功能和上市时间来决定的 , 是三者之间的平衡 。
1.可靠性是指软件产品功能的正确性 , 即无大的缺陷或缺陷很少 。
2.功能是软件产品提供给客户的所有可操作的特性 。
3.上市时间与软件研发的进度相关 。
第6章 附则
第20条 本规定由公司软件研发部制定 , 其修改权、解释权归软件研发部所有 。
第21条 本规定自颁布之日起执行 。
五、软件研发质量管理制度软件研发质量管理制度
第1章 总则
第1条 目的 。
为加强对软件质量的管理 , 符合标准及规范的要求 , 确保技术文档齐全正确并且系统便于维护 , 不断提高公司软件产品的质量水平 , 特制定本制度 。