软件测试流程规范(试行)V1020140403

1、青岛佳明软件测试流程规范为了更好地执行测试计划，完成测试工作，特制订青岛佳明测试流程规范，本规范中规定了测试执行流程、测试任务范围、测试计划/用例格式、BUG状态/级别、测试人员职责、研发人员相关职责、测试报告提交周期等内容。1 测试流程（1） 测试准备阶段，软件测试人员通读项目需求设计文档，包括软件概要设计、软件需求规格说明书（2） 根据软件需求规格说明书编写软件需求列表（3） 根据项目需要，测试人员明确列出本测试任务的范围（4） 制定测试计划，搭建测试软/硬件环境，确认测试方法和测试资源（5） 设计测试用例（6） 执行测试（需配合研发周期）（7） 编制、提交测试报告（8） 研发人员根据报告

2、修正问题，并发布新测试版本（9） 回归测试（10） 测试评审（11） 编写用户手册2 测试任务范围（根据项目规模灵活选择）功能测试；界面测试；接口测试；流程测试；极限测试；负载测试；性能测试；稳定性测试；兼容性测试；安装测试；强度测试；用户测试；3 测试计划（1） 项目简介；对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。（2） 测试背景；产品在哪种情况下开始研发，执行测试，交待为何而测试产品的背景。（3） 测试手段环境；（手工和自动化工具）测试环境测试辅助工具（4） 测试类型（方法）；（黑盒测试）功能测试；界面测试；接口测试；流程测试；极限测试；负载测试；性能测试；稳定性测试；

3、兼容性测试；安装测试；强度测试；用户测试；（5） 测试资源；人力资源 系统资源人员角色职责、任务时间（6） 测试策略测试需求测试任务测试点；针对测试需求定义测试类型、测试方法以及需求的测试工具等。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。列出在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。（7） 测试工作计划表；No工作内容开始时间结束时间责任人提交的结果备

4、注4 测试用例测试用例的主要来源为：（1）需求说明书及相关文档；（2）相关的设计说明（概要设计，详细设计等）；（3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）；（4）已经基本成型的UI（可以有针对性地补充一些用例）。l 测试用例模板1：功能A描述用例目的前提条件用例编号输入/动作期望的输出/响应实际情况示例：典型值示例：边界值示例：异常值功能B描述用例目的前提条件用例编号输入/动作期望的输出/响应实际情况示例：典型值示例：边界值示例：异常值l 测试用例模板2项目名称程序版本功能模块名用例编号编制人编制时间功能特性测试目的参考信息预置条件特殊规程说明参考信息测试用例基本流序号名称说

5、明12备选流序号名称说明12相关的用例无测试场景序号名称说明测试数据测试数据集1：序号操作描述数据预期输出实际输出测试状态（P/F）12测试人员开发人员项目负责人5 BUG状态说明l 新建： 测试人员报告bug的状态l 已指派：测试人员分配bug的状态l 已解决：修改人员修改bug的状态，在解决bug界面准确标注bug的完成度l 已确认：修改人员对暂时不能、以后修改的bug进行确认的状态l 反馈： 测试人员对开发人员认为不修改、但测试人员认为需要修改的bug反馈给研发经理的状态l 公认： 研发经理查看反馈的bug后认为需要修改，则标示bug的状态为公认，认为不做修改，直接关闭此bug，注明原因

6、l 已关闭：测试人员对修正后的bug进行回归测试后，确认bug已修正即可关闭bug状态6 BUG级别说明A（严重级，必须立即修改）：操作系统或者网络瘫痪；B（中等级，一天内修改）：应用程序崩溃、非法退出或功能模块无法实现。C（一般级，三天内修改）：篡改设计；功能实现错误或功能不完善，容错失败、数据逻辑关系错误。D（允许级，短期内无须解决或在下一版本中解决）：界面布局；操作不方便；建议性修改。说明：严重程度越高，优先级越高，原有错误优先级高于新版本错误。7 工作职责（1）测试人员：准确定位bug，新建bug，指派bug与研发经理 对修正后的bug进行验证，确认修正后将其关闭 通过验证，bug仍然

7、存在，重新指派，并将相关情况提交至绩效考核部门 对修改人员认为不需要修改，而测试人员认为要修改的bug，反馈至研发经理 对已关闭的bug以后又浮现，将其重新打开、指派与研发经理，并将相关情况提交至绩效考核部门（2）研发人员：查看指派给自己的bug，准确选择bug的完成度，添加bug注释，将其状态置为已解决 查看bug，确认是bug，进行修正，并注明原因 对不属于自己模块的bug指派其他人修改 对延迟解决的bug标注确认 需要讨论的bug，将其状态置为公认（3）研发经理：查看测试人员提交的bug，确定要修改的，添加注释指派与修改人员 需要讨论的bug，将其状态置为公认 对不做修改的bug，将其关

8、闭8 测试退出准则（1） 系统满足需求规格说明书的要求（2） 按照测试计划完成了系统测试（3） 测试用例执行覆盖率达到100%（4） 测试需求覆盖率达到100%（5） Block，Crash，Major级缺陷修复率达到100%（6） Minor，Trivial级缺陷修复率达到80%（7） Text，Suggestion，Feature级缺陷修复率达到75%（8） 程序能够处理要求的负载（9） 系统在要求的硬件和软件平台上工作正常。9 提交报告（1） 测试人员在软件新版本发布3日内提交有关本版本的功能测试报告（附录一）。（2） 测试人员根据研发人员对于软件缺陷的修复情况，每个月的月底提交汇总性测

9、试报告和程序错误报告（附录二）。（3） 在软件测试结束交付用户前，测试人员需提供测试分析报告（附录三）。10 其他测试人员按照工作计划执行测试和提交测试报告，若由于研发人员未按规定日期时间提交测试版本，造成测试工作未能完成，则由研发人员承担责任。附录一 功能测试报告测试项目项目名称测试人测试类型测试时间版本测试批次功能1功能名称合格率评定分数测试评定BUG级别：A： 个 B： 个 C： 个 D： 个测试问题1、2、功能2功能名称合格率评定分数测试评定BUG级别：A： 个 B： 个 C： 个 D： 个测试问题1、2、附录二 程序错误报告（系统名称）测试项目项目名称测试类型模块名称模块名称版本测试

10、时间测试批次合格率评定分数测试评定BUG级别：A： 个 B： 个 C： 个 D： 个序号BUG级别错 误 描 述BUG状态备注测试人： 附录三 测试分析报告1 概述1.1 编写目的编写本文档的目的在于通过对测试结果的分析得到对软件的评价；为纠正软件缺陷提供依据；使用户对系统运行建立信心。1.2 参考资料说明软件测试所需的资料（需求分析、设计规范等）。1.3 术语和缩写词说明本次测试所涉及到的专业术语和缩写词等。2 测试对象包括测试项目、测试类型、测试批次（本测试类型的第几次测试）、测试时间等。3 测试分析3.1 测试结果分析列出测试结果分析记录,并按下列模板产生BUG分布表和BUG分布图。分析模版：从软件测试中发现的并最终确认的错误点等级数量来评估：从以上提出的BUG等级来统计等级和数量的一个分布情况：（如下表）ABCDEBUG数量217301所占比例9%