从软件工程到软件测试
基础知识
软件
概念：软件是计算机系统中，与硬件相互依存的另一部分，包括程序，数据及相关文档的完整集合
- 程序：按事先设计的功能和性能要求执行的指令序列或者代码结构
- ****数据：使得程序能正常操纵信息的数据结构（数据来自数据库）
- 文档：与程序开发，维护和使用相关的图文资料， 是测试所需的依据内容
特性
- 形态特性：无形的、不可见的逻辑实体
- 智能特性：是复杂的智能产品，它的开发凝聚了人类的大量脑力劳动，体现了知识实践和人类的智慧，具有一定的智能。可以帮助我们解决复杂的计算、分析、判断和决策问题
- 开发特性：软件开发中仍然包含相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素
- 质量特性：由于开发特性存在，所以不存在完全没有缺陷的软件
- 生产特性：与硬件相比，软件一旦开发出来，如果需要提供多个用户，其复制十分简单，成本也极为有限
- 管理特性，相比于传统行业，更为独特
- 环境特性：软件对于计算机系统的环境有着不可摆脱的依赖性，它的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件；
- 不同语言开发的程序，要搭配不同的运行环境来兼容
- 维护特性：软件投入使用以后，需要进行维护，但与传统产业产品的维护不同，它体现在升级、优化、功能更新等，甚至可以重构
- 废弃特性：主要是不能满足市场和用户需求而导致的废弃
- 应用特性：应用极为广泛
软件分类
- 系统软件：负责管理计算机系统中各个独立的硬件，使其可以协调工作
- 服务性程序
- 语言程序
- 操作系统
- 数据库管理系统
- 应用软件：为了某种特定用途而开发的软件。可以是一个特定的程序，也可以是一组功能联系紧密，相互协作的程序的集合
软件的生命周期
定义：又称为生存周期，它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段
同时每阶段又分解成几个具体的任务，然后按规定顺序依次完成各个阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件
软件的一生
问题定义 – 可行性分析 – 需求分析 – 概要设计 – 详细设计 – 编码和单元测试 – 综合测试 – 软件维护
这一个过程会随着项目的迭代升级，不断循环
软件开发模型
发展经历：
边做边改：
- 缺点：随着项目变得复杂，管控越来越难
瀑布模型：
- 流程：计划–需求分析–设计–编码–测试–运行维护
- 特点：软件开发的各项活动严格按照线性方式进行；当前活动接受上一项活动的工作结果；当前活动的工作结果需要进行验证
- 缺点：
- 由于线性开发，增加了开发的风险
- 早期的错误可能要等到开发后期阶段才能发现，错误成本大
原型模型：客户与开发公司紧密联系，开发周期长，会受到需求变更的影响
- 特点：实现客户与系统的交互；进一步细化待开发软件需求；开发人员可以确定客户的真正的需求
螺旋模型：制定计划–风险分析–实施工程（需求确认、软件需求、软件产品设计、设计确认与需求、详细设计、开发、测试）–客户评估
- 特点：
- 螺旋模型是将瀑布模型与快速原型模型结合起来
- 强调了其他模型所忽视的风险分析
- 每次螺旋包括4个步骤，不断递进：制定计划–风险分析–实施工程–客户评估
- 缺点：过于强调风险分析，但要求许多客户接受并相信这种分析，增加了操作难度
敏捷模型：一种以人为核心、迭代、循序渐进的开发方法
- 特点：
- 短周期开发
- 增量开发
- 由程序员和测试人员编写的自动化测试来监控开发进度
- 通过口头沟通、测试和源代码来交流系统的结构和意图
- 测试先行：编写代码前，先写测试代码
- 缺点：
- 团队的组建较难，人员素质要求较高
- 对测试人员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试
DEVOPS：需要做到更强的持续集成，更强的自动化工具的使用
软件开发文档
需求分析文档
概要设计文档
详细设计文档
测试设计文档
测试用例
测试报告
项目各阶段的测试相关工作
编程阶段：单元（白盒）测试，以开发为主，需要测试参与；关注覆盖率
编程完成：开发联调（集成测试），以开发为主
提测：冒烟测试（自动化为主，手工为辅）-测试执行
测试阶段：系统测试（黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试）
验收阶段：验收测试，配合用户或需求
软件测试
定义：是使用人工或者自动的手段，来运行或测定某个软件系统的过程，其目的在于，检验软件是否满足规定的需求，或弄清楚预期结果与实际结果之间的差别
目的：发现问题，检查系统是否满足需求
分类
生命周期，各种测试方法对比
软件测试常用术语
C/S : C 代表客户端， S 代表服务器端；这种软件是基于局域网或者互联网的，需要一台服务器来安装服务器端的软件，每台客户端都需要安装客户端软件。
B/S : B代表浏览器， S 代表服务器端；这种软件同样是基于局域网或者互联网的，区别在于不需要安装客户端，只需要浏览器就可以直接使用。例如常见的门户网站
缺陷（bug/defect）：软件中不符合用户需求的问题
测试环境：软件运行的平台， 包括软件、硬件、网络的集合。
- 测试环境 = 软件 + 硬件 + 网络
测试用例（test case）：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果
- 测试用例 = 输入+输出+测试环境
冒烟测试（smoke testing）：在对一个新版本进行系统大规模地测试之前，先验证软件的基本功能是否实现，是否具备可测性
α测试：由用户、测试人员、开发人员等共同参与的内部测试
β测试：内测后的公测，即完全交给最终用户测试
软件测试常见模型
V模型：是瀑布模型的改进，在软件开发的生存期，开发活动和测试活动几乎同时开始，两个并行的动态的过程就会极大的减少bug和error的出现几率
W模型：相对于V模型，更科学，开发和测试同时进行，有利于及早发现问题；增加了软件各开发阶段中应同步进行的验证和确认活动，明确表示出了测试和开发的并行关系
H模型：将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰体现出来
X模型：探索性测试的模型，可迭代、可继承；对测试人员的经验要求较高
目前，使用更广泛的是 W模型的改进（相当于 W模型 与 H模型的结合），各方面的测试内容，以 W模型 为准， 测试的周期，测试的方法，测试的进度，以 H模型 作为指导
软件测试覆盖率
用来度量测试完整性的一个手段，同时也是测试技术有效性的度量
覆盖率 = （至少被执行一次的 item 数）/ item的总数
作用：
- 检测测试是否充分
- 分析出测试的弱点
- 指导设计能够增加覆盖率的测试用例，提高测试质量
- 不能一味追求覆盖率，因为测试成本会随着覆盖率的增加而增加
标准
对于黑盒测试：需求覆盖、用例覆盖
- 需求覆盖：在测试中，有哪些函数被测试到，其被测试到的频率有多大，这些函数在系统所有函数中的占比有多大通过设计一定的测试用例，要求每个需求点都被测试到
- 需求覆盖 = 被验证到的需求数量 / 总的需求总数
- 用例覆盖：主要体现在我们每轮测试验证通过的用例数在总用例中的比重
- 用例覆盖 = 被验证到的用例数量（包括手工和自动化测试用例） / 总的用例总数
测试覆盖率的运用
简单的测试覆盖率：本次测试执行的用例数 / 所有用例数
- 基于认为总用例数编写全面，一般对于大型系统测试要求覆盖率达到 100%
- 覆盖率审核：抽样验收
基于产品的测试覆盖率：已测试需求点 / 设计所有需求数
- 以产品、需求维度统计，无论大型项目或是小需求迭代，都要求覆盖率达到100%
- 覆盖率审核：抽样验收
基于白盒的测试覆盖率：大多工具判断语句覆盖； 单元测试代码覆盖代码行 / 总代码行
- 更多时候要求覆盖率达到 80% 以上
- 缺陷：只能代表测试过哪些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景
基于自动化的测试覆盖率：自动化覆盖的测试场景 / 所有测试场景
- 用途：侧重于回归验证，没必要追求过高的覆盖率， 而要考虑用例设计
测试覆盖率的意义：
- 应用最多的地方在测试停止标准
- 在瀑布模型中，测试覆盖率并不重要
- 在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
- 在短迭代，
DevOps中，更强调单元测试覆盖率来评估不断增加的代码数量
知识体系
基础知识
流程
测试用例设计方法
兼容性测试/易用性测试
缺陷管理
测试工具使用：自动化、性能、安全
测试文档编写
素质
踏实细心
积极主动
好奇心、怀疑一切
良好的交流能力
自我提升和总结的能力
责任感
测试原则
- 所有测试都应追溯到用户需求
- 尽早启动测试工作
- 帕累托法则
- 穷尽测试是不可能的
- 软件测试越多，其对测试的免疫力越强
- 软件测试人员必须不断编写不同的，新的测试程序，对程序的不同部分进行测试，以便找出更多软件缺陷
- 前进两步，后退一步
- 每次修复之后，必须重新运行先前的所有测试用例，从而确保系统不会以隐蔽的方式被破坏
- 三心二意：细心、信心、耐心；团队合作的沟通意识，时刻保持怀疑态度且有缺陷预防意识
软件工程标准
国内通用： ISO9000 , CMM
ISO9000 ：核心标准是质量保证标准和质量管理标准
- 基本思想：控制与预防
CMM： 软件能力成熟度模型，是向软件组织提供如何增加对其开发和维护软件过程的控制能力
- 侧重于软件开发和改进过程