软件测试流程规范(试行)V1.0-2014-04-03.docx

青岛佳明软件测试流程规范为了更好地执行测试计划，完成测试工作，特制订《青岛佳明测试流程规范》，本规范中规定了测试执行流程、测试任务范围、测试计划/用例格式、BUG状态/级别、测试人员职责、研发人员相关职责、测试报告提交周期等内容。测试流程测试准备阶段，软件测试人员通读项目需求设计文档，包括《软件概要设计》、《软件需求规格说明书》根据《软件需求规格说明书》编写软件需求列表根据项目需要，测试人员明确列出本测试任务的范围制定测试计划，搭建测试软/硬件环境，确认测试方法和测试资源设计测试用例执行测试（需配合研发周期）编制、提交测试报告研发人员根据报告修正问题，并发布新测试版本回归测试测试评审编写用户手册测试任务范围（根据项目规模灵活选择）⑴功能测试；⑵界面测试；⑶接口测试；⑷流程测试；⑸极限测试；⑹负载测试；⑺性能测试；⑻稳定性测试；⑼兼容性测试；⑽安装测试；⑾强度测试；⑿用户测试；测试计划项目简介；对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。测试背景；产品在哪种情况下开始研发，执行测试，交待为何而测试产品的背景。测试手段\环境；（手工和自动化工具）测试环境测试辅助工具测试类型（方法）；（黑盒测试）①功能测试；②界面测试；③接口测试；④流程测试；⑤极限测试；⑥负载测试；⑦性能测试；⑧稳定性测试；⑨兼容性测试；⑩安装测试；?强度测试；?用户测试；测试资源；①人力资源②系统资源人员角色职责、任务时间测试策略\测试需求\测试任务\测试点；针对测试需求定义测试类型、测试方法以及需求的测试工具等。①对于每种测试，都应提供测试说明，并解释其实施的原因。②制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。③列出在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。④不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。测试工作计划表；No工作内容开始时间结束时间责任人提交的结果备注测试用例测试用例的主要来源为：（1）需求说明书及相关文档；（2）相关的设计说明（概要设计，详细设计等）；（3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）；（4）已经基本成型的UI（可以有针对性地补充一些用例）。测试用例模板1：功能A描述用例目的前提条件用例编号输入/动作期望的输出/响应实际情况示例：典型值示例：边界值示例：异常值功能B描述用例目的前提条件用例编号输入/动作期望的输出/响应实际情况示例：典型值示例：边界值示例：异常值测试用例模板2项目名称程序版本功能模块名用例编号编制人编制时间功能特性测试目的参考信息预置条件特殊规程说明参考信息测试用例基本流序号名称说明12备选流序号名称说明1　　2　　相关的用例无测试场景　序号名称说明测试数据测试数据集1：序号操作描述数据预期输出实际输出测试状态（P/F）1　　　　2　　　　测试人员开发人员项目负责人BUG状态说明新建：测试人员报告bug的状态已指派：测试人员分配bug的状态已解决：修改人员修改bug的状态，在解决bug界面准确标注bug的完成度已确认：修改人员对暂时不能、以后修改的bug进行确认的状态反馈：测试人员对开发人员认为不修改、但测试人员认为需要修改的bug反馈给研发经理的状态公认：研发经理查看反馈的bug后认为需要修改，则标示bug的状态为公认，认为不做修改，直接关闭此bug，注明原因已关闭：测试人员对修正后的bug进行回归测试后，确认bug已修正即可关闭bug状态BUG级别说明A（严重级，必须立即修改）：操作系统或者网络瘫痪；B（中等级，一天内修改）：应用程序崩溃、非法退出或功能模块无法实现。C（一般级，三天内修改）：篡改设计；功能实现错误或功能不完善，容错失败、数据逻辑关系错误。D（允许级，短期内无须解决或在下一版本中解决）：界面布局；操作不方便；建议性修改。说明：严重程度越高，优先级越高，原有错误优先级高于新版本错误。工作职责（1）测试人员：准确定位bug，新建bug，指派bug与研发经理对修正后的bug进行验证，确认修正后将其关闭通过验证，bug仍然存在，重新指派，并将相关情况提交至绩效考核部门对修改人员认为不需要修改，而测试人员认为要修改的bug，反馈至研发经理对已关闭的bug以后又浮现，将其重新打开、指派与研发经理，并将相关情况提交至绩效考核部门（2）研发人员：查看指派给自己的bug，准确选择bug的完成度，添加bug注释，将其状态置为已解决查看bug，确认是bug，进行修正，并注明原因对不属于自己模块的bug指派其他人修改对延迟解决的bug标注确认需要讨论的bug，将其状态置为公认（3）研发经理：查看测试人员提交的bug，确定要修改的，添加注释指派