测试质量管理 (一)

lsekfe

测试需要基于高使用率,高复用,维护成本低的情况下去开展工作.否则一人离开一技失去对测试团队是有很大影响的.
开展非功能测试业务时需要评估工作量和定下固定维护人员.不成熟不用,开销高不用,也是很多企业关注的.
“测试是一个服务部门”质量把控的环节,当前工作中是如何开展的？
先确定每个阶段质量目标是什么，不应该区分测试的领域，质量关注是尽可能降低风险，尽可能在交付日期内交付1个符合品质标准的版本，让质量不会成为制约项目时间的要素。
鄙人当前阶段主要是用以下的方法：
一）版本隔离
二）版本控制
三）质量区域
四）不同里程碑SLA
五）测试模块（版本测试和专项测试）
开发完成度达到百分比的进度，取决项目的版本阶段。
从base，aplha，open_beta，close_beta，RC，release
在close_beta来根据里程碑最终服务标准来确定是不是进行下一个阶段版本，还是reopen_beta。
Base阶段测试可以不介入，除非是有技术难点，比如新引擎，新技术例如之前u3d进入国内，我就对unity3d是否支持os，杀毒软件会否误报，im工具组合运行兼容性，稳定性都进行测试评估。Aplha阶段尽早介入测试，在这个环节最好用的是W模型，对于测试人员素质需要前期的培训。
这里还是讲版本交付阶段的，主要是应对快速上线的。
在这里我之前想提及1个如何收敛缺陷的问题，因为这个是术 和质量保证这块是间接关系。
每个测试团队最好先好好挖掘缺陷管理工具的功能，初期花点时间培训，确保bugOR建议描述清晰，主题和系统模块分配正确，概率性问题描述清楚，问题发生环境正确，问题优先级合理，问题过滤器使用，热门问题和逾期问题跟踪等。

一）版本隔离" style="box-sizing: border-box; font-family: 'PingFang SC', 'Hiragino Sans GB', Helvetica, Arial, 'Source Han Sans CN', Roboto, 'Heiti SC', 'Microsoft Yahei', sans-serif; line-height: 20px; color: rgb(17, 17, 17); margin-top: 20px; margin-bottom: 20px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(238, 238, 238); padding-bottom: 15px; font-size: 20px !important;">一）版本隔离

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天完成更合适，而不用由不同的人平时测试项目用不用的浏览器测试没意义，反而会把一些偶发的问题，误导成因浏览器的因素，会引导程序初步判断。
适配测试在交付环境中是很重要的，尤其是最终上线时。
游戏产业的测试人员配置通常不好，但很多模块的拓展，大有大改善，小有小改善。

作者：jiazurongyu

Germin31

Alawn

瞧瞧