软件测试的分类（*）

根据需求规格说明书，在设计阶段产出的俩个设计文档（开发相关的）

概要设计（hld）：设计软件结构，包含软件的组成，模块之间的层次关系，模块之间的调用关系，每个模块的功能等。（大范围描述）

详细设计（lld）：在概要设计的基础上，为每个模块做详细的描述，把功能描述转换为详细，精化到过程。

按开发阶段划分

1.单元测试：

又称“模块测试”，是针对程序中的每个模块进行正确性的检验的测试工作，目的在于检查程序每个模块是否能够正确实现详细设计文档中提出要求。

2.集成测试

又称“组装测试”，通常在单元测试的基础上，逐步将所有模块集成在一起的测试，最终满足于符合概要设计文档中给出的要求。

3.确认测试

又称“有效性测试”，验证软件包含的功能，性能以及相关的其他特性都和用户的预期都保持一致。只有通过了确认测试才能进入系统测试。

4.系统测试

在真实的环境下，运行被检测软件，检查程序能否和相关的系统平台相匹配或者配置，满足用户需求。

5.验收测试

检测软件产品最后的一个环节，按照计划书协议等对整个软件或系统进行测试与评审，从而决定接收系统或者拒收系统。

按照测试技术划分

1.黑盒测试

通过程序的外部表现来发现错误和缺陷，把被测对象看成是一个黑色的盒子，完全不考虑内部结构，只在程序界面处进行测试，来检查程序功能是否符合规格说明书的要求。–》功能测试

2.白盒测试

通过程序的内部结构的分析，来检测出现的问题，把被测对象看作一个透明的盒子，关注内部结构是否正确，所以白盒测试又称“结构测试”

3.灰盒测试

拥有白盒和黑盒的特征，即关注内部，也要看外部结构。

按照代码运行划分

静态测试

不实际运行被测对象，静态查看代码，界面，文档发现错误的地方

a，代码测试：主要测试代码是否符合相应的标准规范

b，界面测试：主要测试软件的实际假面与需求中说明的是否符合

c，文档测试：主要测试用户手册，以及相关的说明文档是否满足用户的实际需求

动态测试

实际运行被测对象，通过输入相关的测试数据，来观察实际结果和预期结果是否一致。

按照软件特性划分

1.功能测试

属于黑盒测试的一部分，它是用来检查实际的软件功能是否符合用户的需求，以及功能结果的正确性。

例：易用性测试，界面测试，安装卸载测试，兼容性测试等等

2.性能测试

一个程序除了能正确实现功能外，还要考虑功能实现的响应时间，处理速度，承受的压力负载等

3.安全性测试

验证安装在系统内的保护机制是否在实际应用中对系统有保护功能，防止非法入侵。

其他测试原则

回归测试

验证之前版本所发现的缺陷确定被修复，修复了旧的的缺陷没有引发心得缺陷产生。

冒烟测试

指的是对新版本软件进行系统大规模测试之前，先验证软件的基本功能是否实现，具备可测试性。通过才进入下一步测试。

随机测试

根据测试人员的直觉和经验，发现一字儿边缘性的错误

monkey测试

自己以一个傻逼的视角，随机对程序操作，看程序的问题。

软件测试的原则

测试用例：一份包含测试步骤的文档，主要体现了软件的功能模块所对应的测试场景

1：所有测试的标准是建立在用户需求之上的

2：测试时时间和质量权衡下，质量起主导地位

3：事先定义好的产品质量标准，这样可以根据测试结果，对产品的质量给出评判和分析

4：项目启动，测试工作开展

5：穷举测试时无法实现的（所有情况）

6：第三方测试可观，有效（原因：节约人力成本，不用考虑人员安排，分摊风险）

7：对于发现错误较多的程序段，应该更深入的测试

8：妥善保存测试过程中的文档，

9：测试应从小规模开始，逐步转变到大规模，并且要持续不断地测试。

通用测试技术

软件测试流程（*）

从项目立项开始软件测试的工作就开展：

《提取测试需求（根据产品需求规格说明书）

《编写测试计划

《制定测试方案

《测试用例的设计（怎么去测试）

《执行测试（用软件按照测试用例，执行测试场景）

《提交缺陷 告

《测试分析与评审

《提交测试 告（测试人员的产出物）

软件测试流程第一个步骤：测试需求的获取

软件需求：

1.定义：a，用户解决问题或者实现目标所需要的条件或者权能例：qq注册操作

b，系统或者系统部件要满足合同，标准，规范所需的条件或权能

（系统或者系统部件指的是软件中的功能，操作该功能是，要遵循的规范要求）

例：qq注册功能：昵称（6-16位字母数字下划线），密码（6-16数字标点字母）

c，将上述出现的情况（条件或者权能）整理成文档，形成了软件需求，它包含了功能性需求，非功能性需求。

总结：需求是明确实现什么样的规格说明。

2.软件需求分类

a，业务需求：指的是从软件功能的业务层面来进行内容分析，包括业务场景，业务流程，要实现该业务是所需的约束条件。

b，系统需求，系统功能性需求，功能性需求指定义了开发人员实现的软件功能，非功能性需求：一般指向的是性能需求

例：微信：上传头像为功能性需求 上传事件的快慢为非功能性需求

测试需求（test requirment）分类

软件需求和测试需求关系：为了更好地实现软件目标，通常掌握了软件需求之后会进行一系列的测试活动，而测试需求的提取往往源于业务需求和系统需求

测试需求的定义（*）：测试需求是测试人员在需求阶段，经过多方渠道收集到的需求，经过可测性的分析而得到的需求。

多方渠道 : 需求说明书，该项目相关的文档（签订合同，协议，沟通纪录，会议纪录）都可参考

可测性分析：指的是提取出来的需求，将来一定是可测试的，会有预期结果的需求。

测试需求分析的意义（*）

a，明确测试范围：

确定需要测试的功能点，以及阐述不需要测试功能点的原因

b，明确测试类型，测试阶段：

测试阶段了解和分析出项目中要进行的功能测试，和非功能测试有哪些；不同的测试类型要涉及到哪些测试阶段

c，识别测试的优先级别，

软件测试活动图

测试需求分析阶段的输入/输出

1.收集测试需求—–>2.分析测试需求 ——>3.参加需求评审大会

最终搞清楚要测什么

收集测试需求——>不同方向

输入：需求规格说明书

输出：原始测试足需求列表

b，分析测试需求—–>进行可测性分析

输入：原始测试需求列表

输出：测试需求跟踪矩阵—->测什么

c，需求评审

输入：测试需求跟踪矩阵

输出：评审结果

最终产出：测试需求跟踪文档—–>测什么

d，收集测试需求的对象（当文档不全面时）：

产品，客户，开发，运维

e，收集测试需求的形式：

面对面沟通，问卷调查

f，收集玩测试需求，就可以进行测试需求分析：测试类型，测试阶段，以及需求文档中未阐述清楚的问题，形成“测试需求跟踪矩阵”

图补充

案例分析：

利用xmind进行需求的提取

以注册界面为例

注意：（*）

测试需求的提取点：不仅要关注好正向需求（满足规则），还要关注反向需求（不符合规则），而且在进行测试需求提取时，多关注反向测试需求点。

测试需求提取：把软件每个模块划分出来，然后再看每个模块所需要的条件（输入项），条件找到后，再来看每个条件的约束规则（正向及反向，没有就不用考虑）