软件测试基础(一)

以下是一些关于软件测试入门的名词及相应解释

一、软件工程:调研、立项、计划、评审、开发、测试、部署、线上跟踪、后期维护

二、软件质量:软件质量是软件符合明确叙述功能和性能需求、文档中明确描述的开发标准、以及所有的专业开发的软件都应具有的隐含特征的程度

1、 软件需求是度量软件质量的基础,与需求不一致的就是质量不高

2、 制定的标准定义了一组指导软件开发的准则,如果没有遵守这些准则,几乎肯定会导致质量不高

3、 通常,有一组没有显示描述的隐含需求(如期望软件是容易维护的)。如果软件满足明确的描述需求,但不满足隐含的需求,那么软件的质量依然是值得怀疑的

三、需求

  • 一听这两个字就头疼,如果你是在比较健全稳定的公司,那么需求是比较好把握的;如果你在创业型或者发展中的公司,那么需求会让你崩溃
  • 那我们如何处理需求呢?
  • 1、必须要有需求文档与原型
  • 2、理解需求
  • 3、对迷糊的需求list出来与产品沟通
  • 4、整理需求,罗列测试点

四、软件测试

  • 软件测试是一种有效的提高软件质量的手段,单即使在投入上有所保证,测试也不能百分百发现所有质量隐患,况且软件质量并不仅仅是测试出来的
  • 很多人认为软件测试就是运行一下软件,看看结果对不对,但实际上,如果在有限的投入下,提高软件测试的效率和产出是一件很见功底的事,好的测试人员不仅要掌握各种测试技术,还要具备丰富的编程经验和对BUG的敏感,测试的复杂之处,除了测试技术问题之外,还有测试管理问题
  • 测试不是可有可无,随心所欲的,规范化的软件开发需要对软件测试早作计划,分配必要的时间,人力和财力等等资源,并将其作为项目管理的一个部分加以控制和协调
  • 软件测试的定义:软件测试是为了发现错误而执行程序的过程
  • 软件测试是根据软件开发的规格说明和程序内部结构而精心设计一批测试用例(即输入数据及其预期输出结果),并利用这些测试用例去执行程序,以发现程序错误的过程。

五、软件测试分类

1、根据项目流程阶段划分软件测试可分为单元测试、集成测试、系统测试、验收测试

  • 单元测试:单元测试(或模块测试)是对程序中的单个子程序或具有独立功能的代码段进行测试的过程。
  • 集成测试:集成测试是在单元测试的基础上,先通过单元模块组装成系统或子系统,再进行测试。重点是检查模块之间的接口是否正确。
  • 系统测试:系统测试是针对整个产品系统进行的测试,验证系统是否满足需求规格的定义,以及软件系统的正确性和性能等是否满足其需求规格的要求。
  • 验收测试:验收测试是部署软件之前的最后一个测试阶段。验收测试的目的是确保软件准备就绪,向软件购买者展示该软件系统能够满足用户的需求。

2、白盒测试、黑盒测试、灰盒测试

          白盒测试与黑盒测试,主要是根据软件测试工作中对软件代码的可见程度进行的划分。这也是软件测试领域中最基本的概念之一。

  • 黑盒测试:指的是把被测的软件看做一个黑盒子,我们不去关心盒子里面的结构是什么样子的,只关心软件的输入数据和输出结果。

    它只检查程序呈现给用户的功能是否按照需求规格说明书的规定正常使用、程序是否能接受输入数据并产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。

  • 白盒测试:指的是把盒子打开,去研究里面的源代码和程序执行结果。

    它是按照程序内部的结构测试程序,通过测试来检验产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条逻辑路径是否都能按预定要求正确工作。

  • 灰盒测试:介于黑盒测试和白盒测试之间。

    可以这样理解,灰盒测试既关注输出对于输入的正确性,同时也关注内部表现。但这种关注不像白盒测试那样详细、完整,它只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的,但内部其实已经错误了,这种情况非常多。如果每次都通过白盒测试来操作,效率会很低,因此需要采取灰盒测试的方法。

3、功能测试与性能测试

          从软件的不同测试面可以划分为功能测试与性能测试

  • 功能测试:功能测试主要检查世纪功能是否符合用户的需求,因此测试的大部分工作也是围绕软件的功能进行。设计软件的目的就是满足用户对其功能的需求,如果偏离了这个目的,则任何测试工作都是没有意义的。功能测试又可以细分为很多种:逻辑功能测试,界面测试、易用性测试、安装测试、兼容性测试等。
  • 性能测试:性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。软件的性能包括很多方面,主要有时间性能和空间性能两种。性能测试又可分为:负载测试、压力测试、并发测试、配置测试、可靠性测试
    • 时间性能:主要是指软件的一个具体的响应时间。例如一个登陆所需要的时间,一个商品交易所需要的时间等。当然,抛开具体的测试环境,来分析一次事务的响应时间是没有任何意义的,它需要在搭建好的一个具体且独立的测试环境下进行。
    • 空间性能:主要指软件运行时所消耗的系统资源,例如硬件资源,CPU、内存、网络宽带消耗等

4、手工测试与自动化测试

     从对软件测试工作的自动化程度可以划分为手工测试与自动化测试。

  • 手工测试:手工测试就是由测试人员一个一个地去执行测试用例,通过键盘鼠标等输入一些参数,并查看返回结果是否符合预期结果。手工测试并非专业术语,手工测试通常是指我们在系统测试阶段所进行的功能测试,为了更明显地与自动化测试进行区分,这里使用了手工测试这种说法。
  • 自动化测试:自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计测试用例并通过评审之后,由测试人员根据测试用例中描述的规则流程一步步执行测试,把得到的世纪结果与期望结果进行比较。在此过程中,为了节省人力、时间和硬件资源,提高测试效率,便引入了自动化测试的概念。自动化测试又可分为:功能自动化测试与性能自动化测试。
    • 功能自动化测试:是把以人为驱动的测试行为转化为机器执行的一种过程。通过测试工具(或框架)录制/编写测试脚本,对软件的功能进行测试,并验证测试结果是否正确,从而代替部分的手工测试工作,达到节约人力成本和时间成本的目的。
    • 性能自动化测试:通过性能功能来模拟成千上万的虚拟用户向系统发送请求,从而验证系统的处理能力。

5、冒烟测试、回归测试、随机测试、探索性测试与安全测试

     这几种测试出现在软件测试的周期中,既不算具体明确的测试阶段,也不是具体的测试方法。

  • 冒烟测试:是指在对一个新版本进行大规模的系统测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。引入到软件测试中,就是指测试小组在正是测试一个新版本之前,先投入较少的人力和时间验证一个软件的主要功能,如果主要功能都没有运行通过,则打回开发组重新开发。这样做的好处是可以节省时间和人力投入到不可测的项目中。
  •  回归测试:指修改了旧代码后,重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。
    回归测试一般是在进行第二轮软件测试时开始的,验证第一轮软件测试中发现的问题是否得到修复。当然,回归也是一个循环的过程,如果回归的问题通不过,则需要开发人员修改后再次进行回归,直到所有问题回归通过为止。
  • 随机测试:是指测试中的所有输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。随机测试可以发现一些隐蔽的错误,但是也有很多缺点,例如测试不系统,无法统计代码覆盖率和需求覆盖率、发现的问题难以重现等。一般是放在测试的最后执行。随机测试更专业的升级版叫做探索性测试。
  • 探索性测试:探索性测试可以说是一种测试思维技术,它没有很多实际的测试方法、技术和工具,但却是所有测试人员多应该掌握的一种测试思维方式。探索性测试强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略。
  • 安全测试:安全测试在IT软件产品的生命周期中,特别是产品开发基本完成至发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。安全测试现在越来越受到企业的关注和重视,因为由于安全性问题造成的后果是不可估量的,尤其是互联网产品,最容易遭受各种安全攻击。

6、什么样的项目适合自动化测试

  1. 任务测试明确,不会频繁变动。
  2. 每日构建后的测试验证。
  3. 比较频繁的回归测试。
  4. 软件系统界面稳定,变动少。
  5. 需要在多平台上运行的相同测试案例、组合遍历型的测试,大量的重复任务。
  6. 软件维护周期长。
  7. 项目进度压力不太大。
  8. 被测软件系统开发较为规范,能够保证系统的可测试性。
  9. 具备大量的自动化测试平台。
  10. 测试人员具备较强的编程能力。

在我们普遍的自动化测试经验中,一般满足以下三个条件就可以对项目开展自动化测试。

  • 1. 软件需求变动不频繁

  自动化测试脚本变化的大小与频率决定了自动化测试的维护成本。如果软件需求变动过于频繁,那么测试人员就需要根据变动的需求来不断地更新自动化测试用例,从而适应新的功能。而脚本的维护本身就是一个开发代码的过程,需要扩展、修改、调试,有时还需要对架构做出调整。如果所花费的维护成本高于利用其节省的测试成本,那么自动化测试就失去了它的价值与意义。

  一种折中的做法是先对系统中相对稳定的模块与功能进行自动化测试,而变动较大的部分用用工进行测试。

  • 2. 项目周期较长

  由于自动化测试需求的确定,自动化测试框架的设计、脚本的开发与调试均需要时间来完成,而这个过程本身就是一个软件的开发过程,如果项目的周期较短,没有足够的时间去支持这样一个过程的话,那么就不需要进行自动化测试了。

  • 3. 自动化测试脚本可重复使用

  自动化测试脚本的重复使用要从三个方面来考量:一是所测试的项目之间是否存在很大的差异性(如C/S系统架构与B/S系统架构的差异);二是所选择的测试技术和工具是否适应这种差异;三是测试人员是否有能力设计开发出适应这种差异的自动化测试框架。

猜你喜欢

转载自www.cnblogs.com/Anemia-BOY/p/9363532.html