软件测试

软件测试定义

• 通过手工或者工具对“被测对象”进行测试操作，从而验证实际结果与预取结果之间是否存在差异

软件测试的特征

1、 可以需求开始，而不仅仅是代码
2、即使静态 也是动态
3、可以来预防失败
4、有助于 尽早发现问题
5、可重用

软件测试的作用

1、通过测试工作可以发现并修复软件中存在的缺陷，从而提高产品的使用信心。
2、测试可以记录软件运行过程产生的一些数据，从而为决策提供数据支持。
3、测试可以降低同类型产品开发遇到的风险。

三、测试原则

• 测是原则： 测试原则指的是我们在测试工作时必须遵守的原则

• 测试只能证明软件存在缺陷：无论进行什么样的操作只能证明软件有缺陷
  3. 不能进行穷尽测试：比如计算器 无法将所有的情况罗列出来 经济型原则
  4. 缺陷存在集群现象 ：2 8 原则 在实际工作中我们会集中测试20% 的核心功能 ，因此我们遇到的缺陷都集中在20%
  5. 测试应尽早介入 ：
  6. 某些测试需要依赖特殊的环境
  7. 杀虫剂现象：同样的测试用例不能执行多次，因为软件会产生免疫
  8. 不存在缺陷缪论：任何软件不可能是完美的
  9. 程序员应该尽量避免检查自己的程序
  10.测试用例要定期的评审
  11.测试现场保护和资料归档

软件测试的目的

1. 以最少的人力、物力、时间找出软件中潜在的各种错误和缺陷,通过修正错误和缺陷提高软件质量,回避潜在的软件错误和缺陷给软件造成的商业风险。
2. 通过分析测试过程中发现的问题可以帮助发现当前开发工作所采用的软件过程的缺陷,以便进行软件过程改进;同时通过对测试结果的分析整理,可修正软件开发规则,并为软件可靠性分析提供相关的依据。
3. ·评价程序或系统的属性,对软件质量进行度量和评估,以验证软件的质量满只用户的需求,为用户选择、接受软件提供有力的依据。

• 软件测试的目的是工程性的以发现错误为最终目的

测试对象的介绍

• 软件测试最经常测试的主体是 软件（主体功能）但是软件也不仅仅只有功能需要测试，我们 可以将软件测试分为3个组成： 功能集合 + 使用说明书+ 配置数据

1. 需求分析阶段：各种需求规格说明书
2. 软件架构设计：api接口文档（接口测试）
3. 编码实现阶段：源代码（白盒测试 单元测试）
4. 系统功能使用 ：软件功能主体（当前行业做的最多的一种测试）

测试级别

1. 单元测试（ut 测试）
2. 集成测试（it测试 接口测试）
3. 系统测试（st当前行业做的最多的）
4. 验收测试 （核心：让用户为当前软禁“买单”）
   • α测试 — 内测
   • β测试 — 公测
   • UTA 测试 — 由客户派出对业务非常精通的人员充当用户对软件主题功能进行测试

系统测试 分类

1. 功能测试 ：验证当前软件主题功能是否可用
2. 兼容性测试:验证当前软件在不同环境下是否可用
3. 安全性测试：验证软件是否只能授权用户使用
4. 性能测试：相对于当前软件消耗的资源他的产出能力

软件质量

1. 功能性 ：软件需要满足用户显示或者隐式的功能
2. 易用性 : 软件易于学习和上手使用
3. 可靠性 ：指的是软件必须指明需求中的具体功能
4. 效率性 ：类似软件的性能高
5. 可维护性 ：要求软件具有将某个功能修复之后继续使用的能力
6. 可移植性 ：当前软件可以从一个平台移植到另一个平台上去使用的能力

软件质量保证

• 软件质量保证是贯穿软件项目整个生命周期的有计划和有系统的活动,经常针对整个项目质量计划执行情况进行评估,检查和改进,向管理者、顾客或其他方提供信任,确保项目质量与计划保持一致。
• 确保软件项目的过程遵循了对应的标准及规范要求且产生了合适的文档和精确反映项目情况的报告，其目的是通过评价项目质量建立项目达到质量要求的信心。软件质量保证活动主要包括评审项目过程、审计软件产品,就软件项目是否真正遵循已经制定的计划、标准和规程等,给管理者提供可视性项目和产品可视化的管理报告。

软件测试与软件质量保证

软件测试是获取度量的一种重要手段

评价指导度量
度量指导测试
评价依据度量
度量依据测试

软件测试流程

1. 需求分析

• 当前的核心目的就是梳理我们需要设计的点是什么。
• 需求的来源:需求规格说明书、API文档、竟品分析、个人经验

2. 设计用例

• 用例就是用户为了测试软件的功能而执行的操作过程
• 设计测试用例是有方法的（等价类、边界值、判定表）

3. 评审用例 ： 对当前测试用例进行添加或删除
4. 配置环境

• 环境：指的是当前被测对象运行所需要的执行环境,
• 环境分类 ：操作系统+服务器+数据库+底层代码执行环境

5. 执行用例

• 一般在执行用例之前会做一个冒烟测试：核心是快速对当前软件核心功能或主题执行验证，如果冒烟测试阶段有问题，可以将此版本退回给开发。

6. 回归测试及缺陷跟踪

• 1、回归测试指的就是当我们将某个缺陷提交给开发之后,由它们进行修复,修复完成之后需要测试认员再次对其进行测试【回归测试】
• 缺陷跟踪:指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。

7. 输出报告

• 将当前的测试过程中产生的数据进行可视化的输出。方便其它人去查看。

8. 测试结束

• 当将整个测试过程中产生的一些文档进行整理归档,方便后续版本使用。

软件架构

常见架构：BS CS

• B ----browser 浏览器
• C-----client 客户端
• S------server 服务器

架构的比较

1、标准：相对cs架构来说 BS会显示的标准一些
2、效率：cs 的客户端可以分单一些数据处理，因此执行效率会高
3、安全：cs会相对安全
4、升级：
5、开发成本 cs中客户端需要自己开发成本会高一些

测试分类概貌图

单元测试

• 单元测试又称模块测试,针对软件设计中的最小单位–程序模块, ,进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元测试的六个问题

什么时候做单元测试？

• 编码后,编译通过后进行,
  由谁来做？
• 白盒测试工程师或者开发工程师,最好不要白己做白己代码的测试。
  单元测试的依据
• 源程序(代码+注释) + 《详细设计文档》
  单元测试的通过标准
• 程序通过所有单元测试用例语句的覆盖率达到100%，分支的覆盖率达到85%
  国内单元测试现状
• 简单+没有单元测试计划、单元测试用例和代码覆盖率的统计。
  如何进行单元测试
• 主要用白盒测试，先静态的检查代码是否符合规范，然后动态运行代码，检车程序的运行结果是否正确是一个最基本的要求，还要关注容错处理，程序的边界值处理等，

集成测试

定义：集成测试又叫组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

※系统测试

定义：指的是将整个软件系统看为一个整体进行测试,包括对功能、性能、以及软件所运行的软硬件环境进行测试。

验收测试

定义：验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒收系统。在系统测试的后期,以用户测试为主或有测试人员等质量保证人员共同参与的测试。

• α测试：指的是由用户，测试人员、开发人员共同参与的内部测试
• β测试：指的是内测后的公测，即完全交给最终用户测试
  验收测试重要点：验收签字、收钱

静态测试

定义：是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能出现的错误过程。

• 分为：
• 代码检测：主要测试代码是否符合相应的标准和规范
• 界面检测：主要检测软件的实际界面与需求的说明是否相符
• 文档检测：主要测试用户手册和需求说明是否真正符合用户的实际需求
• 工具：（Logiscope）telelogic 可以用作java/c++等规范

动态测试

• 定义： 是指实际运行被测程序，输入相应的测试数据，检查实际的输出结果和预取结果是否一致的过程。
• 动态测试方法为结构测试和正确性测试
• 动态测试工具：robot、qtp等

黑盒测试

指的是把被测软件软件看作一个黑盒子，我们不关心盒子里面的结构是什么样子，只关心软件的输入和输出数据

白盒测试

指的是八盒子打开，去研究源代码和程序结构

功能测试

是黑盒测试的一方面，他检查实际软件的功能是否符合用户需求。

• 逻辑功能测试
• 界面功能测试
• 易用性测试
• 安装测试
• 兼容性测试

性能测试

时间性能（事务相应时间）
空间性能（系统消耗资源）
一般性能测试
可靠性测试
负载测试
压力测试

回归测试

是指软件被修改后重新进行的测试，如重复执行上一个版本测试是的用例，是为了保证对软件的修改没有引入新的错误而重复进行的测试，

冒烟测试

是指在对一个新版本进行大规模测试之前，先验证下软件的基本功能是否实现，是具备可测试性否。

随机测试

是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真是操作，并发现一些边缘性的错误

软件缺陷的定义

• 软件未达到产品说明书中标明的功能
• 软件出现的产品说明书指明不会出现的功能
• 软件功能超出了产品说明书中指明的范围
• 软件未达到产品说明书中指明应达到的目标
• 软件测试人员认为软件难以理解和使用、运行速度慢、或最终用户认为不好

软件缺陷属性

发现缺陷后要提交缺陷单，包含以下内容：

• id
• 标题
• 测试环境
• 严重等级
• 优先级
• 类别
• 状态
• 描述信息
• 重现步骤
• 附件
• 测试人员’
• 处理人员

软件缺陷等级

软件缺陷的优先级

软件缺陷的类别

软件缺陷的状态

软件测试的生命周期

缺陷管理常见的问题

开发不认为是一个bug
缺陷无法重现
缺陷太多
找不到缺陷
如何减少无效缺陷的提交
防止重复缺陷提交
开发与测试沟通

软件开发模型

瀑布模型

瀑布模型的特征

• 项目分解为独立的不同阶段
• 阶段之间具有顺序性和依赖性，每个阶段通过预先定义的输出与下一个阶段发生联系
• 如果发现问题，则返回到上一阶段，一次跳一个阶段,直到在某个较早阶段改正该错误。

优点：

• 简单
• 易于组织，易于管理

缺点

• 缺乏灵活性，不能适应用户需求的改变
• 开发的小错误被逐级放大，可能导致软件产品报废
• 返回上一级的开发需要十分昂贵的代价
• 随着软件规模和复杂性的增加，对于需求不能完全确定软件开发项目将产生很大的风险

适用的场景

• 需求分析做的比较好的系统
• 二次开发的系统

v字模型

v字模型的特点

• 活动更加并行化，可减少生存周期结束进行测试所需的时间
• 通过实现为每种活动设计测试，实际上是在进行更好的事先确认同样可以降低最后一刻暴漏问题的风险
• 测试由具有合适技能的人员进行设计

v字模型优点

• 在验证和确认有很大的优势

w模型

w模型强调：

-测试伴随着整个软件开发周期，而测试的对象不仅仅是程序，需求功能和设计同样要测试

w模型的优点

• 在v模型的基础上，增加了开发测试的同步测试，形成了w模型，测试与开发同步进行，有利于尽早发现问题

w模型的局限性

• 仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整。

软件测试与软件开发之间的关系

静态白盒测试

• 单元测试
• 代码评审

静态黑盒测试

• 需求文档测试
• 用户文档测试
• 产品说明书测试

静态测试的对象

静态黑盒测试测试内容：

• 开发文档：软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告
• 用户文档：用户收测、操作收测、维护修改建议
• 管理文档: 项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告

问什么进行需求测试

需求文档测试的必要性

• 在软件开发过程中,**需求分析是最开始的工作,**需求分析如果做得不够详细或者是偏离用户需求的话,往往会给项目带来灭绝性的灾难。
• 用户的表达和需求工程师的理解有时候并不会一致,这样会导致用户所想的和需求说明书上所描述的有偏差。

项目测试的周期

需求评审的目的：

需求评审就是要让需求明确起来，让测试开发、需求方都能对需求达成一致。

测试人员为什么需要参加评审

• 在软件生命周期中,越晚发现的错误越难修改,修改成本越昂贵。
• 软件经历了需求,设计,编码,测试,不同的阶段有专业人士配合完成,由于下游技术人员对于上游技术人员的理解偏差,将导致不同阶段的产物之间存在不一致的现象
• 测试人员参与需求评审,充分地理解需求,确保对需求的理解与需求分析人员是一致的。

需求说明书的检查步骤：

• 获取最新版本的软件需求规格说明书,同时尽量获取用户原始需求文档
• 阅读和尝试理解需求规格说明书中的描述的所有需求想。
• 对照需求规格说明书检查列表进行检查和记录。针对检查结果进行讨论,修订需求规格说明书。

需求规格说明书检查列表：

需求文档的规范：