软件测试理论知识总结--软件测试过程

测试过程

测试阶段划分

单元测试（Unit Testing）

针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。（检测软件模块对《详细设计说明书（LLD）的符合度》）。

集成测试（Integration Testing）

在单元测试的基础上，将所有模块按照概要设计组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。（检测软件模块对《概要设计说明书（HLD）的符合度》）

系统测试（System Testing）

将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。（通过与《需求规格说明书（SRS）》作比较，发现软件与系统需求定义不符合或之矛盾的地方）

单元、集成、系统测试的比较

1. 测试方法不同

• 单元测试属于白盒测试范畴
• 集成测试属于灰盒测试范畴
• 系统测试属于黑盒测试范畴

2. 考察范围不同

• 单元测试主要测试单元内部的数据结构、逻辑结构、异常处理等
• 集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
• 系统测试主要测试整个系统相对于需求的符合度

 3. 评估基准不同

• 单元测试主要是逻辑覆盖率
• 集成测试主要是接口覆盖率
• 系统测试主要是测试用例对需求规格的覆盖率

 

回归测试（Regression Testing）

目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。

（注：回归测试可以发生在任何一个阶段）

回归测试策略

1. 完全重复测试

重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。

     2. 选择性重复测试

即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序

•   覆盖修改法： 即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法
•  周边影响法： 该方法不但包含覆盖修改法确定的测试用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响，该方法比覆盖修改法更充分一点。
•  指标达成法：  这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改的部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

回归测试流程（适用于单元测试，集成测试，系统测试）

• 在测试策略制定阶段，制定回归测试策略
• 确定需要回归测试的版本
• 回归测试版本发布，按回归测试策略执行回归测试
• 回归测试通过，关闭缺陷跟踪单（问题单）
• 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

（注：回归测试比较适合使用自动化工具）

其他测试阶段

1. 验收测试

• 验收测试是以用户为主的测试，验收组应该由项目组成员，用户代表等组成
• 在通过内部系统测试及软件配置审查后，就可以开始验收测试
• 验收测试原则上在用户所在地进行，但经用户同意也可以在公司内模拟用户环境
• 验收测试根据合同、《需求规格说明书》或《验收测试计划》对产品进行验证
• 结果两种（接受与不接受）

   2.  Alpha测试（属于验收测试）

由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。

目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持等）

  3.  Beta测试（属于验收测试）

由软件的多个用户在一个或多个用户的实际环境下进行测试

Alpha测试和Beta测试的区别

Alpha测试过程可控，但是参与人数有限；Beta测试参与人数巨大，但是过程不可控。

测试过程模型

测试过程阶段划分

• 测试计划阶段：测试计划
• 测试设计阶段：测试方案
• 测试实现阶段：测试用例、测试规程
• 测试执行阶段：测试报告

主要测试文档

• 测试计划：指明测试范围、方法、资源、以及相应测试活动的时间进度安排表的文档。
• 测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
• 测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
• 测试规程：指明执行测试时测试活动序列的文档。（后执行用例的输入是先执行用例的输出）
• 测试报告：指明执行测试结果的文档。（注：1）将工作过程表现出来 2）表明个人对测试对象的态度）
• 测试日报：每天测试执行情况的记录和总结。

常见的测试过程模型

1. 瀑布模型缺陷：   测试介入太晚 ， 工作效率低，  成本巨大
2. H模型

测试准备活动，包括测试需求分析、测试计划、测试设计、测试编码、测试验证

另一类是测试执行活动，包括测试运行、测试报告、测试结果分析等。

优点：   试与其他流程并发的进行，  测试准备和测试执行分开

  3. V&V模型

优点：

• 测试与其他流程并发的进行
• 测试准备和测试执行分开
• 测试过程子阶段与开发过程子阶段一一对应。

V&V的含义：  验证（Verification）和确认（Validation）

验证：（“Are we building the product right?”）

• 验证是保证软件正确地实现特定功能的一系列活动
• 验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致

确认：（“Are we building the right product?”）

• 确认是指保证所生产的软件可追溯到用户需求的一系列活动
• 确认是检测每一阶段的工作产品是否与最初定义的软件需求规格相一致

测试过程规范

CMM关于过程的要素

• 角色（Roles）：人
• 入口准则（Entry Criteria）：执行活动所必须满足的条件
• 输入（Inputs）：完成某活动所需要加工或参考的资料、原材料
• 活动（Activities）：流程由一系列有相互关系的活动组成
• 输出（Outputs）：完成某活动后所提交的工作产品
• 出口准则（Exit Criteria）：完成或退出某活动所必须满足的条件
• 评审和审计（Reviews and Audits）
• 可管理和受控的工作产品（Work Products Managed and Controlled）
• 测量(Measurements)：客观指标（一组数据）
• 书面规程（Documented Procedures）
• 培训（Training）：技术支持
• 工具（Tools）：辅助说明
• 职责：权责定义
• 模板：标准格式
• 检查表（Checklist）：要点列表

软件质量

软件质量的定义

质量：实体基于这些特性满足需求的程度。（一个实体的所以特性，基于这些特性可以满足明显的和隐含的需求）

软件质量的三个层次：（需求的分层导致质量也分层）

1. 符合需求规格：符合开发者明确定义的目标，即产品是不是在做让它做的事情。目标是开发者定义的，并且是可以验证的。
2. 符合用户显示需求（基于SRS）：符合用户所明确说明的目标。目标是客户所定义的，符合目标即判断我们是不是在做我们需要做的事。
3. 符合用户的实际需求：实际需求包括用户明确说明的和隐含的需求。

影响软件质量的因素：（铁三角）

1. 流程

好处：将不可见的工作过程变得可见可控；使得整个工作过程有序并减少内耗，提高工作效率。

    2. 技术（设计、开发、测试）

企业技术负载于人（现有职工的技术；企业是否重视技术积累）

技术与流程的关系：有技术，无流程不可能进行现代化的软件开发；有流程，无技术不可能生产高质量的产品

   3.  组织（非直接的）

通过对流程和技术产生作用而间接对产品质量产生影响。

组织对流程的影响（组织应该将流程制度化，规范化以保证其执行效率；当流程执行中遇到阻碍时，组织应给予处理，保证流程顺畅执行）

组织对技术的影响（保证有能力的人去做合适的事情（资源调配）；组织重视并组织技术的积累，建立知识库（财富库））

软件质量管理体系

1. ISO9000    ISO9000族2000版标准主要由ISO9000、ISO9001、ISO9004三个核心标准组成。

2000版的八项质量管理原则：    

• 以客户为中心（在同一组织内部，顾客的定义是下游环节的人员是上游环节人员的顾客）
• 领导作用（1个制定，4个确保，1个创造，2个决定，1个评审）
• 全员参与
• 过程方法
• 管理的系统方法
• 持续改进
• 基于事实的决策方法
• 互利的供方关系

八项质量管理原则的意义：

• 是质量管理的理论基础
• 用高度概括，易于理解的语言所表述的质量管理的最基本、最通用的一般性规律
• 为组织建立质量管理体系提供了理论依据
• 是组织的领导者有效的实施质量管理工作必须遵循的原则。

2. CMM（Capability Maturity Model）/CMMI（Capability Maturity Model Integration）

评估软件承办商能力；协助软件组织改进过程，提高过程能力

基本术语：

• KPA（Key Process Area）关键过程域（过程域简单的说就是做好一个事情的某个方面，对于软件开发而言就是做好软件开发的某个方面）
• 如果该级别的全部PA达到要求了，就认为该级别达到了
• 如果判断PA达到要求呢？（每个PA包含几个目标（Goal）；如果这几个目标都达到要求了，就认为该PA达到要求了）
• 如何判断Goal达到要求呢？（每个Goal包含几个实践（Practice）；每个实践达到要求了，就认为该Goal达到要求了）

CMM/CMMI用途

• 可以识别组织的长处和弱处
• 评估组织用以来评价软件承包商的能力和风险
• 领导可以借此来进行过程改进，提高企业软件生产能力
• 开发和技术人员参照CMM/CMMI进行执行过程改进

CMM/CMMI的选择

• 企业本身项目特点（软件开发用CMM；有软件开发且包括硬件和采购用CMMI）
• 考虑企业自身的能力成熟度
• 企业对经费的预算
• 若企业只想在某个方面（如过程）提高进行改进（使用CMMI）
• CMM向CMMI的转型

CMM/CMMI区别

1. 降低了复杂度和规模；扩大了模型覆盖率；表达方式（CMM：阶段式表示；CMMI：阶段式（初始级、可重复级、已定义级、已管理级、优化级）、连续式（管理类、支持类、项目类、过程类））
2. CMMI强调对需求的管理；加强对工程过程的重视，强调度量；加强了对风险的管理；CMM中的“组间协调”在CMMI中作为“集成化项目管理”CMM中的一个目标；中的KPA“同行评审”在CMMI中抽象为KPA“验证”；
3. CMM是作为评估标准出现的，是“必要”是才能保证评估的标准；CMMI是作为改进模型出现的，罗列了较多的最佳实践，易于过程改进。
4. CMM主要是针对软件的

CMM/CMMI的各级特点

• 初始级（Initial）过程能力是不可预测的，过程是无序的。
• 可重复级（Repeatable）过程能力是有纪律的。
• 已定义级（Defined）过程能力为标准的和一致的。（SEPG软件工程过程组）
• 已管理级（Managed）过程能力为可预测的。
• 优化级（Optimizing）过程能力的基本特征是不断改进，不断改善其项目的过程性能。

ISO9001和CMM的关系

• 最大的相似点（强调管理、过程、规范化和文档化）
• 不同点（CMM把焦点严格对准软件；ISO9001的范围包括硬件、软件、流程性材料和服务）
• 两者之间的联系（CMM2和ISO9001强相关；CMM的每个关键过程域至少按某种解释与ISO9001弱相关）
• 六西格玛（本质是一个全面管理概念，而不仅仅是质量提高手段）

3. 六西格玛管理法是以质量作为主线，以客户为中心，利用对事实和数据的分析，改进提升一个组织的业务流程能力，从而增强企业竞争力，是一套灵活的，综合性的管理方法体系。

六西格玛管理法原则：（与ISO9000族2000版的八大原则进行比较）

• 注重客户
• 注重流程
• 全员参与
• 预防为主
• 事实依据的决定
• 持续和突破性改进

六西格玛改进区域：

• 周期时间（流程速度、回应能力）
• 输出物的变差（产品或服务的直通率，缺陷成本降低，客户满意升高）
• 营运效率（更低成本）

六西格玛的实施模式（DMAIC）

• 定义（Define）提出问题，确定目标
• 测量（Measure）收集资料，寻找原因
• 分析（Analysis）研究资料，确定原因
• 改进（Improve）优化解决方案
• 控制（Control）推行控制系统

三大质量管理体系的区别：

ISO9000是不分行业的质量管理体系；CMM/CMMI只适用于软件行业的质量管理体系；六西格玛是考虑质量、成本、进程三方面的不分行业的质量管理体系。

软件质量模型

项目和产品的区别（依据需求来源不同）：

项目：由特定用户提出，以合同、契约为方式表现，企业需求人员获得；

产品：由企业内部的市场人员进行对潜在客户群进行分析后得出。

 

质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。

• 内部质量：从接收到用户的原始需求开始到产品交付用户之间的所有中间过程产品的质量（由开发与测试人员决定）（影响因素“铁三角”流程最主要）
• 外部质量：软件系统作为一个整体运行时所体系出来的特性（系统测试-测试人员决定）
• 使用质量：用户评价

软件质量模型

1. 软件功能性（核心）

当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。

• 适合性（Suitability）：软件产品为指定的任务和用户目标提供一组合适的功能的能力。
• 准确性（Accuracy）：软件产品提供具有所需精确的正确或相符的结果或效果的能力。
• 互操作性（Interoperabiblity）：软件产品与一个或更多的规定系统进行交互的能力。
• 保密安全性（Security）：软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。
• 功能性的依从性

      2. 软件可靠性

在指定条件下使用时，软件产品维持规定的性能级别的能力。

• 成熟性（Maturity）：软件产品为避免由软件中错误而导致失效的能力。
• 容错性（Fault Tolerance）：在软件出现故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。
• 易恢复性（Recoverability）：在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。（MTTR平均恢复时间和恢复业务的程序）
• 可靠性的依从性

    3.  软件易用性

在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力

• 易理解性（Understandability）：软件产品使用用户能理解软件是否合适以及如何能将软件用于特定的任务和使用环境的能力。
• 易学性（Learnability）：软件产品使用户能学习其应用的能力。
• 易操作性（Operability）：软件产品使用户能操作和控制它的能力。
• 吸引性（Attractiveness）：软件产品吸引用户的能力。
• 易用性的依从性

  4. 软件效率（性能测试重点）

在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。

• 时间特性（Time Behavior）：在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。（即完成用户的某个功能需要的响应时间（响应时间是从发起请求到收到成功提示信息））
• 资源利用性（Resource Utilization）：在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的能力。
• 效率依从性

   5.   软件维护性

软件产品可被修改（修正、改进或软件对环境、需求和功能规格说明变化的适应）的能力。

• 易分析性（Analyzability）：软件产品诊断软件中的缺陷或失效的原因或识别待修改部分的能力。
• 易改变性（Changeability）：软件产品使指定的修改可以被实现的能力。
• 稳定性（Stability）：软件产品避免由于修改而造成意外结果的能力。
• 易测试性（Testability）：软件产品使已修复软件能被确认的能力。
• 维护性的依从性

    6. 软件可移植性

软件产品从一种环境迁移到另一种环境的能力。

• 适应性（Adaptability）：软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段就可能适应不同的指定环境的能力。
• 易安装性（Installability）：软件产品在指定环境中被安装的能力（安装测试）。
• 共存性（Co-existence）：软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
• 易替换性（Replaceablity）：软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力。
• 可移植性的依从性

软件质量活动（软件质量保证（SQA）和测试）

SQA和测试的关系：

• SQA从流程方面保证了软件的质量
• 测试从技术方面保证了软件的质量
• 只进行SQA活动或者只进行测试活动不一定能产生很好的软件质量。

SQA的主要工作范围：（被称为老师，医生，警察）

• 指导（指导项目成员执行过程，培训）并监督（过程的执行是否符合规范）项目安装过程实施
• 对项目进行度量（度量数据的采集，度量使得不可见的智力过程变得可见）、分析，增加项目的可视性
• 审核（审计过程产品是否符合相关模块，审计问题产生原因）工作产品，评价工作产品和过程质量目标的符合度
• 进行缺陷分析（提出过程改进意见给SEPG），缺陷活动预防，发现过程的缺陷，提供决策的参考，促进过程的改进

SQA需要职能：

• 软技能（个人素质、沟通能力）自我修炼
• 掌握项目管理
• 熟知软件工程
• 了解业务知识
• 熟练掌握过程改进体系

质量管理PDCA循环（螺旋式上升逐步实现质量目标）：

• Plan计划：制定计划，明确目标；基于目标的方法步骤
• Do执行：执行Plan
• Check检查：检查实际执行结果与计划中预期目标的差距（目标的实现程度，若存在差距，分析原因）
• Act改进：根据分析原因给出明确方案并制定下一轮过程改进目标

软件度量的概念和目的：

度量：对事物属性的量化表示

软件度量：是指计算机软件中范围广泛的测度，包括对软件系统、构件或生命周期过程具有的某个给定属性的度的一个定量测量

目的：

• 提高软件生产率，缩短产品研发周期，降低研发成本、维护成本（对于开发商）
• 提高软件产品质量，提高用户满意度（对用户）
• 为组织持续改进提供量化的指标和反馈（对开发商长远）

软件度量的作用：

• 理解
• 预测
• 评估
• 改进

软件度量分类：

四个基本度量项：

• 规模（Size）：软件产品的大小
• 工作量（Effort）：完成各软件工作产品和活动所用人时（或人天等）
• 进度（Schedule）：各软件工作产品和活动开始和结束的时间
• 质量（quality）-缺陷(defect)：在各软件工作产品和活动中产生的缺陷数

其他度量指标：

• 缺陷密度：研发活动发现缺陷密度；研发活动引入缺陷密度；工作产品缺陷密度
• 生产率：SRS、HLD、LLD阶段文档生产率：页/人天；编码阶段生产率：KLOC/人天；UT、IT、ST用例设计阶段生产率：用例/人天
• 测试执行效率：执行用例数/人天
• 用例密度：用例数/KLOC