软件测试基础再理解

摘要:从做软件测试开始,我正式走进了互联网行业,在本文里我将会使用 5W1H 法则来阐述我对软件测试基础概念的一些理解,相信这是一个不错的开始。

What—什么是软件测试?

如果要问我什么是软件测试,我想先说说什么是软件,就像我们想要用手机打电话给别人,必须先要知道手机是什么。
软件测试的主体对象是软件,而软件并不仅仅是我们日常生活中所说的某某应用,某某程序。相信了解研发的朋友肯定知道,IT 类的研发主要包括硬件研发和软件研发,那么这里所说的软件就八九不离十了,因为软件是指计算机系统中与硬件相互依存的另一部分,它是程序、数据、文档的完整集合。

主要两点:

1、与硬件相互依存,没有脱离硬件而存在的软件,就比如一个操作系统也是一个软件,但是它是需要在我们的计算机硬件上的才能运行发挥它的功能的。
2、软件=程序+数据+文档。

这么看来,软件测试就不是简单只是针对某个应用或某个程序来说了,而是对整个软件系统而言的,其中数据可以理解为数据库实例和程序运行需要的参数,文档可以理解为需求文档,设计文档等等,这些都是做软件测试需要考虑的范围。甚至于软件系统和硬件之间能否很好的结合,正常地发挥其该有的功能,也是软件测试要考虑的,我想这也是对一个软件测试工程师的要求吧。

Why—为什么要做软件测试?

我相信有很多非测试人员,甚至也有很多不太了解软件测试的开发人员会认为软件测试就是在找 bug。然而事实并非如此,相信通过前面的介绍,我们大概已经感觉到软件测试的目的不单纯在于程序本身的 bug 了,那么还有数据、文档呢。的确,找 bug 并不是软件测试的唯一目的,如果把一个软件系统当做一个产品来看的话,那么软件测试的目的就是确保最终交给用户的产品符合用户的需求,在产品交给用户之前尽早尽可能的多发现问题,并协助开发改正问题,共同保证产品的质量。

这里所说的问题,可以是程序的 bug,也可以是需求分析、设计过程中存在的问题,往往这些问题在软件开发过程中如果没有及早发现解决,后期来修复的成本是巨大的且不划算的。因为你不能保证用户提供的原始需求一定是合理并且正确的,或者是将用户原始需求转化为软件需求规格说明书的过程中一定没有歧义,软件概要设计过程一定没有逻辑问题。所以对于这些文档性质的内容也是需要进行测试的,或者说是评审。而这些也是一个项目中软件测试工程师的首要工作,通过这些工作来保障项目正常开始,是在软件开发项目的初期就着手的去做的。

举个例子,如果软件的某个功能点在需求规格说明书中的解释存在问题而未经发现,后期经过测试发现达不到客户要求重新修改,那么重新对这个功能模块进行修改,无疑又要耗费额外的人力物力,但是这个问题要是最初阶段发现并解决了,岂不是很好地提高了项目的效率!

软件是人为的产物,当开发一个软件的前提条件全部准备充分了,包括良好的工作环境、高性能的硬件条件以及优秀的程序员。然而最后导致程序运行过程中出 bug 的因素不是服务器资源不够、网络不好等等,还是在于程序本身。毕竟程序员是人不是机器,人的不同心理或生理状态,工作的效率和质量也会不同,心情好的时候和心情不好的时候,舒服和生病的时候写出来的代码当然是后者更容易出现问题,这是不可避免,也是软件测试存在的必要条件。同样的道理,软件测试工程师也是人,再优秀的软件测试工程师也不能保证测试后的程序会没有一个 bug,但是却可以说经过系统全面测试并使已发现的缺陷并得以解决的软件产品或服务是合格的、是满足用户需求的、是拿得出手的!

Who, When, Where—什么人在什么时候针对软件的哪方面做测试?

软件测试的主体应该是软件测试工程师,因为软件测试工程师拥有专业的测试思路并会通过一些专业的测试方法对软件开展测试工作。但如果将测试人员的范围扩大化、概念模糊化,那么执行测试的人员可以是项目经理、开发人员、客户以及软件产品发布后的用户群体。比如说单元测试一般会让更熟悉代码结构的开发人员进行。测试后期的验收测试中 β 测试则是用户在实际环境中进行的测试,就完全脱离了开发人员和测试人员进行测试。

软件测试的时间,通过前面的介绍,我们应该能想到,软件测试是在项目启动的时候就已经开始了的,而结束的时间一般来说就是别指望。为啥这么说呢?除非这个软件已经弃用,或者这个软件项目已经停止更新了,否则软件测试就会要不断的进行,每一次的软件版本迭代更新伴随而来的是一次又一次的回归测试,来确保新版本的质量。所以说测试工作不要做结束的指望。但是在软件项目开发的过程中,测试工作的时序还是有着一定的规律性。

一般来说,可以分为以下几个阶段:(时序按先后顺序排列)

1.需求阶段

主要任务:进行需求分析与评审,参与对客户或用户关于软件产品原始需求的分析,或者指导客户提需求,保证需求的合理性。

输入内容:用户或客户的原始需求
输出内容:《产品需求规格说明书》,同时测试工作包括对《产品需求规格说明书》的评审(包括后续各阶段的文档都是需要经过评审通过的)

2.计划阶段

这个阶段则是针对需求对整个测试工作的一个宏观计划,我认为应该至少包括以下两点:

  • 资源计划:包括时间资源:人员资源的利用,什么人在什么时间点做什么工作,时限多少。
  • 策略计划:测试在什么阶段针对什么需求使用什么方法,执行方案。

这两点需结合起来才算式比较完整的计划,同时这个阶段的输入内容是《产品需求规格说明书》,输出内容是《项目测试计划》。

3.设计阶段

这个阶段主要就是设计测试用例啦,计划做好了,为了执行测试的规范,高覆盖率和高效率。就要根据计划对各功能点,各个需求设计测试用例,开发自动化测试脚本等。

输入内容:《项目测试计划》、《概要设计文档》、《详细设计文档》
输出内容:《测试用例》

4.执行阶段

前面几个阶段都如期完成后,这个阶段的主要工作就可以根据《测试用例》来执行测试了,通过测试发现的BUG提交给程序员修复,修复完成后返测。

这个阶段又可以按照时序分为:单元测试、集成测试、系统测试(包括确认测试)、验收测试。直到验收测试结束,第一阶段的测试工作也快接近尾声了,后续版本更新的时候又会有大量的回归测试工作要做。这个时候之前设计阶段的成果《测试用例》就体现出优势了,通过第一轮测试后测试用例会不断完善,之前做过的测试工作在回归测试的时候就会更加顺手,甚至可以通过开发自动化测试工具代替我们完成测试执行工作。

输入内容:《测试用例》
输出内容:《测试报告》(包含测试覆盖率,bug 修复率等数据)

5.总结阶段

最后我认为也是最重要的阶段,通过对测试工作的总结,能发现许多工作中存在的问题,分析之后,对以后的工作效率,工作准确度的提高有很大的帮助。这个阶段的输出是《测试总结文档》。

在软件测试工作不断积累和提高下,也衍生出了许多与软件测试相关的模型,比如 W 模型,就强调了软件开发与测试是同步进行的,测试的对象不仅仅是程序,需求、设计等同样要测试的观点。

How—如何进行软件测试?

其实这个问题比较大,就软件测试的分类就不下20种,每种分类又有着不同的含义和操作方式。而设计测试用例的方法也多种多样各有优劣。对于如此庞大的一个知识体系,难以一篇文章介绍详尽,我们不妨换一个角度来看这个问题,找一个切入点来聊聊这个话题。

比方说,软件测试的工作内容是什么?通过前面的介绍,我想大家或许最软件测试工程师的工作内容有个基本的概念了,总的来说可以简单归纳为以下几点:

  1、参与分析需求评审测试需求
  2、参与测试计划的制定和执行
  3、评审开发设计并参与测试设计和开发
  4、测试环境的搭建
  5、测试的执行
  6、缺陷的发现和提交并协助定位、解决缺陷
  7、测试的分析和总结  

  上面这7点其实也是作为一个合格软件测试工程师需要具备的能力。至于更加进阶的测试形式如:自动化测试、专项测试、性能测试等,它们如何具体去开展,如果我知道也会通过博客把我所了解的知识和锻炼出来的技能和大家分享。当然不同企业的要求也不同,测试工作开展的方式也会不同。努力学习知识并将其转化为自己的技能自然是极好的。

  直到现在我还并没有将软件测试的官方定义贴出来,不过我相信现在大家再去看下面这个软件测试的定义,想必是十分容易理解的了吧。

软件测试的定义:使用人工或自动手段,来运行或测定某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

本文完~

Tips:本站使用 Disqus 评论,被墙访客请科学上网后点击加载。