测试部门现状分析与规划

测试部门现状分析与规划

目录

1.引言 (3)

1.1测试部门现状 (3)

1.2编写规划目的 (3)

2当前测试工作需要改进的几个方面 (3)

2.1规范测试流程 (3)

2.2测试人员分配 (5)

2.3编写测试用例 (5)

2.4建立测试用例评审制度 (7)

2.5定义Bug等级（或类别） (7)

2.6建立Bug评审制度 (7)

2.7建立版本管理流程 (8)

2.8建立对测试过程的跟踪制度 (10)

2.9根据项目的等级对测试标准的划分 (11)

项目级测试标准 (11)

升级项目测试标准 (11)

3 建立培训机制和自动化工具引入 (11)

3.1对于测试人员的培训 (11)

3.2自动化工具的引入 (12)

1.引言

1.1测试部门现状

通过这段时间的了解，我们公司现阶段的测试组的情况如下：

●测试流程不规范；

●测试文档不健全；

●测试版本管理混乱

●测试没有建立测试用例评审机制；

●测试没有建立bug评审机制；

●测试没有建立培训机制等。

1.2编写规划目的

根据测试部门现状，以及公司领导对测试部们的重视与期望，该文档明确、测试流程、测试文档规范以及测试部门人员技能与业务的培训等方面，在后期的工作实践中由测试部门成员不断地改进优化，使得测试部门能够更好与其他部门成员做好产品的质量控制。

2当前测试工作需要改进的几个方面

2.1规范测试流程

规范的测试流程能够帮助大家提高工作效率，避免现在有的项目再重蹈覆辙，以后的项目进展才会越来越顺利，产品质量上才能得到进一步的提升。根据我们的实际业务和目前的实际情况，我们的测试流程图如下：

测试流程图

2.2测试人员分配

问题描述：

目前测试人员是一个项目一个人员，人员上是紧缺的，最近也是在加紧招聘中。

风险：

当一个人负责一个项目的测试时，首先一个人想问题不是很全面，在设计测试用例时，考虑有可能不全面，内部也不能进行用例评审；还有目前我们的测试任务也比较急，在这种情况下，测试人员也有可能测试不全面；还有当人员因为一些外部因素请假时，那项目都无法进行下去，所以目前这种状态其实风险还是很多的。

措施：

测试工作安排方面采用2人组合方式进行。也就是说按照咱公司的人员编制，一个项目有两个人员负责测试，具体实现时可以采用：专职为主、兼职为辅和交叉测试的策略。在这样的状态下就可以规避以上这些风险。

2.3编写测试用例

问题描述：

测试用例作为软件测试的重要手段，测试质量的重要依据，应该占用相当长的时间，但是，目前我们是在没有测试用例的条件下进行盲目的测试。

风险：

这样的测试虽然也可以发现一些问题，但是，这些问题是根据测试人员的测试经验和专业经验才能发现的。并且，在说明软件质量是如何得到保证时，缺乏有力的依据，在这样的测试下，我们的功能测试覆盖率根本无据可查，更可以认为这样的测试是无效的测试。

措施：

测试用例编写原则及规范

1.统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，

提高编写的测试用例的可读性，可执行性、合理性。

2.测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、

PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。

3.编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

用例颗粒度原则：

测试用例是执行的最小实体，用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：

1.一个功能正常流程，编写一个测试用例；

2.一个功能中多个异常流程，应分开编写多个测试用例；

3.同一功能不同入口，可合并编写一个测试用例；

4.同一功能不同数据准备，应分开编写多个测试用例；

5.同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

用例编写要求规范：

1.具有清晰名称、前提条件、操作步骤、期望结果的；

2.可被他人理解的；

3.可被他人执行的；

具体分项要求如下：

1.用例名称

2.前置条件

3.重现步骤

用例维护规范：

测试用例编写完成后，应对测试用例进行持续的维护：

1.新项目需求变更，应及时对测试用例进行修改；

2.维护期项目，可根据项目组情况周期对用例进行维护；

3.所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例。

2.4建立测试用例评审制度

由于各方面原因的局限性，测试用例会有一定的缺陷。所以，让更多的人参与进来，对测试用例进行完善，以提高测试标准。

2.5定义Bug等级（或类别）

问题描述：

对Bug的等级（严重、一般、轻微）进行明确的划分。

制定某些等级或类别的错误是必须修改的相关制度（其实我更偏向于只要是Bug就必须修改，只不过是放在此次修改还是在下版本中修改的问题）。

优点：

有利于Bug进行管理，便于相关人员对修改工作日程安排做出正确的计划。

2.6建立Bug评审制度

问题描述：

对于测试部门测试出来的有争议问题，应该经过Bug评审，首先要确定是否属于Bug，然后再确定应该由哪一个部门或者说研发人员对其进行修改以及修改的时间，对应的测试人员要及时进行回归测试等。咱们还有个bug 来源是外部的，包括业务方、实施人员等，他们会提交一些bug。但他们往往因为对于系统的不了解或者说对产品的设计不是很熟悉的情况下，有时候会提交问题并不是bug。

参与人员：

项目组中涉及的各个部门相关人员或负责人，包括产品、研发、测试等人员。

Bug流转图：