测试入门秘籍<<独孤九剑>>之总决式-软件测试工程师基础知识

总决式-软件测试工程师基础知识

总决式：有种种变化，用以体演总诀，共有三百六十种变化。

软件的概念

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合
程序是按事先设计的功能和性能要求执行的指令程序列
数据是使程序能正常操纵信息的数据结构
文档是与程序开发，维护和使用有光的图文材料

软件的十大特性

1. 形态特性：软件是无形的，不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它确实毫无意义的
2. 智能特性：软件是复杂的智力产品，它是开发凝聚了人们大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析 、判断和决策问题
3. . 开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但目前为止尚未实现自动化。软件开发中任然包含 了相当分量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素
4. 质量特性：软件是由个人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件
5. 生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限
6. 管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特
7. 环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性
8. 维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大的差别，维护体现在升级，优化、功能更新等方面。甚至可以全盘重构
9. 废弃特性：与硬件不同，软件并不是由于被“用坏”被废弃的
10. 应用特性：软件的应用极为广泛，如今它已渗透入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可替代的地位

软件的分类

系统软件：系统软件是负责管理计算机系统中各种独立的硬件，使得他们可以协调工作

• 服务性程序：如诊断程序、排错程序、练习程序 等
• 语言程序：如汇编程序、编译程序、解释程序
• 操作系统
• 数据库管理系统

应用软件：应用软件是为了某种特定的用途而被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组工联系紧密，可以互相卸载的程序集合

软件的生命周期

软件的生命周期：它是按开发软件的规模和复杂程度，从时间上把软件软件开发的整个过程 进行分解，形成相对独立的阶段
每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档为各个阶段的开发成果，最后生产出高质量的软件

graph LR A[问题定义] -->B(可行性研究) B-->C[需求分析] C-->D[概要设计] D-->E[详细设计] E-->F[编码和单元测试] F-->G[综合测试] G-->H[软件维护]

1. 确定好要解决的问题是什么？
2. 确定该问题是否存在一个可以解决的方案
3. 深入了解用户的需求
4. 设计出实线目标系统的几种可能方案，设计程序的体系结构
5. 详细设计每个模块，确定实现模块功能所需的算法和数据结构

余额宝的诞生
是由于基金公司想在淘宝上买基金，但是发现客流量不大，所以有人设计t+0余额宝的雏形，结论是可以做，快速做。其实银行存储利润是非常大的，但是给客户的只有零点几，因为大家对支付宝使用量很大，在支付宝上有很多资金存留，所以支付宝想给客户产生一些收益，所以和银行一拍即合。
可行性研究提出的问题
需要考虑基金是否合规
是否支持千万用户的基金流量
余额宝基金需要将销售端和清算端进行融合。
基金变成724小时是否可行，正常情况下基金是524
双方的数据交互中心要怎么搭建

软件开发模型

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

瀑布模型

计划->需求分析->设计->编码->测试-> 运行维护

特点：

1. 软件开发的各项活动严格按照线性方式进
2. 当前活动接受上一项活动的工作结果
3. 当前活动的工作结果需要进行验证

缺点：

1. 由于线性，增加了开发的风险
2. 早期的错误可能要等到开发后期的阶段才能发现

原型模型

客户与开发公司紧密联系，开发周期长。开发会受到需求变更的影响
特点：

1. 实现客户与系统的交互
2. 进一步细化待开发软件需求
3. 开发人员可以确定客户的真正需是什么

螺旋模式

制定计划->风险分析->实施工程->客户评估
特点：

1. 螺旋模型是将瀑布模型与快速原型模型结合起来
2. 强调了其他模型所忽视的风险分析
3. 每一次螺旋都包好四个步骤

缺点：

1. 强调风险分析，但要求许多客户接受并相信这种分析，是不容易的

敏捷模型

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法

特点：

1. 短周期开发
2. 增量开发
3. 由程序员和测试人员编写的自动化测试来监控开发进度
4. 通过口头沟通、测试和源代码来交流的结构和意图
5. 编写代码之前先写测试代码，也叫测试先行

缺点：

1. 团队的组建比较困难，人员素质要求较高
2. 对测试员要求完全掌握各种脚本语言编程、能执行单元测试、自动化测试

软件开发文档

需求分析文档
概要设计文档
详细设计文档
测试设计文档
测试用例
测试报告

阿里系开发模型的变迁

最早期：边做边改-> 稳定期：瀑布流->发展期：敏捷->创新期：DEVOPS

211 2周上线一个小需求，1周之内开发，1 项目最后的回归测试+项目发布 在1个小时内发布

项目的一生

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

软件测试

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

软件测试方法和分类

生命周期各测试方法对比

	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测后	冒烟测试通过后	发布前
测试对象	最小模块	模块间的接口	整个系统	整个系统	整个系统
测试人员	白盒测试或开发	白盒测试或开发	黑盒测试	黑盒测试	最终用户或需求方
测试依据	代码、注释、详细设计文档	单元测试模块、概要设计文档	冒烟测试用例	需求说明文档、测试方案、测试用例	用户需求、验收标准
测试方法	白盒测试	黑盒与白盒的结合	黑盒测试（手工或与自动化接合）	黑盒测试	黑盒测试

软件测试常用术语

C/S： Client and Server,需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。如QQ，客户端网游
B/S： Browser and Server,不需要安装客户端，只要有浏览器，就可以直接使用，便于升级和维护，是测试的重点
APP ：

Bug/Defect:软件的Bug指的是软件中，不符合用户需求的问题
测试环境：软件测试环境就是软件运行的平台，包括软件、硬件、和网络的集合。用一个等式来表示：测试环境=软件+硬件+网络
测试用例（Test case）：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。用一个等式来表示：测试用例=输入+输出+测试环境
冒烟测试（Smoke Testing ）：在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
a测试：验收测试的一种，指的是由用户、测试人员、开发人员等共同参加的内部测试
b测试：验收测试的一种，指的是内测后的公测，即完全交给最终用户的测试

软件测试的常见模型

V模型

V模型是我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果

V模型就是改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态过程就会极大的减少Bug和Error 出现的机率

W模型

一些高性能高风险的系统、互联网软件、或一个系统难以被具体模块化的时候、就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型

W模型从V模型演化而来，实际上开发时V，测试时并行的V；
相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确的表示除了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。

H模型

真正的测试级别之间不存在严格的次序关系，各个阶段间可以反复触发、迭代、增量

为了解决V模型和W模型存在的问题，形成了iyge完全独立的流程，将测试准备活动和测试执行活动清晰地完全体现出来

X模型

测试覆盖率

覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量
覆盖率=（至少被执行一次的item数）/item的总数

特点：

1. 通过覆盖率数据，可以检测我们的测试是否充分
2. 分析出测试的弱点在哪方面
3. 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加

测试覆盖率对于黑盒测试来说，主要指两个方面：需求覆盖和用例覆盖

需求覆盖：

1. 它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到的
2. 计算公式：需求覆盖=（被验证到的需求数量）/（总的需求总数）

用例覆盖：

1. 主要体现在我们每轮测试验证通过的用例数在总用例中的比重
2. 计算公示：用例覆盖=（验证通过的用例数量）/（总的用例数）

测试覆盖率的运用

简单的测试覆盖率（基于用例）：本次测试执行的用例数/所有用例数
上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%
覆盖率的审核：抽样验收

基于产品的测试覆盖率：已测试的需求点/设计所有需求数
以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%
覆盖率的审核：抽样验收

基于白盒的测试覆盖率：大多工具判断语句覆盖，即单元测试代码行/总代码行
更多的考察研发人员；更多时候要求覆盖率达到80%+
缺陷：覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景

基于自动化的测试覆盖率：自动化覆盖的测试场景（测试用例）/所有测试场景（用例）
80/20原则.比如用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化车市的用例选择更着重于这20%的核心功能
用途：自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计

测试覆盖率的最终意义

应用最多的地方在测试停止标准

单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断的迭代累加，很难确定哪些模块在开发过程中没有给与足够的测试

在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码数量

测试团队组织架构

金字塔式管理

矩阵化管理模式

测试人员必备

软件测试知识体系

测试人员必备素质

软件测试的原则

1. 所有测试都应该追溯到用户需求
2. 尽早启动测试工作
3. Pareto法则应用于软件测试
4. 穷尽测试是不可能的
5. 杀虫剂怪事：软件测试越多，其对测试的免疫力越强的现象。
6. 前进两步，后退一步
7. 三心二意：细心、信心、耐心 团队合作的沟通意识、时刻保持怀疑的态度且有缺陷预防意识

软件工程标准

国内通用的软件工程标准主要有ISO9000及CMM （Capability Maturity Model）

ISO9000

1. 控制的思想，即对产品形成的全过程-从采购原材料、加工制造到最终产品的销售、售后服务进行控制
2. 预防的思想，通过对产品形成的全过程进行控制以建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品

CMM

CMM准确来说不是标准，只是对过程能力的评估结果
CMM对软件企业的评估从初始级开始，共分为5级，一级一级的改进，一级一级的向上提高。等级的上升过程是一个” 动态渐进“的过程
CMM是专为软件开发组织设计的，侧重于软件开发和改进过程、在产婆的设计和开发的细节作了较多要求

软件测试规范

测试系统主要由6个相互关、相互作用的过程组成

1. 测试规划
2. 测试设计
3. 测试实施
4. 配置管理
5. 资源管理
6. 测试管理

软件测试过程中一般会从以下几个方面入手来规范过程，并在每个子过程中明确角色、职责、活动描述以及所需资料

• 角色的确定
• 进入的准则
• 输入项
• 活动过程
• 输出项
• 验证与确认
• 退出的准则