测试部门工作规程.docVIP

专用测试组工作规程 日期 版本 修订人 修订内容 8-6 V1.0 初稿 目录 一、 目的 2 二、 产品测试工作 2 1、 工作流程 2 2、 详细说明 2 3、 注意事项 3 三、 外部技术支持工作 3 1. 工作流程 4 2. 详细说明 4 3. 注意事项 4 四、 其他要求 5 1. bug填写 5 2. 日报周报 5  目的 规范专用测试组工作内容和工作流程，通过规范化的工作模式，提高专用测试组的整体工作效率。 产品测试工作 工作流程 见测试工作流程图，如下： 详细说明 初始 从产品经理或技术经理处获得产品的版本规划情况，包括版本号、计划完成时间、需求内容、修改内容等，根据不同产品的需要，参加需求和设计评审，评审过程中要从测试的角度评审需求和设计是否是可测试的。 （目前研发中心的需求和设计评审几乎没有，属于过程遗漏，对产品质量有影响） 计划 根据版本规划的时间和需求范围制定测试计划，选择已有的测试用例，编写新功能的测试用例，明确每一轮测试所要用到的用例有哪些，用例的选择要经过评审确认。（目前公司评审机制较薄弱，替代的方法是测试人员在收到开发提交的测试申请后选择的用例范围要经过测试主管审核，再执行测试） 输出：测试计划、测试用例 执行 收到提交测试的产品包后，首先须进行冒烟测试，保证基本的安装/卸载过程正常，数据流正常，才可以进入功能测试。 每一轮的测试要将已经确定的测试用例完整执行一遍，将一轮测试中发现的bug填写到bug系统中，交给开发进行修改，所有的bug修改完成后才可以提交完整包进行下一轮的测试。在下一轮测试开启前，允许开发提交两次文件，以替换的方式进行bug验证，bug验证通过后再要求开发打包提交进行下一轮测试。 输出：bug列表，阶段性测试报告（每一轮测试执行完成后发出） 收尾 内测通过后，如果需要进行beta测试的的，要编写观察方案，写明观察时间周期、观察重点、检查项、观察通过的标准。 内测完成后要编写内测报告，编写版本发布说明、用户手册、安装说明文档等配套文档。对于一些子模块的入库，可以不提供用户手册。 输出：beta测试方案（可选）、内测报告、版本发布说明、用户手册（可选）、安装说明文档 完成 测试通过的包需填写正式入库申请，入正式库后认为是测试阶段完成。 输出：入库申请表 注意事项 开发提交的测试申请，要检查是否符合入口标准，如果描述不清晰、不准确，或者存在明显的产品命名、版本号不正确之类的错误，要求开发修改后重新提交测试申请。 保证每一轮都将测试用例跑完，再将bug提交给开发人员，要求开发人员将bug全部修复完成之后再提交测试，如果只是部分修改，除非有合理的理由，否则不接受测试。 外部技术支持工作 工作流程 详细说明 初始 外部问题的提交最好采用邮件的形式进行交互，测试人员收到问题后认真查看问题的描述，如果对于问题描述有不理解的地方直接与问题提交人进行交互。 分析 判断问题是否为已知缺陷，如果是已知缺陷，直接答复给问题提交人处理问题的方式。 如果不是产品的已知缺陷，需要在现场重现此问题，分析定位问题发生的原因，将分析结论转给开发人员，由开发人员给出解决方案。同时，要把问题填写进bug管理系统。 收尾 给出问题解决的报告，报告内容包括分析定位的结论、如果是已知缺陷给出解决方案。报告要发给问题提交人，抄送给测试主管和产品经理。 完成 与问题提交人确认问题是否解决，若已解决，则任务完成。 注意事项 问题的交互最好都采用邮件的方式，以保存问题交互记录，作为追溯和工作记录的依据。 对于新发现的问题如果是产品缺陷，一定要填写bug，无论是否已通过其他手动方式解决。 其他要求 bug填写 bug填写时要描述清楚以下几个方面的内容： 测试时的操作步骤，描述清楚测试的时候是如何做的操作。 问题现象，最好可以附上截图。 测试分析结论、建议，给出测试的分析结论。 日报周报 日报内容主要包括： 任务名 所用工时（小时） 详细情况描述 当天结果 补充测试用例 3 未解决 完成业务数据流程图 2 已完成 汇总这一周外测的观察情况 2 已完成 Bug统计 New（新录入bug数） Reopen（重开bug数） Closed（关闭bug数） Reject(开发拒绝bug数) 1 0 0 说明： 描述当天做了哪些工作，每项工作大概使用多少工时（单位：小时），情况如何。 对当天的bug情况进行总结。 周报内容包括： 本周主要任务分布：（%） 测试任务 文档编写/修改 外部技术支持 其他 10% 20% 50% 20% 1、 ######### 2、######### 说明： 对一周的工作做一个归纳总结，描述每一类型的工作占用工作时间的百分比。 对当周发现的问题进行总结，任何方面的问题