软件测试基础

软件测试的流程

获取测试需求->编写测试计划->制定测试方案->开发与设计测试用例->执行测试->提交缺陷报告->测试分析和评审->提交测试总结->准备下一版本测试。
每个测试的流程都会有相应的文档。

软件测试过程模型

测试过程的理念

V模型

W模型

H模型

这种测试方式一般适用于测试外包公司的测试流程。

X模型

软件测试分类（按照开发阶段进行划分）

单元测试

单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
一般要读程序和代码，一般时候单元测试都是由开发人员自己去完成。但是一般不会认为是在做测试。

集成测试

又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。（接口测试工具和方法）是一个不断持续的过程。

确认测试

有效性测试：验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。一般不作为正式的测试环节。

系统测试

软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，目的在于与系统需求比较，发现问题。
是一个全面的测试，系统所有功能的测试，模拟所有的软件用户操作。

验收测试

以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
不是对系统进行全覆盖测试，而是对核心业务流程进行测试。一般供求双方，三种验收主体：

• α测试：软件的开发商自己进行的，交付前的测试。
• β测试：软件的需求方自己进行测试。
• γ测试：第三方的软件测试。

代码运行

软件测试分类（按照代码运行划分）

静态测试

代码静态分析和文档测试都属于静态测试：
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下：

• 检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
• 静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。

动态测试

动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、等性能。

• （1）动态测试有三部分组成：构造测试用例、执行程序、分析程序的输出结果。
• （2）大多数软件测试都属于动态测试。

软件测试分类（按照软件特征划分）

功能测试

性能测试

安全性测试

软件测试分类（按照测试技术划分）

黑盒测试

黑盒测试也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据。

白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子，去研究里面的源代码和程序结果。
白盒测试也是接口测试的一种。

灰盒测试

灰盒测试是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。
灰盒测试：功能+接口

软件测试分类（按照测试运行主体划分）

手工测试

手工测试是由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一种。

• 优点：自动化测试无法代替探索性测试、发散思维类无既定结果的测试。
• 缺点：执行效率慢，量大易错。

自动化测试

所谓自动化测试，就是在预设条件下运行系统或应用程序，评估运行结果。（预先条件包括：正常条件和异常条件）。简单来说，自动化测试就是是把人为驱动的测试行为，转化为机器执行的一种过程。

自动化测试有：测试自动化、性能测试自动化、安全测试自动化。（一般情况下，我们说的自动化是指功能测试的自动化）
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。
自动化实施的步骤：

• （1）完成功能测试，版本基本稳定
• （2）根据项目特性，选择适合项目的自动化工具，并搭建环境
• （3）提取手工测试的测试用例转换为自动化测试的用例
• （4）通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期
• （5）生成自动测试报告
• （6）持续改进、脚本优化

其他测试分类

回归测试

冒烟测试

随机测试

是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。

猴子测试

测试原则

设计和编写测试用例的区别？
设计是一项脑力活动，编写是一项体力活动，将设计好的内容通过文字的形式表现出来。

测试用例

涉及相关的面试问题

1. 什么是测试用例？
2. 测试用例真的有必要耗费时间进行设计和编写吗？
3. 时间不够用的情况下，还要进行详细的测试用例设计吗?
4. 测试用例需要经常更新吗？（必须更新，尤其是发现过缺陷的测试用例）

测试用例的定义

测试用例的模板

利用excel软件就可实现：
设计测试用例包括：测试用例编号、测试项、依赖用例、测试步骤、输入数据、预期结果

• 测试用例编号：TestCase_项目名称_模块名称_功能名称_0001
• 测试项：用一句话去表明 测试的目的 ，表明你的测试模块，测试对象，方式，事件。（使用谷歌浏览器打开百度首页）
• 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。例如增加一个数据的测试用例，将会被删除数据的测试用例依赖。
• 测试步骤：描述操作的详细步骤。
• 输入数据：单独整合测试数据，必须和测试步骤中的数据保持一致
• 预期结果：准确、对象的准确，内容的准确性，原则上每一个操作都要有一个结果，一般在重要的步骤之后，设定预期结果，与测试目的密切相关，测试目的决定了测试步骤和预期结果。
• 测试结果：在测试执行完成之后添加，没有执行的话就保持为空，测试结果只有两个：通过/失败。Pass/failed；
• 测试人：测试的执行人，可以和设计者相同，也可以不同
• 备注：为了测试用例正常执行而做的特殊准备。例如：专门制造网络不通畅的时候，软件进行错误提示。
  

测试用例的作用和意义

测试用例的设计方法（针对黑盒测试）

没有哪一种设计方法是单独使用的。

• 所有的软件，都是因为某种操作才会导致一定的结果 。----考虑使用因果图
• 所有的软件都有文本框。----考虑必须一定使用等价类、边界值

等价类划分法

针对测试用例选择的方法：就是选择怎样的数据更能提高测试的效果，发现更多的错误。
等价类的划分不固定，只要有正确的理由即可。



用例设计的实例说明：
要求

等价类：

测试用例：

边界值分析法

例子
在选取边界值的时候，需要选择边界值和此边界值。

1）5，6，7；11，12，13
2）6和12属于无效数据，那么7和11变成了边界，所以选择的边界值是：6，7，8；10，11，12

因果图法

原因和结果的关系：

• 恒等：原因a成立，结果b一定成立
• 非：原因a成立时，结果b一定不成立
• 或：原因a，b，c三个有一个成立，结果d就一定成立
• 与：原因a，b，c三个全部成立结果d才会成立
  

判定表法

场景法

正交实验法

统计和分析实验数据，本质就是从大量的实验中找到合适的实验数据组合。（原本是用于工业生产的数据组合与实验室的数据挑选）。从大量的实验组合中，挑选出来一部分具有代表性的点，进行实验，分析数据。




可以利用正交实验工具进行设计。

功能图法

用的比较少

其他用例设计方法

测试大纲法

无需用例设计。一般从根节点开始分析，到叶节点为止，这样的一条路径就是一条测试用例。
一般用于快速的测试和记录过程，用例一般进行后补。

探索式测试法

基于经验和直觉
是计划内测试用例设计的补充。
探索式测试执行前也需要设计测试用例

猴子测试（随意性测试）

用例设计方法综合选择

所有的测试用例的设计方法，没有独立使用的。都是融合在一起使用的。往往在一个软件的界面中，都可以使用好几种测试用例的设计方法。

软件测试中的缺陷

缺陷的定义

缺陷的属性

缺陷的类型

需求分析，设计阶段，文档类型的缺陷多；
集成测试阶段，一般接口类型的缺陷多一些；
系统测试阶段，功能、界面类型的缺陷多一些；
验收测试阶段，更多的关注性能缺陷；
实施过程，可能会遇到一些软件包的缺陷

缺陷的严重程度

缺陷的严重程度是指因缺陷引起的故障对软件产品的影响程度。
每个公司对严重程度的定义可能会有所不同。

缺陷修复的优先级

很大程度上取决于缺陷对测试工作的影响程度。优先级的衡量，一般可以根据测试的软件系统的全业务流程划分。软件的基本功能的缺陷，优先级高；
软件的备选流、基本功能中的反向测试的内容，优先级较低，有些可改可不改
面试题：缺陷的严重程度和缺陷的优先级有什么关系？
1.两者之间没有任何直接的关系。
2.严重的缺陷优先级不一定高；
面试题：提交缺陷的时候能不能夸大缺陷的严重程度和优先级？
不能

缺陷的状态

缺陷的来源

一般关注较多的是缺陷的来源（直接原因），在测试总结的时候，关注的是缺陷的根源。

缺陷的生命周期

• 发现缺陷：由测试人员
• 提交缺陷：由测试人员
• 确认缺陷：一般由测试主管、质量保证、或者产品经理进行确认
• 分配缺陷：经确认之后，一般有谁确认的缺陷就由谁分配，分配的对象可能是开发，UI，或者是产品经理。
• 修复缺陷：主要由开发进行修复，或者是产品经理修复问题，或者UI。
• 验证缺陷：测试人员去验证缺陷是否修复成功。
• 关闭缺陷：经验证之后，由测试人员进行关闭。一般出现问题，要关闭缺陷的人员进行背锅。
  面试题：针对工作中发现的一个bug，说说这个bug的处理过程。（缺陷的生命周期中，每一个环节由谁做什么）

缺陷的识别

缺陷报告的撰写

跟测试用例的编写类似，利用excel进行。

• 缺陷编号：Bug_项目名称_模块名称_功能名称_0001。
• 所属模块：一级模块/二级模块/三级模块
• 优先级：缺陷的修复紧急程度。p1>p2>p3>p4
• 严重程度：s1>s2>s3>s4
• 缺陷概述：用一句话描述缺陷的基本情况
• 缺陷的描述：将缺陷的复现步骤、预期结果和实际结果列出来。
• 提交人：
• 备注：一般写产生该缺陷的一些特殊情况。如果没有特殊情况的话，可以将缺陷的截图进行截图。
  
  
  
  

测试需求和测试用例、缺陷报告的关系？

测试的基本流程：
获取测试需求、编写测试计划、指定测试方案、设计和开发测试用例、执行测试、提交缺陷、测试分析和评审、测试总结、准备下一版本的测试。
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。
有了测试需求之后，就开始对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此在测试过程中，衡量需求的覆盖程度，就非常重要。使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数。
如果需求覆盖度<100%,那一定说明了测试的覆盖度不够。