测试部门现状分析与规划.docx

测试部门现状分析与规划.docx

《测试部门现状分析与规划.docx》由会员分享，可在线阅读，更多相关《测试部门现状分析与规划.docx（10页珍藏版）》请在冰豆网上搜索。

测试部门现状分析与规划

测试部门现状分析与规划

作者

余邦利

日期

2018/8/8

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流转图：

我们测试内部提交的bug一般情况下是可以确认的，只有极少一部分的bug是需要评审的。

对于这部分的bug评审通过后就可以直接转给开发进行修复，对于没有通过的bug就要closed，我们原则上谁提交的谁关闭；外部提交的bug，首先要测试人员确认是否是bug,当无法确认的可以找外部提交的人员确认或者找多方评审确认，其他流程和测试提交bug流程一致。

2.7建立版本管理流程

根据目前我们测试反应的情况大概有这么几种：

1.测试的功能并不在提交测试的版本中；

2.测试在构建时经常失败；

3.提交给客户的版本该有的功能没有了；

等等这样一些情况吧，总之就是在版本控制方面做的不是很好，希望能够加强版本控制能实现：

提高开发和测试的效率，提高软件版本稳定性，便于追溯问题。

流程图：

1.制定合理版本发布计划，加强版本控制管理。

协商测试版本发布及发布频率：

制定版本进度计划，该计划中包括开发团队提交不同版本的计划时间、每个版本中新增功能模块列表、提交版本的要求、修复的bug列表等。

测试版本发布基础：

代码评估（代码review），版本控制的文档（标识新增或修改的功能、修复的bug、能够很方便的跟踪和监控测试版本的执行） 

测试启动条件：

功能是否开发完成、有没有进行自测（避免出现版本质量太差）、软件版本说明。

提测后注意事项：

非bugfix的修改，必须说明（如代码重构）；Bugfix涉及的代码，明确回归范围和影响范围（避免修复bug是修改共同文件，引起全局问题）。

2、强化测试准入条件 

测试启动条件：

功能是否开发完成、有没有进行自测（自测报告，避免出现版本质量太差）、软件版本说明（清楚每一次版本更新都修改了什么，会对哪些功能造成影响）。

开展冒烟测试：

保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断，如果最基本的测试都有问题则直接打回。

（开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。

）

冒烟测试的通过标准：

基本的功能和流程通过就可以。

软件提测后注意事项：

非bugfix的修改，必须周知（如重构），Bugfix涉及的代码，代码review，明确回归范围，减少质量隐患。

3、强化bug管理 

bug内容（发现版本，对应人员，发现模块，回归次数，bug关闭的版本号），可以分析不同版本和不同模块bug走势。

发现此次迭代范围外的之前遗留的bug，测试记录后，和开发及项目管理人员商讨是否解决，解决方式（代码限制OR操作说明中限制），是否占用此次迭代的开发时间。

4、版本控制文档管理工作 

版本信息、测试记录、测试结果（开发和测试活动的追溯）

5.降低测试的轮次

保证开发和测试环境的独立性：

测试环境和开发环境分开，尽量做到测试数据不会被开发人员修改。

明确测试需求：

需求功能点全部实现，如果有需求不能在规定时间完成，需要在需求阶段提出，而不是在测试阶段完善需求，从而加长了开发和测试时间，影响效率。

冒烟测试：

达到送测标准，在服务器上取下测试的版本，编译、部署后，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。

如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。

6.测试环境的维护

测试环境最好是专人维护，频繁发布新功能或者修改是不可取的。

保证版本的统一性很重要。

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

问题描述：

测试过程就是执行测试用例以及记录测试用例执行结果的过程，这一过程应该被明确记录，是测试被执行的依据。

优点：

●测试用例是否是按照计划的逐个的执行的将更加明确；

●测试是否通过的标准——测试用例的通过率统计时的重要依据；

●作为对测试人员工作监督的一个重要手段。

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

项目级测试标准

●所有项目均应该通过单元测试、集成测试、系统测试、安装测试、验收测试五个测试阶段的测试；

●功能覆盖率应达到100%；

●测试用例通过率不低于90%；

●BUG修复率不低于90%；

升级项目测试标准

●升级项目测试标准应在项目级测试标准的基础上，增加兼容性测试；

●对于上版本中的遗留问题，应该在此次升级工作中解决；

●采用对测试工作流程化管理之后，由于有了相对的技术沉淀（原有的测试用例、已知缺陷报告），仅需对升级部分编写测试用例，将会大大减少测试工作量，缩短项目周期。

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

3.1对于测试人员的培训

●测试部门根据部门人员能力情况，以及测试人员的发展方向，定期安排技能、工具和业务流程的培训等。

●测试人员应积极弥补自己在测试方面、专业知识方面的不足，积极学习先进的测试技术，提高测试水平；

●建立知识共享库，包括测试中生成的技术文档、学习资料、个人经验笔记都可以放到知识共享库分享给大家；

3.2自动化工具的引入

对于一些基本的、逻辑性不强的操作，可以使用自动化测试工具。

应该说，现在在性能测试、压力测试等方面，自动化测试有其不可替代的优势。

它可以用简单的脚本，实现大量的重复的操作。

从而通过对测试结果的分析，得出结论，这样不仅节省了大量的人力和物力，而且使测试的结果更准确。

对于一些逻辑性很强的操作，如果自动化测试不是很健全的话，不建议使用。

因为这需要比较复杂的脚本语言，不可避免的增加了由于测试脚本的缺陷所造成测试结果错误的误差。

这时就需要手动测试了。

自动化工具常用的有：

1.Web自动化测试工具：

selenium、QTP。

2.性能自动化测试工具：

loadrunner、jmeter。

3.接口自动化测试工具：

SoapUI、postman。

引入自动化测试的前提条件：

●项目周期长，需求变动不频繁 测试用例的稳定性决定了自动化测试的维护成本。

如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试。

如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。

我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

●自动化测试脚本可重复使用 如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便毫无意义。

●测试任务手工测试难以实现 比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持。

自动化测试工具是我们一个长远的目标，我们将逐步实现。