软件测试课复习资料
- 格式：doc
- 大小：326.71 KB
- 文档页数：15
题型：
-客观题：选择题(10*1’)+填空题(10*2’ ) +判断题(10*1’ )共40分
-简答题: 4或5道，共20分
-分析题: 4或5道，共40分
#Chap 1
·1、软件测试的概念 (P9)
从一个通常是无限的执行域（集合）中选择合适的、有限的测试用例，对程序所期望的的行为进行动态验证的活动过程。
·2、软件测试正反2种观念的争辩。代表人物、他们的主要观念及存在的问题。
(P7~9)
1972年，软件测试领域的先驱BILL Hetzel博士（代表论著《软件测试完全指南》），在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。
观点：软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。
（1） 测试是试图验证软件是工作的，也就是验证软件功能执行的正确性。
（2） 测试的目的是验证软件是否符合事先定义的要求。
（3） 测试的活动是以人们的设想或预期的结果为依据。这里的设想或预期的结果指需求定义，软件设计的结果。
存在问题：
（1） 可能使软件测试的活动效率降低
（2） 甚至缺乏有效的方法进行测试活动。
Myers（代表论著《软件测试的艺术》）认为不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。
观点:测试是为了发现错误而执行的一个程序或者系统的过程。
一个成功的测试必须是发现了软件问题的测试否则测试就没有价值。这个定义引导人们证明软件是不工作的，以反向思维方式，不断思考开发人员理解的误区，不良的习惯，程序代码的边界，无效数据的输入以及系统的弱点，试图破坏系统摧毁系统，摧毁系统，目标就是发现系统中各式各样的问题。
存在问题：
（1） 如果只强调测试的目的是寻找错误，就可能是测试人员容易忽视软件产品的某些基本需求或者客户的实际需求，测试活动可能会存在一定的随意性和盲目性。
（2） 如果只强调测试的目的是寻找错误，使开发人员容易产生一个错误的印象，认为测试人员的工作就是挑毛病的。
（3） 除此之外还强调测试是执行一个程序或者系统的过程，也就是说测试活动是在代码完成之后进行，而不是贯穿整个软件开发过程的活动，及软件测试不包括软件需求评审，软件设计评审和软件代码静态检查等一系列活动，从而使软件测试的定义具有局面性和片面性。
总结：这正反两方面的观点是从不同的角度看问题，一方面通过测试来保证质量，另一方面又要改进测试方法和提高软件测试的效率，两者相辅相成。软件测试就是在这两者之间获得平衡，但对于不同的应用领域，二者的比重不一样。
·3、结合V模型谈谈开发与测试关系附录：V模型 (P10-P11)
V模型 ：能准确反映出开发活动和测试活动之间的关系，说明：
1） 测试活动与开发活动同时启动；
2） 每个开发活动都有相应级别的测试类型相对应。
3） 测试是分层的。只有完成单元测试、集成测试、系统测试、验收测试4个层次的测试，才是对软件产品的完整测试。
·4、请结合实例，谈谈为什么穷尽测试是不可能的。(开放题，从输入和路径穷尽来考虑)
通过测试并不能发现和修改测试对象中的全部的缺陷和问题，因此，不可避免有一些缺陷会遗漏到客户的使用现场，从而触发软件产品产生令用户不满意的失效或者各种问题。
即使是规模很小的软件或者软件产品，其逻辑路径和输入数据的组合也几乎是无穷的。假如测试人员想对测试对象进行完全的检查和覆盖，那基本上是不可能的.
测 试人员面临的测试时间和测试资源往往是非常有限的。多年的测试实践经验表明，测试团队往往很难获得测试计划中预留的测试时间，当软件开发和测试的时间发生 冲突的时候，测试团队常常被要求压缩测试时间；同时，测试过程中的测试资源限制，例如：测试平台、测试人员的限制，使得测试团队只能在有限的条件下开展测 试活动
测试内容几乎是无穷的，而测试时间和测试资源非常有限，我们能做的就是采取合适的测试策略，在现有条件下如何做的更好。
测试的尽早介入。集中精力在缺陷刚刚被引入的阶段就发现它，避免缺陷向后续阶段转
移（不仅可以降低成本，同时也可避免缺陷的雪崩效应）；
基于风险的测试。确保测试高优先级的关键的功能首先被测试，尽早和尽量多的发现严
重程度的缺陷，而不是将有限的测试时间和资源浪费在无关紧要的地方；
·5、了解测试目的、测试驱动开发的概念 (P9
P13)
测试目的：验证软件是否符合事先定义的要求。
测试驱动开发：测试在先，编码在后的开发方法。它要求在编写
某个功能的代码之前先编写测试代码，然后只编写使测试通过的
功能代码，通过测试来推动整个开发的进行。
6、了解SQA质量保证的概念、与软件测试的关系 P11-P12
SQA质量保证：通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。
与软件测试的关系：相辅相成，既存有包含又存有交叉的关系。
（1）SQA指导、监督软件测试的计划和执行，督促软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程 的改进。
（2）软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。
（3）它们的相同点在于二者都是贯穿整个软件开发生命周期的流程。
（4）它们的不同之处在于SQA是一项管理工作，侧重于对流程的评审和监控，而测试是一项技术性的工作，侧重于对产品进行评估和验证。
#Chap 2
·1、软件质量的概念
软件质量定义：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。它包括：1软件产品质量满足用户要求的程度；2软件各种属性的组合程度3用户对软件产品的综合反映程度4软件在使用过程中满足用户要求的程度 （P15）
·2、ISO9126软件质量模型（一层6个即可），并分别说明各个质量属性的含义
(P17)
Iso9126模型：高层：软件质量需求评价标准（SQRC）属性：功能性、可靠性、可用性、效率、可移植性、可维护性
中层：软件质量设计标准（SQDC） 属性： 安全性、、成熟性、可理解性、时间表现、可分析性、适应性
低层：软件质量度量标准（SQMC）
·3、软件缺陷的定义，常见缺陷的辨识
软件缺陷：是指计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵，其结果会导致软件产品在某种程度上不能满足用户的需求
表现形式：1运行出错，包括 运行中断、系统崩溃、界面混乱2数据计算错误，导致结果不正确3功能、特性没有实现或部分实现4在某种特点条件下没能给出正确或准确的结果5计算的结果没有满足所需要的精度6用户界面不美观7需求规格说明书的问题8设计不合理，存在缺陷9实际结果与预期结果不一致10用户不能接收的其他问题 （P18）
·4、软件测试的分类：按阶段、按目标、按方法。
目的分类：集成测试、功能测试、回归测试、性能测试、可靠性测试、安全测试、兼容性测试
阶段分类：需求评审、设计评审、单元测试、集成测试、系统测试、验收测试、α测试、β测试
方法分类：静态测试、动态测试、黑盒测试、白盒测试
-静态测试和动态测试、黑盒测试和白盒测试的划分原则
根据测试过程中被测软件是否被执行，软件测试可分为静态测试和动态测试。
根据是否针对系统的内部结构和具体实现算法来完成测试，软件测试可分为白盒和黑盒
-非功能测试：性能测试、可靠性测试、安全性测试，及常见非功能缺陷P22
性能测试：测试系统在不同负载条件下的系统具体的性能指标
可靠性测试：检验系统能否保持长期稳定，正常的运行，如确定系统平均故障间隔时间，包括强壮性测试和异常处理测试。
安全性测试测试系统在应对非授权的内外部访问，有意攻击时的系统防护能力。
-5、什么是黑盒测试和白盒测试，它们各自的局限性是什么。P26~P28
黑盒测试：不关注软件内部结构，着眼于程序外部用户界面，关注软件的输入和输出，关注用户的需求，从用户的角度验证软件的功能，实现端到端的测试。 缺陷：1是否不正确或遗漏了功能2能否正确地接收输入数据，能否产生正确的输出信息3功能操作逻辑不合理4界面是否出错、是否不美观5安装过程中出现问题，安装步骤不清晰、不够方便灵活6系统初始化问题
白盒测试：按照程序内部的结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等 缺陷：试图列举所有路径测试，是不可能的，企图遍历所有的路径是很难做到的，即使每条路径都测试了，覆盖率得到100%，程序也可能出错。
-6、按阶段：单元测试、集成测试、系统测试、验收测试，它们的概念与不同。附录：测试阶段定义 P28
类别 对象 目的 测试依据 测试方法
单元测试 模块内部程序 消除局部模块逻辑和功能上的错误和缺陷 详细设计文档
API说明 白盒测试
集成测试 模块间的接口和调用关系 找出与软件设计相关的程序结构，模块调用关系、接口方面的问题 概要设计文档
接口设计说明 灰盒测试
系统测试 整个系统，包括系统软硬件等 对整个系统进行一系列的功能、非功能测试，发现功能或非功能问题。 系统需求规格说明文档 黑盒测试
验收系统 整个系统，包括系统软硬件等，采用真实用户环境 对整个系统按用户环境和用户使用场景进行一系列整体的解决方案级测试,
确认系统与用户需求的匹配程度 用户需求 黑盒测试
·7、验证与确认（V&V）的概念及两者区别V&V (P25)
验证：检验软件是否已正确实现了产品规格说明书所定义的系统功能和特性
确认：确认软件是否真正满足用户需求，一切从客户出发，理解客户的需求。
Verification：是否正确构造了软件？即是否正确的做事，验证开发过程是否遵守已经定义好的内容。
Validation：是否够早了正确的软件？即是否做正确的事，即正在构建用户需要的功能？
区别：验证是检验开发出来的软件产品和设计规格说明书的一致性，即是否满足软件厂商的生产要求。但设计规格说明书本身就可能存在错误，所以即使软件产品中某个功能实现的结果和设计规格书完全一致，但可能并不是用户所需要的，因为设计规格说明书很可能一开始就对用户的某个需求理解错了，所以仅进行验证测试还是不充分的，还要进行确认测试。确认就是检验产品功能的有效性，即是否满足用户的真正需求。
