美文网首页
构建之法-13-软件测试

构建之法-13-软件测试

作者: BigLong | 来源:发表于2019-05-19 17:20 被阅读0次
软件测试

本章介绍了一些主流的测试方法。


13.1 基本名词解释及分类

  1. 介绍几个名词

Bug:软件的缺陷
Test Case:测试用例,测试用例描述了一个完整的测试过程,包括测试环境、输入、期望的结果等。
Test Suite:测试用例集,即一组相关的测试用例。

  1. Bug的组成部分:

1. 症状(Symptom):即从用户的角度看,软件出了什么问题。例如,输入(3211)时,程序出错退出。
2. 程序错误(Fault):即从代码的角度看,代码的什么错误导致了软件的问题。例如,代码在输入为某种情况下访问了非法的内存地址——0X0000000C。
3. 根本原因(Root Cause):错误根源,即导致代码错误的根本原因。例如,代码对于id1==id2的情况没有做正确的判断,从而引用了未赋值的变量,出现了以上情况。

  1. 按测试设计的方法分类

黑箱:指的是在设计测试的过程中,把软件系统当作一个“黑箱”,无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计(Be-havioral Test Design),即从软件的行为,而不是从内部结构出发来设计测试。

白箱:指的是在设计测试的过程中,设计者可以“看到”软件系统的内部结构,并使用软件的内部结构和知识来选择测试数据及具体的测试方法。

  1. 按测试的目的分类


    功能测试分类
    非功能测试
  2. 按测试的时机和作用分类


    测试“烽火台”
不同的测试方法

13.2 各种测试方法

  1. 单元测试(Unit Test)

参看本书第2章“单元测试”一节

  1. 构建验证测试(Build Verification Test,BVT)

是指在一个构建完成之后,构建系统会自动运行一套测试,验证系统的基本功能。

  1. 验收测试(Acceptance Test)

在“基本场景”的基础上,把系统在理论上目前支持的所有场景都列出来,然后按功能分类测试,如果测试成功,就在此场景中标明“成功”,否则,就标明“失败”,并且用一个或几个“小强”/Bug来表示失败的情况。

  1. “探索式”的测试(Ad hoc Test)

“Ad hoc”也意味着测试是尝试性的,“我来试试,在这个对话框中一通乱按,然后随意改变窗口大小,看看会出什么问题……”,如果没问题,那么以后也不会再这么做了。

  1. 回归测试(Regression Test)

请看本书第2章“回归测试”一节的介绍

  1. 场景/集成/系统测试(Scenario/ Integration / System Test)

在软件开发的一定阶段,我们要对一个软件进行全面和系统的测试,以保证软件的各个模块都能共同工作,各方面均能满足用户的要求。

  1. 伙伴测试(Buddy Test)

是指开发人员可以找一个测试人员作为伙伴(Buddy),在签入新代码之前,开发人员做一个包含新模块的私人构建(Private Build),测试人员在本地做必要的回归/功能/集成/探索测试,发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后,开发人员再正式签入代码。在项目后期,签入代码的门槛会变得越来越高,大部分团队都要求缺陷修正(Bug Fix)必须经伙伴测试的验证才能签入代码库。

  1. 效能测试(Performance Test)
  1. 设计负载
    例如,一个购物网站,客户认为正常的设计负载是每分钟承受20次客户请求。
  2. 令用户满意的服务质量
    例如,每个用户的请求都能在2秒钟内返回结果。
  3. 设计负载的细化
  • 设计负载的细化上面我们只提到“承受20次客户请求”,那么这些客户的请求到底是什么,可以按请求发生的频率来分类。
  • 有些请求,是要对数据进行“写”操作,可以要求慢一些,比如“用户下订单,购买商品”,对这一服务质量,请求可以放宽为5秒钟,甚至更长。
  1. 压力测试(Stress Test)

软件在超过设计负载的情况下是否仍能返回正常结果,没有产生严重的副作用或崩溃。

  1. 内部/外部公开测试(Alpha/Beta Test)

开发团队希望让用户直接接触到最新版本的软件,以便从用户那里收集反馈,这时开发团队会让特定的用户(Alpha/Beta用户)使用正处于开发过程中的版本,用户会通过特定的反馈渠道(E-mail、BBS、微博等)与开发者讨论使用中发现的问题,等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。

  1. 易用性测试(Usability Test)

“易用性测试”似乎更多地用来描述一套测试软件可用性的过程,这个过程一般不是由测试人员来主导的,而是由对软件设计和软件可用性有大量研究的“可用性设计师”来实行

  1. “小强”大扫荡(Bug Bash)

一般是安排出一段时间(如一天),这段时间里所有测试人员(有时也加入其他角色)都放下手里的事情,专心找某种类型的小强


13.3 实战中的测试

  1. 一些不正确的观念

测试在项目的最后进行就可以了。

测试就得根据规格说明书(Spec)来测,所以是很机械的。

测试人员当然也写代码,但是质量不一定要很高。

测试的时候尽量用Debug版本,便于发现Bug。

  1. 测试工作中的文档


    测试工作中的文档

The End

相关文章

  • 构建之法-13-软件测试

    本章介绍了一些主流的测试方法。 13.1 基本名词解释及分类 介绍几个名词 Bug:软件的缺陷Test Case:...

  • 构建之法--软件工程

    这本书是微软高级工程师邹欣所著,是一本关于软件工程的大学教材。 曾经被用于清华/北航等学校的软件工程课程的教学,非...

  • jenkins测试环境构建使用手册

    1. 测试版本构建流程简介   软件系统测试环境的版本构建使用jenkins平台进行,jenkins自动化构建分为...

  • 「没有银弹」的 《人月神话》

    这是近期我阅读的第二本关于软件工程的书籍,第一本是《构建之法》;虽然两本书都是关于软件工程方面,但各有侧重。《构建...

  • Jenkins配置-Android自动化打包-Mac版

    Jenkins是一款开源CI$CD软件,用于自动化各种任务,包括构建、测试和部署软件优点:持续的软件版本发布、测试...

  • 构建之法

    个人能力的衡量(开发的工作量和质量的衡量):通过代码行数或功能点来衡量;花费的时间;交付的代码有多少bug来衡量;...

  • 【完美测试】之测试架构从何而来

    1.什么是测试架构 从基本的观点看,测试架构师由软件系统技术架构和软件测试结构构建的需求而定。 2.测试领域架构 ...

  • Jenkins

    构建工具 1、持续、自动地构建/测试软件项目; 2、监控软件开放流程,快速问题定位及处理,提示开放效率; 即:自动...

  • 构建之法,超越软件,不止于代码

    老实说,我是不适合写书评的,作为一名会计学专业的学生,书中太多难啃的概念,大部分章节都一知半解不知所云。以至于,读...

  • 传统测试与敏捷测试工作模式对比

    传统软件测试与敏捷测试是基于两种不同的思路构建的软件测试工作方式。 1.传统测试中,测试通常是不同于开发的部门/小...

网友评论

      本文标题:构建之法-13-软件测试

      本文链接:https://www.haomeiwen.com/subject/vvrqzqtx.html