需要谈谈的游戏测试（五）

由新浪的地址慢慢搬过来，基本都以前写的。

刚获悉一些问题，有压力。基本框架本年内肯定是没完成，每天碎片时间不超过2小时，只能依赖重写系统测试案，来试图查出隐患。（框架的协作性需要磨合，核心也是节约时间和人力成本）

先图表再归纳成文字。

产品最终是定义稳定性和健壮性，某种意义取舍还是关注的是产品的健壮性。

如何寻找现有突破，依然是82原则和28定律的通过过往的问题来探究将来可能重点方向的。

1.Create test case from bug（从缺陷创建测试用例，又要追回传统软件的一些办法）

2.通过RBT中风险概率计算因子的更进一步细化和风险影响因子计算的模型（最起码需要1-2个人）

3.半自动和自动化参与到冒烟测试中，最终目标为把1次冒烟的时间可以完成1.5次为佳。冒烟时间以用户视角和当前版本开放多少为内容基本，以更新了服务端，客户端或者配置表为时间定向，来完成。

4.至于交付方面，还需要思考下 在冒烟测试前，通过内-外部评审，然后“通过测试”，才执行冒烟测试（验证版本完整性）->交付。

冒烟测试发现了大的问题，如果不是发版本前更新出来的，那本阶段测试的质量需要测试自己打个问号？然后去优化和寻找原因。测试还是先找自己原因，然后在追寻哪里的问题。

最近几周工作压力，下面的也比较紧了。

 

原新浪地址：

http://blog.sina.com.cn/chendamao1983