![](https://img-blog.csdnimg.cn/584c5e77a497488381329a9591173084.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
软件评测师考试笔记(已完结)
文章平均质量分 78
对软件评测师考试的知识点进行整理;笔记的主要展示方式为“定义+举例”。
是李黏黏鸭
这个作者很懒,什么都没留下…
展开
-
第29章 人工智能时代下的软件测试技术发展
与人相似的思维和响应方式的计算机技术。原创 2022-10-17 19:56:27 · 832 阅读 · 0 评论 -
第28章 可信软件验证技术
NSTC1997年,美国科学与技术委员会认为,即使系统在存在错误、环境存在故障、系统遭受破坏的情况下,设计者、实现者、用户都能够极大地去保证系统不失效、或表现不好的系统就是可信的NRC美国国家研究委员会认为系统在崩溃、人为操作失误、恶意攻击、系统存在设计或实现错误的情况下,也能够按照预期运行的系统是可靠的国家自然科学基金委2008年,国家自然科学基金委认为可信软件就是,客观的对诸多属性在人们心目中一个综合的反应;原创 2022-10-17 19:57:20 · 1025 阅读 · 0 评论 -
第27章 大数据系统测试
是指无法在一定时间内用常规的软件工具来进行捕捉、管理和处理的数据的集合。原创 2022-10-17 19:57:28 · 1216 阅读 · 0 评论 -
第26章 物联网软件系统测试
物联网是一个基于互联网、传统电信网等信息承载体,让所有能够被独立寻址的普通物理对象实现互联互通的网络。简单理解物联网是把所有物品通过信息传感设备与互联网连接起来,进行信息交换,即物物相息,以实现智能化识别和管理。具有普通对象设备化、自治终端互联化和普适服务智能化3个重要特征。设备层是指部署物联网的解决方案时所使用到的硬件,即“物”的实体通信层是指安全发送/接受数据的媒介,即物联网解决方案中的连接网络云平台层是指物联网解决方案的后端,主要用于对接收到的数据进行分析和处理。原创 2022-10-17 19:57:36 · 3250 阅读 · 0 评论 -
第24章 分布式架构软件测试
分布式架构是指在一个分布式系统中,一组独立的计算机展现给用户的是一个统一的整体,就好像是一个系统似的。分布式 : 将一个单体项目分成很多个模块,各个模块协同工作,各个模块构成了分布式系统;集群:针对单个模块或者单个系统在多台服务器上部署,称为集群。为了提高系统的可用性,增加系统的负载。原创 2022-10-17 19:57:00 · 1780 阅读 · 1 评论 -
第23章 微内核架构软件测试
微内核:微内核就是精简的内核,集成的功能相对宏内核来说要少,要实现其他的功能可能需要在内核之外写程序,并且通过内核来调用实现。宏内核:相当于一个是一个中央集权控制中心,把内存管理,文件管理等功能全部管理,例如Windows、linux。由图可知,微内核机构是在内核系统下挂了很多插件,所以也称为插件架构;软件的内核相对来说比较小的组件,内核只包含软件运行的最小的功能,主要功能、业务规则和业务逻辑都是通过插件模块来实现的;将功能从架构中剥离出来了,降低了架构的复杂性;原创 2022-10-13 21:54:07 · 1149 阅读 · 0 评论 -
第22章 事件驱动架构软件测试
指 状态的显著变化;例如有一个超链接,将鼠标放到超链接上是一个状态,点击超链接后又是另一个状态;从来源来分,事件可以分为系统内部事件和外部事件;从类型来分,可以分为业务事件和系统事件。原创 2022-10-13 21:07:17 · 967 阅读 · 0 评论 -
第21章 分层架构软件测试
技术人员和客户代表对代码服务相关的技术进行详细的交流,由此确定代码审计的方案(哪些代码要审计、用什么方式审计、审计的时间、审计的要求等)代码审计报告提交和沟通之后,跟开发人员针对代码审查发现的问题进行修改,然后代码审查人员进行回归的检查,然后提交复查的报告;本层不需要了解其它层的实现细节,只需要考虑与本层相关的两层之间的接口和调用的情况。然后对客户要求的功能点进行人工的代码审查,对源代码的扫描结果进行人工的分析和确认;结合自动化扫描的结果和人工审查的结果生成测试对象的代码审查报告,最后提交给客户;原创 2022-10-13 19:36:34 · 2019 阅读 · 0 评论 -
20.5-风险分析和缓解措施设计 20.6-测试级别与测试实施 20.7-测试估算与平衡策略
20.5-风险分析和缓解措施设计 20.6-测试级别与测试实施 20.7-测试估算与平衡策略原创 2022-10-13 07:52:22 · 468 阅读 · 0 评论 -
第20章 基于风险的测试技术 20.1-项目实践中的测试实施实践 20.2-基于风险的测试计划制定 20.3-基于风险测试的相关概念 20.4-基于风险的测试计划
基于软件测试项目会遇到的、或面临的威胁来考虑如何进行测试的一种技术。思想:把软件发布之后会面临的风险分解到对应的软件质量特性上面去,根据对应的质量特性,再决定应该采用什么样的措施、什么样的策略来进行测试。原创 2022-10-11 18:57:00 · 293 阅读 · 0 评论 -
第19章 基于质量特性的测试技术
通过对系统体系架构和功能模块的分析以及系统用户的分布和使用频率的分析,来构造系统综合场景的测试模型,模拟不同用户执行不同操作,最大限度模拟系统真实场景,使用户预知系统投入使用后的真实性能水平,从而对系统做出相应的优化及调整,避免实际情况中出现系统长时间不响应及崩溃的情况。目的是对检查点进行压力测试,预测系统投入使用后在检查点能够承受的用户压力情况,并根据相应的响应时间和各项资源使用情况分析、确定系统存在的性能瓶颈,为系统的优化和调整提供依据。资源利用性主要考察系统所采用的各种资源的利用程度。原创 2022-10-09 21:23:34 · 1422 阅读 · 1 评论 -
第18章 基于经验的测试技术
是基于创造性、经验的测试方法。测试人员基于现有相关的知识、测试项、前期的探索以及相关软件行为和故障类型的启发,自发的设计和执行测试的测试方法。可以辅助测试人员在实际开始测试之前建立起一个全局的目标,确定对软件进行探索性测试的整体的方向,以便系统化的方式组织测试工作,从而尽量覆盖软件的复杂程度及特性。探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试,在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。在测试设计不充分的情况下,探索性测试可以基于之前类似的测试和结果进行测试。原创 2022-10-09 08:23:19 · 616 阅读 · 0 评论 -
第17章 自动化测试技术
自动化测试就是把人为的驱动测试行为转化为机器执行的一种过程。就是模拟人手工的测试步骤,通过执行由程序语言编制的测试脚本自动的完成软件的测试设计、测试执行、单元测试、功能测试等相关的工作。对于整个测试技术来讲,测试自动化不仅是技术、工具的问题,更是一个公司和组织的文化问题。原创 2022-10-08 21:02:18 · 1579 阅读 · 0 评论 -
16.16 -基于结构的测试技术历年下午题型考点
当控制流分叉之后还有分叉(if...else...语句后还有并行的if...else...语句),控制流图中不需要汇聚结点,直接将上一个分叉的控制流连到下一个分叉的控制流即可。例如程序控制流在分叉之后直接结束了,没有这两个分叉共同执行的后续代码,就需要加一个空圈圈作为汇聚结点( 分叉之后没有闭合就需要加一个汇聚结点);当一段程序代码在执行的过程中没有共同执行的部分,就需要在程序的控制流图后加一个汇聚结点(一个空圈圈);(2)使得每个判定条件的每个结果(真和假)在程序中都被覆盖到。(1)找出所有判定;原创 2022-10-08 19:29:22 · 1177 阅读 · 0 评论 -
16.13-基于结构的测试辅助技术 16.14-测试覆盖准则 16.15-最小测试用例数计算
16.13-基于结构的测试辅助技术 16.14-测试覆盖准则 16.15-最小测试用例数计算原创 2022-10-07 16:11:55 · 1015 阅读 · 0 评论 -
16.12 - 基于数据流设计用例
给变量赋值的过程叫做定义;给变量赋一次值,叫做定义一次,也就是说在程序的运行过程中对一个变量可能会进行多次定义,定义可能是给了变量一个新的值,也有可能等于原来的值;从变量定义到使用(计算使用或谓词使用)的控制流子路径从每个变量定义到该定义的每次使用(包括谓词使用和计算使用)的所有控制流子路径例如当定义到计算使用有两条路径时,全使用只需要测试其中一条路径即可,但是全定义--使用必须把这两条路径都测试了变量定义到使用(计算使用或谓词使用)的子路径。原创 2022-10-07 16:11:33 · 2532 阅读 · 3 评论 -
16.4-基于控制流设计用例 16.5-语句测试 16.6-分支测试 16.7-判定测试 16.8分支测试与判定测试的区别 16.9分支条件测试 16.10分支条件组合测试 16.11修正条件判定测试
找出入口之后看这个语句是否产生出口,就是看这条语句是否跳出去,没有跳出的话继续看下条语句是否有多个跳出的点,是不是出口......将所有的入口和出口找好了,那么程序的基本块也就划分好了。设计足够多的测试用例,来确定各个条件能够影响到包含的判定结果,这要包括两个条件,第一个是每个程序的入口到出口点至少要被调用一次,每个程序的判定的所有可能的结果值要转换一次,程序判定被分解为通过逻辑操作and和or连接的布尔条件时每个条件对判定结果的值是独立的(两次计算)。判断a与b或c的运算结果,为真时执行x=1;原创 2022-10-06 23:02:47 · 1091 阅读 · 0 评论 -
16.3-数据流分析 、接口分析、表达式分析、基于结构的动态测试用例设计原则
数据流分析 、接口分析、表达式分析、基于结构的动态测试用例设计原则原创 2022-10-06 20:31:48 · 616 阅读 · 0 评论 -
16.2 - 控制流分析
Switch(变量):Switch后的括号中是变量,变量的比较是在case语句中进行的,Switch和case组合在一起才是一个判定,所以绘制控制流图的时候需注意,要将Switch和case绘制到一个结点(一个圆圈),而不是两个圆圈。:当一段程序代码在执行的过程中没有共同执行的部分,就需要在程序的控制流图后加一个汇聚结点(一个空圈圈)。until循环:先判断循环条件,当循环条件为假时执行循环体的内容,执行完循环体的内容后返回判断点,再次判断循环条件,当循环条件为真时,跳出循环执行循环后面的语句结构。原创 2022-10-06 18:07:13 · 3600 阅读 · 1 评论 -
第16章 基于结构的测试技术(白盒测试技术) 16.1 - 静态测试技术
代码检查一般是在编译和动态测试之前。能够快速的找出软件的一些缺陷,而且看到的是缺陷的本质而不是表面现象。(黑盒测试看到的就是缺陷的表面现象,也就是能看到缺陷,但是缺陷的原因还需要去调查。)有效的组织代码检查能够有效的发现30%~70%左右的逻辑设计和编码的缺陷。但是这种测试的效率比较低,而且对测试人员的经验和知识有一定的要求。静态分析是一种检查代码的方法,该方法无需执行程序;原创 2022-10-06 13:43:07 · 586 阅读 · 0 评论 -
15.18 - 历年下午题典型考点
航空公司开发了一个程序来计算会员在该促销活动后的奖励,程序的输入包括会员在活动期间的乘机次数C、官网购票金额A(单位:元)、和手机客户端购票金额B(单位:元),程序的输出为本次活动奖励档次L。其中C、A、B为非负整数,L为0~5之间的整数(0表示无奖励)。(1)无法体现出C、A/B之间的制约关系,比如当满足A/B(转换后对应的点数满足),但不满足C(乘机次数)的情况。采用等价类划分法对该程序进行测试(同时对输入输出进行等价类划分),等价类表入表2-3所示,请补充表2-3的空(1)~(4)。原创 2022-10-05 20:12:06 · 736 阅读 · 0 评论 -
15.12-随机测试、15.13-测试设计方法选择策略、15.14-测试用例的编写、15.15-测试设计规格说明书、15.16-测试用例规格说明、15.17-测试规程规格说明
这种测试技术不需要对测试的输入域进行划分,仅要求输入值是从输入域当中随机选择的。原创 2022-10-05 18:06:03 · 317 阅读 · 0 评论 -
15.11 - 场景测试
可以再补充一个:结算选择错误后返回基本流,结算选择正确后继续执行,验证码验证失败1次后再返回基本流,输入正确验证码,是否结算成功的测试用例。从一个流程开始,通过描述所经过路径的过程,从而达到遍历所有可能的基本流和备选流的场景,完成对系统功能的测试这就是场景法。验证用户密码失败:验证用户密码错误(3次),锁定用户,并返回发起结算界面。验证用户密码失败3次时,提示验证失败3次,结算失败,返回发起结算界面。发起结算失败时,提示发起结算失败原因,返回发起结算界面。发起结算,结算选择,验证用户密码,结算完成。原创 2022-10-05 16:50:23 · 988 阅读 · 0 评论 -
15.10 - 状态转移测试
把软件若干种状态之间的转换条件和转换路径抽象出来,从覆盖所有状态转移路径的角度去设计测试用例,关注状态的转移是否正确。原创 2022-10-05 14:50:12 · 1561 阅读 · 0 评论 -
15.9 - 因果图法
等价类划分法和边界值分析法都是着重考虑输入条件,但没有考虑输入条件的各种组合,输入条件之间的相互制约关系,这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被疏忽了。根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合,从而设计测试用例。从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出结果),它适合于检查软件的输入条件涉及的各种组合情况,最终生成的是判定表。各结点表示状态,可取“0”或“1”,0表示某状态不出现,1表示某状态出现。原创 2022-10-05 14:05:22 · 2907 阅读 · 0 评论 -
15.8 -判定表测试
在很多情况下的输入条件之间会存在制约关系,不同的条件组合会产生不同的操作结果,例如输入1执行代码A、输入2执行代码B,输入1和2得到的结果不同;这种不同的输入执行不同的操作的情况下,可以选择判定表进行测试,判定表能将复杂的条件组合表达的更加明确。通过因果图生成执行条件的组合到结果之间的关系,再转成判定表。合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件。本来是两条规则,但是无论条件c的条件项的值是什么,都不影响最后执行动作项1,所以可以将条件c的条件项合并,用符号“-”表示。原创 2022-10-04 20:40:04 · 1405 阅读 · 0 评论 -
15.7- 组合测试
界面上有多个选项,每个选项下面又有多个选值,对于这个界面测试的组合会非常的庞大,很容易产生组合爆炸;组合测试的目的就是为了在组合爆炸的情况下提供一种相对合理的测试解决方案,在保证错误检出率的前提下,采用较少的测试用例进行测试。原创 2022-10-04 19:22:04 · 5352 阅读 · 0 评论 -
15.6 - 语法测试
很多程序设计的说明书是采用形式化的方法进行描述的,对于这种程序规格说明书可以采用语法测试的技术进行测试。形式化的描述方法采用的是巴克斯范式,巴克斯范式是一种通过递归的思想来表达计算机语言符号集的定义规范。原创 2022-10-03 21:06:31 · 686 阅读 · 0 评论 -
15.5 - 边界值法
边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。原创 2022-10-03 20:28:41 · 1549 阅读 · 0 评论 -
15.4 - 分类树法
也就是说单一组合只需考虑一个测试条件,只要这个测试条件的取值都被覆盖了就行,无需考虑条件之间的组合。:不划分也可以,因为食物的子集之间不存在重叠的情况。将输入域拆分成子集,按照分类树划分,两个子集之间是完全不相交的,就是不存在重叠的情况。分类树生成测试用例的组合可能有多种方式,因为分类树生成测试用例用的是单一组合方式。基于测试特征集、测试条件,生成分类树,将测试条件的输入补充到分类树中。分类树法生成的测试用例的数量,一般是测试条件里输入最多的取值。是另一种将程序的输入划分子集的方法。TCOND1:目的地。原创 2022-10-02 16:07:03 · 1915 阅读 · 0 评论 -
15.3-等价类划分
但是无效等价类a输入程序已经报错了,根本不会再去判断等价类b,所以错误信息中只包含无效等价类a的错误信息,其实无效等价类b也是错误的。一个软件中要求用户输入以年月表示的日期,假定日期的输入范围限定在2000年1月至2100年12月之间,并且规定日期由6位数字字符组成,前4位表示年,后2位表示月,那么对应的“日期输入格式检查”这一功能的等价类。在确知已划分的等价类中,各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。3、设计一个新的测试用例,使其只覆盖一个无效等价类。原创 2022-10-02 14:29:18 · 2466 阅读 · 0 评论 -
第15章 基于规格说明的测试技术 15.1 - 基于规格说明的测试的概述 15.2 - 测试用例设计方法
黑盒测试:黑盒测试也称为功能测试、基于规格说明书的测试、基于数据驱动的测试。本章中讲的基于规格说明中的测试技术就是黑盒测试相关的测试技术。黑盒测试就是将软件看成一个不透明的黑色盒子,看不到盒子内部程序的结构和逻辑,只能看到外部输入了什么、输出了什么、有哪些需求。黑盒测试是基于产品规格说明书的功能,从用户的角度去考虑产品的功能、特性并且去验证它。原创 2022-10-01 16:35:11 · 941 阅读 · 0 评论 -
第14章 软件测试过程和管理
收集相关信息,并将收集到的信息应在试验完成报告中进行评估和总结。可以从以下文件但不限于:测试计划(例如,项目测试计划、系统测试计划或性能测试计划);测试结论;测试状态报告;各个测试阶段和测试类型的完结报告,及事件报告。原创 2022-10-01 15:36:10 · 1365 阅读 · 0 评论 -
13.8 - 软件测试工作量及成本估算 3.9 - 软件测试成本估算示例
系统风险性中,软件完整性定义为B,完整性因子范围是1.3~1.5;系统风险性低,软件完整性定义为C,完整性因子范围是1.1~1.2;系统风险性微小,软件完整性定义为D,完整性因子范围是1.0;A级完整度的软件测试成本高于D级软件测试的成本。原创 2022-09-17 17:25:51 · 2678 阅读 · 2 评论 -
13.4-软件测试标准 13.5-测试过程标准 13.6-测试文档标准 13.7-测试技术标准
软件测试标准 、测试过程标准 、测试文档标准、测试技术标准原创 2022-09-17 14:30:46 · 976 阅读 · 0 评论 -
第13章 软件测评相关标准 13.1-标准化的概述 13.2-软件质量模型与评价标准
软件测评相关标准、标准化的概述、软件质量模型与评价标准、使用质量、产品质量原创 2022-09-16 20:03:09 · 1283 阅读 · 0 评论 -
12.9-测试类型:回归测试、按关联代码划分、按实施主体划分、按工程阶段划分、按执行代码划分、按质量特性划分、按符合性情况划分
12.9-测试类型:回归测试、按关联代码划分、按实施主体划分、按工程阶段划分、按执行代码划分、按质量特性划分、按符合性情况划分原创 2022-09-13 20:53:19 · 432 阅读 · 0 评论 -
12.4-测试与质量保证 12.5-测试用例 12.6-测试策略 12.7-软件测试的原则 12.8-软件测试模型
无法对软件进行全局的、各种可能的测试,因为软件测试毕竟也是一个项目,也会受到时间和资源的限制,所以软件测试需要在符合指定的要求和测试强度之间找到一个合理的点,设置测试的终止条件。针对敏捷开发方法的测试模型就是敏捷测试模型。测试是为了降低软件质量的风险,但是测试本身也是有风险的,在制定测试策略时,应该考虑测试的风险,利用风险管理原则对软件测试的风险进行相关的管理。也就是说基于测试的需求、风险评估的结果去定义测试的范围、测试的要求,选择合适的测试方法,然后去制定测试启动、测试停止、测试完成的标准和条件。原创 2022-09-12 20:23:06 · 642 阅读 · 0 评论 -
第12章 软件测试基础 12.1-软件测试 12.2-验证与确认 12.3-软件缺陷
73年的Bill Hetzel给出了软件测试的第一个定义,他认为软件测试是为了向人证明程序能够按照预定的、设想的运行而建立信心的。(为了表明软件是正确而测试的正向性测试)79年的Myers认为,软件测试是为了发现错误而执行的一个程序或者系统的过程。(为了表明软件是错误而测试的反向性测试)1983年Bill Hetzel将软件测试的定义修改为,以评价一个程序和系统的特性或能力,并确定它是否达到预期的结果为目的的任何行为就是软件测试。(按照需求来进行测试,符合需求的则认为测试通过,不符合的则认为有bug。原创 2022-09-12 16:16:00 · 552 阅读 · 0 评论 -
11.32-投影与select语句 11.33-选择与select语句 11.34-笛卡尔积与select语句 11.35-θ连接与select语句 11.36-自然连接与select语句
11.32-投影与select语句 11.33-选择与select语句 11.34-笛卡尔积与select语句 11.35-θ连接与select语句 11.36-自然连接与select语句 11.37-关系代数查询优化准则原创 2022-09-11 22:34:37 · 945 阅读 · 0 评论