“If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it. ”(如果有两种选择，其中一种将导致灾难，则必定有人会作出这种选择。)

“墨菲定律”是一种心理学效应，是由爱德华·墨菲(Edward A. Murphy)提出的。 根据墨菲定律，人们主要总结出以下四点：

一、任何事都没有表面看起来那么简单

二、所有的事都会比你预计的时间长

三、会出错的事总会出错

四、如果你担心某种情况发生，那么它就更有可能发生。

墨菲定理告诉我们，事情往往会向你所想到的不好的方向发展，只要有这个可能性。这个定律在某种意义上讲，似乎是我们软件测试这个行业的诅咒。作为软件测试人员，我们的职责就是需要保障产品的质量，总希望我们测试的产品可以顺利发布并且在用户使用过程中不要出现问题。这与墨菲定律所说的所有事物都会往不好的方向发展似乎是背道而驰的。

看到这里，或许开始有测试人员感到消极了，其实没必要悲观，让我们换个角度去想想。软件测试人员应该都知道：任何软件都不是完美的，多多少少总会存在一些缺陷，作为测试就是尽可能多的将这些缺陷找出来并解决，将缺陷降低到最少，我想也没有哪个测试人员敢保证自己测试的产品百分百没有一个Bug遗漏。我们总是会有问题遗漏出的，我们需要做的就是将那些影响发布非问题测试出来，确保测试的产品达到发布质量，所谓达到发布质量并不是一个Bug都没有，相信这句话测试人员都可以理解。既然这样，墨菲定律似乎不再只是一种诅咒，我们也可以理解为一把钥匙一种警示。或许可以帮助我们测试人员发现被我们忽略但是却严重的问题。接下来，我会就我的理解分析一下，软件测试中的存在的一些墨菲定律。

一、任何事都没有表面看起来那么简单

这个问题相信不用我多讲，大部分测试人员都会深有体会。测试人员在需求Review阶段，在测试设计阶段，在测试执行阶段都会有这种感觉。

先说需求Review吧，测试人员就应该有将问题复杂化的思想，千万不要以为能够百分百理解需求文档中所讲的功能就OK了。任何问题都没有表面看起来那么简单，同理，所有功能都没有需求文档中所写到的那么简单。测试人员更多的是应该深挖出需求文档中没有写到的相关功能，并且及时确认，这样必然会给后续的测试工作节省很多时间。

举个例子：需求文档中讲解一个评分引导的功能，大都会说明这个评分引导什么时候会显示，会有什么条件，显示什么东西。但是必然不会写该功能是有服务器推送还是客户端控制，如果服务器推送那么API如何定义，有没有超时处理之类等等，需求文档主要讲解功能，并不可能写明所有细节，然而这些细节却是测试人员必须考虑到的。如果一个测试人员仅仅停留在对功能的表面的理解上，想必所测试的产品必然会Bug无数。

我们之前做过这么一个工作，分析自己提交的觉有意义的Bug。大概看了一些自己提交的一些Bug，表面上看那些Bug真心不起眼，谁都可以发现，似乎都没有任何意义，不知道如何分析。可以倘若真的较真起来，所有Bug都可以深挖的，连续问几个为什么，总会发现源头的问题。举个例子：测试一个国外APP时，发现某句话的单词少了一个字母，这必然会提交Bug，并且是一个再简单不过的文案错误。也许仅仅只是开发人员在Copy的时候少Copy了几个而已。事情真的仅仅这么简单吗?开发为什么是Copy漏掉一些，会不会是因为翻译文案的文档仅仅只是一个简单的TXT文件，就算是做成一个小有规模的Excel文档，那这个Excel文档中的所有翻译文案是否存放的毫无规律，不方便查找，这些都是有可能导致后面的问题的源头。

有人说测试的工作是在鸡蛋里面挑骨头，或许在别人眼里，我们是在鸡蛋中挑骨头，然而在测试的人眼里，这个“鸡蛋”必然比别人眼里的鸡蛋要复杂的多，甚至已经不再是一个“鸡蛋”。不要把任何一件事物看的太简单，遇事多思考这应该是作为测试人员必需的一种思维方式，倘若一直停留在事物的表面，想必对自身而言也再难进步。

二、所有的事都会比你预计的时间长

测试人员经常会遇到这样的情况：被分配执行测试用例，假如有100条用例，你自己估算每条用例最多需要一分钟，那么100条用例100分钟，然后再加上可能休息的时间20分钟。最多2个小时可以执行完这100条测试用例。可是实际上，我们花费的时间往往是超出2个小时的，并且往往会超出很多。有经验的测试人员往往都可以理解这种现象，往往分配测试任务的时候的预计时间也不会去逐条的去评估时间，更多的预计时间是根据以前的用例执行经验来算的，而且不同的人执行的时间往往也会差别很大。测试人员也往往被问到这样的问题：时间紧迫，只有一天的时间去执行测试，然后交付版本，但是还有2个功能还未开始执行测试，需要如何去安排测试。其实解决了这个问题就可以打破这一条墨菲定律的魔咒。我们的测试时间不可能无限长，因此我们总会有一个所谓的预期时间，我们所有的测试任务如果不做任何计划，完完整整的要将每一条用例执行的清清楚楚，想必时间总会是不够的。那么如何打破这个魔咒了，相信很多测试人员都知道优先级一说了，我们的测试工作不应该是毫无计划的，测试计划做好了，测试时间的问题再也不再是问题，把测试任务按照重要、紧急、难易度等等条件组合后整理优先级，然后再根据固有的时间去制定测试计划，优先完成哪些任务可以覆盖百分之多少的测试点，测试计划里都会很清楚。就算时间再压缩，相信也不怕了。测试计划有时就像考试一样，如果考试时完完全全按照题目顺序去作答，想必时间一般都是不够的，倘若按照分值和难易度去划分优先级，先做完简单并且分值大的题目，想必就算最后无法全部完成，考试分数也不会太低。

三、会出错的事总会出错

这句话似乎太消极，有种身不由己的感觉，用测试的角度去理解，好像是就算我们再细心测试，该出问题的最后还是会出问题。

这是一种理解方式，我不否认这种理解，但是又不完全赞同。我来说说我的理解吧，软件程序中的Bug本来就应该是客观存在的，同一个产品不会因为测试人员的不同导致程序中的Bug不同。既然如此，我就可以理解为，该有Bug的地方总会有Bug，就看作为测试的我们怎么去发现它。Bug的存在不是因为测试的发现才去说Bug存在，难道测试没发现这个Bug，它就不存在了吗?一个苹果有没有毒是客观存在的，不能因为没人吃它致死就说它没有毒。并且也不是非要通过吃它再死人去证明这个苹果有毒，通过观察化验或许也可以发现苹果有毒。映射到测试中来，难道Bug非要在测试中发现了才算Bug，在需求Review中，在研究功能逻辑的时候也会看出些问题来的。测试人员针对Bug的观念相信很多人都存在着误差，很多人觉得测试与Bug的关系像是父母与儿女，有测试人员才有Bug，其实测试与Bug的关系更像伯乐与千里马。

四、如果你担心某种情况发生，那么它就更有可能发生

我觉得这个算是墨菲定律中的精髓了，主要阐述了偶然性中的必然性。你偶然感觉到你发布的版本会出问题，这里面必然存在一个你也许自己都不知道的原因，否则你不会凭空的偶然感觉到，还是在你清醒的情况下。这个你所不知道的原因，可能是因为此次版本发布的Bug趋势好像不是那么正常，这一次的测试执行好像很快就完成了，反正总有一件事情和以前存在着些许不同，然而这些不同里也许就暗藏着某些即将出现的问题。如果你所有的测试计划都制定的完美，测试设计都覆盖的很全面，测试执行都都非常仔细，Bug收敛趋势正常，Bug数符合预期，所有事情都在你的掌控之中，你自然不会出现那种偶然的担心。

从需求Review到测试发布，测试人员总会敏锐的嗅到存在的风险，这种敏锐我暂时只能归为经验。我们的经验会告诉我们这次版本测试哪里可能会出现问题，测试时间是否会不够，测试发布后哪些功能可能会被吐槽等等，当我们遇到这些担心的时候，我们就没理由将这些担心放置一边了，因为只是担心，还没有进化成问题，那么我们就应该先去验证我们的担心是否会真的成为问题，如果成为问题我们该如何解决，如果不是问题，真的只是乱担心的话，那自然就最好了。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。