身为测试工程师的我们，主要工作职责就是运用各种手段来保证产品的质量。
每一位测试人，都希望经过测试验证过的产品，在发布后没有任何问题发生。
为了达成这个目标，测试的工作会贯穿整个产品研发过程，参与包括产品需求讲解、开发设计讲解、软件测试、上线发布等多个环节的工作；
在需求阶段，参与需求讲解会，确认产品需求文档中每个细节的预期结果；
在测试阶段，我们会进行功能、性能、稳定性等多种类型的测试验证，保证每个实际结果与预期结果都是一致的；针对UI和交互，我们关注每个文案以及用户操作路径，是否与需求文档中的描述是一样的；
在版本发布阶段，会制定详细的验证策略，保证发布过程中，每项功能都符合预期。
经过这样详细的测试验证，来保证产品研发过程中每个环节的质量，因此我们对发布出去的产品质量信心满满。
然而总有事与愿违的事情发生。例如在版本发布后，经常会收到用户的反馈，说在某某环境下，某某功能失效了、卡顿了、崩溃了等等。
在针对大量线上用户反馈的情况进行分析后发现，以下这三类问题会经常出现：
用户的操作路径没有被测试用例覆盖到。例如，在进行应用程序覆盖安装的同时，触发了应用程序的自升级，进而导致覆盖安装失败；
用户系统环境中的某个程序与我们发布的产品不兼容。例如，在某个应用程序中使用搜狗输入法，导致应用程序某个功能无法使用，或者出现卡死、崩溃等；
交互设计较复杂或者不符合用户使用习惯，导致用户不知道该如何操作。例如，应用程序弹出的通知界面中，没有“关闭按钮”或“不再提醒”这种选项，影响到了用户的使用。
上述的三类问题都有一个共性，那就是“不确定性”。我们不知道用户机器上都安装了哪些程序，我们不知道用户都会怎么使用我们的产品，我们不知道用户是否能够接受目前的交互设计。
身为测试的我们，面对以上这三类问题，有时会感觉到些许的无奈（用户怎么还能这么操作？），那么我们该如何解决呢？
在这里和大家分享一个有效的方法：MECE（Mutually Exclusive Collectively Exhaustive，无遗漏无重复）法则。使用MECE法则，能够防止我们在测试方面出现遗漏或重复，能够做到把握产品质量的整体。一旦把握了整体，你就不会被出乎意料的情况吓倒。在使用MECE法则把握整体后，即可确立测试工作开展的优先顺序，同时也可以制定出版本发布的质量标准。
那么MECE法则该如何应用到测试工作中，解决测试过程中的“不确定性”呢？诀窍就是“逆向思维”。
1. “要消除死角，就不能仅仅考虑正面因素，负面因素也必须考虑到”
在测试过程中，既要保证产品需求文档明确提到的内容得到准确的验证，同时也要积极的思考需求文档中没有提到的内容也可以被充分的验证。这些没有被提到的内容，测试可以大胆的思考，大胆的验证。当测试针对所有能够想象到的场景进行了充分验证，都没有发现问题时，那就说明产品的各项功能是完整可用的。
在制定产品测试策略时，需要考虑的测试类型有很多，包括功能、性能、稳定性、易用性、安全性、合理性等等。如果能够针对所有的测试类型进行完整地验证，那必然是好的，但实际项目上是没有足够的时间允许测试开展这么完整的测试工作的。那么测试该如何选取呢？这时可以反过来思考一下。如果不进行某一类型的测试会发生什么。思考完成后，相信你就不会去做那些回报率较低的工作了。
在编写测试用例或者执行测试用例的时候，可以将自己的角色设定为实际的目标用户，站在用户的角度思考，他们会如何使用我们的产品。将所想到的操作路径按照时间轴的方式描述出来。通过这样的方式，尽可能多的描述用户操作路径，进而做到更多的场景覆盖。
在针对产品需求文档、交互设计等方面进行充分“确定性”的验证后，可以使用以上三个方法，有效的帮助我们降低“不确定性”所带来的质量风险，进而更好的提高产品质量。
本文分享自微信公众号 - 搜狗测试（SogouQA）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
