软件测试复习笔记
软件测试复习笔记
-
- 软件缺陷：
-
- 来源：
- 等级：
- 哪些属于软件缺陷：
- 缺陷报告包含的基本信息：
- 决策表/判定表法：
- 白盒测试与黑盒测试：
-
- 测试需求分析：
- 测试用例：
- 等价类：
- 基于逻辑覆盖的方法：
- 测试修改后，测试用例为何需重新测试（回归测试）：
- 接口测试的目的：
- 软件测试解决了什么问题：
软件缺陷：
IEEE Standard 729的定义：
（1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
（2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
其他来源的定义：
- 软件未实现产品说明书中所提及的功能
- 软件实现了产品说明书中不应该提及的功能
- 软件未实现产品说明书中虽未提及但应该实现的功能
- 软件实现了产品说明书中未提及的功能
- 软件使用不方便，难以理解，从测试的角度觉得用户认为不好
来源：
规格说明书、系统设计结果、编程的代码
造成软件缺陷的主要原因：
1.技术问题
(1)开发人员技术的限制，系统设计不能够全面考虑功能、性能和安全性的平衡。
(2)刚开始采用新技术，解决和处理问题时不够成熟。
(3)由于逻辑过于复杂，很难在第一次就将问题全部处理好。
(4)系统结构设计不合理或算法不科学，造成系统性能低下。
(5)接口参数太多，导致参数传递不匹配。
(6)需求规格说明书中有些功能在技术上无法实现。
(7)没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等需求，导致系统存在安全性、可靠性的隐患。
(8)一般情况下，对应的编程语言编译器可以发现这类问题；对于解释性语言，只能在测试运行的时候发现。
2．软件本身
(1)不完善的软件开发标准或开发流程。
(2)文档错误、内容不正确或拼写错误。
(3)没有考虑大量数据使用场合，从而可能会引起强度或负载问题。
(4)对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某几个边界条件造成的问题。
(5)对一些实时应用系统，缺乏整体考虑和精心设计，忽视了时间同步的要求，从而引起系统各单元之间不协调、不一致性的问题。
(6)与硬件、第三方系统软件之间存在接口或依赖性。
3．团队工作
(1）团队文化，如对软件质量不够重视。
(2）系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难，从而造成对用户需求的误解或理解不够全面。
(3）不同阶段的开发人员相互理解不一致，软件设计对需求分析结果的理解偏差，编程人员对系统设计规格说明书中某些内容重视不够，或存在着误解。
(4）设计或编程上的一些假定或依赖性，没得到充分的沟通。
等级：
缺陷的严重程度
含义：由于缺陷引起的故障对软件产品的影响程度
缺陷的优先级
含义：指缺陷被修复的紧急程度
哪些属于软件缺陷：
· 功能、特性没有实现或部分实现
· 设计不合理，存在缺陷
· 实际结果和预期结果不一致
· 运行出错，包括运行中断、系统崩溃、界面混乱
· 数据计算结果不正确、精度不够
· 用户不能接受的其他问题，如存取时间过长、界面不美观
缺陷报告包含的基本信息：
· 缺陷标题
· 缺陷类型
· 重现步骤
· 预期结果
· 实际结果
· 缺陷优先级
· 附件
决策表/判定表法：
五个元素：
条件桩（ Condition Stub )：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
动作桩（ Action Stub )：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
条件项（ Condition Entry )：列出针对它所列条件的取值。在所有可能情况下的真假值。
动作项（ Action Entry )：列出在条件项的各种取值情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作。
白盒测试与黑盒测试：
定义：
白盒测试也称结构化测试或逻辑驱动测试，主要用于检测软件编码过程中的错误。已知产品的内部工作过程，清楚最终生成软件产品的计算机程序结构及其语句，测试程序内部的变量状态、逻辑结构、运行路径等，检验程序中的每条通路是否都能按预定要求正确工作，检查程序内部动作或运行是否符合设计规格要求，所有内部成分是否按规定正常进行。
特性：
- 基于代码
- 尽可能覆盖实现的行为
黑盒测试也称数据驱动测试，主要检测软件的每一个功能是否能够正常使用。在完全不考虑程序内部结构和内部特性的情况下，测试人员针对软件直接进行测试。
黑盒
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qF2rmWKP-1655047373613)(C:\Users\86151\AppData\Roaming\Typora\typora-user-images\1653215008897.png)]
测试需求分析：
1）详细了解并深挖需求
2）确定测试范围
测试用例：
测试用例是为了特定的测试目的而设计的测试条件、测试数据及与之相关的测试规程的
一个特定的使用实例或场景。
测试用例解决的问题：
（1）测试用例是测试人员在测试过程中的重要参考依据。
（2）测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的
测试操作。
（3）良好的测试用例不断地被重复使用，使得测试过程事半功倍。
（4）测试用例是一个知识积累的过程。
作用：
（1）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
（2）测试用例的使用令软件测试的实施重点突出、目的明确。
（3）在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩
短项目周期。
（4）检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计
冒烟测试：指在对一个新版本进行系统大规模测试之前，先验证一下软件的基本功能是否实现，是否具
备可测性。
**功能测试：**根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设
计需求。
性能测试：主要关注软件中的某一功能，在指定的时间、空间条件下，是否使用正常。软件
的性能包括很多方面，主要是时间性能和空间性能两种。
**自动化测试：**利用工具软件，或者编写代码的方法，测试被测的软件系统。
安全测试： 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非
法入侵，不受各种因素干扰。
回归测试：是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
**压力测试：**模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运
行 测试软件，来测试被测系统的性能、可靠性、稳定性等。
**容错性测试：**检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者
某种灾难性恢复的手段
**验收测试：**软件产品检验的最后一个环节，按照项目任务或合同、供双方约定的验收依据文
档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
等价类：
是某个输入域的子集，在该子集中每个输入数据的作用是等效的。
**有效等价类：**指输入完全满足程序输入的规格说明、有意义的输入数据所构成的集合，利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。
**无效等价类：**和有效等价类相反，不满足程序输入要求或者无效的输入数据构成的集合。使
用无效等价类，可以测试程序/系统的容错性——对异常输入情况的处理。
基于逻辑覆盖的方法：
**判定覆盖法：**设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至
少经历一次，即判断真假值均曾被满足
**条件覆盖：**设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至
少满足一次（每个条件）。
判定-**条件覆盖：**判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件
中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
测试修改后，测试用例为何需重新测试（回归测试）：
1）验证之前版本产生的所有缺陷已全部被修复
2）确认修复这些缺陷没有引发新的缺陷。
例如：修改了数据库字段名，会引起相关错误。
接口测试的目的：
接口测试是测试系统组件间接口的一种测试，主要用于测试系统与外部其他系统之间的接口，以及系统内部各个子模块之间的接口。测试的重点是要检查接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性，以及对各种异常情况的容错处理的完整性和合理性。
软件测试解决了什么问题：
软件测试保证了软件质量。