一个项目带你走进产品经理的世界(8):你真的了解测试吗?

上一篇我们简要分析了研发测试,这一篇,我们来重点关注一下测试的工作内容。

测试和产品经理有什么关系?

  • 测试是最有可能发现产品问题的人,不管是功能 Bug、还是设计问题。
  • 测试前的准备工作决定了测试是否完备。或者说,测试之前,测试点的整理和测试用例的撰写决定了测试过程中是否会漏测、少测。
  • 测试过程决定了产品的质量,而产品经理需要对整个产品负责。因此,测试工作和产品经理息息相关。
  • 产品经理有时也需要参与测试过程,以保证产品的质量。之前纯银在做「一罐」的时候,他就说自己在整理测试用例。

嗯,明白了测试的重要性,那就和我一起了解测试吧。
什么是测试?
如果我说最初的产品开发并没有「测试」这个岗位,你会相信吗?哈哈,不管你信不信,这都是事实。因为最初的产品都比较简单,开发小哥哥自己就能搞定测试。慢慢地,产品越来越复杂,致使产品开发环节出现精细化分工,才导致了「专职测试」的出现。
测试这个岗位也被成为 QA(quality assurance),也就是质量保障,主要的工作是比较或者说审核开发小哥哥写的代码的实际输出和产品需求的预期输入。

测试的工作内容是什么?

Step 1:理解需求

熟悉并理解需求是测试工作得以顺利进行的基础条件。如果一个测试人员不理解需求,那么之后所有的工作都有可能存在问题。举个简单的例子,我们以计算器的 「加法」为例,看下测试的工作内容。

Step 2:测试点整理

测试点可以简单理解为需要测试的地方,或者测试的框架。测试人员需要根据需求列出测试点,计算器加法需求的测试点如下所示:
(1)输入验证

  • 小数
  • 负数
  • 最大数
  • 输入「.」

(2)清除输入项验证

  • 输入「被加数」时清除
  • 输入「加数」时清除
  • 计算完成之后清除

(3)运算结果验证

  • 整数运算
  • 小数运算
  • 负数运算

(4)边界验证

  • 最大值与最大值相加
  • 空值数值操作

Step 3:整理测试用例

(1)什么是测试用例?
测试用例「test case」是为了实施测试而向被测的产品提供的一组集合。简单来说,就是让测试有章可循的方法。没有测试用例的测试,很可能会变成随机测试,而有测试用例之后,按照测试用例测试,会让测试变得「正规」起来。
(2)怎么整理测试用例
测试用例的集合包括以下几个:

  • 用例编号 :保证唯一。可以用数字 + 字母组合,最好采用统一的规定,方便阅读和理解,管理起来也很方便,比如:可以采用「产品编号 _ 测试点名 _ 测试点子项 _ 编号」。
  • 功能模块(测试点) :可以根据需求填写功能模块或者测试点。
  • 重要程度 :重要程度或者优先级均可。用「高」、「中」、「低」代表即可。「高」代表对产品非常重要(使用频率较高或者是产品的基本功能),「低」代表可有可无、不是很重要的模块或功能。
  • 前置条件 :执行当前测试用例的前提条件,比如:测试一部手机的功能,前置条件是「手机开机」。「前置条件」可以用文字说明,也可以用测试用例编号代替。
  • 测试输入参数 :可以理解为测试过程中输入的数据,比如:测试登录时,至少需要输入「账号」和「密码」两个参数才能验证。
  • 操作步骤 :测试人员是怎样一步一步执行这个测试用例的,需要给出完整的操作步骤。有的时候,「测试输入参数」和「操作步骤」也会合并为「操作步骤」,会写成「输入 0 」。
  • 预期输出 :执行操作用例时,期望的结果是什么。这个主要是用来和实际结果相比较,以判断该测试用例是否应该通过。输出可以说明:(1)界面的变化;(2)数据库的变化;(3)相关信息的变化。
  • 备注 :除以上信息之外的其它信息。

然后,再根据测试点将以上集合进行整理,就能得到「测试用例」,如下所示:

Step 4:测试 + Bug 管理

测试过程中,难免会遇到 Bug,那为什么要叫 Bug 呢?
(1)为什么叫「Bug」?
> 据说,1945 年的某一天,一只小飞蛾钻进了计算机电路里,导致系统无法工作,一位名叫格蕾丝·赫柏的人把飞蛾拍死在工作日志上(见图),写道:就是这个 bug(虫子),害我们今天的工作无法完成——于是,bug 一词成了电脑系统程序的专业术语,形容那些系统中的缺陷或问题。
—— 来源:网络,如知晓来源,请告知。

以下内容摘自美国海军网站(Naval History & Heritage Command):
> The following image shows an organism of great historic significance, reporte