软件测试(更新中)

软件和软件测试

• 软件
  • 程序
  • 数据
  • 文档
• 软件的分类
  • 按层次分类
    • 系统软件
    • 应用软件
  • 按组织划分
    • 商业软件（windows, qq）
    • 开源软件
  • 按结构划分
    • 单机软件
    • 分布式软件

软件缺陷的定义

• 软件未实现产品说明书的功能
• 软件实现了产品说明书指明不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现产品说明书不明确提及但应该实现的目标

所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷

缺陷的由来

• 软件缺陷的由来
  • Bug
  • Defect
    计算机软件第一夫人：Grace Hopper
    发明了cobol计算机语言，也是找出电脑程序中第一个bug的女程序员

软件测试的由来

• 起源于上世纪70年代中期
  • 《测试数据选择的原理》
  • 《软件测试的艺术》
• 20世纪80年代早期，软件行业开始逐渐关注软件产品质量，并在公司建立的软件质量保证部门QA(QUALITY ASSUR)或SQA

软件测试的定义和目的

• 正向思维的定义
• 反向思维的定义
• IEEE定义的软件测试
• 广义的软件测试
• 软件测试的目的
• 测试和调试的区别
• 软件测试的对象

软件测试的目的

• 以最少的人力，物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后有由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
• 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误

测试和调试的区别

• 在主体，目标，方法和思路上有所不同
• 测试是从已知条件开始，使用预先定义的过程，并且有预知的结构，调试是从未知的条件开始，结束的过程可能不可预计

软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象

软件工程

• 基于软件危机对于计算机发展的阻碍，1968年，在联邦德国召开的国际会议上，北大西洋公约组织的计算机科学家讨论软件危机问题，提出了软件工程这个名称，从此软件生产进入工程化时代
• 软件工程包括两个方面
  • 软件开发技术：软件开发方法学，软件工具和软件工程环境
  • 软件项目管理：软件质量，项目估算，进度控制，人员组织，配置管理，项目计划
• 引起软件危机的主要问题是软件质量问题
• 软件工程主要解决的就是软件质量问题
• 软件测试是软件质量管理体系中一个非常重要的手段

生命周期

• 需求分析
• 概要设计
• 详细设计
• 编码
• 测试
• 验收

软件开发模型

• 瀑布模型
• 螺旋模型 --主要用于风险控制
• 迭代模型 --软件功能更新，不新建分支
• 增量模型 --将软件分割为独立模块，分批次的完成交付，缺点是打破原有的软件结构和框架，可能会带来一定的风 险，增量模型一般会和迭代模型一起运用（新增了什么功能，优化了什么功能，修复了已知/未知bug）
• 快速原型模型 --应用领域越来越多，原型：就是一个模型 百度搜axure

敏捷宣言

灵敏快速

软件测试流程

• 获取测试需求
• 编写测试计划
• 制定测试方案
• 开发与设计测试用例
• 执行测试
• 提交缺陷报告
• 测试分析与评审
• 提交测试总结
• 准备下一版本测试

软件测试过程模型

• V模型

  • 
  • V模型揭示了开发过程与测试过程中各阶段的对应关系
  • 缺点与不足：V模型仅仅把测试过程作为在需求分析，系统设计及编码之后的一个阶段，忽略了测试对需求分析，系统设计的验证；需求的满足情况一直到后期的验收测试才被验证；没有体验出“尽早地和不断地进行软件测试”的原则。

• W模型

  • 
  • W模型，由两个V字模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系
  • 优点：测试的活动与软件同步开发同步进行；测试对象不仅仅是程序，包括需求和设计；尽早发现软件缺陷可降低软件开发的成本
  • 局限性：在W模型中，需求，设计，编码等活动被视为串行的，这样就无法支持灵活的迭代

• H模型

  • 
  • H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
  • H模型揭示了一个原理：软件测试是一个独立的流程！
  • H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到了准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，也可以反复进行

• X模型

  • 
  • X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人发现计划之外的软件错误

软件测试过程理念

• 尽早测试
  • 测试人员早期参与软件项目
  • 尽早的开展测试执行工作
• 全面测试
  • 对软件的所有产品进行全面的测试
  • 软件开发及测试人员（有时包括用户）全面的参与到测试工作中。
• 全过程测试
  • 测试人员要充分关注开发过程
  • 测试人员要对测试的全过程进行全程的跟踪
• 独立的，迭代的测试
  • 测试活动是独立的
  • 测试活动应该是循环往复，不断的进行

软件测试分类

• 按照开发阶段划分
  • 单元测试：单元测试又称模块测试，是针对软件设计的最小单位----程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元是否正确实现详细设计说明中的模块功能，性能，接口和设计约束等要求，发现各模块内部可能存在的各种错误，单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试
    • 提示：单元测试一般要读程序和代码，大多数时候，单元测试都是有开发人员自己完成（交叉）（但是一般不认为是在做测试）
  • 集成测试：集成测试也叫做组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的，递增的测试，集成测试是检验程序单元或部件接口关系，逐步集成为符合概要设计要求的程序部件或整个系统
    • 提示：集成测试一般是接口测试
  • 确认测试：确认测试也叫有效性测试，是在模拟的环境下，验证软件的所有功能和性能及其特性是否与用户的预期要求一致，通过了确认测试之后的软件，才具备了进入系统测试阶段的资质
    • 提示：确认测称为（冒烟测试），一般不作为正式测试的步骤
  • 系统测试：系统测试是在真实的系统运行环境下，检查完整的程序系统能否和系统（包括硬件，外设，网络和系统软件，支持平台等）正确配置，连接，并最终满足用户的所有需求
  • 验收测试：是软件产品检验的最后一个环节，按照项目任务书或合同，供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
• 按照测试技术划分
  • 黑盒测试:通过软件的外部表现来发现其缺陷和错误，黑盒测试法把测试对象看出一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检测程序是否按照需求规格说明书的规定正常实现。黑盒测试又称功能测试。
  • 白盒测试:：通过对程序内部结构的分析，检测来寻找问题。白盒测试可以把程序看出装在一个透明的盒子里，检测是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试
  • 灰盒测试: 介于白盒与黑盒测试之间的测试。灰盒测试关注输入对于输出正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细，完整，只是通过一些表征性的现象，事件，标志来判断内部的运行状态。
• 按照代码运行划分
  • 静态测试
    • 指不实际运行被测对象，而只是静态地检查程序代码，界面或文档中可能存在错误的过程
    • 代码测试：主要测试代码是否符合相应的标准和规范
    • 界面测试：主要测试软件的实际界面与需求中说明是否相符
    • 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求
  • 动态测试
    • 指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态还是静态就看是否运行
• 按照软件特性划分
  • 功能测试
    • 逻辑功能测试
    • 界面测试
    • 易用性测试
    • 安装/卸载测试
    • 兼容性测试
  • 性能测试
    • 功能的另一个指标，主要关注软件中的某一功能在指定的时间，空间条件下，是否使用正常
    • 软件的性能包括很多方面，主要是有时间性能和空间性能两种
  • 安全性测试
    • 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。
• 其他测试类型

软件测试的原则

• 所有测试的标准建立在用户需求之上
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从于质量。
• 事先定义好产品的质量标准，只要有了质量标准，才能根据测试结果，对产品的质量进行分析和评估
• 软件项目–启动，软件测试也就是开启，而不是等待程序写完，才开始进行测试
• 穷举法是不可能的
• 第三方测试会更客观，更有效
• 软件测试计划是做好软件测试的前提
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性

什么是测试用例

• 测试用例的定义

  • 简单地说，测试用例就是：
    • 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到所设计的预期结果
    • 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件测试人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员，软件开发人员获取通知后，将这个问题修改完成与下一个测试版本内
    • 软件测试工程师获取新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已经修改完成。(回归测试)
    • 

• 测试用例应该包含：

  • 测试用例编号
  • 测试项
  • 依赖用例
  • 测试步骤
  • 输入数据
  • 预期结果
  • 测试结果
  • 测试人
  • 备注

• 用例设计和编写的作用

  • 有效性：测试用例是测试人员测试过程中的重要参考依据
  • 可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率
  • 易组织性：即使是小的项目，也可能会有几千个甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。
  • 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
  • 可管理性：测试用例也可以作为检验测试人员进度，工作量以及跟踪/管理测试人员的效率的标准

• 测试用例编写注意事项

  • 不要设计“穷举测试用例”

• 测试用例模板和包含的内容

• 设计测试用例的作用

黑盒测试用例设计方法（一）

• 测试数据选择

  • 等价类划分法
    • 把程序的输入域划分成若干类
  • 边界值分析法

• 测试步骤设计

  • 因果图法

    • 多种输入条件组合的测试方法 （手机号，验证码，勾选用户协议，密码，确认密码）44
    • 

  • 判定表达

  • 正交实验法

  • 功能图法

• List item

  • 场景法

实战(一)

三角形的判断

• 直角
• 等腰
• 等边
• 钝角
• 锐角

实战：接口测试

• 接口的定义：
  • API(Application Program interface):接口属于一种系统或程序的调用接口
  • GUI(Graphic User Interface):接口属于一种图形界面的操作软件系统
  • 尤其是API，有些公司会制定自己的系统接口标准，当需要执行系统整合，自定义和程序应用等操作时，公司所有成员都可以通过该接口标准调用源代码，该接口标准被称之为开放式API
• 接口测试
  • 接口测试是测试系统内部各个组件间接口，以及系统与外部系之间的交互点
  • 测试的主要内容为：
    • 检查数据的交换
    • 传递和控制管理过程
    • 系统间的相互逻辑依赖关系
  • 接口测试的必要条件
    • 接口说明
    • 调用url
    • 请求方法（get/post）
    • 请求参数，参数类型，请求参数说明
    • 返回参数说明
  • 如何获取接口信息
    • 标准化的接口文档
    • 询问开发人员
    • 测试人员自己抓包获取数据和信息
• 接口测试必须具备的知识
  • 常见的接口传输协议
    • http/https
    • ftp
    • jdbc
    • …
  • 常用的接口测试工具
  • 常见的接口数据组织方式
• 接口测试用例设计
  • 用例设计方法
    • 等价类划分法
    • 边界值分析法
    • 因果图
    • 判定表
    • 正交实验法
    • 场景法
    • 错误猜测法
    • 随机测试
  • 接口测试用例模板
  • 
• 网络层次
  • 
• http协议
  • 无连接
  • 独立
  • 无状态
  • get请求：https://www.baidu.com/s?wd=%E7%BA%AF%E9%BB%91&rsv_spt=1