软件验证与确认复习大纲
考试题型:
- 选择题10题,10*2
- 判断题10题10*2
- 设计题2题2*15
- 分析题2题2* 15
大题范围:场景、类测试、性能和bug管理
复习大纲:
- 、测试的基本定义和缺陷基本的概念,理解测试的流程,阶段。对一些概念性问题能够进行叙述和判断。
软件测试就是“验证(Verification)”和“有效性确认(Validation)”活动构成的整体,“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。
软件缺陷: 即bug小虫子。
- 软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好;
- 软件未达到需要规格说明书中指明的功能;
- 软件出现了需求规格说明书中指明不会出现的错误;
- 软件功能超出需求规格说明书中指明的范围;
- 软件未达到需求规格说明书中虽未指出但应达到的目标。
测试的流程:测试需求分析、制定测试计划、测试设计、实施测试、建立和更新测试文档(测试评估)。
软件质量保证的概念以及它和软件测试的区别,联系。
软件的质量保证就是向用户及社会提供满意的高质量的产品,确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。
软件质量保证与软件测试二者之间既存在包含又存有交叉的关系。测试可以查找错误并进行修改,从而提高软件产品的质量。软件质量保证则是避免错误以求高质量,并且还有其他方面的措施以保证质量问题。
从共同点的角度看,软件测试和软件质量保证的目的都是尽力确保软件产品满足需求,从而开发出高质量的软件产品。两个流程都是贯穿整个软件开发生命周期中。
软件质量保证(SQA)侧重对流程中过程的管理与控制,是一项管理工作,侧重于流程和方法。而测试是对流程中各过程管理与控制策略的具体执行实施,其对象是软件产品(包括阶段性的产品),即测试是对软件产品的检验,是一项技术性的工作。测试,常常被认为是质量控制的最主要手段。
- 不同测试阶段的测试内容,区别。
单元测试:(指对软件中的最小可测试单元或基本组成单元进行检查和验证)
内容:静态检查和动态测试
(对被测单元功能的测试属于黑盒测试,而对模块代码所做的测试为白盒测试)
集成测试:
内容:模块之间的接口以及集成后的功能。
(不经过单元测试的模块是不应进行集成测试的,否则将对集成测试的效果和效率带来巨大的不利影响)
系统测试:
内容:功能测试、性能测试、安全性测试、兼容性测试、用户界面测试、可安装性测试
系统测试与单元测试和集成测试的主要区别:
- 系统测试不仅限于软件。为保证交付给用户的软件产品能够在实际的用户使用环境下运行正常,系统测试是涉及软件、硬件、网络等多方面因素的过程,而单元测试和集成测试主要针对软件进行测试;
- 系统测试不能忽略。一般地,对于开发人员来说,系统测试是产品交付给用户前的最后一个测试环节,占有重要的地位。当面临紧迫的交付压力时,单元测试和集成测试很可能被取消,但系统测试只能被压缩,不可能完全不做系统测试。
- 测试方法不同
- 测试对象和目标不同
- 评估基准不同
2.黑盒测试白盒测试的优缺点
黑盒测试:
优点:对测试人员的技术要求相对较低;不需要了解程序实现的细节;
缺点:测试结果的覆盖度不容易度量,测试的潜在风险较高;
白盒测试:
优点:针对性强,测试效率高,通过不同的白盒覆盖指标有助于衡量对被测对象的测试覆盖程度;在函数级别开始测试工作,缺陷修复的成本低;
缺点:对测试人员的技术要求高,没有一定编程经验的人是无法做白盒测试的。
- 黑盒的常用方法设计用例,包括主要使用的方法,和利用这些方法实际设计用例,主要以课上讲解和章节的课后习题为主。
黑盒测试方法:
- 功能层面的测试方法,侧重于系统业务流程的梳理,基本思想是基于动态业务过程设计用例,目标是希望测试能完全覆盖所有的主业务流程,保证系统在各功能点交叉约束条件下能实现用户期望的基本功能。典型方法为:基于场景的测试。(必考)
- 函数层面的测试方法,侧重于系统测试数据的选择,基本思想是基于静态的测试数据来设计用例,目标是希望测试能完全覆盖所有的无效和有效输入或输出域,并重点覆盖边界及边界附近的数据,保证系统对所有可能的输入情况都正确处理。典型方法为:边界值测试、等价类测试、基于决策表的测试和基于正交表的测试。
- 白盒的常用方法设计用例,包括主要使用的方法,和利用这些方法实际设计用例,区分语句覆盖和路径覆盖,主要以课上讲解为主。
动态白盒测试:对判定的测试、对路径的测试、对循环的测试
静态白盒测试:同行评审、静态结构分析、代码质量度量、对变量的数据流测量;
语句覆盖:选取足够多的测试数据,使被测试程序中每个语句至少执行一次;
路径覆盖:选取足够多的测试数据,使被测试程序中每一条可执行路径至少执行一次;
- 章节习题,包括基本路径测试,画控制流图,环路复杂度,用例设计
基本路径测试方法:
以设计或代码为基础,画出相应的流图。
计算结果流图的环形复杂度
确定独立路径的一个基本集。
准备测试用例,强制执行基本集中的每条路径 (一定要有输入、输出)
计算流图G的环路复杂度V(G)=边的条数-节点个数+2
一条新路径必须包含一条新边。
- 面向对象测试的ppt中涉及到的一些基本概念,包括面向对象软件测试的特点,类测试的特点,和与传统的测试的区别等等。理解面向对象软件,特别是类测试的关键问题。 详情请见ppt第10讲。(必考)
面向对象软件测试层次:
①方法级(Method Level),测试类中定义的每个操作(方法、过程或函数);
②类级,考察封装在一个类中的方法和数据之间的相互作用;
③类簇级。考察一组协同操作的类之间的相互作用;
④系统级。考察由所有类和主程序构成的整个系统。
面向对象(object-oriented) = 对象 + 分类 + 继承 + 通信
传统的测试计算机软件的策略是从“小型测试”开始,逐步走向“大型测试”,且单元测试集中在最小的可编译程序单位——子程序。
面向对象程序的结构不再是传统的功能模块结构,而是作为一个整体,并且对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。
面向对象的软件测试分为:面向对象分析的测试,面向对象设计的测试,面向对象编程的测试,面向对象单元测试,面向对象集成测试,面向对象系统测试。
类测试的关键问题:
(1)信息隐蔽对测试的影响(阅读ppt掌握类测试的)
类的重要作用之一是信息隐蔽。它对类中所封装的信息的存取进行控制,从而避免类中有关实现细节的信息被错误地使用。这些细节信息正是软件测试所不可忽略的,因此,隐蔽机制给测试带来了困难。
(2)封装和继承对测试的影响
若一个类得到了充分的测试,当其被子类继承后,继承的方法在子类的环境中的行为特征需要重新测试。
测试面向对象程序时,一般先测试父类,再测试子类。那么在测试子类时,父类的哪些测试用例可以利用,哪些部分需要重新测试,这些都取决于子类在继承父类时,继承了哪些方法,对哪些方法重定义,又增加了哪些父类没有的方法
(3)多态性对测试的影响
多态性是指一个引用可以与多个对象绑定的能力。多态能减少代码的复杂性和规模,同时还可以实现动态绑定。但依赖于不规则的类层次的动态绑定可能产生编程人员没有想到的结果。某些绑定能正确的工作但并不能保证所有的绑定都能正确地运行。以后绑定的对象可能很容易将消息发送给错误的类,执行错误的功能,还可能导致一些与消息序列和状态相关的错误。
类测试概念:验证类的实现是否和该类的说明完全一致。
类测试的方法:通过代码检查或执行测试用例的方法来有效地进行类测试。(后者优于前者)。
(三)
1.集成测试的概念,理解集成测试的执行过程,
集成测试是在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统进行的测试活动。
集成测试四个方面的评价:
测试用例的规模应越小越好;驱动模块的数量应越少越好;桩模块的数量应越少越好;单个集成测试涉及接口数量(即模块数量)越少越好。
集成测试的流程:
集成测试计划 |
集成测试分析与设计 |
集成测试实现 |
集成测试执行 |
集成测试评估 |
软件体系结构初步分析 |
集成测试对象分析 |
集成测试工具开发 |
建立集成测试环境 |
集成测试数据分析 |
关键特性分析 |
集成策略选择 |
集成测试代码开发 |
执行集成测试 |
集成测试评估 |
工作量估计 |
集成测试工具选择和设计 |
集成测试用例开发 |
测试结果记录 |
|
资源安排 |
集成测试代码设计 |
|
|
|
进度安排 |
集成测试用例设计 |
|
|
|
- 掌握集成测试的策略,理解不同策略的优劣。
非增值式策略
优点 :一是方法简单,二是允许多个测试人员并行工作,对人力、物力资源利用率较高。
缺点:必须为每个模块准备相应的驱动模块和辅助桩模块,故测试成本较高;其次,一旦集成后的系统包含多种错误,难以对错误定位和纠正。
增值式策略:(自顶向下、自底向上)
优点:较早发现模块间的接口错误;发现问题也易于定位;
缺点:测试周期比较长,可以同时投入的人力物力受限。
项目 |
测试用例数目 |
桩模块 |
驱动模块 |
缺陷定位 |
并行测试 |
成对集成 |
由边数决定 |
需要 |
需要 |
非常容易 |
可以 |
邻居集成 |
主要由中间节点数决定 |
需要 |
需要 |
困难 |
可以 |
大爆炸 |
少 |
不需要 |
不需要 |
非常困难 |
|
自顶向下 |
较多 |
需要 |
不需要 |
较容易 |
困难 |
自底向上 |
较多 |
不需要 |
需要 |
较容易 |
可以 |
三明治 |
较多 |
需要 |
需要 |
较困难 |
可以 |
(四)
1.系统测试的概念,理解系统测试的过程,以及系统测试在整个软件测试过程中的地位。
系统测试:将通过确认测试的软件,作为整个基于系统的一个元素,与硬件、某些支持软件和人员等其它系统元素结合在一起,在实际运行环境下,对系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较,发现软件
过程:需求、测试计划、用例设计、执行测试、执行结果记录和bug记录、.defect tracking、测试报告
2.掌握功能测试中,包括对业务流程的理解,判断场景之间的关系,利用场景进行测试用例的设计。理解系统测试阶段的功能测试与其他阶段功能测试的区别。
场景测试详细内容:p76页
- 了解性能测试的基本内容以及性能测试的相关问题,能对比需求的性能测试指标,分析性能测试结果。
典型的性能测试指标:CPU的使用情况、I/O的使用情况、主要存储内存的使用情况、每个模块的执行时间百分比、系统反应时间、系统吞吐量等。
内容:常规性能测试、压力测试、负载测试、可靠性测试、大数据量测试
详情请见书上p237面
(五)、
- 自动化测试的概念,自动化测试的特点,优缺点
自动化测试:通过测试工具、测试脚本等手段,按照测试工程师的预定计划对软件产品进行自动的测试,从而验证软件是否满足用户的要求。
优势:
提高测试执行效率,节约时间成本;
解放人力去做更重要的工作;
可重复利用,建设对人的依赖;
提升客户满意度;
提升测试团队的整体水平;
可大幅度减少兼容性测试的工作量;
有些测试工作必须依靠自动化实现来完成;
劣势:
开发测试脚本需要花费较大的时间成本,拉长周期;
产品的快速迭代,自动化脚本也将不断迭代,时间成本很高;
不同的项目之间自动化脚本的复用度很低;
对短期型项目产品实现自动化价值不高;
自动化无法完全代替手工测试找到bug,实现100%覆盖;
自动化更多的适用于回归测试;
自动化开发过程对软件测试团队的技术有更高的要求;
- 掌握软件测试过程管理对保证软件质量的作用。(可能不全)
过程管理:bug管理和流程管理
强制按照统一的流程处理缺陷;
对缺陷实现全生命周期的闭环管理;
依据缺陷的相对和绝对重要性来修复问题;
有利于缺陷信息的清楚传达;
透明的缺陷修复进展;
获得更多有价值的信息;
为技术支持和市场部门提供支持。
- 理解软件BUG管理,流程管理
测试组长:直接面对测试人员,对测试和缺陷报告的质量负责。
测试工程师:负责报告缺陷,并监控所报告的缺陷的解决。
测试经理:测试组长和测试工程师的领导,对测试工作的质量负责,监督测试人员。
程序员:使得系统出于现状的关键人物,并负责Bug修改。
产品经理:主要关心产品稳定性和技术支持成本;可能是最有力的质量支持人士;可能最关心产品能按时发布;从市场的角度对一些特定问题特别感兴趣。
技术支持(售后服务),工程实施人员:需要知道产品中有多少已知的缺陷;出席缺陷延期处理评审会,就那些会增加客户服务电话比率的问题提出反对延期处理建议;有时在关键的最后时刻报告缺陷;客户报告缺陷的接口。
系统分析设计人员:系统需求与设计修改者。
项目经理:负责开发高质量的软件;决定缺陷修正优先次序;最终决定缺陷修正的相关事项;分配给适当的程序员。
高级管理者:喜欢缺陷的统计数量,缺陷报告和修正图表;不关心单个缺陷,除非程序的行为使公司感到不安或一个非常大的吸引客户的特征出现了失败或程序的表现惹恼了用户。