QC要有随时随地质疑的意识

牛亦喜

我觉着吧，做QC，思维方式里要有随时质疑的意识。不能因为策划、或程序、或其它QC的说法，而减少了对质量的控制。



比较明显的就是，要把“预期输出”建立在最可靠的基础之上。



假设一个规则：每个士兵基础攻击力为9（配置表），士兵数为10（手工操作获得），总攻击为90（设计规则是总攻击=每个士兵的基础攻击力*士兵数）。



a同学测试总攻击计算规则，当时**面显示总攻击，他的预期输出只能与程序协商，加一个print来查看。

后来有界面了，b同学测试界面显示的总攻击。b同学的“预期输出”应该用规则本身的计算值，而最好不要用print值。



这只是举例，而且例子是最简单的，因为规则简单。如果规则复杂，预期输出的不可靠，会导致测试的不可靠。



b同学要信任a同学的测试可靠度，拿a已有的测试结果做预期输出的基础。但这个过程不单单是b和a的信任这么简单，而是有可能设计规则、程序实现都会有改变，这一切都是质量保证的风险因素。尤其是当b和a的测试是并行的，或者间隔版本很大时。


本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/qiaoanlu/archive/2010/02/05/5290454.aspx

maxwell12

赞同
没看到实际情况的时候我怀疑一切.可能都养成职业病了，看待其他事情也是这样.如果有一些输出值让我放心,我到是会踏实一点，要不不做良性判断。
如果是lua脚本写的副本,掉落,数据表,我都先检查脚本再检查实际客户端输出
如果是程序做的系统,我确实做不了白盒,流程还能明白,但命令,函数现在都看不懂了.我就从简单输入开始检查客户端输出,然后逐步到复杂输入条件的输出.就这样还可能在哪里潜伏着bug。因为总也做不到100%的代码覆盖。即使是微软、暴雪他们出品的精品也会有bug出现的。虽然作为测试，在已经出品的产品中发现bug是件很不爽的事，但这个事还没有解决的办法。
我信任我的同事，都是一起战斗的兄弟。但他们做出来的东西我还是要检查，这是我的工作职责。我就是干这个的，吃这碗饭的。