软件测试知识基础（三）

学习网址：https://coding.imooc.com/learn/list/411.html
软件概念：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及相关文档的完整集合。

• 程序是事先设计的功能和性能要求执行的指令序列。
• 数据是使程序能正常操纵信息的数据结构。
• 文档是与程序开发，维护和使用有关的图文材料。

软件十大特性：

• 形态：软件是无形的、不可见的逻辑实体。
• 智能：软件是复杂的智能产品，它的开发凝聚了人们的大量脑力活动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能，帮助我们解决复杂的计算、分析、判断和决策的问题。
• 开发：使用工具来辅助软件开发工作，但目前尚未实现自动化，软件开发中仍存在个体劳动，使得该工作充满个人行为和个人因素。
• 质量：软件由人编写，由于开发特性存在，所以不存在没有缺陷的软件。
• 生产：软件一旦开发出来，它的复制十分简单，其成本也极为有限。
• 管理：由于生产特性存在，所以软件过程中的管理显得更加重要与独特。
• 环境：软件的开发和运行都离不开相关的计算机系统环境，包括支持它相关的软件和硬件。软件对计算机系统的环境有不可摆脱的依赖性。
• 维护：软件投入使用以后需要进行维护，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构。
• 废弃：与硬件不一样，软件并不是由于被用坏而废弃的。
• 应用：软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位。

软件的分类：

• 系统软件：负责管理计算机系统中各个独立的硬件，使得它们可以协调工作，如服务性程序、语言程序、操作系统、数据库管理系统。
• 应用软件：为了某种特定的用途而被开发的软件。

软件生命周期（生存周期）：按开发软件的规模和复杂程度，从时间上把软件开发的整个过程，从计划开发到软件报废的整个历史阶段进行分解，形成相对独立的几个阶段。每个阶段分解为几个具体的任务，按规定顺序依次完成任务，并规定一套标准的文档作为各个阶段的开发成果，最终生产出高质量的软件。

• 软件开发顺序：问题定义→可行性分析→需求分析→概要设计→详细设计→编码和单元测试→综合测试→软件维护（8）
• 软件开发内容：确定好要解决的问题。确定该问题是否存在一个可以解决的方案。深入具体了解用户的需求。设计出实现目标系统的几种可能方案，设计程序的体系结构。详细设计每个模块，确定实现模块功能所需的算法和数据结构。开始编码和单元测试，通过综合测试后上线，并此之后对软件进行维护。

软件开发模型：由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更。

• 瀑布模型：计划→需求分析→设计→编码→测试→维护（6）
  特点：软件开发的各项活动严格按照线性方式进行，当前活动接收上一项活动的工作成果，当前活动的工作成果需要进行验证。
  缺点：由于开发模型是线性的，增加了开发的风险。早期的错误可能要等到开发后期阶段才能发现。

• 原型模型：客户与开发公司紧密联系，更强调需求，开发周期长，开发会受到变更影响。
  特点：实现客户与系统的交互。进一步细化待开发软件需要。开发人员可以确定客户真正的需求。

• 螺旋模型：制定计划→风险分析→实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试）→客户评估（4）
  特点：螺旋模型是将瀑布模型与快速原型模型结合起来。强调了其他模型所忽视的风险分析。每个螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估。
  缺点：强调风险分析，但要求客户接受并相信风险分析是不容易的。

• 敏捷模型：敏捷开发是以人为核心、迭代、循序渐进的开发方法。
  特点：短周期开发。增量开发。由程序员和测试人员编写的自动化测试来监控开发进度。通过口头沟通、测试和源代码来交流系统的结构和意图。编写代码之前先写测试代码，测试先行。
  缺点：团队人员素质要求高。对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试。

软件开发文档：需求分析文档、概要设计文档、详细设计文档、测试设计文档、测试用例、测试报告（6）

阿里系开发模型的变迁：最早期：边做边改→稳定期：瀑布式→发展期：敏捷→创新期：DEVOPS（敏捷升级，侧重于自动化）

项目进程：编程阶段：单元测试（白盒测试）-测试参与→编程完成：开发联调（集成测试）-开发为主→提测：冒烟测试（自动化为主，手工为辅）-测试执行→测试阶段：系统测试（黑盒测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试）→验收阶段：验收测试-配合用户或需求

软件测试概念

• 经典定义：软件测试（SoftWare Testing）在规定的条件下，对程序进行操作，以发现程序错误，衡量程序质量，并对其是否能满足设计要求，进行评估的过程。
• 标准定义：软件测试是使用人工或自动的手段，来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果之间的差别。

软件测试目的：发现问题，检查系统是否满足要求。

软件测试方法和分类

按生命周期划分：单元测试、冒烟测试、集成测试、系统测试、验收测试
按测试方法划分：白盒测试、黑盒测试、灰盒测试

• 白盒测试：静态分析、动态分析（逻辑覆盖测试、mock测试）
• 黑盒测试：功能测试（界面测试、冒烟测试、回归测试、业务测试、兼容性测试、易用性测试）、自动化测试（web自动化测试、接口自动化测试）、性能测试（性能测试、负载测试、压力测试、容量测试、并发测试、持久性测试）、安全测试（手动测试、自动化审计）

其他：随机测试、探索性测试、α测试、β测试

生命周期各测试方法对比

软件测试常用术语

• C/S：Client指客户端，Server指服务端。基于局域网或互联网，需要一台服务器安装服务端软件，并且每个客户端需要安装客户端软件（QQ）。
• B/S：Browser指浏览器，Server指服务器。与C/S区别在于，不需要安装客户端，只需安装浏览器就可以使用，便于升级和维护（网站）。
• Bug/Defect：指软件（程序与文档）中不符合用户需求的问题。
• 测试环境：指软件运行的平台，包括软件、硬件和网络的集合。
• 测试用例（Test Case）：在测试执行之前设计的一套详细的测试方案，包括测试环境、操作步骤、测试数据和预期结果。
• 冒烟测试（Smoke Testing）：在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具有可测性。
• α测试：验收测试的一种，指由用户、测试人员、开发人员等共同参与的内部测试。
• β测试：验收测试的一种，指内测后的公测，完全交给最终用户测试。

软件测试常见模型

• V模型：瀑布模型的改进，开发与测试处于并行状态。单元测试是以详细设计为参考的，集成测试 - 概要设计，系统测试 - 需求分析，验收测试 - 用户需求。

• W模型：V模型的演化，开发是V，测试是并行的V。W模型增加了软件各个开发阶段，应同步进行的验证和确认活动，明确表示测试与开发并行的关系，有利于尽早全面地发现问题。
  
  V模型与W模型的缺陷在于，无法进行迭代变更（一条直线进行下去）。

• H模型：不存在严格的次序关系，各阶段之间可以反复触发、迭代、增量。将测试活动完全独立出来，清晰体现测试准备活动和测试执行活动。

• X模型：可迭代、集成、探索性测试，对测试人员要求高。
  
  目前使用最多的是W模型，W+H模型。其他以W为准，测试以H作为指导，X是最终或熟练性测试的模板。

测试覆盖率：覆盖率是用来度量测试完整度的一个手段，同时也是测试技术有效性的一个度量。
覆盖率 = （至少被执行一次的 item 数）/ item 的总数
特点：通过覆盖率数据，可以检测我们的测试是否充分。分析出测试的弱点在哪里。指导我们设计能够增加覆盖率的测试用例，有效提高测试质量。

黑盒测试的测试覆盖率：需求覆盖、用例覆盖

• 需求覆盖：在测试中，有哪些函数被测试到了，其被测试频率多大，在所以函数占比例多大，通过设计一定的测试案例，要求每个需求点都被测试到。
  需求覆盖 = （被验证到的需求数量）/ 总需求数量

• 用例覆盖：主要体现在每轮测试验证通过的用例数在总用例中的比重。
  用例覆盖 = （验证通过的用例数）/ 总用例数

测试覆盖率的运用

• 简单的测试覆盖率：本次测试执行的用例数 / 总用例数。
  建立与对总用例数编写全面，一般对大型系统测试要求覆盖率100%。覆盖率审核：抽样验收。
• 基于产品的测试覆盖率：宜昌市需求点 / 总需求点。
  无论什么项目都要求覆盖率达到100%。
  覆盖率审核：抽样验收。
• 基于白盒的测试覆盖率：大多工具判断语句覆盖，即单元测试代码覆盖代码行 / 总代码行。
  更多是对研发人员的考察，要求覆盖率达到80%+。
  缺点：只能代表测试过哪些代码，不能代表是否测试好这些代码，容易遗漏逻辑、判断等场景。
• 基于自动化的测试覆盖率：自动化覆盖的测试用例 / 总测试用例。
  80 / 20原则：用户80%时间在使用20%的功能，自动化测试用例侧重于这20%的核心功能。
  自动化更着重于回归验证，没必要追求高覆盖率，而是要考虑用例设计。

测试覆盖率的意义：应用最多在于测试停止标准，在需要迭代累加的模型中很重要（螺旋、敏捷）。在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码量。

测试团队组织架构：

• 金字塔管理模式：管理更加清晰，对于测试人员来说更加有归属感，有更细致的分工。
  
• 矩阵式管理模式：项目+专业。如有任务上的冲突，先完成项目方向的工作（横向），在空余时间再完成专业领域的晋升（纵向）。
  

测试人员必备


软件测试原则

• 所有的测试都应追溯到用户需求。
• 尽早启动测试工作。
• 28（Pareto）法则：在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出80%的缺陷，最后的4%缺陷可能在用户的大范围、长时间使用后才会暴露出来。（100 - 80 - 20 * 80% = 4）
• 穷尽测试是不可能的。
• 杀虫剂怪事：软件测试越多，其对测试的免疫力越强的现象。解决方法：随机测试、探索性测试等。
• 前进两步，后退一步：缺陷修复总会以20-50%的几率引入新缺陷。每次修复后，必须重新运行先前所有测试用例，从而保证系统不会以隐蔽的方式被破坏。
• 三心二意：细心、信心、耐心、沟通意识、缺陷预防意识。

软件工程标准
国内通用软件工程标准：ISO9000、CMM

• ISO9000：其核心标准是质量保证标准和质量管理标准。
  基本思想：控制与预防。对产品形成的全过程进行控制，建立并有效运行自我完善机制以达到预防不合格。
  
• CMM（Capability Maturity Model）：软件能力成熟度标准，提供增加软件开发和维护软件过程能力的控制能力。
  CMM是对过程能力的评估结果，专为软件开发组织设计，侧重软件开发与改进过程，分为5级。

软件测试标准

• 测试大流程组成（6）：测试规划、测试设计、测试实施、配置管理、资源管理、测试管理
• 测试小流程（7）：角色的确定、进入的准则、输入项、活动过程、输出项、验证与确认、退出的准则