软件测试阶段

目录

组件:也叫单元

组件测试也称单元测试:针对一个(单个的)软件单元的测试。

测试重点:

所需知识:

前提条件:

 组件测试相关知识:

驱动器: 

 桩模块:

 模拟器:

集成:把组件/系统合并为更大部件的过程。

集成测试:

测试重点:

所需知识:

前提条件:

 集成测试所需知识: 

集成测试策略: 

系统测试:

测试重点:

所需知识:

前提条件:

系统测试所需知识: 

 验收测试:

验收测试分类:


组件:也叫单元:

  1. 单元是软件里最小的、可以单独执行编码的单位,通常由于一个人完成编程;
  2. 对于采用流程语言设计的软件,单元可以用一个或若干个最接近的函数或过程所组成;
  3. 对于采用面向对象语言的软件,单元可以是一个类或类的实例,或者由方法来实现的功能;
  4. 对于网页或用户窗口界面,单元可以是一个文字输入窗口或一个按钮等。

组件测试也称单元测试:针对一个(单个的)软件单元的测试。

相关术语:模块测试、单元测试、类测试、程序测试。

测试重点:

  1. 功能性测试;
  2. 健壮性(逆向测试:无效值):不仅能够正确计算,还能够屏蔽错误。(逆向测试:也叫反向测试、负向测试,主要测试无效值)
  3. 性能。

所需知识:

  1. 开发知识和技能:编写桩、测试驱动器、模拟器;
  2. 基本的测试技术。

前提条件:

  1. 完成编译的测试对象;
  2. 测试环境(驱动器、桩);
  3. 开发工具;
  4. 测试对象的规范说明书。

 组件测试相关知识:

  1. 技术:a:白盒测试技术(语句、分支覆盖等);b:黑盒测试技术(等价类划分,边界值分析);
  2. 发现缺陷:a:在组件内的功能性缺陷;b:运行时的缺陷;c:(本机)性能问题;d:健壮性问题;
  3. 可能遗留的缺陷:a:接口问题;b:“大环境”中的问题;c:许多非功能性的缺陷。

驱动器: 

        通过接口与测试对象通讯的辅助工具。用于调用被测试的组件或系统替代性程序,调用被测模块的模块。(编写驱程序代替A的功能调用B)

 桩模块:

        桩用于替代或模拟那些还没有完成的组件(模块),用于模拟输入和输出(针对不完整的功能),被被测模块调用的模块。(编写桩程序代替B和C的功能,去测A)

 模拟器:

        用一个系统来描述另一个要测试的抽象系统的行为特征。

集成:把组件/系统合并为更大部件的过程。

集成测试:

        一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试,有多种集成类型,如:
        1.组件集成测试:测试的目的在于发现接口和集成后组件间协同工作的缺陷;
        2.系统集成测试:a:测试系统与其他软件包的集成,例如:与商务标准软件的集成;
                                    b:测试与外部系统的接口和交互,例如:电子数据的交换、网络。

测试重点:

  1. 接口;
  2. 系统内不同部分的相互作用(交互)。

所需知识:

  1. 最好具备开发知识和技能(有可能还需要测试驱动器和桩);
  2. 测试技术;
  3. 具备有关组件间的交互知识。

前提条件:

  1. 完成集成的被测系统;
  2. 测试台(在组件测试阶段使用的一些工具或生产的产品可能在集成测试中被再次使用);
  3. 有关组件间交互的文档。

 集成测试所需知识: 

  1. 技术:a:白盒测试技术(内部接口);b:黑盒测试技术(等价类划分);
  2. 发现缺陷:a:接口的缺陷;b:组件之间的协调错误(交互);
  3. 可能遗漏缺陷:a:相关组件外的问题;b:对整个系统的需求的不满足;c:与外部系统的接口常常被忽略。 

集成测试策略: 

  • 自顶向下集成:
  • 自底向上集成:

系统测试:

        测试集成系统以验证它是否满足指定需求的过程,一个集成系统的基于风险的测试,为的是确认此系统满足了特定的功能性和非功能性的需求,测试环境应尽可能与以后的目标环境保持一致。

测试重点:

  1. 系统需求;
  2. 整个系统的功能;
  3. 非功能的需求;

所需知识:

  1. 测试技术(主要是黑盒测试技术);
  2. 系统域的知识;
  3. 非功能性测试技术。

前提条件:

  1. 先前的测试阶段已经成功结束;
  2. 完整集成的系统;
  3. 与系统需求有关的文档。

系统测试所需知识: 

  1. 技术:a:功能性和非功能性测试;b:黑盒测试技术(等价类划分);
  2. 发现缺陷:a:非功能性缺陷;b:涉及整个系统的问题;
  3. 可能遗漏的缺陷:a:对用户需求的错误理解;b:没有实现或者没有完全实现用户的隐性需求。

 验收测试:

        一般是由用户/客户进行的确认是否可以接受一个系统的验证性测试。是根据用户需求,业务流程进行的正式测试以确保系统符合所有验收准则。测试由系统用户的参与,按照客户的期望进行测试。
        测试验证:是否在现有的技术背景下,系统满足了客户显性和隐形的需求。
        目标:对系统或子系统建立信心,或例如,对系统非功能性的特性赢得信任。(发现缺陷已经不再是验收测试的主要目标了)。
        验收测试不一定就是最后的测试阶段,例如,在验收测试后可能会有个大规模的系统集成测试,在早期的测试阶段也可以执行部分的验收测试。

验收测试分类:

  1. 用户验收测试:验证由商业用户使用一个系统的可用性;
  2. 进行(验收)测试:由系统管理员对系统的验收测试,包括:a:测试备份和回复备份;b:灾难恢复测试;c:用户管理测试;d:维护任务测试;e:安全漏洞阶段性检查。
  3. 合同和法规性验收测试:a:合同验收测试:根据合同中规定的生产客户定制软件的验收准则,对软件进行测试;应该在合同拟定时定义验收准则;b:法规定验收测试:根据必须要遵守的法律法规来进行测试。比如政府、法律和安全方面的法律法规。
  4. α测试:潜在的客户/用户在开发场地进行的测试;
  5. β测试:由潜在客户/用户在他自己的环境下测试软件系统。例如,商务标准软件。
  6. 测试目的是识别在未知的或非特指的应用环境下对系统的影响。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值