初级测试知识点汇总

一、测试基础

1．软件测试的定义

• 1983年，IEEE提出的软件工程标准术语，软件测试定义如下：
  “使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。
  图示：
  

缺点：只强调动态测试，忽略了静态测试。

• G…J.Myers认为：
  1）程序测试是为了发现错误而执行程序的过程；
  2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
  3）成功的测试是发现了至今为止尚未发现的错误的测试。 缺点：只强调了了发现错误，而忽视了缺陷。

以上两种定义都忽略了性能和效率测试。

2．软件测试的含义（重在理解）：

• 软件测试是一个过程，包含若干活动，运行软件进行测试只是活动之一，它也包含一些不运行软件的活动
• 进行软件测试可以运用人工方式也可以借助于工具
• 进行软件测试可以运行软件也可以不运行软件
• 软件测试的目的是发现软件错误和不足（缺陷），观察角度要全面

3．软件测试的目的：
证明（表明软件能够工作） 检测（发现错误） 预防（管理质量）
测试目的之证明：

• 获取系统在可接受风险范围内可用的信心；
• 尝试在非正常情况和条件下的功能和特性；
• 保证一个工作产品是完整的并且可用或者可被集成。

测试目的之检测：

• 发现缺陷、错误和系统不足；
• 定义系统的能力和局限性；
• 提供组件、工作产品和系统的质量信息。

测试目的之预防：

• 澄清系统的规格和性能；
• 提供预防或减少可能制造错误的信息；
• 在过程中尽早检测错误；
• 确认问题和风险，并且确认解决这些问题和风险的途径。

4．软件测试的主要工作：

• 检视代码、评审开发文档
• 进行测试设计、写作测试文档（测试计划、测试方案、测试用例等）
• 搭建测试环境、执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正
• 通过测试度量软件的质量

5．软件危机的表现：
随着软件复杂度增加，对软件质量的要求越来越高，软件成本增加，投入比较大，系统可用度很低，进度大量滞后。

• 由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；
• 开发早期需求分析不够明确，造成开发后期矛盾集中暴露；
• 不遵循开发规范，开发文档不完整，软件难以维护；
• 缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。

6．软件危机的后果：

• 软件质量不高，很难稳定；质量方面
• 软件项目延期，进度无法控制；进度方面
• 成本增加，无法控制预算。成本方面

7．软件危机的根源：

• 根据摩尔定律，硬件发展很快，相应对软件系统的期望越来越高；
• 软件系统复杂程度增大，开发难度增大，个人已经很难完成开发工作,团队协作对软件需求的理解和沟通出现问题；
• 软件开发是人的智力活动，无法用已有的产业工程方法来组织管理。

软件生命周期（基于瀑布模型）各个阶段：

8．为什么要划分生命周期：

• 把一个混沌的研发过程清晰化；
• 便于监控和管理；
• 每个阶段都会有成果物输出，把智力活动成果固化下来，易于维护；
• 人员利用更加合理。

9．软件生命周期各个阶段具体工作内容：

计划：

• 确定软件开发总目标；（需要研发什么？）
• 给出软件的功能、性能、可靠性以及接口等方面的设想；（需要产品做什么？）
• 研究完成该项目的可行性（包括技术可行性和成本可行性），探讨问题解决方案；（是否可行？）
• 对可供开发使用的资源、成本、可取得的效益和开发进度作出估计；（多长时间能够完成？耗费人力、物力？取得效益？）
• 制定完成开发任务的实施计划。（如何完成？步骤如何？）

需求分析：
对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定，哪些需求是可以满足的，并且给予确切的描述，写出软件需求说明书SRS(Software Requirement Specification)。（把用户的需求细化成可以用来设计的需求规格说明书SRS）

软件研发的类型不同，需求的来源也不同，需求分析中的“用户”针对的具体对象也不同。

• 针对产品的软件研发
  需求来源：市场调研
  用户：市场调研人员
  特点：自己想研发什么，自己就来研发
• 针对项目的软件研发
  需求来源：客户要求
  用户：实际的用户
  特点：别人想研发什么，我们帮着研发

设计：
设计是软件工程的技术核心，这个阶段需要完成相应的设计说明书，设计原则是：高内聚，低耦合（每个模块功能单一，模块间的联系简单）。

• 概要设计阶段需要完成概要设计说明书HLD(High Level
  Design)，把每项需求转换成相应的体系结构，每一部分是功能明确的模块；（每个功能设计一个模块）

• 详细设计阶段需要完成详细设计说明书LLD(Low Level
  Design)，对每个模块要完成的工作进行具体的描述。（实现每个模块，写函数实现）

编码：
把软件设计转换成计算机可以接受的程序，即写成以某个程序设计语言表示的源程序清单，使用RDBMS工具建立数据库。（写代码，建立相应数据库）

测试：
测试是检验软件是否符合客户需求，达到质量要求，一般由独立的小组执行，测试工作分为：

• 单元测试（参照LLD）
• 集成测试（参照HLD）
• 系统测试（参照SRS）

运行和维护：
这个阶段将软件交付用户投入正式使用，以后便进入维护阶段，可能有多种原因需要对它进行修改，如软件错误、系统软件升级、增强软件功能、提高性能等。
10．软件研发相关要素：
人员、过程、工具。（研发既包括开发也包括测试）

• 只有合适的人员借助合适的工具经过合适的过程才能研发出高质量的软件。
• 工具为人员和过程服务，起辅助作用，起关键作用的是人员和过程。

11．软件项目组人员组成：
项目组一般由项目经理领导并负责制定项目计划，分配任务。项目组一般由下列人员参与：

• 分析人员；
• 设计人员；
• 开发人员；
• 测试人员；从技术方面保证软件质量
• 配置管理人员；
• SQA（Software Quality Assurance）质量保证人员。SQA独立与其他部门，起监督作用，从流程方面保证软件质量。

常见项目组架构：

软件开发组：包括开发经理、分析人员、设计人员、开发人员。
软件测试组：包括测试经理、测试人员。
配置管理组：包括配置经理、配置管理员CMO(Configuration Management Officer)

12．基本软件研发流程：

• 瀑布模型
  优点：
  1）划分阶段，阶段清晰；
  2）各阶段都有成果物输出；
  3）人员分配合理。
  缺点：
  1）测试介入过晚，发现缺陷过晚；
  2）修复缺陷的成本大。

  瀑布模型适用于稳定的项目（稳定的版本）和增量的开发。

• 螺旋模型
  优点：迭代、引入了风险分析；
  缺点：复杂度大，成本高，研发周期长，依赖于风险分析，风险分析必须准确、充分。

  螺旋模型适用于预研、人事安全的产品，如金融、军事、航天等。而且必须配备一个风险分析专家。

• RUP流程(Rational Unified Process)统一软件开发过程（商用） 该流程针对于面向对象的设计。
  优点：
  1）子系统相对比较独立；
  2）对需求进行了严格的管理跟踪；
  3）把复杂的系统分解成比较简单的系统（逐步实现）
  缺点：
  1）对需求分析人员能力要求较高；
  2）周期长、成本高；
  3）对系统架构人员能力要求非常高。
  该流程适用于大型项目，如ERP、CRM等。

• IPD流程(Integrated Product Development)集成产品研发流程（IBM研发） 该流程针对以产品为目标的软件公司及涉及到软硬件结合的产品。
  优点：
  1）把各个部门间的流程集成在一起，消除了部门间的壁垒；
  2）端到端的研发活动；
  3）把每个项目都作为一项投资来看。

13．软件研发的几个重要过程：
需求管理、配置管理、缺陷管理、同行评审。

14．测试与调试的差别：
1）测试有目的性，有预期的输出；调试是没有目的性的，从未知的条件开始，操作很随机，结束的过程不可预计。
2）测试由测试人员进行；调试由开发人员进行。
3）先通过测试发现错误或者缺陷，然后开发人员再通过调试去定位引发错误或者缺陷的根源。
4）测试是一个过程，可重复进行；调试只是一次性的行为，没有可重复性。

15．软件缺陷和Bug的概念：

• 软件缺陷：既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。

• Bug：代码中的缺陷。有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。

• 软件错误、软件缺陷、Bug在实际工作中可以认为一样。

16．引入缺陷的原因：（原因有很多，主要靠理解）
1）需求分析出现偏差；
2）设计过程中缺乏有效的沟通或者没有沟通，以致与对需求的理解出现偏差或者设计人员设计能力低；
3）软件复杂度越来越高；
4）编码环节产生错误（程序错误或者开发人员对设计的理解不一致）；
5）需求不断变更；
6）项目进度的压力；
7）不重视开发文档；
8）软件开发工具本身隐藏的问题；
9）白盒测试可能修改代码引入缺陷。

17．缺陷分类：

• 遗漏：规定的或预期的需求未体现在产品中（可能未将规格说明书全面实现，也可能需求分析阶段就遗漏了需求）；

• 错误：未将规格说明书正确实现（可能设计错误，也可能是编码错误）；

• 额外的实现：规格说明书并未规定的需求被纳入产品，得到实现。

18．缺陷放大类型：
随着级数的增加，2/3的缺陷后期会被放大。
在前期尽早去发现缺陷，使得缺陷不会在后期被放大。
解决办法：
1）尽早参与评审，与用户、分析人员、设计人员、编码人员沟通交流；
2）测试准备工作尽早开展；
3）尽早预防，做缺陷分析。
如何选择模型：从质量、成本、进度的方面考虑。

二、软件质量

1．质量的定义
质量概念的引入：实体

• 产品：手机、MP3、汽车、ERP软件、桌子……
• 服务：酒店、出租车、快递、培训、美容……

ISO关于质量的定义表示如下：
一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。而质量就是实体基于这些特性满足需求的程度。（实体特性满足用户需求的程度。）

2．软件质量的三个层次

• 内部质量：从产品立项到产品交付用户之间产生的所有工作产品的质量。目标是开发者定义的，并且可以验证，即看产品是不是在做让它做的事情。（符合需求规格）
  衡量标准：需求规格说明书SRS（显式需求和隐式需求）。

• 验收质量：是用户来评价，衡量标准是显式需求。目标是客户定义的，即判断我们是不是在做我们需要作的事情。（符合用户显式需求）

• 使用质量：用户依据真实的需求（包含显式需求和隐式需求）在真实的使用过程中进行评价。（符合用户实际需求）

3．影响软件质量的因素：

• 流程
• 技术
• 组织

以上三方面是影响软件质量的铁三角，软件质量的提高应该是一个综合的因素，需要从每个方面进行改进，同时还需要兼顾成本和进度。

3.1流程对质量的影响
什么是流程？
它说明了一系列活动及活动间的执行关系。
什么是过程？
过程是方法论、更为详细的流程，它包含很多因素：

• 角色：涉及到活动中的人；
• 职责：角色在活动中应该担当的责任或任务；
• 入口准则（入口条件，入口标准）：开始某项活动所必须满足的条件或环境；
• 输入：开始某项活动时多必须参考的资料或需要加工的原材料；
• 活动：构成过程的一系列动作（活动）；
• 输出：完成某项活动所能够交付的工作成果；
• 出口准则（出口条件，出口标准）：退出某项活动所必须满足的条件或环境；
• 培训：完成某项动所需要的技术支持；
• 方法/工具：完成某项活动所需要的方法/工具；
• 模板：输出成果必须满足、符合的标准；
• 查检表(Checklist)：QA的工作基础；
• 度量(Measurement)：采集一些数据进行度量。

流程对质量的影响：
1）使得不可见的生产过程变的可见；
2）分解质量目标到各个活动中去，使得质量目标易于实现并控制；
3）使得整个生产效率提高，减少内耗，节约成本；
4）资源分配合理
5）流程可以推动人做事情。

3.2技术对质量的影响
什么是技术？技术就是科学的方法论。

流程与技术的关系：
1）只有流程、没有技术，不可能进行现代化软件开发；
2）只有技术、没有流程，不可能研发出高质量的软件产品。

3.3组织对软件质量的影响
什么是组织？组织约等于高层领导。
组织对产品质量不产生直接影响，是对流程和技术产生直接影响，从而间接影响到产品质量。
组织对流程的影响：（规范、标准，静态，只有通过执行才能起作用）
1）当流程的执行遇到阻碍或者困难时，组织应予以支持和解决，以保证流程被顺利执行。
2）组织应确保流程的规范化、制度化，从而保证其执行的效力。
组织对技术的影响：
1）组织应确保有能力的人去做相应的事情（调动工作积极性）。
2）组织是否注重建立企业财富库（知识库、案例库），做技术知识的积累。