美文网首页测试基础课测试
制度:测试管理制度

制度:测试管理制度

作者: 时间的磨练lolo | 来源:发表于2019-06-14 15:55 被阅读7次

    测试管理制度规范

    一、目的

    本制度规定测试日常项目实施、大型项目实施等质量保证过程中各个阶段及每一阶段的任务、要求和交付文件,以及每个阶段的测试职责。使整个项目质量保证过程阶段清晰、要求明确、任务具体,实现产品质量保证过程的标准化。

    二、适用范围

    本制度适用于公司发起的、结果数据直接或间接影响财务报表的系统开发及日常项目实施,以及大型项目期间的维稳项目实施。

    三、相关角色和职责

    3.1测试负责人

    A、负责测试组质量标准,工作方式;

    B、保障系统测试质量与效率;

    C、培养人员测试能力,探索技术演进;

    D、研究测试组持续改进与创新能力;

    E、组织测试组周例会、月例会,收集组员反馈的问题,找出问题症结,推动解决;

    3.2测试组长

    A、合理安排需求测试资源;

    B、Review测试计划、测试方案、测试策略;

    C、Review 需求质量、业务系统架构质量、技术方案质量、代码质量、测试用例质量、流程质量;

    D、监督研发测试流程,主动发现问题并推动解决;

    E、承担大型复杂的需求相关内容分解;

    F、领导本组的业务知识积累和技术演进,多组织分享;

    负责本组周报和月报;

    3.3测试组员

    A、参与需求评审,技术评审,组织需求反述、用例评审;

    B、进行需求分析,制定测试计划,编写测试方案、测试策略、测试用例;

    C、负责产品缺陷的提交和缺陷修复情况的跟踪和再测试;

    D、负责项目合并后的回归测试,负责项目上线后的再验证;

    E、负责线上问题的复现、跟踪与修复后再验证;

    F、协同需求负责人一起发现问题并推动解决,有困难及时反馈给小组长;

    G、知识库积累;

    H、业务测试、测试技术分享演讲;

    四、项目质量管理办法

    4.1 需求分析管理办法

    项目开发过程前期,产品经理组织需求评审会时,所有参与该项目的测试人员均需要参与需求评审会。需求评审会后,项目测试负责人需要组织所有测试人员进行需求分析和反述,需要执行的事项有:

    1. 需求任务分解:测试小组长将项目所有需求进行拆解,并分配到组内测试成员手中。需要产出的文案有:

    ① 需求分解详情(以项目上每个需求安排的测试人员为准)。

    ② 测试进度管理表格(建立该项目的测试进度管理共享表格,包含所有需求任务的描述、负责产品经理、负责开发人员、负责测试人员、是否通过需求反述、需求反述备注、是否通过测试分析评审、测试分析评审备注、是否通过用例评审、用例评审备注、预计提测时间、提测次数、实际提测时间、测试工时、当前状态、BUG数、测试预计完成时间、实际完成时间,是否通过产品经理验收)<ps:可通过类似jira工具进行管理>

    ③ 测试过程管理表格(建立该项目的测试过程管理共享表格,包含所有需求任务的描述、case总数、case通过数、case失败数、case未执行数、case通过率、负责测试人员)。<ps:可通过类似jira工具进行管理>

    1. 需求分析和反述:测试组长组织组测试组员,对每个需求进行分析反述。每个需求的测试人员一起对需求进行反述和分析:产品经理对该需求的原始要求是什么、该需求需要如何测试、测试关注点主要在哪些领域、需不需要整体回归测试、是否有自动化测试可以使用等。并汇报给测试组长,测试组长给出分析和反述管理意见。需要产出的文案有:

    对测试进度管理表格进行更新(将该需求的测试进度管理共享表中:“是否通过需求反述”的状态进行更新,并将需求反述内容更新到“需求反述备注”中)

    明确职责:测试组员对单一需求的分析和反述结果及产出负全责。

    4.2 测试分析与用例管理办法

    项目需求评审和需求分析反述完毕后,所有测试人员需要对各自负责的需求进行测试分析和用例编写。需要执行的事项有:

    1. 详细测试分析:测试人员对所负责的需求进行详细分析,有哪些测试要点、需要构造哪些测试数据、需要采用哪些测试手段、需要哪些外部团队提供协助等,并通过测试组长、开发人员、产品经理的评审。需要产出的文案有:

    ① 测试分析详情(将该需求的测试进度管理共享表格中:“是否通过测试分析评审”的状态进行更新,并将测试分析内容更新到“测试分析评审备注”中)。

    1. 测试用例和测试要点编写:测试组员对所负责的需求进行测试用例或者测试要点的编写,并通过测试组长、开发人员、产品经理的评审。需要产出的文案有:

    ① 对测试过程管理表格进行更新(将该需求的测试过程管理共享表格中:“case总数”进行更新)。

    ② 对测试进度管理表格进行更新(将该需求的测试进度管理共享表格中:“是否通过测试用例评审”的状态进行更新,并将测试分析评审内容更新到“测试用例评审备注”中)。

    ③ 将该需求所有测试用例,编写到用例管理系统。

    明确职责:测试组长、测试组员对单一需求的测试分析、测试分析评审结果、用例编写、用例评审、用例数据等过程和产出负全责。

    4.3沟通管理办法

    测试组员应当积极主动与测试负责人、测试组长、开发人员、产品经理沟通需求分析、测试分析、测试用例编写、测试用例执行、缺陷提交、缺陷跟踪修复等过程中遇到的一切需要他人协助解决的问题。与他人沟通时,应该无障碍、无消极情绪、努力达成一致。测试负责人、测试组长应当协调项目测试过程中一切沟通问题,并努力将这些问题解决。

    明确职责:测试负责人、测试组长、测试组员对单一需求的测试全程的沟通问题的解决负全责。

    4.4提测管理办法

    测试组员在开发人员针对单一需求提交测试前,需要主动督促开发人员完成交付测试。在交付测试前,测试组员需要主动完成冒烟测试用例,冒烟测试用例应当从该需求的所有测试用例中提取出来进行标注,冒烟测试用例的定义是:能够对该需求的主干流程进行检查的用例,包含测试数据的准备。在交付测试阶段,测试组员需要执行冒烟测试用例,并跟踪用例执行结果。如果交付测试不通过的,不允许交付,打回重新修改,并记录该需求的提测次数到测试进度管理表格中。以此类推,直到冒烟测试用例执行通过,才算真正完成提测。当该需求真正提测时,此时才算该需求的实际开发完成时间,测试组员需要记录该时间到测试进度管理表格中。需要产出的文案有:

    1. 每日按时对测试进度管理表格进行更新(将该需求的测试过程管理共享表格中:“当前状态”、“提测次数”、“实际提测时间”进行更新)。

    明确职责:明确职责:测试组长、测试组员对单一需求的提测过程的产出及结果负全责。

    4.5 单一需求测试执行管理办法

    测试组员在单一需求测试执行阶段,应当保证在承诺测试工期内对所有负责的测试任务,完成测试用例执行、缺陷提交和缺陷跟踪修复。测试组长在单一需求的测试执行阶段,应当每日监控每个需求的测试进度和测试过程,保证进度无异常,实时跟踪测试执行过程中遇到的问题,并努力寻找解决方法,协助团队成员解决问题。测试组员需要在单一需求测试完毕后,找到产品经理对每个需求进行验收。需要产出的文案有:

    1. 每日按时对测试过程管理表格进行更新(将该需求的测试过程管理共享表格中:“case通过数”、“case失败数”、“case未执行数”、“case通过率”进行更新)。

    2. 每日对测试进度管理表格进行更新(将该需求的测试进度管理共享表格中:“当前状态”、“BUG数”、“测试时间完成时间”、“是否通过产品经理验收”进行更新)。

    3. 将该需求所有BUG,及时提交到jira系统,并每日跟踪bug状态,督促开发人员进行修复和再次验证。

    明确职责:测试组长、测试组员对单一需求的测试全程的测试执行过程的产出及结果负全责。

    4.6 缺陷管理办法

    测试组员在测试全过程中,应当保证每个需求的所有BUG都得到开发人员的修复,并验证完毕BUG的修复情况。根据测试策略,在执行回归测试阶段,应当保证自己负责的测试任务的所有BUG都得到开发人员的修复,并验证BUG的修复情况。如果确实有BUG无法解决,需要遗留,需要同步产品经理进行遗留BUG记录。需要产出的文案有:

    1. 遗留BUG记录:测试组长汇总项目所有未修复的遗留BUG,并交给产品经理确认是否需要修复,以及计划修复日期。

    明确职责:
    A、测试组员对测试全程的BUG提交、修复后再验证、确认完全修复,以及遗留BUG汇总和汇报负全责。
    B、测试组长对项目整体的遗留BUG记录汇总、产品经理确认、计划修复日期确认等负全责。
    C、测试负责人对测试完毕后的最终产品质量负全责。

    4.7 系统测试和回归测试管理办法

    单一需求测试完毕后,项目进入系统测试和回归测试阶段。根据在需求分析时的测试策略,进行系统测试和回归测试,需要完成的事项包括不限于:

    1. APP端和业务插件:单业务插件全流程集成测试、机型兼容测试、分辨率兼容测试、弱网测试、安装包新装和覆盖升级测试、业务插件升级测试、交叉自由测试。全域主流程回归测试、全域交叉自由测试等。

    2. 后台服务:单系统功能集成测试、单系统主流程功能回归测试、单系统全接口回归测试等;

    需要产出的文案有:

    ① 测试报告

    4.8 预发布验证管理办法

    项目系统测试和回归测试完毕后,项目进入预发布验证阶段。预发布验证阶段由测试组员针对单一需求做业务回归验证,由测试组长组织相关测试人员进行主流程回归验证和整体自由测试。如果在此过程中发现BUG,由测试负责人与项目负责人、产品经理一起确认是否需要修复,以及安排BUG修复以后的再次验证。需要注意的是,预发布环境中所有测试数据都需要由专门的测试人员进行构造,或者有产品经理提供,或者直接采用预发布环境已有的测试数据。不允许有未经部门经理审批过的写操作发生,线上的配置相关,特别是金额相关,禁止任意修改,若造成损失,由测试组员负责,包括不限于构造测试数据、执行功能测试等。测试通过后,在DMS上进行结果反馈,运维进行正式上线操作。

    明确职责:测试组长对预发布阶段的验证执行、验证监督和最后的验证结论负全责。测试组长对预发布后的最终遗留BUG记录的输出负全责。

    4.9 项目上线过程管理办法

    项目上线时,测试组长应当组织相关测试人员对项目上线后的产品进行线上验证,如果需要产品经理在线上验收,则跟踪产品经理的验收结果。最后测试组长汇总并输出验收结果。如果有需要修改的点,则重新配分修改验证任务到每个测试人员,并跟踪修改验证任务的最终完成。

    1. 线上验证结论:测试组长根据全体测试人员反馈的线上验证结果,汇总得出项目发包上线后的测试验证结论,并邮件给相关人员。

    明确职责:测试组长对项目上线时的验证执行、验证监督和最后的验证结论负全责。

    4.10 项目总结与回顾管理办法

    项目上线后,测试组长应当组长项目回顾会议,并推动整个项目组参与项目回顾会议,在会议上总结项目研发整体过程中难点、痛点、做得好的点、做得不好的点、今后可以采取的改进措施等。需要产出的文案有:

    1. 项目回顾会议总结:需要包含项目回顾会议内容、今后可采取的措施等。

    明确职责:测试组长对项目发布后的项目回顾会议的组织、推动参与、输出会议总结负责。

    4.11 线上问题跟踪管理办法

    在日常工作中,测试人员应当主动汇报各系统发生的线上问题到测试负责人。同时部门经理和测试负责人应当密切跟踪企业微信群、邮件中的线上问题反馈情况。线上发生问题时,采取逐级分解机制来做线上问题复现和确认。首先由具体团队的测试组长立即对线上问题复现任务进行分解,安排到具体的测试人员头上,由测试人员立即进行复现。确认是线上问题后,测试负责人和开发负责人一起确认修复排期,并分解修复验证任务,安排到具体的测试人员头上进行修复验证。线上问题修复后,测试负责人组织开发负责人、具体开发人员、具体测试人员进行线上问题原因分析(RCA),并邮件给相关人员。需要产出的文案:

    1. 线上问题汇总周报:测试组长根据当周线上问题汇总情况,输出线上问题汇总周报,需要包含当周所有线上问题记录、问题原因、是否已经解决、解决方案、测试遗漏原因分析、改进措施等。

    2. 重大线上事故分析报告(RCA):测试负责人根据线上问题汇总记录的分析,针对重大的线上事故,需要和测试人员一起输出重大线上事故分析报告,需要包含事故现象、事故确认时间、事故修复时间、影响的范围、事故处理人、事故根本原因、事故处理过程、改进措施等。

    明确职责:测试负责人对日常线上问题的跟踪、处理、复现任务的分解、复现后的修复检查确认、事后的汇总、当周线上问题汇总报告的输出负全责。

    五 日常行为管理办法

    5.1 内部请假管理办法

    为了保证组内正常工作秩序,避免临时请假,造成不必要的问题,请大家尽量按以下方式进行请假(紧急事件除外):

    请假3天以上包括3天需要提前一周告知;

    请假2天需要提前2天告知;

    请假1天需要提前1天告知;

    5.2 风险分析和汇报管理办法

    在日常项目研发和测试全程中,全体测试人员应当主动的、积极的、有针对性的将自己认为无确定把握的、有风险的问题点,包括不限于:工作执行风险、测试操作风险、测试进度风险、测试范围风险、测试策略风险等。汇报给测试组长或测试负责人,涵盖的范围包括不限于测试分析中不清楚的知识点、测试用例编写和执行阶段遇到的不清楚的知识点与问题点、测试操作是否会带来数据风险的问题点、交叉测试时遇到的疑似问题点、系统测试和回顾测试阶段遇到的疑似问题点、风险等。测试组长或测试负责人应当积极主动配合测试人员解决这些问题点,并给与其建议。

    明确职责:测试组员对测试负责人所分解和安排的工作任务服从负全责。测试组员对工作任务的结果正常输出负全责。测试负责人对每个测试人员进行合理的工作任务分解和安排负全责。测试负责人对最终整体任务的完成结果输出负全责。测试负责人对整个测试团队的管理和鞭策,使团队形成统一的、目标高度一致的、有优秀结果输出能力的战斗力负全责。

    5.3 日常沟通和协调管理办法

    1. 全体测试人员在项目研发和测试全程中,应当遵循积极活跃的、无歧义的、无消极情绪的、令人愉悦的沟通协调准则。

    2. 在与其他测试伙伴、开发人员、产品经理、上级leader的沟通过程中,应当无条件遵守这些准则。

    3. 测试负责人应当对全体测试人员的沟通协调过程结果进行监督和疏导,对单个沟通存在问题的测试人员进行指导和批评。

    4. 测试人员应当积极接受测试负责人的指导和批评,并限期改正自己存在的沟通协调方面的态度或能力问题。

    5. 测试负责人应当对测试人员的改正情况进行跟踪和再review,确保改进措施生效并正常执行。

    6. 如果测试人员持续一段时间内有多次出现沟通协调方面的问题,且拒不接受测试负责人的指导和批评,则将直接影响绩效考评。

    7. 全体测试人员在项目研发和测试全程中,应当做到积极协助兄弟测试团队以及测试人员解决他们面临的问题。具体形式包括不限于:协助测试任务的完成、协助测试资源的分配、协助达成项目整体结果、协助知识传承、协助测试数据构造、协助解答疑惑等。

    8. 测试负责人应当从团队层面,和其他兄弟测试团队的测试负责人一起,努力确保团队与团队之间的沟通协调问题的解决,并一起努力确保测试部门整体目标的达成。

    9. 如果测试人员和测试负责人在此过程中难以和兄弟测试团队达成一致,应当及时汇报给部门leader进行决策。当部门leader做出最终决策后,全体测试负责人和测试人员应当无条件服从安排,并努力配合完成任务。

    10. 如果在此过程中出现个人与个人之间、团队与团队之间难以沟通和配合的问题,则将影响测试组、测试小组、测试人员的绩效考评。

    11. 如果在此过程中出现个人与个人之间、团队与团队之间多次的、或者持续一贯的难以沟通和配合的问题,则部门经理有权对指定测试团队或单个测试人员进行处罚,处罚形式包括不限于:批评测试负责人或测试人员、对测试团队或个人绩效结果的影响、团队或个人在测试组内公开检讨、团队或个人在项目组内公开检讨。

    5.4 知识传承和数据沉淀管理办法

    全体测试人员在项目研发和测试全程中,应当积极主动的将所有需要沉淀和传承的数据进行持久化存档。这些数据包括不限于:业务知识、测试分析、测试用例、自动化测试脚本、SQL脚本、典型线下缺陷、线上缺陷分析、团队会议记录等。测试负责人应当随时督促团队成员执行,并随时review执行过程和结果。

    明确职责:测试组员对项目全程的知识传承的数据沉淀的输出负全责。测试负责人对团队整体的知识传承、数据沉淀的过程监督和结果review负全责。

    相关文章

      网友评论

        本文标题:制度:测试管理制度

        本文链接:https://www.haomeiwen.com/subject/uqkpfctx.html