前言

测试需要基于高使用率,高复用,维护成本低的情况下去开展工作.否则一人离开一技失去对测试团队是有很大影响的.
开展非功能测试业务时需要评估工作量和定下固定维护人员.不成熟不用,开销高不用,也是很多企业关注的.
“测试是一个服务部门” 质量把控的环节,当前工作中是如何开展的?
先确定每个阶段质量目标是什么,不应该区分测试的领域,质量关注是尽可能降低风险,尽可能在交付日期内交付 1 个符合品质标准的版本,让质量不会成为制约项目时间的要素。
鄙人当前阶段主要是用以下的方法:
一)版本隔离
二)版本控制
三)质量区域
四)不同里程碑 SLA
五)测试模块(版本测试和专项测试)

开发完成度达到百分比的进度,取决项目的版本阶段。
从 base,aplha,open_beta,close_beta,RC,release
在 close_beta 来根据里程碑最终服务标准来确定是不是进行下一个阶段版本,还是 reopen_beta。
Base 阶段测试可以不介入,除非是有技术难点,比如新引擎,新技术例如之前 u3d 进入国内,我就对 unity3d 是否支持 os,杀毒软件会否误报,im 工具组合运行兼容性,稳定性都进行测试评估。Aplha 阶段尽早介入测试,在这个环节最好用的是 W 模型,对于测试人员素质需要前期的培训。
这里还是讲版本交付阶段的,主要是应对快速上线的。
在这里我之前想提及 1 个如何收敛缺陷的问题,因为这个是术 和质量保证这块是间接关系。
每个测试团队最好先好好挖掘缺陷管理工具的功能,初期花点时间培训,确保 bugOR 建议描述清晰,主题和系统模块分配正确,概率性问题描述清楚,问题发生环境正确,问题优先级合理,问题过滤器使用,热门问题和逾期问题跟踪等。

一)版本隔离

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

2.分支管理
实现分支管理的,第一步就是需要有集成编译的,hudson+svn 持续集成编译发布。要实现快速上线的基础也是这个,需要非手动编译发布的环境,测试团队也要学会使用。
项目组和测试配合过程中,如果没有分支管理,将使代码版本隔离失去意义。分支管理可以具体看看 svn merge branch,是最基础的。
如果面对海外版本和不同版本资源号差异,一定要管理好版本阶段的整包和当前版本资源号应用版本号的文档,这里属于测试内部的文档管理,也可以随时应答项目组问询版本号出什么版本的问题。

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 阶段的每个大版本进行一次。
第一步还是确保游戏引擎和载体的支持度。除了机型适配需要用到云测试,其他都可以使用 adb shell 来测试安卓的,Ios 也有其他办法。

举个页游的例子:
适配测试由 1 个人专门花 1~2 天完成更合适,而不用由不同的人平时测试项目用不用的浏览器测试没意义,反而会把一些偶发的问题,误导成因浏览器的因素,会引导程序初步判断。
适配测试在交付环境中是很重要的,尤其是最终上线时。
游戏产业的测试人员配置通常不好,但很多模块的拓展,大有大改善,小有小改善。


↙↙↙阅读原文可查看相关链接,并与作者交流