如何开展测试质量管理?

如何开展测试质量管理?

前言

测试需要基于高使用率,高复用,维护成本低的情况下去开展工作.否则一人离开一技失去对测试团队是有很大影响的。

“测试是一个服务部门”质量把控的环节,当前工作中是如何开展的?

先确定每个阶段质量目标是什么，不应该区分测试的领域，质量关注是尽可能降低风险，尽可能在交付日期内交付1个符合品质标准的版本，让质量不会成为制约项目时间的要素。

开发完成度达到百分比的进度，取决项目的版本阶段。

从base，aplha，open_beta，close_beta，RC，release

在close_beta来根据里程碑最终服务标准来确定是不是进行下一个阶段版本，还是reopen_beta。

Base阶段测试可以不介入，除非是有技术难点，比如新引擎，新技术例如之前u3d进入国内，我就对unity3d是否支持os，杀毒软件会否误报，im工具组合运行兼容性，稳定性都进行测试评估。Aplha阶段尽早介入测试，在这个环节最好用的是W模型，对于测试人员素质需要前期的培训。

这里还是讲版本交付阶段的，主要是应对快速上线的。

在这里我之前想提及1个如何收敛缺陷的问题，因为这个是术和质量保证这块是间接关系。

每个测试团队最好先好好挖掘缺陷管理工具的功能，初期花点时间培训，确保bugOR建议描述清晰，主题和系统模块分配正确，概率性问题描述清楚，问题发生环境正确，问题优先级合理，问题过滤器使用，热门问题和逾期问题跟踪等。

一)版本隔离

1.单独的测试服务器

Beta后由稳定的版本后，最好日常测试中研发版本和测试版本分成2个服务器，测试服务器由测试svnmerge和服务端相关更新，这样可以规避开发版本产生的一些抛错混淆质量。

2.分支管理

实现分支管理的，第一步就是需要有集成编译的，hudson+svn持续集成编译发布。要实现快速上线的基础也是这个，需要非手动编译发布的环境，测试团队也要学会使用。

项目组和测试配合过程中，如果没有分支管理，将使代码版本隔离失去意义。分支管理可以具体看看svnmergebranch，是最基础的。

如果面对海外版本和不同版本资源号差异，一定要管理好版本阶段的整包和当前版本资源号应用版本号的文档，这里属于测试内部的文档管理，也可以随时应答项目组问询版本号出什么版本的问题。

3.研发的版本交付出口

交付唯一出口测试，项目组版本提交后，测试服务器测试通过后，最终交付到运维手上，是测试给予的包。如果包含md5验证的文件，md5码以测试给予匹配。

当然如果封版本阶段，如果还有需求变更，有需求变更单，需要多方一起确定才能补充提交是最好的。

二)版本控制

1.维护测试最小密度-测试用例

包含测试点变更到测试用例维护，变更冒烟测试文档，冒烟测试控制在40分钟左右。

冒烟测试会根据简单操作常发的点，只要任务分解法，定期维护下，不用人力充足，也是可以执行的，测试用例维护也是，用例是保证测试方法大家一致和规避漏测的。

存在冒烟测试一般是beta阶段后，版本交付前会分三轮去执行。

2.版本交付测试流程控制

一轮测试主要是关注本版本新功能的测试，做好问题备注。

二轮测试主要是把所有模块的重要case过再回归一遍。

二轮测试的多产问题的case上关注修改状态和是否需要特殊的测试。

三轮测试就是必修问题都修复后，进行冒烟测试或者快速复查，封版上线。

第三段是需要资历比较深的测试人员或者测试负责人变更下角色，确定版本发布时间和跟踪svn里提交项。

Svn里可以对单文件提取slowlog.把关配置表。

配置表相关的最好可以有检查工具,复用程序的读表和代码数据读入适用程序提供的接口.无论是程序还是策划修改,都可以察觉。

如果团队有能力做性能测试，最好做下基准测试，对比二个版本的差距，为何会有对应的性能参数变化，是否合理。

应对持续交付，需要做checklist。checklist是本期新增和优化内容，如果本期有额外产生问题没有修复的，需要滚动到下期，持续维护这份文档，文档可做为交付给项目组和外部用。

3.计划，每日汇总，测试数据采集

如果存在多部门合作的，我是会在每周分周三前和周三后列1个计划后，让所有测试人员明确本周目标和工作内容，同时如果有变更，也会对计划做出变更。实际上这个并不用人员充足的情况下都可以进行。

由测试经理对工作内容进行汇总，了解测试进度情况和阻塞项，由测试经理或者负责人去推动一些进度或者做接口工作。

每日汇总：任务完成度，测试负责人确认任务，bug新增，bug修复率，未fixed数量，是否存在阻断。阶段版本：问题top5的产生模块，测试密度(数字)，缺陷收敛曲线图，激活率，不可重现问题占比，热门问题占比。

里程碑版本：历史遗留问题数量，高发问题区域，安全区，不可必现问题，非内网版本载体问题数量，测试密度，逾期问题总计等。

其中不要轻易做一些对项目帮助不大的任务，所以任务分配时有很大意义，除非是项目空闲期进行技能提升。

修复率没有改善，可以考虑适当堆积一部分bug，这里指挂起，挂在测试人员或者测试经理身上，根据开发节奏进行。

4.交叉测试(不是很推荐)

这里想提到，交叉测试存在必要性，在现代的质量里比较陈旧，交叉测试是可存在，但不是绝对需要，优点是易培训和管理。

建议是宁可用数据化去管理缺陷密度，激活率，阻断模块，逾期修复。交叉测试用于测试中后期，后期需要给予更稳定的测试，让测试人员固定负责一些模块是必要的。在项目多和人员不充足的情况下，我们也实现了很少加班。

交叉测试带来负面效果是测试成员对团队的依赖性，而且往往是一个版本后，如果次日进行回归，除非用例调整后，如果没有，只会让团队产生疲惫。当缺陷数量无法堆积，产生杀虫剂驳论后，会因为团队里不同的人测试方式场不一样，进行交叉测试。

这里有一项破绽，我们从何得知应该需要多少的bug才需要开启回归测试或者多少bug量才是不够的，还是需要回归数据化管理。交叉测试并不会影响是否漏测，只是面对杀虫剂驳论。不过在测试团队培养里，成员对于不同项的测试进行交叉测试熟悉是必备的。

5.适配测试切入点

适配测试在测试领域里可以拆成4部分(载体兼容，分辨率显示兼容，安装、反安装，机型适配)。

除非这个引擎是团队第一次接触的，否则只需要在beta阶段的每个大版本进行一次。

第一步还是确保游戏引擎和载体的支持度。除了机型适配需要用到云测试，其他都可以使用adbshell来测试安卓的，Ios也有其他办法。

举个页游的例子：

适配测试由1个人专门花1~2天完成更合适，而不用由不同的人平时测试项目用不用的浏览器测试没意义，反而会把一些偶发的问题，误导成因浏览器的因素，会引导程序初步判断。

适配测试在交付环境中是很重要的，尤其是最终上线时。

游戏产业的测试人员配置通常不好，但很多模块的拓展，大有大改善，小有小改善。