第13章 软件测试简介

13.1.1,2  软件测试背景及著名案例（狮子王案例、Intel浮点出发软件缺陷、美国航天局火星登陆、爱国者导弹防御系统）

13.1.3  软件缺陷

定义

  • 软件未达到产品说明书标明的功能。
  • 软件出现了产品说明书指明不会出现的错误。
  • 软件功能超出产品说明书指明范围。
  • 软件未达到产品说明书虽然未指出但应达到的目标，此条是抓住产品说明书上遗漏之处。
  • 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

原因

  • 软件模型或者说业务建模制定不正确，这类占了70%左右，并且难以纠正。
  • 软件庞大，功能复杂。
  • 编程过程出错，此类占20%左右，一般比较容易纠正。
  • 个别功能要求改变而影响其他部分。
  • 与要开发的软件对接的第三方软件有缺陷。
  • 人为因素。 不同时期修复BUG的投入费用也不一样，越到开发后期修复BUG的成本越高。

Bug发现阶段修正花费对照表

  纠错阶段 单位费用
1 功能需求搜集分析/软件设计阶段 1单位费用
2 编程或分块测试阶段 5单位费用
3 整体或系统测试阶段 10单位费用
4 早期用户使用或Beta测试阶段 15单位费用
5 软件推出市场后 30单位费用

 

13.1.4 软件测试原则

  • 完全测试程序是不可能的，不可能找出软件的所有缺陷。
  • 软件测试是有风险的行为，风险来自于软件测试的范围，故要去粗存精。
  • 测试无法显示的潜伏的软件缺陷。
  • 软件缺陷都是成群出现的。
  • 软件测试方法及技术要不断更新。
  • 不是所有软件都能修复。
  • 开发小组对于缺陷的的定义不一定一致。
  • 产品不断升级导致缺陷越多。
  • 软件测试员在小组不受欢迎。

13.1.5 软件的版本

  • Alph版本：公司内部测试的版本
  • Beta版本：对外发布公测
  • 正式版：正式发布版本一般在Beta3之后软件正式发布

13.1.6 优秀软件测试原必备

探索精神、故障排除能手、不懈努力、创造性、追求完美、判断准确、老练稳重、表达能力、在编程方面受过教育。

13.2软件测试分类

软件测试特性：白盒测试、灰盒测试、黑盒测试。

软件开发过程：单元测试、集成测试、系统测试、用户验收测试、回归测试

软件测试要求：基本功能测试、全面测试、基准测试。

软件特性：功能测试、非功能测试。

13.3自动化测试

一般认为使用（自动化测试）工具来进行的测试交自动化测试，一般不需要人进行干预。

优点

  • 节省大量时间与资源。
  • 没有时间限制。
  • 可以反复执行。
  • 保证测试的一致性以及准确性。
  • 有较高的功能测试覆盖率。
  • 模拟操作进行压力测试。

缺点

  • 并非所有都能使用自动化。
  • 没有创造性。
  • 受具体项目资源限制，受人力限制。

步骤

  • 编写测试用例。
  • 分析、验证测试用例。
  • 对已有测试用例归类，制订自动化计划方案。
  • 编写自动化测试程序。
  • 尽量用“数据驱动”来提高测试覆盖率。
  • 将测试用例编写成自动化测试程序。
  • 执行测试程序，记录并反馈BUG。
  • 不断完善自动化测试系统或程序。

13.4BUG管理流程

微软研发中心的BUG管理。

通用的BUG管理流程

  1. BUG登记——测试工程师，初始。
  2. 指派任务——项目经理，激活。
  3. 修改BUG——开发工程师，修改。
  4. 验证——测试工程师，通过则转第5步，否则转第2步，状态为再激活。
  5. 关闭——测试工程师。

分类

  • 按缺陷状态分类。
  • 按缺陷严重分类。
  • 按缺陷优先级分类。

第14章 系统实现与测试过程

14.1 CMMI中对应实践

技术解决方案（Tenchnical Solution，TS）过程域中对应的实践

  • SG3 Implement the Product Design（实现产品设计）
  • SP3.1 Implement the Design（实现设计）
  • SP3.2 Develop Product Support Documentation（建立产品支持文档）

产品集成（Product Integration，PI）

  • SG1 Prepare for Product Integration（产品集成准备）
  • SP1.1 Establish an Integration Strategy（建立集成战略）
  • SP1.2 Establish the Product Integration Environment（建立产品集成环境）
  • SP1.3 Establish Product Integration Procedures and Criteria（建立集成规程及准则）
  • SG2 Ensure Interface Compatibility（确保接口的兼容性）
  • SP2.1 Review Interface Descriptions for Completenss（审查接口描述的完整性）
  • SP2.2 Manage Interfaces（管理接口）
  • SG3 Assemble Product Components and Deliver the Product（装配产品组件并交付作品）
  • SP3.1 Confirm Readiness of Product Components for Integration（确认用于集成的产品组件准备就绪）
  • SP3.2 Assemble Product Components（装配产品备件）
  • SP3.3 Evaluate Assembled Product Components（评估已装配产品部件）
  • SP3.4 Package and Deliver the Product Component（打包并交付产品或产品组件）

验证（Verification，VER）

  • SG1 Prepare for Verification（准备验证）
  • SP1.1 Select Work Product for Verification （选择待验证的工作产品）
  • SP1.2 Establish the Verification Environment（建立验证环境）
  • SP1.3 Establish Verification Procedures an Criteria（建立验证规格说明）
  • SG3 Verify Selected Work Products（验证选定的工作产品）
  • SP3.1 Perform Verification（执行验证）
  • SP3.2 Analyze Verification Results（分析验证等级）

14.2 系统实现与测试过程简述

系统实现与测试过程达到目的

1、实现产品组件的编码并产生相应的支持文档

2、准备产品/系统集成，确保接口兼容性，组装产品组件。

3、同时适时对产品组件进行单元测试和集成测试，实现对产品组件及集成的产品构件的验证。

实现及测试活动流程图

 

14.3编码流程

14.3.3 编码中常见问题

1、如何避免卡法阻塞？

　　项目经理合理安排分配任务。

2、有最好的编程语言吗？

　　没有，只有最适合的编程语言。

3、换用更快的计算机还是开发更快的算法？

　　根据“成本——收益”来决定。

4、要多用新技术和技巧吗？

　　应当尽可能采用成熟可靠的技术开发软件。

5、夜里编程效率更高吗？

　　因为一鼓作气完成效率高，中途如果停下来，思路会被打断。

6、如何提高团队编程的质量

　　编程人员中新手的比例不超过50%，多一些责任心。

14.4测试流程

单元测试

在设计阶段整个系统被分为许多的单元模块，因此要先进行单元测试来找出具体问题。

集成测试

集成测试是单元测试的逻辑扩展，找出当许多单元结合时产生的问题。

14.5缺陷管理与改错

如果在测试发现了缺陷，开发人鱼应当尽早消除缺陷，并且需要对缺陷的全生命周期进行详细的跟踪及管理。

第15章 制定测试方案及编写测试用例

15.1 CMMI中对应实践

  • SP1.1 Select Product for Validation（选择需要确认的产品）
  • SP1.2 Establish the Validation Environment（建立确认环境）
  • SP1.3 Establish Validation Producedures and Criteria（建立并维护确认过程和准则）

15.2 测试资料收集与整理

1、通用信息

　　一般信息：公司大体情况；测试部门大体情况；周围人与事、工作环境；公司文化

　　技术信息：软件类别及构成；软件的用户界面；涉及的第三方软件

2、被测软件的类别及构成

　　需要了解软件的类别及结构

3、被测软件的用户界面

　　需要了解最终用户的软件界面

测试计划要解决的重点：

  • 软件及测试基本情况
  • 软件目前主要存在的问题
  • 软件管理流程（BUG）
  • 使用的测试软件、BUG管理软件、配置管理软件
  • 测试环境
  • 软件产品的文件、说明

15.3检查软件说明书

充分利用说明书可以测试和找出缺陷。

15.4 测试方案的制订

测试方案是软件测试的总体规划。

测试计划书的衡量标准——必须有明确的测试目标、范围和深度、具体实施方案、及测试重点；提供大体的测试进度及所需的资源（人力、物力、软件、硬件等）

15.5 测试计划书的编写及要素

测试计划内容

  • 测试计划书的文件名及版本号
  • 基本情况介绍
  • 测试的具体目标
  • 具体执行的测试类型
  • 测试通过的判断标准
  • 测试用例
  • 测试准备工作及测试结果的处理
  • 测试工作中涉及的相关事项
  • 部门责任分工
  • 测试人力资源分配
  • 测试进度列表
  • 测试工作可能面临的偶然事件及危机处理；缺陷管理流程

第16章 系统测试

16.1CMMI中对应实践

VAL过程域

SG2 Validate Product or Product Components（确认产品或产品组件）

SP2.1 Perform Validation（执行确认）

SP2.2 Analyze Validation Results （分析确认结果）

16.2系统测试简述

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计的标准和规定。

16.3系统测试活动内容

  • 用户层,主要是面向产品最终的使用操作者的测试，重点是突出从操作者角度，测试系统对用户支持的情况。
  • 应用层，针对产品应用的测试，重点在系统应用的角度，模拟实际应用环境，对系统兼容性、可靠性、性能进行的测试。
  • 功能层、针对产品具体功能实现测试。
  • 子系统层，针对产品具体功能实现的测试。
  • 协议/指标层，针对系统支持的协议、指标的测试。