如何测试才能保障系统没有问题

先来看一个段子：

 

我的答案：无论怎么测试都不能保证系统100%没有问题

 

再看看朋友群里的讨论：

 

你看，每个人都有不同的视角，无论你的测试方案多周密，总有人会说有测试点没有覆盖到。

这说明两个问题：

1. 引入更多的人进行测试是有收益的
2. 测试用例是无穷的，你永远无法穷举所有的场景

上述两点其是有矛盾的，为了追求覆盖更多的场景，我们需要加大投入，引入更多的人，设计更多的测试用例。而第2点又说穷举测试是不可能的，也是不科学的。

 

关键点，即要扩大测试范围，又不能无限的扩大，要掌握一个合适的度。

如何掌握这个度？

看需求，根据需求确定测试范围和测试用例的优先级。

如何确定测试范围？以本段子为例，测试对象是一个酒吧，主要的功能是提供售酒和良好的饮酒环境。大概可以从以下几个方面考虑：

功能测试：提供哪些种类的酒？支持哪些类型的付款方式？是否提供点歌服务？是否提供其他类型的服务？

UI测试：门面设计，吧台设计，桌椅设计，地板设计，等等，一切看的到的东西

性能测试：每小时最多能制造多少杯啤酒？鸡尾酒呢？最大能容纳多少客户？

用户体验测试：酒吧的灯光，温度，噪音，座位的舒适度，等等，凡是你感觉不好的，都可以提出来

安全测试：防火措施，防盗措施，防暴措施等等

然后根据测试范围设计测试用例，并确定测试用例的优先级。

 

本段子中的关键点是，点炒饭是不是测试范围？产品经理说肯定是啊，这么普通的功能你们都没有测到。测试也很委屈，需求上没有说提供炒饭服务啊，我们是按照需求测试的，穷举测试又是不可能的，你总不能让我把点面条，龙虾都测试一遍吧，要是有人点海洛因呢？

所以说，理清需求很重要，想到做好产品，就把需求搞清楚。所有的事情不能想当然，要明确下来，写进需求文档。拿本段子来说，就是，产品不要想当然的以为酒吧就应该提供炒饭，测试就应该覆盖，测试也不能想当然的以为酒吧就不提供炒饭，就不去覆盖。至于酒吧为什么要卖炒饭？卖炒饭为什么不去开饭店？这类的争议实在是不想在本文讨论，当然，以我的脑回路也是想不通的，这个还是让给产品经理吧，他们的脑洞比较大（开个玩笑，产品经理不要打我）。

关于需求文档，也要说一说，如果产品经理懒惰，就要推他一下，如果是因为他本身就没想清楚，那么就让他想清楚了再写出来，如果是产品经理说不负责管理需求，那么这个产品经理可以下课了。俗话说的好，不会写需求文档的产品经理不是好的产品经理。

附带说一下测试用例的优先级，在本段子中，有些测试用例的的优先级是不高的，在人力资源有限的情况下，是可以削减的，比如把老板打一顿这种。当然，需要强调一下，优先级高不高，不是测试说了算，是还是要看产品，看需求。如果需求对安全的要求非常高，那么打老板这种测试用例有可能就会变成高优先级的测试用例了。