当前位置: 网站首页  >> 知识库  >> 软件测试  >> 查看详情

新手小白必学软件测试基础知识

发布时间:2019-11-04 08:46:09  浏览次数:3726 
  1983年IEEE提出的软件工程术语中给软件测试下的定义是:“使用人工或自动的手段来运行或测定某个软件系统的过程,其目的是为了检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。"这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。

  一、测试定义与目的

  定义:

  1983年IEEE提出的软件工程术语中给软件测试下的定义是:“使用人工或自动的手段来运行或测定某个软件系统的过程,其目的是为了检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。"这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。

  目的:

  获取系统在可接受风险范围内可用的信心;尝试在非正常情况和条件下的功能和特性;保证一个工作产品是完整的并且可用或者可被集成

  发现缺陷、错误和系统不足;定义系统的能力和局限性;提供组件、工作产品和系统的质量信息

  澄清系统的规格和性能;提供预防或减少可能制造的错误的信息;在过程中尽 早检测错误;确认问题和风险,并且提前确认解决这些问题和风险途径

  二、测试原则

  测试人员应该尽早介入,越早发现缺陷,修复缺陷的成本越低

  缺陷具有集群性,测试过程中80%的错误分布在20%的模块上

  站在用户的角度去体验产品,所有的测试都应该追溯到用户的需求

  设计测试用例时,要考虑合法的输入和不合法的输入以及各种边界条件,特殊情况下要制造极端状态和意外状态,100%的覆盖需求

  完全测试是不可能的,测试需终止,运用风险分析和不同系统功能的测试优先级,里确定测试的关注点

  程序员避免检查自己的程序,除单元测试外。开发对自己的作品在思维上具有局限性;交给第三方或专业测试,利用各种测试技术、测试经验和对Bug的敏感性,提高软件质量

  制定严格的测试计划,并妥善保存测试过程中的所有文档

  对错误结果要进行一个确认过程

  三、测试分类

  按测试阶段划分

  单元测试、集成测试、系统测试、验收测试(正式验收测试,Alpha测试、Beta测试)

  按测试技术划分

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

  按测试手段划分

  手工测试、自动化测试

  被测对象是否运行划分

  动态测试、静态测试(文档检查、代码走查、界面检查)

  按测试内容划分

  功能测试、安全测试、界面测试、兼容性测试、易用性测试、性能测试、

  压力测试、负载测试、恢复测试

  其他测试

  冒烟测试、回归测试、探索性测试(测试思维)

  四、软件的生命周期

  定义:

  软件的产生直到报废或停止使用的过程

  阶段:

  一、问题定义与规划

  主要确认软件开发的目的及可行性,制定开发计划。

  二、需求分析

  在确定软件开发可行的情况下,对软件的需要实现的各项功能进行详细分析,明确客户的需求,输出需求规格说明书(原型图)。

  三、软件设计

  把需求分析的结果转换为软件结构和数据结构,形成系统架构。

  概要设计:主要是架构的实现,指搭建架构、表述各模块功能、模块接口连接和数据的实现等。

  详细设计:对概要设计的各个功能模块进行深入分析,对各个模块组合进行分析等。

  这一阶段要求达到伪代码级别,已经把程序的具体实现的功能,现象等描述出来,其中包括数据库的设计说明。

  四、软件编码

  按照设计好的详细模块功能表,编程人员编写出计算机可运行的程序代码。

  五、软件测试

  在软件设计完成后就要经过严密的测试,以发现软件在整个过程中存在的问题并加以纠正。测试方法主要有白盒测试和黑盒测试。

  单元测试:主要测试程序代码,为的是保证各个单元模块被正确的编译,比如有具体到模块的测试,也有具体到类、函数、方法的测试等,一般由开发人员完成

  集成测试:单元测试后,将各个单元组成完成的体系,测试单元之间的接口是否正确,数据能否正常传递。

  系统测试:把软件系统搭建起来,按照软件规格说明书中所要求,测试软件的性能功能等是否和用户需求相符合,在系统中运行是否存在漏洞等。—— 根据测试用例完整的测试

  回归测试:主要是用户在拿到软件的时候,在使用现场根据前面所提到的需求以及规格说明书来做相应的测试,以确定软件达到预期效果。—— 用户对软件进行验收

  六、运行维护

  软件的维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应客户的需求。要延续软件的使用寿命,就必须对软件进行维护。

  软件的维护主要包括纠错性维护和改进性维护两个方面。

  五、软件测试模型

  瀑布模型

  瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来

  V模型

  RAD(Rap Application Development,快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件测试的V模型。

  优点:

  1. 明确地标注了测试过程中存在的不同测试类型;

  2. 清楚的描述了这些测试阶段和开发过程期间个阶段的对应关系;

  缺点:

  1. 不适合需求变化频繁的程序;

  2. 发现错误时间较晚;

  3. 仅仅把测试作为在编码之后的一个阶段,未在需求阶段就进入测试;

  W模型

  目的:为解决V模型的缺陷而产生,增加了软件个开发阶段中应同步进行的验证的确认活动

  特点:测试的对象不仅是程序,需求、设计等同样要测试,开发与测试同步

  优点:可以尽早的发现错误,降低风险,减少成本,提高质量

  缺点:

  1. 不能适应用户需求变化频繁的项目

  2. 需求、设计、编码等活动被视为串型的 3. 测试和开发活动也保持这一种线性的前后关系,上一阶段完全结束,才可以正式开始下一个阶段工作 4. 无法支持敏捷开发模式

  5. 对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临的困惑

联系我们
在线咨询 QQ客服 0731-88362910
地址:湖南省长沙市雷锋大道1389号
如有问题,可在线提交表单