软件测试学习笔记-概念篇（一）

前言

　　每个系统的成型，上线都离不开测试，这段时间陆陆续续的学习测试，在这里总结一番；作为学习交流之用；

正文

软件测试概述

软件测试的历史：

这里写图片描述

什么是软件测试：

早期定义：软件测试是对程序能够按预期运行建立起一种信心。

经典定义：测试是为了发现错误而执行程序的过程。

IEEE定义（ISO/IEC/IEEE 29119）：使用人工或者自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试≠程序测试

五大要素和两个目标：

这里写图片描述

五大要素有：质量、人员、资源、流程、技术。

其中最主要的是软件质量，其他四个要素都是为质量服务的。

其次是人员，决定了技术，资源，流程，以及配置和使用。

技术包含了：软件测试技术、软件测试方法、使用的工具。技术是手段。

流程：测试计划，测试用例，测试执行，测试报告。有一些进入进出的标准（规范性，对软件测试做一个规范的要求）。

资源：测试所需要的硬件设备、网络环境、测试设备、测试时间（周期）。

注意：人不是资源。

目标：

①提升测试覆盖率-> 能够有效的保证软件的质量

②提升测试效率->能够使我们更好地完成软件测试

软件测试所遵循的原则

一、测试显示缺陷的存在，但不能证明系统不存在缺陷。

经过软件测试，可以发现软件中的故障；但是经过软件测试，不能保证软件就没有故障了。

二、穷尽测试是不可能的，应设定及时终止的条件。

三、测试应该尽早进行

这里写图片描述

四、缺陷具备群集特性

越是发现问题多的模块，越是需要重点测试的对象

五、测试的杀虫剂悖论

在测试中，如果采用同样的测试用例，同样的测试方法。多次重复的测试某一个模块，最后就不能再发现新的缺陷。所以说，测试用例和测试方法应该不定期的评审修改，并且增加不同的测试方法和用例来测试不同的部分，从而更多的发现软件的缺陷。

六、测试的二八原则

测试时间和资源往往是有限的，要找出所有的缺陷是不可能的，这时我们需要遵循二八原则。

把80%的时间或者资源用在20%的重点模块上，重点测试模块中20%的重要模块。来达到测试效率和资源配置的最佳的比例。

七、测试活动依赖于测试背景

针对不同的测试背景针对的活动是不同的，比如：电信级的软件对性能、大并发量的访问会有更高的要求。而金融，银行系统相关的软件，对安全性能要求更高。

软件测试阶段，手段，模式

按测试阶段来分类

单元测试、继承测试、系统测试、验收测试

单元测试

什么是单元测试

对软件中的最小可测试单元进行检查和验证

单元测试的原则：

1.尽可能保证各个测试用例是相互独立的；

2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。

单元测试的益处：

1.能尽早发现缺陷；收益最高；

2.有利于重构；

3.简化集成；

4.文档；

5.用于设计；

单元测试的限制

1.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误；

2.每一行代码，一般需要3-5行测试代码才能完成单元测试。所以存在投入和产出的一个平衡；

单元测试框架：

Xunit，JUnit，nunit，PPUnit，CppUnit

集成测试：

定义:

在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统过程中各部分工作是否达到或实现相应技术指标及要求的活动

集成测试的主要实施方案

1.Big Bang 全部完成，测试

2.自顶向下　　

3.自底向上从最低层测试，逐步组装测试；（常用测试）

4.核心系统集成

5.高频集成

集成测试&单元测试

1.测试的对象不同；

2.测试的一举不同；

3.测试的方法不同；

系统测试

定义：是将经过集成测试的软件，作为计算机系统的一个部分，系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

关注点

关注系统本身的使用

关注系统与其他相关系统间的连通

关注系统在不同使用压力下的表现

关注系统在真实使用环境下的表现

系统测试&集成测试

　　测试环境：

　　　　集成测试：由通过了单元测试的各个模块所集成起来的构件

　　　　系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统；

　　测试时间：

　　　　集成测试介于单元测试和系统测试之间测试

　　　　系统测试在集成测试之后

　　测试内容：

　　　　集成测试：各个单元模块之间的接口

　　　　系统测试：整个系统的功能和性能

　　测试角度：

　　　　集成测试：偏向于技术角度的验证

　　　　系统测试：偏向于业务角度的验证

验收测试　

　　定义：也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户、或其他授权机构决定是否接受系统。

　　细分

　　　　用户验收测试

　　　　运行验收测试

　　　　合同和规范验收测试

　　　　alpha测试

　　　　Beta测试

按测试手段来分类：

　　黑盒测试、白盒测试

　　静态测试、动态测试

　　手工测试、自动化测试

黑盒测试

　　定义：把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。主要针对软件界面和软件功能进行测试。

　　图例：

优点：　

　　1.容易实施，不需要关注内部的实现

　　2.更贴近用户的使用角度

缺点：

　　1.测试覆盖率角度，一般只能覆盖到代码量的不到40%；

　　2.针对黑盒测试的自动化测试，复用率较低，维护成本较高；

关注点：

　　1.是否有不正确或者遗漏的功能？

　　2.在接口上，输入是否能正确的接受？能否输出正确的结果？

　　3.是否有数据结构错误或者外部信息(例如数据文件)访问错误？

　　4.性能上是否能够满足要求?

黑盒测试的主要设计方法

白盒测试

定义　

　　白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。”白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。”白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。

图示：