测试流程

点击这里,边看视频讲解,边学习以下内容

为什么需要专门的测试团队

在IT行业,为什么现在测试的职位数量 仅次于开发,成为第二大就业岗位?

很多公司,尤其是小公司,都没有测试人员,不一样开发软件吗?

所以会有这样的困惑,为什么需要独立的测试团队?开发人员自己测测不就行了吗?

因为:

  • 人力不够

    很多软件产品已经比较复杂,为了保证系统在各种情况下都能正常工作,测试的工作量非常大。

    开发人员本身的开发工作已经够呛,实在没有精力去做这样大量的测试工作。

  • 立场问题

    开发人员 对待自己的产品就像看自己的孩子,怎么看都是美好的。有时候明显的问题都看不见。 甚至为了某些原因,明知有问题(可能是难以解决的问题),也不愿提出来。

    需要独立的测试团队 从比较客观角度看待产品。

所以,公司要保证产品的质量,就必须有独立的测试团队。

测试人员要做哪些事?

有些人以为测试就是像用户一样使用 产品 ,发现有问题提交报告就行了。

为了保证尽可能发现系统存在的错误(英文叫bug),测试在使用(测试)产品前后通常有很多的工作要做。

在产品 调研、需求分析、设计、开发、上线运营 各个阶段,测试都有相应的事情(活动)要做。

那么,我们就必须明白上述各阶段测试人员该做什么。

要明白测试人员该做什么,你首先要明白 这些阶段 的 总体目标。 测试只是其中的一部分工作,为了达到总体目标而服务的。

那么我们接下来就 了解一下各阶段整个团队要做的事,和测试人员要做的事。

调研阶段

这个阶段通常是老板 和 产品经理做的事情,就是调研 想做的产品

  • 大体有哪些功能?

  • 到底有没有价值?

  • 到底能不能做?

比如要做一个 K12在线教育 系统, 大体实现哪些功能?

比如 :

要做直播 授课功能吗?要做 录播课程功能吗?要做学生考试功能吗?

做这些 国家政策允许吗?

如果允许,准备从哪里找优质老师提供 课程资源、题目资源?

假如上面问题都能解决,都可以做,那么还有

要不要做?比如已经有行业垄断的巨头(像腾讯垄断IM这样的),还有做的必要吗?

商业(盈利) 模式是什么?

就是 怎么寻找客户(学生、老师、家长),怎么转化客户,怎么收费、怎么

如果要做,大概要多少人力、财力的投入

等等。。

调研阶段的重要性就像 打仗前的决策阶段,这个仗要不要打,胜算如何。

通常由 最高领导(老板或者产品部门老大) 和 参谋部 (产品团队+研发领导团队) 讨论决定。

如果调研有问题,做出来的产品 根本卖不出去,甚至违背了国家法律,根本无法运营。

这个阶段,测试人员通常没有什么要做的事情。即使有,通常也就是测试部门最高领导参与一下。

很多创业公司,这时候,往往团队里面还没有测试人员。

需求分析阶段

点击这里,边看视频讲解,边学习以下内容

如果调研阶段决定产品要做,接下来就是确定产品的功能。

调研阶段确定产品的 大体功能 ,而需求分析阶段则是确定 具体的功能

这个阶段的工作通常是 产品经理开发经理 讨论制定需求细节, 开发人员 和测试人员参与评审。

比如要做一个 K12在线教育 系统, 需要具体实现哪些具体功能,和功能的细节需求。

功能要一一列出来,比如

  • 直播课程

  • 录播课程

  • 学生、老师 注册

  • 学生考试

  • 每年学生升级

每个功能点要不断 细化 ,直到可以给开发人员没有什么疑问,可以着手开发工作

比如,学生考试功能:

考试功能包括哪些子功能?

创建试卷、学生答题、批改方式、结果呈现、数据分析


每个子功能还要继续细化,比如

试卷要包含多少题?

题目是系统自动选择还是人工挑选?

系统自动选择题目的时候,注意根据哪些要素?

题型应该怎么分配? 选择、填空、问答?

考完,是全自动批改吗?

这些细节都要考虑,甚至要画出界面原型图方便大家理解。


需求阶段 也非常重要,是后面设计阶段的基础。

千万不要小看需求阶段的工作量和工作难度,非常考验产品团队的能力。

很多不成熟的团队,需求分析还没有做好,就去开发了,把各种问题留在了开发阶段。导致开发出来的功能 不能用,重新开发。浪费了大量的时间。

这个阶段,产品经理和开发领导 应该逐步的推出 需求文档。

多次推出改进、完善版。

而且如果系统功能点很多,往往就一个功能点就需要出一个需求文档,需求文档会有好多份。

有个总体介绍文档,各个大的功能点 单独再出需求文档。


这个阶段,测试人员 需要 做如下事情:

  • 评审需求文档

    通过评审了解需求,甚至参与需求分析讨论,看看 需求有没有错误、矛盾、遗漏的地方。

  • 整理测试需求

    什么是整理测试需求?

    就是通过需求文档的评审分析(产品、开发人员往往写的比较乱,不全面), 从测试的角度 进行 需求和场景的分类,

    其实这是 更加 具体的、有条理的需求文档。

    相当于测试用例的提纲,为后续编写测试用例 准备 测试需求,

这个阶段,建议不用写测试用例,因为后续产品的设计、编码阶段,很可能会对产品需求进行返工修改,此时就写测试用例,很可能是无效的。

而且此时,最终产品细节(包括界面、接口)往往都是没有的,也没有办法写测试用例。

设计阶段

点击这里,边看视频讲解,边学习以下内容

需求分析好了,接下来的重要任务,就是开发人员设计系统了,

开发工程师不是一上来就编码的。

需求阶段只是做了 高层需求的设计,完成这个高层需求,还需要开发人员进行 系统设计、子系统设计、接口设计等。

比如,要开发 web网站,需要开发人员根据需求文档,设计 系统的 前端 和后端,前端和 后端 的 信息交互接口 等。

通常也要出设计文档,这些是开发编码的依据。


这个阶段,测试人员根据开发人员的设计文档, 和开发人员多交流,得知产品的细节功能。

包括系统的 功能细节、 界面原型,这些是写测试用例的依据。


有条件的,甚至应该了解 系统的内部设计,比如系统由哪些子系统组成,子系统之间的接口,如何通讯。

这对写出更有针对性的测试用例非常有帮助。

流程比较细致的企业,测试人员也会参与设计文档的评审,甚至代码评审。


搞清楚产品设计细节(甚至一部分实现细节)后,测试团队就应该制定 写测试计划 ,编写 测试用例

测试计划要完成:

  • 评估工作量和人力配备,风险评估,从而确定测试目标

  • 制定测试任务(包括指定测试协调人、编写用例、学习和开发测试工具、准备环境),并且分派到人员

  • 其他为了实现测试目标和任务确定必要的测试活动。

这些通常都是测试部门领导干的事情,不是本文的重点。


分派给测试人员的任务,其中最重要的就是 编写测试用例。

编写测试用例有很多方法,个人觉得最重要的就是

  • 判定表(因素组合法)

  • 边界值法

  • 错误猜测法

白月黑羽实战班学习会有针对性的练习

开发阶段

点击这里,边看视频讲解,边学习以下内容

开发阶段 当然 就是 开发工程师(码农们)加班加点、没日没夜 的根据设计开发了。

这时,测试工程师不要闲着,有些事情可以做

  1. 评审测试用例
  2. 准备测试工具、学习使用测试工具
  3. 准备测试环境
  4. 和开发人员保持沟通,因为开发过程中 开发人员随时可能推翻原来的设计,修改功能,你要相应改变测试用例。

发布测试版本,测试开始

点击这里,边看视频讲解,边学习以下内容

开发人员辛辛苦苦,终于发布了测试版本,测试人员的主要工作,当然就是 根据前面写的 测试用例 进行测试了。


在正式测试前,往往会有一个 冒烟测试

冒烟测试 是 挑选针对 最基本的功能点 的测试用例, 进行的测试。 如果这些最基本的功能点都有问题,测试不通过, 那么后续的大量测试用例 都是没法测试的。 就会立即打回测试版本,要求开放人员改正后,再进行测试。

如果通过了冒烟测试,就可以进入正式的测试环节。


测试过程中发现的问题(bug) 提交到 问题跟踪系统,比如:BugZilla、禅道、Redmine、JIRA 之类,开发人员根据优先级和严重级别 决定下个版本修正哪些bug。


测试过程中,测试人员往往会发现实际的产品实现 和 需求设计文档(或者从开发人员口头了解的)功能不符, 当然也就和你写的测试用例不符。

这时候就要和开发人员确认,要求修改对应文档。测试人员也要相应更新测试用例。


在测试过程中,测试出产品问题后, 有时开发人员会认为这不是bug。

比如登录时,用户输入错误密码,测试人员认为系统的提示信息非常不显眼。

但是,开发人员他可能就认为已经提示很清楚了。

所以争执就来了,这就是QA和开发人员最容易产生冲突的地方。有打架的。

产品的需求设计文档不可能详细到每处设计的非常清楚,有原型图(没有那么多的时间),QA写测试用例也不可能每处细节都描述的非常清楚(也没有那么多时间)。

上面的情况,设计文档和 测试用例可能就简单这样写了一句: 密码出错时,提示错误。

那么什么依据来评判上面的是否算问题,需要开发修改呢?

这时,就得有权威决策人(老板、产品经理?),不一致的意见,最终由他来拍板。

如果没有这样的决策人,必定会出现吵架的问题。

所以成熟团队,一定要有这样的角色,以免损伤 团队和气 和士气。


测试结束后,通常会有一个 测试报告 ,给出这次测试的结果的描述,比如:

  • 测试覆盖的功能点有哪些

  • 总共多少测试用例,通过了多少,不通过的有多少。

  • 发现问题,哪些是特别严重的


测试人员往往会在测试过程中发现测试用例有不足的地方,需要及时改进。

回归测试

点击这里,边看视频讲解,边学习以下内容

当一轮测试结束后,会发现一批bug,当然开发人员需要修改这些bug。

并不是所有的bug都会立刻修改,根据发现bug的严重程度和出现几率,开发人员确定优先级,修复一批bug。

修改后会发布一个新的测试版本。

测试人员需要根据这个新的测试版本进行测试,这次测试有两个目的

  • 验证开发工程师修复的bug正确修复了
  • 确保在修复的过程总没有引入其他bug

要确保第二点,就需要在大量的测试用例中挑选 这次修复可能引发问题的地方。

这个特别考验测试人员的经验。而且往往最可靠的方法就是所有用例全部重测,工作量很大,可以通过自动化测试来节省人力资源(自动化测试开发的投入本身也很大,这是另外一个话题)


新版本也可能不只修复bug,可能会添加一些前面没有实现的功能点。

如果是这样,测试的目标就不只是 回归测试,还要包括新功能点的测试。

发布正式版本

经过N次内部版本的发布、测试后,产品实现的功能越来越多,并且通常bug会越来越少。

到了某个版本,经过评估,如果实现的功能足够,并剩余的bug,不影响产品发布给客户,就会作为正式版本发布给客户使用。

功能添加,产品迭代

虽然产品已经正式发布给客户使用了。

但是产品可能还有后续的需求(可能来自客户,也可能来自产品团队),需要在目前版本的基础上继续开发。

这时就会重复前面 从 需求调研阶段 到 发布正式版本阶段的 流程。

引入自动化测试

一个复杂的产品,要经过很多轮的回归测试,才能最终发布。

每轮回归都有大量的测试用例 需要重测,防止修复bug的过程中引入新的bug。

这样的反复测试,非常耗费测试工程师的精力。

一个典型的解决方法,就是使用自动化测试系统,代替人工测试。

有经验的测试经理会在合适的时机,组建自动化团队(从市场招聘人员或者内部转入人员),开发自动化系统。

并且合理的分批次挑选用例,进行自动化,从而有效的提高测试效率。

挑选哪些用例自动化呢?可以考虑如下因素:

  • 需要反复执行的测试用例
  • 对应功能点稳定
  • 容易自动化

下一页