软件测试小整理

软件测试

一、发展历程

软件测试是保证软件的质量是符合用户需求的一系列手段，由软件危机引出。

软件测试的三个阶段：

工程系体系，预防bug而非找bug。

**软件测试的目的：**为了发现错误而执行程序的过程，但不涉及改正错误。
**程序调试（Debug，排错）的基本步骤有：**错误定位、修改设计和代码，以排除错误、进行回归测试，防止引进新的错误。
**软件测试的基本准则有：**所有测试都应追溯到需求、严格执行测试计划，排除测试的随意性、充分注意测试中的群集现象、程序员应避免检查自己的程序、穷举测试不可能、妥善保存测试计划等文件。
二、软件测试的分类
按方法分：
黑盒测试、白盒测试、灰盒测试（灰即 黑+白结合）

按方向分：
功能测试
性能测试（
压力测试->通过确定一个系统的瓶颈或者最大使用极限的测试

负载测试-> 确定在各种工作负载下系统的性能，目标是测试当负载 逐渐增加时，系统各项性能指标的变化情况 。

强度测试->强度测试是一种性能测试，在系统资源特别低的情况下软件系统运行情况。

容量测试：确定系统可处理同时在线的最大用户数（在用户可接收 的范围内）。

负载测试是从并发量维度出发，不断增加并发量的情况下，系统的性能指标；
压力测试是从访问时间维度出发，在并发量一定的情况下，不断增加连续访问的时间，系统的性能指标；
负载测试的目标是测试在一定负载情况下，系统的性能；（这里不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可；）实际中，我们常从较小的负载开始，逐渐增加模拟用户用户的数量，观察不同负载下，系统的响应时间，所耗资源，直到超时或关系资源耗尽，这就是所说的负载测试；
压力测试的目标是测试在一定负载的情况下，系统长时间运行时的稳定性。比如我们经常利用脚本或工具事先吃掉服务器的一部分CPU、内存或带宽等，创造出一定的负载环境并测试此时系统的事务处理能力，响应时间等等。压力测试尤其关注大业务量情况下长时间运行系统时，系统性能的变化（例如是否反应变慢，是否会内存泄漏导致系统逐渐崩溃）；
）
安全测试

按阶段分：
单元测试、集成测试、系统测试、验收测试
V、W模型：
软件测试的V模型：

V模型的目的在于改进软件开发的效率和效果。
在V模型中：
明确的标注了测试过程中存在着那些不同的测试类型，并且清楚的表达了测试阶段和开发过程各阶段的对应关系。
从这种对应关系我们分析：
单元测试和集成测试对应于详细设计和概要设计，那么在单元测试和集成测试中我们就需要检测程序的执行是否满足软件设计的要求。
系统测试对应于需求与系统分析，在系统测试过程中我们就需要检测系统的功能，性能，质量上是否满足系统要求的指标。
验收测试对应于用户需求阶段，在验收测试中我们就需要确定软件的实现是否已经满足用户的需求。
V模型缺点：在V模型中，只是把测试作为编码之后的一个阶段，并没有在需求开发阶段就进入测试。

集成测试的方法有两种： 非增式测试和增式测试 ，而采用增式测试时又有两种选择： 自顶向下结合、自底向上结合。
① 自顶向下结合的步骤
⑴ 主控模块作为测试驱动器；
⑵ 根据集成的方式（深度或广度），下层的桩模块一个一个地被替换为真正的模块；
⑶ 在每个模块被集成时，都必须进行单元测试。
重复第二步，直到整个系统结构被集成完成。
② 自底向上结合
自底向上增式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的， 由于是从最底层开始集成，因此不需要使用桩模块来辅助测试 。
自顶向下测试的优点在于它可以自然地做到逐步求精，一开始就可以让测试者看到系统的框架；缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定的困难。
自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难；缺点在于直到最后一个模块被加进去之后才能看到整个程序的框架。

桩模块（Stub）是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。在自顶向下的集成过程中尤其有效。

非增量式测试（No-Incremental Integration）也称做大爆炸集成。分别对系统中每个模块进行集成测试，然后将所有模块按层次结构图组装到一起进行测试，最终得到所要求的软件。

软件测试的W模型

W模型增加了软件开发的阶段中应同步进行的验证和确认活动，W模型由两个V字模型组成，分别代表测试与开发过程。
在这里，测试的对象就不仅仅是程序。需求和设计等同样需要进行测试，测试和开发是一起进行的。
这有利于在早期发现问题，比如，需求分析完成以后，经过测试，我们就可以尽早的找出不合理或者错误的需求，对需求进行的测试，我们也可以在早期就了解项目情况，及早制定相应的应对计划，减少后期的测试工作时间，从而加快项目的整体进度。
按对象分：
APP测试、WEB测试、物联网测试、车联网测试、嵌入式测试、大数据测试、AI测试。。。
按状态分：
静态测试：
1）代码检查：代码会审、代码走查、桌面检查；
2）静态结构分析；
3）代码质量度量。

动态测试：
（1）黑盒测试：又称功能测试。这种方法把被测软件看成黑盒，在不考虑软件内部结构和特性的情况下测试软件的外部特性。
（2）白盒测试：又称结构测试。这种方法把被测软件看成白盒，根据程序的内部结构和逻辑设计来设计测试实例，对程序的路径和过程进行测试。

即：动态测试需运行相关的程序，静态测试不需。

其他：
冒烟测试（测试前的测试）、回归测试、
α测试（内测；由用户做测试，但开发人员在场，一般是请用户到开发现场去测试）、
β测试（公测；完全交给用户，由用户做测试，返回测试报告，相当于发行前的一个版本 ）

确认测试（包含α、β测试）：
确认测试是对通过组合测试的软件进行的，这些软件已经存于系统目标设备的介质上。确认测试的目的是要表明软件是可以工作的，并且符合”软件需求说明书”中规定的全部功能和性能要求。确认测试是按照这些要求定出的”确认测试计划”进行的。测试工作由一个独立的组织进行。而且测试要从用户观点出发。

所有测试项没有残余一级、二级和三级错误。

一、 黑盒测试：是一种常用的软件测试方法，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。几种常用的黑盒测试方法和黑盒测试工具有，等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。

二、 因果图法：等价类划分法和边界值分析方法都是着重考虑输入条件，如果程序输入之间没有什么联系，采用等价类划分和边界值分析是一种比较有效的方法。如果输入之间有关系，例如，约束关系、组合关系，这种关系用等价类划分和边界值分析是很难描述的，测试效果难以保障，因此必须考虑使用一种适合于描述对于多种条件的组合，产生多个相应动作的测试方法，因果图正是在此背景下提出的。因果图法着重测试规格说明中的输入与输出间的依赖关系。
1、 因果图的符号的关系

以下是符号的具体说明:
原因→结果

原因→原因

结果→结果

2、因果图法测试用例的设计步骤
（1）确定软件规格(需求)中的原因和结果
（2）确定原因和结果之间的逻辑关系
（3）确定因果图中的各个约束(constraints)
（4）画出因果图并转换为决策表
（5）根据决策表设计测试用例

三、实例分析
产品说明书：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。
（1）确定需求中的原因与结果

（2）确定原因与结果 的逻辑关系
C1 与 C2 需要一个中间结果Cm1, C3、C4、C5 需要一个中间结果Cm2.
（3）确定因果图中的约束
C1 与 C2 是或的关系, C3、C4、C5 是或的关系。
（4）画出因果图并转化为决策表

决策表
将原因C1、C2、C3、C4、C5按二进制由小到大分别取值，并分析中间结果的成立与否，进而得出下面的简化版（即中间结果Cm1、Cm2成立的情况）


简化版
（5）根据决策表设计测试用例

三、软件测试的生命周期

1、需求分析阶段：测试人员了解需求、对需求进行分解、分析，得出测试需求。

2、测试计划阶段：根据需求编写测试计划/测试方案

3、测试设计、测试开发阶段：测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例。

4、测试执行阶段：测试执行阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试。

5、测试评估阶段：在执行的过程中记录、管理缺陷，测试完成后编写测试报告，进行测试评估。

软件验收测试合格通过来准则：
1软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
2所有测试项没有残余的源一级二级三级的错误。
3立项审批表、需求分析文档、设计文档和编码实现一致。
4验收测试工件百齐全（测试计划，测试用例，测试日志，测试通知单，测试分析报告）

测试驱动开发，英文全称Test-Driven Development，简称 TDD ，是一种不同于传统 软件开发流程 的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。
TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。