教你三招，揪出你产品中的BUG

在前面，我们已经了解到了几类BUG对我们产品造成的危害。

于是有人就会问，那我们要怎么去预防呢？

小编不得不很遗憾地告诉大家，无法预防！

BUG之所以被叫做“BUG”，就是因为它的出现，不会是我们能预料得到的。

你会预料到你家厨房什么时候会爬出一只蟑螂吗？

BUG的产生本身就是意料之外的问题，但幸运的是，我们可以在后面把它找出来！这项工作就叫“测试”。

今天我们就来说说可以通过哪些测试方法把BUG揪出来。

人工测试

适用条件：

开发工时≤600人/天

兼容性要求不高

用户群体小

各个功能点能正常使用

逻辑流程能正常运转

这是最传统的一种方式，由人工去对产品进行反复的操作，检查每一个细节，尽可能多的找出BUG，再交由开发人员解决。

这种测试方法其实在产品原型设计好之后，就要由测试人员开始着手准备了。

产品原型设计好之后，测试人员会根据原型准备出《测试用例》。

它包含测试人员根据产品原型所预想到的针对每一个功能点所执行的操作的描述。

测试人员会在《测试用例》中事先写好这些操作所应该产生的结果，等到开发人员完成了这些功能的开发后，测试人员就会根据这些事先写好的操作来测试，记录出每一个实际结果。

如果实际结果与《测试用例》中的不符，那就表示出现了BUG。

就比如说我在《测试用例》中表示：登录界面输入账号但没有输入密码时，点击登录按钮应该弹出提示“请输入密码”。

但是在开发人员做好登录功能后，我输入账号不输入密码，点击登录却没有任何提示，那么这就是BUG。

那么接下来，我就要通知负责登录功能的开发人员来修改这个BUG了。

这里还要提醒大家，《测试用例》中所写出的操作，不仅仅是按照产品原型所设计的正常操作。

而是要写出在多种不同条件下去执行操作。

比如说一个登录按钮，正常的操作是：

输入账号输入密码点击登录按钮。

而测试人员在写下这一个操作的之外，还要写出：

输入账号，却输错了密码会得出什么结果，会有什么提示；

输入的账号不存在，应该会有什么结果，会有什么提示；

输入的账号格式错了（只能输数字却输入了字母），会有什么结果，会有什么提示；

······

如此一来，测试人员对整个项目所编写出的《测试用例》，数量单位通常都是“本”。

这也是为什么要从产品原型设计出来后就要开始编写，因为它内容多，很耗时间。

也因此，它仅适用于只要求各项功能可正常使用，规模不大的小型项目。

自动化测试

适用条件：

开发工时＞600人/天

兼容性要求高

用户群体较大

各个功能点能正常使用

逻辑流程能正常运转

我们刚才说人工测试仅适用于小型项目，那如果项目较大呢？

如果小编我是测试人员，当产品项目比较大，功能点很多的时候，我可能连写《测试用例》都写不完。

或者写完了，还要花费大量的时间去一一执行这些操作并记录结果。

如此一来，使用人工测试效率明显太低！

那么此时我就会想要让我的机器代替我去测试，并记录数据。这就是自动化测试。

这种方式的方便之处是在于为测试人员节省了测试时间，只需要花费时间在工具中编写好测试脚本。

那是不是说我们连《测试用例》都不用写了呢？当然不是。

脚本是告诉你的机器去模拟不同的方式去操作这个产品，要产生什么结果才是正确的。

就相当于把刚才我们说的登录功能的那几个不同的情况通过脚本告诉机器。

这就相当于写出了《测试用例》，只不过我们再也不用写成一个本子那么多了。

将这些操作全部写成脚本，交给机器去执行，当发现BUG的时候，机器会通过某种方式反馈给测试人员，比如生成日志文件。

然后测试人员根据反馈出来的信息，找到相应的开发人员，去进行处理。

很显然，单从时间上，自动化测试省去了测试时间，比传统的人工测试效率至少高出一半。

那么能用人工完成的测试可不可以用自动化来完成呢？当然可以，但是从成本上考虑，这可能就不太划算。

也就是说，当产品需要测试的功能点比较多，而且还要考虑兼容性问题的话，采用自动化测试才是最合适的。

压力测试

适用条件：

兼容性要高

用户群体非常大

各个功能点能完美运行

逻辑流程能非常稳定

对硬件性能有所要求

当我们产品必须考虑硬件设备的性能的时候，比如说服务器承载量、并发量上限，依此我们可以知道需不需要更换硬件设备。

此时我们就要采取针对性更强、效率更高的测试方式，即压力测试。

拿产品服务器的承载量来说，就好比吹一个气球，当气球被吹到最大的时候，再吹就会爆掉。

产品也是一样，如果它的服务器的访问量超过了承载量上限，会崩溃。

我们通常在做压力测试的时候，其实和刚才说的那种自动化的工具有些类似。

我们同样要编辑出脚本，告诉机器模拟同一时间多人一起打开我们的产品，并且分阶段地增加这个访问人数。

然后开始执行，直到产品页面出现报错，我们就会知道我产品服务器的承载量上限。

当然啦，也不需要非得把产品整卡死，我们的产品应该在设计之初就要考虑到我们的目标用户有多少，服务器最高需要承受多大的访问量。

比如说我们产品的目标用户最多能有一百人，一天之内最多也就100人同时访问。

那么只需要测试出从1到100人同时访问时服务器是不会崩溃就好了。

显然，这种测试方式侧重于对硬件设备性能的测试，针对性强。

那么当我们的项目并不需要考虑网络、服务器等硬件性能要求的时候，也就不需要压力测试了。

其实对于产品的测试，不得不说，用哪种方式你都不可能把问题全部解决，因为我们不可能真正做到完美无缺。

只是出于效率以及成本上考虑，我们需要用一个最适合我们产品项目的测试方式，来尽可能多的找出BUG，让我们的产品更符合客户要求。

我记得曾在知乎上看到有人说：

测试不是追求零缺陷、软件质量无限好。而是让产品更加符合需求。

客户要的不一定是一个完美无瑕的产品，一定是要一个最符合自己要求的产品。

既然最后咱们说到了成本，OK！下周我们就来专门聊聊我们的项目成本，通常都是如何组成的吧。

想要了解更多的知识干货

那就关注

程序范儿 Style