测试的无奈与可为
“比方说有这样一个bug，在主角手里拿着汉堡再吃的时候同时被打中左腿和右腿，然后跑着跳进一个敞篷车，在车速超过120KM/H的时候跳车被迎面而来的垃圾车以一个很特别的角度撞到会发生一个贴图bug，这种bug应该如何测试出来呢？”很多人尤其是游戏玩家可能对这种问题比较关注，但是我自己对待这种bug的态度是：I don’t care!
如果我是这个游戏的测试人员，问题中的这个bug（我们先假设导致bug的真实条件真如问题中描述的那样），实事求是的说，我测不出来！
为啥我自己认为自己测不出来？因为我实际肯定不会测这种超复杂的还有特定条件的组合。
这就是测试的无奈，我们根本就不可能测到所有bug! 标榜0 bug的组织不过是在自欺欺人而已。
但是在TestBird看来这种无法测到所有bug的事情不能够算是测试的锅，尽管我们不背这个锅，但是我个人认为还是可以做一些事情的，对于上面那位同学的提问，我的回答如下（原回答，不打算拓展太多）
1，这种bug产生的原因跟你前面描述的一堆条件没关系，如果是贴图bug，跟吃不吃汉堡没关系。
2，测试的本质是质量保证，也就是保证整个项目的质量在可控范围内，复杂条件下的小概率bug我个人认为是可以容忍的。
3，确保正确的规则是测试通过的，及玩家可能出现的场景是测试通过的，再加上一些特殊情况，性能，压力，接口，兼容等等，就可以了。
4，没有任何测试团队会测试如你说的这种复杂条件（可能太武断了，但是，起码我经历过的数家知名游戏公司是这样的。）
5，测试的时间是受限的，没有任何项目给你无限时间去测试每种可能性。正因为如此，所以在软件测试理论中，才会出现等价类、因果图、判定表、边界值等等更加科学合理的方法。
6，控制好进度比发现某个外围bug更重要。
玩家对游戏bug和测试的理解可能与我们测试人员不同，但是我们自己要清楚测试的本质，不要被忽悠瘸了（带偏了）。
:( 上线后总是会出现杂七杂八的BUG，这个能说明测试不充分，不见得！ 现在主要是测试人员很明白测试的意义，但是负责验收的产品经理以及你的上司并不理解。这是目前存在的最大问题：不给测试人员足够的时间去进行测试，开发人员的开发进度较慢然后就挤压测试时间，最后时间不够测试，然后出了bug还是测试人员的能力不行。
哎，心累
这种事情很是无奈努力j减少bug
页:
[1]
