测试入门概述

龙俊亨

已于 2022-03-15 10:10:47 修改

阅读量172

点赞数

分类专栏：测试文章标签：单元测试集成测试系统测试验收测试回归测试

于 2021-10-29 09:38:42 首次发布

本文链接：https://blog.csdn.net/u010804417/article/details/121006974

版权

测试专栏收录该内容

32 篇文章 0 订阅

订阅专栏

测试入门概述

测试常识

测试常识

软件测试产生的背景

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。

测试工作的定位

相关前辈提到“测试工作负责桥接开发的结果与客户的需求，站在客户的角度审视开发的结果是否是用户想要的作品，做好产品发布前的最后一班岗”。

百度百科自称IEEE提出的软件测试定义：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。（这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体）。

有博客提到“软件测试是一种实际输出与预期输出之间的审核或者比较过程”和”软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程”。

有博客提到测试的目的是“为了发现程序中存在的错误而执行程序；
为了证明程序有错，而不是证明程序无错误”，即以发现开发的问题为目的，以客户需求为标准衡量是否是问题（即也不要乱提问题）。

教学视频中提到“一个好的测试相当于半个产品经理”，因为需要你精准把握测试的标准。

软件测试的基本原则

站在用户的角度，从需求出发，对软件进行把控，软件缺陷是一定存在的，所以需要尽早、尽多地发现并跟踪和分析软件中存在的问题，对不足之处提出质疑和改进意见。

需求的定义

所有不满足需求或超出需求的都是软件缺陷，其中的关键在于如何界定需求。比如买水，你买成了饮料，这是否正确在于需求是解渴还是好喝。

软件缺陷的定义

要以产品说明书为准，分为BUG和Defect。

产品说明书要求的功能未实现
产品说明书禁止的功能实现了
产品说明书未提到的功能出现了
产品说明书未提到（但应实现）的目标未实现
其他影响用户体验的地方（难用、难理解、运行慢等等）。

软件测试的具体原则：

1、准备详尽的测试工作计划，并及时维护。
2、所有测试的标准都应该建立在需求之上。
3、事先定义好产品的质量标准，并不遗余力的去执行。
4、尽可能早的开始测试工作。
5、避免让程序员测试自己的程序。
6、测试用例是设计出来的，不是写出来的。
7、对发现错误较多的程序段，应进行更深入的测试；对于出错多的程序员编写的程序同样需要给予特别关注。

测试工作的流程

在这里插入图片描述

测试流程的各个阶段

在这里插入图片描述

单元测试：
目前自己的理解，单元测试针对的是工程中的单个方法。对工程中的各个方法进行功能测试、边界测试、容错测试、界面测试、控制流和数据流测试，以及模块内的业务流程测试。

此类测试策略的优点在于所需分析数据较少，且针对性较强，程序开发者于开发过程中可通过操作经验明确出问题所在的大致区域，随后针对此类问题对相关单元展开分析，进行问题排查。

但需注意的是，某些程序中无具体单元驱动程序，即单个单元无法有效驱动，易出现问题，若针对此类软件展开测试，需重点注意此类分解单元。
集成测试：
也叫组装测试或联合测试。是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。

集成测试是单元测试的逻辑扩展，它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

系统集成后的相关接口测试、功能测试、容错测试、约束测试，跨模块的业务流程测试等。
系统测试：
系统性的初始化测试、功能测试、业务处理和数据处理测试、性能测试、压力测试、安装卸载测试等。
验收测试：
在用户现场和用户一起对系统进行功能确认、用户需求确认、备份恢复测试、安全性测试等。
回归测试：
系统使用过程中发现问题修改完成以后，测试对应的问题是否修改好了，测试新修改的功能是否引发新的缺陷，测试与修改代码相关的其它程序功能是否依然正确。