测试需要基于高使用率,高复用,维护成本低的情况下去开展工作.否则一人离开一技失去对测试团队是有很大影响的.
开展非功能测试业务时需要评估工作量和定下固定维护人员.不成熟不用,开销高不用,也是很多企业关注的.
“测试是一个服务部门” 质量把控的环节,当前工作中是如何开展的？
先确定每个阶段质量目标是什么，不应该区分测试的领域，质量关注是尽可能降低风险，尽可能在交付日期内交付 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 天完成更合适，而不用由不同的人平时测试项目用不用的浏览器测试没意义，反而会把一些偶发的问题，误导成因浏览器的因素，会引导程序初步判断。
适配测试在交付环境中是很重要的，尤其是最终上线时。
游戏产业的测试人员配置通常不好，但很多模块的拓展，大有大改善，小有小改善。