测试入门指导——软件测试基本概念

1.软件（software）:

是指一系列按照某种特定规则组织在一起，实现用户需求的计算机数据和指令的集合体。

2.常见的软件研发流程：

(1)瀑布模型:
主要的问题
    a.严格分级导致的自由度降低
    b.开发成果输出过晚，风险高
    c.后期需求的变化难以调整，代价高昂
(2)原型模型：
(3)迭代模型:适合使用与前期需求不稳定，需求多变的项目
(4)增量模型：
(5)敏捷模型:主张简单/拥抱变化/递增的变化/快速反馈

3.软件测试的目的:

(1)发现被测对象与用户需求之间的差异，即缺陷。
(2)通过测试活动发现并解决缺陷，增加人们对软件质量的信心。
(3)通过测试活动了解被测对象的质量状况，为决策提供数据依据。
(4)通过测试活动积累经验，预防缺陷出现，降低产品失败风险。

4.软件测试的原则:

(1)测试证明软件存在缺陷
(2)不可能执行穷尽测试
(3)测试应尽早启动、尽早介入
(4)缺陷存在群集现象
(5)杀虫剂悖论
(6)不同的测试活动依赖于不同的测试背景
(7)不存在缺陷的谬论(证无缺陷远远不如高质量)

5.测试阶段划分:

单元测试（Unit Testing）          ---LLD
集成测试（Integration Testing）   ---HLD
系统测试（System Testing）        ---SRS
验收测试（Acceptance Testing ）

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

(1)测试方法不同
  单元测试属于白盒测试范畴
  集成测试属于灰盒测试范畴
  系统测试属于黑盒测试范畴
(2)测试对象不同
  单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等
  集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
  系统测试主要测试整个系统相对于需求的符合度
(3)判断标准不同
  单元测试判断标准是详细设计说明书
  集成测试的判断标准是概要设计说明书
  系统测试的判断标准是软件需求规格说明书

7.验收测试通常有以下分类：

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

β（BETA)测试：是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试

UAT（User Acceptance Test）测试：用户接受度测试，一般用于商业用户验收系统的可用性。

8.验收测试的结果有两种情况：
软件功能、性能等质量特性与用户的要求一致，软件可以接受
软件功能、性能等质量特性与用户的要求有差距，不被用户接受

9.软件测试方法：

（1）是否关心软件内部结构:
    黑盒测试：只考虑其整体特性，不考虑其内部具体实现
    白盒测试：基于程序结构的逻辑驱动测试。

（2）是否运行软件程度：
    静态测试：不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。
    动态测试：按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。

（3）是否借助工具：
    手工测试：测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式
    自动化测试：一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成

10.软件测试模型：

（1）V 模型：
    瀑布模型演变而来的测试模型；从上自下、从左至右
    缺点：测试活动太滞后于研发活动，项目早期的缺陷，在后期才能发现

（2）W 模型（双V模型）：
    研发和测试并行，时刻进行文档、软件的确认和验证工作

（3）X 模型：
    将程序分割成多个代码片段，最后进行集成。提出了探索性测试的概念

（4）H 模型：
    测试活动和开发是完全分离的，分测试准备阶段和测试执行阶段，当开发活动到达某一个测试执行点的时候，开始进行测试执行阶段。

11.软件测试类型：

（1）.功能测试
（2）.性能测试
（3）.负载测试
（4）.压力测试
（5）.容量测试
（6）.稳定性测试
（7）.安全性测试
（8）.兼容性测试
（9）.GUI测试
（10）.可用性测试
（11）.接口测试
（12）.异常测试
（13）.文档测试
（14）.安装与卸载测试

12.整个测试流程由四大步骤组成：

(1)测试计划：

    a.评审软件需求
    b.编写测试计划

(2)测试设计:

    a.测试需求分析
    b.测试方案

(3)测试实现:

    a.设计测试用例
    b.搭建测试环境
    (准备测试数据
    开发测试工具
    编写测试脚本)

(4)测试执行:

    a.执行测试用例
    b.提交缺陷单报告
    c.回归测试
    d.优化测试用例
    e.测试报告

13.缺陷管理：

(1)缺陷的评价标准：

    a.软件未实现需求规格说明书（SRS）要求的功能
    b.软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
    c.软件出现了需求规格说明书（SRS）指明不应出现的错误
    d.软件实现了需求规格说明书（SRS）未提到的功能
    e.软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好

(2)软件缺陷产生的原因多种多样，一般可能有以下几种原因:

    a.需求表述、理解、编写引起的错误。
    b.系统设计架构引起的错误。
    c.开发过程缺乏有效的沟通及监督，甚至没有沟通或监督。
    d.程序员编程中产生的错误。
    e.软件开发工具本身隐藏的问题。
    f.软件复杂度越来越高。
    g.与用户需求不符，即使软件实现本身无缺陷。

(3)缺陷报告单写作准则：
    a. Correct（准确）

        每个组成部分的描述准确，不会引起误解
    b. Clear（清晰）

        每个组成部分的描述清晰，易于理解
    c. Concise（简洁）

        只包含必不可少的信息，不包括任何多余的内容 
    d. Complete（完整）

        包含复现该缺陷的完整步骤和其他本质信息
    e. Consistent（一致）

        按照一致的格式书写全部缺陷报告

（4）缺陷报告的相关属性：

    缺陷ID
    缺陷标题
    缺陷所属模块
    缺陷严重程度：
        致命：例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 
        严重：例如，由于单功能失效导致多个相关功能均失效 
        一般：例如，软件的单个功能失效；
        提示：软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；

    缺陷优先级
    缺陷详细报告：
        测试环境：描述发现此缺陷时，可能与缺陷相关的环境和配置描述
        执行步骤：发现此缺陷操作步骤的描述，描述要求要详细，无歧义，开发人员参照可以重现缺陷。
        期望结果和实际结果对比：给出缺陷的现象

    缺陷附件
    可再现性
    缺陷发现人
    缺陷状态:

    -NEW（缺陷的初始状态）
    -Open（开发人员开始修改缺陷）
    -fixed（开发人员修改缺陷完毕）
    -closed（回归测试通过）
    -reopen（回归测试失败）
    -postpone（推迟修改）
    -rejected（开发人员认为不是程序问题，拒绝缺陷）
    -duplicate（与已经提交的BUG重复）
    -abandon（被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态。Abandon是一种特殊意义的Closed)

    缺陷发现阶段
    缺陷所属版本
    缺陷修改日期
    缺陷引入阶段
    缺陷引入原因

（5）缺陷管理的作用：

    a.保证信息的一致性
    b.保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效
    c.利于缺陷分析、产品度量，使项目情况可视化加强

14.需求管理：

（1）需求：
    解决用户问题或达到用户目标所需的条件或能力
（2）需求跟踪矩阵：
    确保需求被设计
    确保需求被实现
    确保需求被验证
    了解需求变更影响的范围
 （3）软件需求跟踪规程：
    在SRS review之前，PM维护分配需求和软件需求清单
    完成RTM中分配需求与SRS的跟踪关系，并确定全套跟踪编号规则（包括需求、设计、测试用例、代码等）
    初始的RTM以验证SRS与分配需求一致
    在SRS review后，RTM和SRS一起进行基线化，作为SRS review的输入
    在后续完成了相应的工作产品后，项目经理要确保RTM在工作产品review前得到及时更新
    更新后的RTM在工作产品review时，作为输入验证工作产品与分配需求一致
    测试完成以后，PM要确保测试用例及其执行状态的跟踪**

15.软件需求评审：

（1）同行评审：
    通过作者的同行来确认缺陷和需要变更区域的检查方法

    作用：
        早期发现缺陷
        去除缺陷
        降低成本
        提高质量
    类型：
        正规检视
        技术评审
        走读
（2）通用评审流程计划阶段：
    项目负责人指定组织者
    作者自检工作产品
    组织者规划本次评审
    检查入口准则
    准备评审包
    制定评审专家（3-6人）
    组织者将评审包、评审通知单发给相关人员

16.什么样的需求是好的需求：

完整性
准确性
一致性
正确性
可行性
可验证性

17.测试需求分析：

来源：
    开发需求
    协议/标准/规范
    用户需求（用户经验）
    测试案例库（测试经验）
    竞品分析

18.衡量软件质量的六个特性：

    功能性
    可靠性
    易用性
    效率
    可移植性
    可维护性

19.黑盒测试用例设计方法：

等价类划分法
边值分析法
判定表法
状态迁移图法
流程分析法
正交试验法
输入域测试法
输出域覆盖法
异常分析法
错误猜测法

20.等价类划分法：

有效等价类
无效等价类