基本的测试流程标准

T.H

需求分析
      ↓
根据需求搭建测试环境/配置服务器与客户端资源/编写测试工具(为自动化准备)
      ↓
制定测试计划,需要注意分析测试过程可能出现的情况和处理方法(风险分析)
      ↓
根据测试计划编写测试用例(基本功能检查),这里说明一下为什么没白盒的,因为程序那边会在内部把集成和单元测试消化掉,程序在完成了代码的调试和检查后合成Build,再给测试部门.
      ↓
冒烟测试(版本基础功能粗略检查,主要是检查这个版本是否可测试,冒烟是自动化的,时间不超过3小时,注意冒烟并不是把所有功能都测一次,主要是检查版本中有没有无法安装、当机现象太严重导致无法测试进行、大部分功能根本没做、压力测试中机器人的登陆要求是否达到压力测试标准)
      ↓
冒烟测试通过
      ↓
执行测试(基础功能检查)同时自动化启动,自动化方面的主要看测试覆盖范围是否需要进行压力和性能测试
      ↓
进行Ad Hoc测试(异常测试、极端行为,主要是在特殊操作下发生的问题)
      ↓
提交BUG给开发
      ↓
开发返回BUG后进行回归测试
      ↓
完成里程碑内基础功能检查发现BUG的回归测试后,再检查AdHoc测试发现的BUG也是否修复,一般来说程序会优先修复基础功能的错误和设计上的错误,对于Ad Hoc发现的BUG会延迟修复,这个看你们项目经理是怎么制定的。

--------------------------------------------------------------------------------------------------------------
现在的项目测试中能做到以上流程的已属不易了
大部分公司都免去去测试需求分析，测试计划，用例.
绝大多数的测试都是在开发的后期才参与到项目的中的对于整个制作流程，制作形式都缺乏一定的熟悉度这是无形中加大了测试的难度
此流程还望各位有识之士赐教 [em6]

funcman

你觉得游戏开发这种创造性的工作，能生搬硬套这样死板的工序么？

fx19880207

这是软件测试吧？

T.H

首先这不是软件测试流程~软测的流程比这个繁琐
其次如果游戏测试都随便制定流程的话那测试说白了也就是打杂没什么盼头
不要以开发是创造性这种可笑的理由来指责别人的总结谢谢

lhk243044

基本流程没什么问题，但自动化测试现在没有几个公司可以做，主要是游戏软件内容，相比常规软件较复杂。

现在一般公司采用V模型测试流程，测试时间较落后，并没有与整个研发团队同步，造成很多问题在程序做好后才发现，
大大延长了研发时间。比较好的测试模型用的比较少，W模型测试流程可以帮助研发团队提前发现问题，但这个测试体系得需要公司其他三个部门支持，一般很难实现，国内也就几个公司建立了这类体系。具体的可以在网上查下，或是看下软件测试手册。。。

funcman

光看到你那啥自动化测试，就觉得这流程是拍脑袋想出来的。
游戏开发无法用这些死板的东西，当然是因为游戏开发是创造性的。任何团队都不可能把之前做的再来一遍，总是在追求新东西，大量不可知而需要探索的内容。开发起来，哪有多少正常的形式。流程如果不是一眼就看完，那这个流程肯定会拖慢项目进度。
提高游戏稳定性，真正能起到效果的，开发过程中的单元测试，游戏测试组的手工测试，辅助的东西包括自制的压力测试，运行监控程序等。
现实的问题是程序员由于各种原因，测试工作展不开；手工测试没那么大本钱投入硬件和人力。
没有那家厂商愿意把低质的东西放出去，如果搞套理论就把问题解决了，他们不是傻子看不到。

khan

找到个旧文档，本来以为文档都掉光了的。

“测试和发布更新流程的完善化与风险应对策略”

[点击右键另存为]

如今对文档的一点看法：每个公司或团队或单位情况其实不太一样。具体情况具体分析。

T.H

funcman: Re:基本的测试流程标准

光看到你那啥自动化测试，就觉得这流程是拍脑袋想出来的。
游戏开发无法用这些死板的东西，当然是因为游戏...

那在你看来测试的作用就是接到需求手工测试然后反馈或测试通过对吧
何以见得自动化就是死板或者拍脑袋想出来的呢？

funcman

好吧，你具体说说怎么个自动化~

T.H

最简单的自动化~使用按键精灵即可完成你重复的操作次数已验证某些几率性问题
疑惑这通过截包手段来验证重复的发包对于服务器的负载和干扰正常的消息包序列
别都把自动化想的是什么什么都不需要人为操作完全脚本或程序完成~即使是软测也没有完全自动化吧 [em18]