从零开始学产品第二篇：关于测试的一切

第一章 动手设计之前，先学会验收
 

 

先放一个镇楼图以示敬意。

其实用磨刀来描述测试，并不算特别的准确，但一时间想不到更好的比喻。

 

本章用来总述，为什么学产品要先从测试开始，以及产品和测试的关系是什么

怎么测试，学到什么程度，放在接下来的章节里。

 

第一节 关于测试的一切

在学习什么是产品之前，先了解什么叫测试。

 

一 三个环境

这是常见的三个环境，开发环境，测试环境和线上环境。

线上环境，是大家平常接触的最多的，如果关注新闻的话，可能会听说过线上事故之类的术语。

 

这个线上，就是指正式给用户提供使用的环境。

 

那，什么叫环境呢？通常指的就是服务器。

什么叫做服务器？

你现在用的电脑叫做PC，个人电脑，性能比较差

（其实，现在很多服务器都比不上PC的性能），而服务器呢，运行在云端（这个术语不算特别准确，不过无所谓了）。

 

也就是说，通常而言，都会有至少三台服务器，一台用做开发，一台用做测试，一台用做线上。

三台服务器互相之间独立，不会有任何的关联，在某些要求严格的公司，三个环境都是物理隔离的，意思就是说，互相不可通信。

 

为什么要有三台？

因为线上很慎重，没有人敢轻易把未经验证的代码发布到线上。

因此会有了一个测试环境。

 

 

为什么要有测试环境？不是在开发环境直接测试完呢？

 

两个原因：

第一，开发人员往往没有办法测试出自己写的代码的问题。

第二，测试环境通常需要一个稳定的环境，不允许随时更改和发布，而开发环境通常每天会发布四五次还要多。

这是三个环境的由来，也是测试这个岗位的工作平台。

 

所以我们先明确了，测试人员工作的边界。

第一，会在开发人员提交测试之前（有的叫提测），参加Demo，以判断是否达到提测标准。

第二，在整个测试环境，都是自己的工作平台，直到验证无误，可以提交发布到线上。

 

 

二 为什么产品经理要懂测试？

 

那么，为什么产品经理要先懂测试呢？

第一，产品经理是需求的发起者，更是验收者，不知道如何测试，就代表着不知道怎么去验收研发团队的工作。

 

第二，到了线上，产品经理更应该是直接接受用户反馈的角色，通常会收到很多建议或者是Bug。

这就需要对手里的Bug做好排期，必须了解Bug的优先级。

（Bug，可以简单理解为问题）

 

第三，产品经理通常应该决定一个版本是否可以上线，什么时候上线。

而往往这个版本会是一个带着Bug的产品。

TO BE OR NOT TO BE，一直以来都是一个问题，这也是产品经理需要懂测试的原因。

 

第四，对于新入行的产品经理而言，先学会验收别人的产品，相对简单，更能够深入理解一个功能。

同时，由测试出发，往往会更清楚的了解，自己的产品设计需要详细到什么程度，才可以交付给研发团队，有助于培养自己思维的严谨性。

 

 

三 测试都包括哪些内容？

测试的知识点不多，主要包括：

测试用例，Bug的级别，Bug的生命周期，性能测试和自动化测试，以及发布流程。

 

这些知识点，都会在接下来的文章中陆续谈到。

对于一个想要入门的产品经理而言，可能第一个要学会的：

就是抛开自己是一个正常的用户，让自己变的不正常起来。

听过那个关于测试的故事不？

 `

一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
一个测试工程师走进一家酒吧，要了一杯洗脚水
一个测试工程师走进一家酒吧，要了一杯蜥蜴
一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@
一个测试工程师走进一家酒吧，什么也没要
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿
一个测试工程师走进一
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷
一个测试工程师走进一家酒吧，要了NaN杯Null
1T测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶
1T测试工程师把酒吧拆了
一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱
一万个测试工程师在酒吧门外呼啸而过
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧
一个测试工程师跳进一家酒吧。
一个测试工程师蒙着眼睛，倒退着走进一家酒吧。
一个测试工程师走进一家酒吧，要了一杯美国啤酒，一杯德国啤酒，
     一杯比利时啤酒，一杯青岛啤酒（五厂）。
一个体重五百吨的测试工程师走进一家酒吧。
一个酒量五百吨的测试工程师走进一家酒吧。
一个酒量为零的测试工程师走进一家酒吧。
一个测试工程师走进一家酒吧，点了一杯啤酒，一边喝一边用指尖把啤酒逼出体内。
一个测试工程师来到一家酒吧门口，拿出电脑，敲了几个命令，2^32 - 1 个测试工程师走进一家酒吧。
一个测试工程师戴着墨镜，手持两把 Uzi 冲进一家酒吧，对着室内一顿扫射，然后要了一杯啤酒。
两个测试工程师走进一家酒吧。
一个测试工程师走进一家酒吧，要了一杯Nil，一杯Null和一杯None
一个名叫exception的测试工程师走进一家酒吧，被丢了出来
一个测试工程师走进酒吧，另个一师程工走也进吧酒
我走进酒吧要了一杯">_ 我盗用老板身份走进了酒吧进了后台放了一瓶我自己
的酒 我走进酒吧在吧台放了一杯' and 1=1
一个测试工程师走进一家酒吧,<>alert"要了一杯酒";</>
 

这里就是隐藏了很多边界测试，注入测试，随机测试，并发测试，合法输入测试等等。

 

如果你是一个普通用户，你只需要关注正常的流程。

如果你想做一个产品经理，从现在开始，你就要了解：

在过去，你看到的都只是冰山中的一角，而你，就是这座冰山，或者是整个世界的创造者。

 

 

四 什么叫做测试用例？

简单来说，就是有条不紊的给系统挑刺。

刚开始，会依据功能模块，列几个主要的功能点，以登录注册为例，功能点可能就是这样的。

 


![clipboard.png](/img/bVbkVKH)


 

那么在注册这个功能点之下，我们应该做哪些测试呢？

测试的前提是需要了解需求。

 

假设：

我们的需求就是用户可以通过手机号来注册，密码必须在大小写字母和数字和划线，不允许低于八位，不允许超过128位。

用户的手机会收到短信验证码，短信验证码有四位数字构成，半个小时之内都会是同一个验收码。

 

这是一个简要的需求说明，简单的描述了一些要求。

我们接下来该怎么测试？

测试要有完备性， 要能覆盖各种各样的场景，所以，开脑洞的时候到了。

 

         用户会不会只输入1位数字？
         用户会不会输入中文？
         用户会不会输入一个空号？
         用户会不会输入一个已经存在的手机号？
         用户输入了一个错误的验证码会怎么样？
         用户不输入验证码会怎么样？
         ........
         用户的如果在2个小时之后才点击注册按钮呢？
         
 

怎么样，胡思乱想的感觉是不是很不错？

可是，这些都是随意的，不严谨的测试。

比如说，当你测出来一个问题，然后研发人员修复了。

你要去验证，可是你却忘记了操作的步骤（用户注册的例子也没那么简单），怎么办？

 

最好的解决方案，就是用一个固定的模板，来把我们做过的测试记录下来，这个，就是测试用例。

 

所以，我们来看一下，对一个测试用例来说，应该拥有哪些基本的属性

（看了一下百度百科，定义太繁琐，这里给一个简化版）。

 

 

1.前置条件
2.操作步骤
3.预期结果
4.对应功能点
这就够啦。

所谓的前置条件，是因为用户的操作是有顺序的，比如说：

有要求验证码只能在1分钟之后才能继续发送，所以前置条件就应该是，1分钟之前已经点过发送验证码。

 

操作步骤就是你具体要做的事情。

预期结果，就是正常的系统，应该可以看到的结果。