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