软件测试基础入门知识点

一、行业前景

前言

程序员之间流传着这样一句话：有人喜欢创造世界，他们做了开发工程师，有人喜欢挑毛病，所以他们做了测试工程师。

什么是软件测试

软件测试就是利用手工或测试工具按照测试方案和流程对产品进行功能和性能测试，简单的来说就是为软件做“质检”。

软件测试的重要性

bug 的经济损失：

软件 bug 对我们的生活，工作都会带来毁灭性的破坏。据悉，每年的软件 bug 会让整个市场经济带来近600亿美元的损失！

成立软件测试部门的原因
- 软件测试能提前发现软件存在的缺陷
- 社会分工越来越细 -- 要求软件测试越来越精细
- 专人负责，责任到位

二、测试基础

2.1、什么是软件测试

在规定的条件下对程序（App，.exe安装文件，网页等）进行操作，从而发现错误，对软件质量进行评估的一个过程。

2.2、软件测试的目的

是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。（注意这个问题的答案，经常会与软件测试的定义混淆）

2.3、软件测试的定义

使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

2.4、软件测试的原则

所有的测试都应追溯到用户需求（视频网站，点击后最大化）
应当把 “ 尽早和不断地测试 ” 作为座右铭
测试工作应该由独立的专业的软件测试机构来完成
Pareto 原则，测试发现的错误中80%很可能起源于20%的模块中
设计测试用例（测什么？怎么测？）时，应该考虑各种情况
对测试出的错误结果一定要有一个确认的过程（描述缺陷报告）
制定严格的测试计划
完全测试是不可能的，测试需要终止
注意回归测试的关联性
妥善保存一切测试过程文档

2.5、回归测试

指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

三、软件工程和测试模型

3.1、软件开发过程模型

在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，如：瀑布模型、快速原型模型、螺旋模型。

软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便找准自己在其中的位置，从而发挥自身的价值。

3.1.1、瀑布模型

瀑布模型是线性模型的一种，在所有模型中占有重要地位，是所有其他模型的一个基础
每一个阶段执行一次，按线性顺序进行软件开发
测试的切入点：

测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动，否则将导致测试不充分，很多问题到项目后期才暴露。
瀑布模型的优缺点
- 优点：
  - 开发的各个阶段比较清晰
  - 强调早期计划及需求调查
  - 适合需求稳定的产品开发
- 缺点：
  - 依赖于早期的需求调查，不适应需求的变化
  - 单一流程不可逆
  - 风险往往延至后期才显露，失去及早纠正的机会
  - 问题在项目后期才开始暴露
  - 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败
- 改良
  - 沿用瀑布模型的线性思想，细化各个阶段，在某些重要关注的阶段之间掺入迭代的思想

3.1.2、软件测试 & 软件工程

软件测试与软件工程息息相关，软件测试是软件工程组成中不可或缺的一部分。
在软件工程、项目管理、质量管理得到规范化应用的企业，软件测试也会进行得比较顺利，软件测试发挥的价值也会更大。
要关注软件工程、质量管理以及配置管理与软件测试的关系；在不同的开发模式下，如何进行软件测试。

3.2、测试模型

随着测试过程的管理和发展，测试人员通过大量的实践，从而总结出了不少测试模型，如常见的 V模型、W模型、H模型等。这些模型与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要参考依据。

3.2.1、V模型

V模型是最具有代表意义的测试模型，最早是由 Paul Rook 在20世纪80年代后期提出，由英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果。
V模型推出之前，人们通常把测试过程作为在需求分析、概要设计、详细设计、编码全部完成之后的一个阶段，尽管当时已经出现了测试工作会占用这个项目周期一半的时间，但是大多数人认为测试只是一个收尾工作，V模型在这个时候推出，就是为了改变之前行业的普遍认识。
V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。
V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。

V模型的详细说明
- 需求分析
  - 用户需求、业务需求、需求规格说明书
- 概要设计
  - 系统架构（BS CS）、模块划分（首页、列表页、详情页等）、模块与模块之间的接口（点击首页按钮打开列表页，点击列表页按钮打开详情页）
- 详细设计
  - 模块内部实现的逻辑和方法（如：QQ - 点击好友头像 - 聊天页面 - 输入内容 - 发送 - 都可查看发送内容）
- 编码
  - 实现上面的设计
- 单元测试
  - 检测代码的开发是否符号详细设计的要求（是针对软件设计中的最小单位 - 程序模块的测试）
- 集成测试
  - 检测此前测试过的各组成部分是否能完好地结合到一起（就是将单元测试组装在一起的测试）
- 系统测试
  - 检测已集成在一起的产品是否符号系统规格说明书的要求（整个软件的整体流程测试）
- 验收测试
  - 检测产品是否符号最终用户的需求
V模型的优缺点
- 优点
  - 开发V模型即包含了底层测试又包含了高层测试：
    - 底层测试：检验源代码质量的测试，如：单元测试
    - 高层测试：检验整个系统的需要，如：系统测试
  - V模型清楚地标识出了软件开发的阶段。
  - V模型采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。
- 缺点
  - V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程序已经完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。
  - 同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程，返工量非常大，模型灵活性比较低。
- 改良
  - 进行小型迭代，敏捷型开发

3.2.2、W模型（双V模型）

IEEE std1012-1998 《软件验证和确认（V&V）》的原则中提出了在软件的需求和设计阶段也应该有测试活动，并且提出了相应的原则
W模型由 Evolutif 公司提出：开发一个V，测试一个V，组合的W模型
测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。

W模型的优缺点
- 优点
  - 开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试
  - 更早的接入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复
  - 同样是分阶段的工作，便于控制项目过程
- 缺点
  - 依赖于软件开发和软件测试依然保持的一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整
  - 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用
  - 使用起来技术复杂度高，对于需求和设计的测试要求很高，实践起来困难

四、软件测试分类

黑盒测试（black-box testing）
- 又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和输出数据。
- 黑盒测试能发现以下几类错误
  - 功能不对或功能遗漏
  - 界面错误
  - 数据库访问或者处理错误
  - 性能问题
- 黑盒测试的优点
  - 测试人员不需要了解实现的细节，包括特定的编程语言（没有编程经验的人也可以设计测试用例）
  - 测试人员和编程人员是相互独立的（黑盒测试用例设计与程序如何实现无关）
  - 从用户的角度进行测试，很容易被接受和理解
  - 有助于暴露任何与规格不一致或者歧异的地方
- 黑盒测试的缺点
  - 不能测试程序内部特定部位
  - 如果程序未执行的代码无法发现
  - 不可能做到穷举测试
- 黑盒测试的分类
  - 功能测试（function testing） - 是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求
    - 逻辑功能测试（function testing）
    - 界面测试（UI testing）
    - 易用性测试（usability testing）
    - 安装测试（installation testing）
    - 兼容性测试（compatibility testing）
  - 性能测试（performance testing） - 是软件测试的高端领域，性能测试工程师的待遇和白盒测试工程师不相上下，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师
    - 时间性能（事务响应时间等）
    - 空间性能（系统资源消耗）
    - 一般性能测试
    - 稳定性测试
    - 负载测试：通过负载测试来确定在各种工作负载下，系统各项性能指标的变化情况
    - 压力测试：通过确定一个系统的瓶颈或者刚好不能接受的性能点，来获得系统能够提供的最大服务级别
白盒测试（white-box testing）
- 指的是把盒子打开，去研究里面的源代码和程序结构。
- 在软件公司，往往采用黑盒测试&白盒测试相结合的方式
  - 软件的整体功能和性能进行黑盒测试
  - 软件的源代码采用白盒测试
灰盒测试
- 是介于白盒测试和黑盒测试之间的一种测试（既看功能又看代码），即可保证黑盒的关注点又可掌控白盒的内部结构，但不会去对内部程序功能和运作做详细了解，灰盒测试结合了白盒测试和黑盒测试的要素。
静态测试（static testing）
- 指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误过程。
动态测试（dynamic testing）
- 是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
冒烟测试
- 相当于整体被测项目的流程，流程只要没问题，冒烟测试就相当于是通过了
随机测试（探索测试）
- 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊情况、特殊的使用环境、并发性进行检查，尤其对以前测试发现的重大bug，进行再次测试，可以结合回归测试（Regressive testing）一起进行。
验收测试
- α 测试
  - Alpha是内测版本，即现在所说的CB,此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug较多，普通用户最好不要安装。
- β 测试
  - Beta是公测版本，是对所有用户开放的测试版本。该版本相对于 α 版已有了很大的改进，消除了严重的错误，但还是存在者一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可以从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户的安装
- γ 测试
  - gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了，与即将发行的正式版相差无几，成为正式发布的候选版本。
- 软件正式版本推出之前的几个版本，需要有人测试一下，看看是不是有问题。在开发该软件的公司内部的由该公司内部人员测试的称为：Alpha测试。Alpha测试主要看看有没有功能缺失或系统错误，Alpha测试完后一般不会有大问题了，然后把软件拿给用户测试，称为：Beta测试，主要是看用户对软件外观、使用方便等的反应。这么多的测试版本一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量减少了软件中的bug，然后做过一些修改，成为正式发布的候选版本时，叫做Gamma（现在叫做RC-Release Candidate）。
- 简单来说，Alpha测试主要是测试人员在开发环境下的测试，Beta测试是在实际环境中的测试，或者公司内部人员在模拟真实环境中的测试。