软件测试复习

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件测试的定义和目的:使用手动或者自动工具来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清实际结果与预期结果之间的差别。

软件测试的目的:寻找BUG 预防bug 保证软件的质量。

软件生命周期:计划需求设计编码测试运行。

软件测试组织架构:分析人员、设计人员、开发人员、测试人员、配置管理人员、QA、测试经理、开发经理。

软件测试模型:瀑布模型—计划、需求分析、设计、编码、测试、运维。

螺旋模型IPD流程RUP流程

软件中为什么会引入缺陷:1.沟通2.软件复杂度3.编程错误4.不断变更的需求5.时间压力

6.缺乏文档的代码

7.软件开发工具

8.人员的自大

软件缺陷的类型:遗漏错误额外的实现

测试工程师的主要工作:检视代码、评审文档、进行测试设计、写作测试文档(测试计划、测试方案、测试用例等)执行测试、发现软件缺陷、提交缺陷报告,并确认缺陷最终得到修正。通过测试度量软件的质量。

第二章测试过程

单元测试(LLD)——详细设计文档(白盒测试,主要测试单元内部的数据结构、逻辑控制、异常处理等,评估的基准主要的逻辑覆盖率)

集成测试(HLD)——概要设计文档(灰盒测试,主要测试模块直接的接口与接口之间的数据传递关系,以及模块组合后的整体功能。评估基准主要是接口覆盖率)

系统测试(SRS)——需求分析文档(黑盒测试,主要测试整个系统相对于需求的符合度。评估基准主要是测试用例对需求规格的覆盖率)

回归测试:完全重复测试选择性重复测试周边影响法指标达成法

系统测试模型:V模型VV模型H模型

系统测试阶段:系统测试计划阶段输入软件开发计划、软件测试计划、需求规格说明书输入评审通过输出系统测试计划

系统测试设计阶段输入需求规格说明书、系统测试计划

输入评审通过输出系统测试方案

系统测试实现阶段输入需求规格说明书、系统测试计划、系统测试方案

输入评审通过输出系统测试用例、系统测试预测试项、系统测试规程

系统测试执行阶段输入系统测试计划、系统测试方案、系统测试用例、

系统测试规程系统测试预测试项

输入评审通过输出系统测试预测试报告、系统测试报告、软件缺陷报告

第三章软件质量

质量铁三角:组织、技术、流程

软件质量模型:六大特性:功能性、可靠性、易用性、效率、可移植性、可维护性。

功能性:适用性、准确性、互操作性、保密安全性、功能的依从性。

可靠性:易恢复性、成熟性、容错性、可靠性的依从性。

易用性:易操作性、易理解性、易操作性、吸引性、易用性的依从性。

效率:时间特性、资源利用性、效率的依从性。

可维护性:易分析性、易改变下、稳定性、易测试性、维护性的依从性。

可移植性:适应性、易安装性、共存性、易替换下、可移植性的依从性。

白盒测试静态分析:控制流分析技术,数据流分析技术,信息流分析技术

动态测试:逻辑覆盖率测试(分支测试,路径测试),程序插装。

语句覆盖、判断覆盖、条件覆盖、判断条件覆盖、路径覆盖。

优点:迫使测试人员仔细思考软件实现,可以检测代码中的每条分支和路径,揭示隐藏在代码中的错误,对代码的测试比较彻底,最优化。

缺点:昂贵,无法检测代码中遗漏的路径和数据敏感性错误,不严重规格的正确性

黑盒测试错误类型:功能错误或遗漏,界面错误,性能错误,数据结构或外部数据库访

问错误,初始化和终止错误。

优点:效率高,测试人员不需要了解实现的细节包括特定的语言,测试人员和编码人员是彼此独立的,从用户的视角测试容易被大家理解和接受,有助于暴露任何

规格不一致或有歧义的问题,测试用例可以在规格完成之后马上进行。

缺点:不可以完全测试,没有清晰和简明的规格测试用例比较难以设计,交流不便会导致重复测试,路径测试的忽略,不能针对特定的程序段。

静态测试:不通过执行程序而进行的技术

动态测试:包含了程序在受控的环境下使用特定的期望结果进行正式的运行。

第五章配置管理

配置管理:就是通过对软件生命周期的不同的时间点上锁产生的文件进行标示,并对这些被标识的文件进行系统控制,今儿达到保证软件产品的完整性和可溯性。

配置项包含各个配置。

配置管理工具:VSS(Microsoft visual Sourcesafe)开源软件CVS(Concurrent Verslon System)开源软件SVN Borland Starteam IBMRational ClearCase

基线:软件基线是项目储存库中每个工件版本在特定时期的一个"快照"。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。

变更控制流程:提交CR ——CMO 标识并提交给CCB——CCB开会讨论(拒绝即返回)——CMO标识已接受开放CI配置库权限——项目组成员更改并验证——CCB继续开会审查(不通过继续修改)——CMO检查验收CR记录,收回配置库权限关闭标识——返回

第六章需求管理

需求:业务需求用户需求系统需求功能需求

需求规格说明书7大特征:完整性正确性可行性必要性划分优先级无二义性可验证性每条需求规格说明的4大特点:完整性一致性可修改性可追踪性

需求分析:1.原始需求(可以要求,合同)2.显式和隐式需求:功能的范围性能的要求其它属性要求(可移植性,可用性,安全性等)接口规格(用户接口,外部软件接口,外部硬件接口)约束(操作系统,资源约束等)

测试人员评审需求检测:1.对需求的描述是否易于理解 2.是否存在有歧义的需求 3.是否定义了术语表,对特定含义的术语给予了定义 4.最终产品的每个特征是用唯一的术语描述的么?5.需求中的条件和结果是否合理,有没有遗漏一些异常的因果关系?6.需求中有没有包含不去定性的描述,如:大约、可能等7.每个规格是不是都有明确的说明8.环境搭建是否可能或有困难?

相关文档
最新文档