软件测试Day3|软件测试理论01

1.缺陷

1.1 缺陷的定义和属性

1.1.1 定义

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

• 软件未实现产品说明书中的功能
• 软件实现了产品说明书不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现了产品说明书未明确提及但应该出现的功能
• 软件难以理解、不易使用、运行缓慢或者最终用户会认为不好

1.1.2 缺陷由来

计算机软件第一夫人，大明路Colbol计算机语言，将缺陷命名为BUG。

1.1.3 缺陷属性

属性名称	描述	描述
缺陷类型（Type）	缺陷类型是根据缺陷的自然属性划分的缺陷种类	功能、用户界面、文档、软件包、性能、系统/模块接口
缺陷严重程度（Severity）	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度	致命（Fetal）、严重（Critical）、一般（Major）、较小（Minor）
缺陷优先级（Priority）	缺陷优先级指缺陷必须被修复的紧急程度	P1-P4依次递增
缺陷状态（Status）	缺陷状态指缺陷通过一个跟踪修复过程的进展情况	见下表
缺陷起源（Source）	缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段	需求、构架、设计、编码、测试、用户
缺陷来源（Origin）	缺陷来源指缺陷的起因（直接因素）	需求说明书、设计文档、系统集成接口、数据流（库）、程序代码
缺陷根源（Root Cause）	缺陷根源指发生错误的根本因素	测试策略（错误的测试范围、误测了测试目标、超越测试能力）、过程，工具和方法、团队/人、缺乏组织和通讯、硬件配置不对（算术精度、内存溢出等）、软件设置等（无法释放资源、千年虫的问题等）、工作环境等

• 缺陷严重程度和优先级有什么关系？（没有直接关系，不要认为严重的优先级更高）

缺陷状态	描述（大部分由开发人员标注）
激活或打开	问题还没解决，存在在源代码中，确认”提交的缺陷“ ，还没有进入缺陷的处理流程，等待处理，测试人员进行标注
确认	确认新提交的缺陷是一个真实有效的缺陷，一般有测试主管或质量保证（QA）或产品经理进行确认 。有效的缺陷指派给相关人员进行处理
已修正/修复	缺陷被修复后，一般由开发人员进行标注
关闭或非激活	缺陷被修复完成后，经过测试人员验证后，没有问题
重新打开	缺陷被修复完成后，经过测试人员验证后，缺陷没有完成修复，需要重新打开缺陷修复
推迟	这个软件缺陷可以在下一个版本或阶段中解决
保留	由于技术原因，开发人员不能被解决的缺陷
不能重现	开发不能重现缺陷，一般闪退、崩溃类型或操作系统差异、浏览器缓存等的缺陷。因此，测试人员提交缺陷时需要再三确认
需要更多信息	作为测试人员，尽可能将bug相关的文件一起提交（图片、视频等）
重复	测试中，一定要避免这种情况的出现；尤其在软件的某一个功能被多个模块调用，模块被不同测试人员测试
不是缺陷	一定不要在测试工程师的生涯中被开发人员标注为不是bug
需要修改软件规格说明书	缺陷不是技术原因造成，而是由于需求或设计不明确

1.2 缺陷的生命周期

1）发现缺陷->2）提交缺陷->3）确认缺陷->4）分配缺陷（由谁确认，由谁分配）->5）修复缺陷（主要由开发，或UI、产品经理等）->6）验证缺陷->7）关闭缺陷（只能是测试人员关闭，一旦出问题测试一律不背锅）

1.3 缺陷的识别

• 依据：需求文档、设计文档、产品原型、测试用例，都是客观的标准、同行业类似的成熟软件、和开发人员沟通、和有经验的测试人员沟通；都是带有主观色彩的依据

1.4 缺陷报告

名称	模块
1.缺陷编号	Bug_项目名称_模块名称_功能名称_0001
2.所属模块	一级模块/二级模块/三级模块
3.优先级	P1>P2>P3>P4
4.严重程度	S1>S2>S3>S4
5.缺陷概述	用一句话概述缺陷的基本情况
6.缺陷描述	将缺陷的复现步骤、预期结果和实际结果列出来
7.提交人	谁提交的写谁
8.备注	一般写产生该缺陷的特殊情况，将bug的截图作为备注信息

• 编写目的
  1）易于搜索软件测试报告的缺陷
  2）报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
  3）软件开发人员希望获得缺陷的本质特征和复现步骤
  4）市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
• 预期读者：开发人员、质量管理人员、市场人员、运维人员
• 编写准则 5C
  1）Correct准确：每个组成部分描述准确，不会引起误解
  2）Clear清晰：每个组成部分的描述清晰，易于理解
  3）Concise简洁：只包含必不可少的信息，不包括任何多余的内容
  4）Complete完整：包含修复该缺陷的完整步骤和其他本质信息
  5）Consistent一致：按照一直的格式书写全部缺陷报告
• 描述准则：单一准确、可以再现、完整统一、短小简练、特定条件、补充完善、不做评价（不对缺陷表现出来的效果进行主观臆断）
• 缺陷跟踪系统：Bugzilla（英文），Bugfree（中文），禅道（中文国产），QC（外国英文）、JIRA（java）、企业自己开发

2. 软件测试的定义和目的

2.1 软件测试定义

• 正向思维：出发点:使自己确信产品是能够正常工作的评价一个程序和系统的特性或能力，并确定它是否达到期望的结果，软件测试就是以此为目的的任何行为。（调试）
• 反向思维：测试是为发现错误而执行一个程序或系统的过程；测试是为了证明程序有错，而不是证明程序无错；一个好的、成功的测试用例是发现了以前未发现的错误的测试。（测试）
• IEEE定义的测试：在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构建的某些方面给出评价。
• 广义的软件测试：在软件形成过程中的所有工作产品进行测试，而不是只针对程序。

2.2 软件测试目的

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

3. 软件开发模型

3.1 生命周期

3.2 瀑布模型

• 最早提出的软件开发的过程模型。
• 存在的问题：
  1）强调时间顺序严格执行（前阶段不完成后阶段不开始）【线性开发，各个阶段划分完全固定，阶段之间产生大量文档，极大增加工作量】
  2）将测试放在编码之后。没有体现出测试贯穿软件生命周期的原则，不能避免需求的问题一直衍生到编码完成。
  3）不适应用户需求的变化。

3.3 螺旋模型

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

• 引入了其他模型没有的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
• 更适合大型的昂贵的系统级的软件应用。

3.4 迭代模型

迭代包括产生产品发布（稳定、可执行的版本）的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入

• 开发迭代是一次完整的经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。
• 优点
  1）降低了在一个增量上的开支风险。
  2）降低了产品无法按照既定进度进入市场。
  3）加快了整个开发工作的进度。
  4）迭代过程这种模式使适应需求的变化会更容易些。

3.5 敏捷开发模型-scrum

敏捷宣言也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法

3.6 增量模型

把软件分割成独立的模块，能够分批次的完成和交付

• 缺点：打破原有的结构和框架，可能会带来一定的风险
• 一般会和迭代模型一起运用
  1）增加了新功能
  2）优化了…功能
  3）修复了…已知bug

3.7 快速原型模型

应用领域越来越多；原型：就是一个模型，可以模拟操作、简单运行【典型运用软件 Axure—产品经理制作原型】

4. 软件测试流程和模型

4.1 软件测试工作流程

1）获取测试需求->2）编写测试用例->3）制定测试方案->4）开发与设计测试用例>-5）执行测试->6）提交测试报告->7)测试分析与评审->8）提交测试总结->9）准备下一版本测试

4.2 软件测试模型

4.2.1 V模型

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

4.2.2 W模型

由两个v字型模型组成，分别代表测试与开发过程,明确表示出了测试与开发的并行关系。

• 优点:
  1）测试的活动与软件开发同步进行
  2）测试对象不仅仅是程序，包括需求和设计
  3）尽早发现软件缺陷可降低软件开发的成本
• 局限性: 在w模型中，需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代。

4.2.3 H模型

H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

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

4.2.4 X模型

• x模型也是对V模型的改进，x模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接通过集成最终合成为可执行的程序；缺点类似V模型
• X模型定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
  

4.3 软件测试理念

• 尽早测试：测试人员早期参与测试项目；尽早开展测试执行工作
• 全面测试：对软件的所有产品进行全面测试；软件开发和测试人员全面的参与到测试工作
• 全过程测试：测试人员成分关注开发过程；对测试的全过程进行全程的跟踪
• 独立的、迭代的测试：测试活动是独立的；测试活动应该是循环往复、不断进行的

5. 软件测试技术

5.1 软件测试分类

5.1.1 按开发阶段分：重点

• 单元测试：单元测试又称模块测试，是针对软件设计的最小单位-程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。（白）
  1）一般要读程序；
  2）大多是时候是开发人员自己去完成（但是一般不认为是测试）
• 集成测试：集成测试也叫做组装测试。涉及到许多接口测试，是一个持续不断的过程。通常在单元测试的基础上，将所有的程序模块进行有序的递增的测试，是检验程序单元或部件的接口关系，逐步集成为符合概要设计需求的程序部件或整个系统。（灰）
• 确认测试：也叫有效性测试（有时候称为冒烟测试，冒烟测试一般不作为正式的测试环节）。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质。（功能是否实现，一般都是正向测试）（黑）
• 系统测试：是在真实的系统运行的环境下， 检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接，并最终满足用户的所有需求。（黑）
• 验收测试：是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。（黑）

5.1.2 按代码运行分

• 静态测试：不实际运行被测对象，静态检查程序代码、界面或文档中可能出现错误的过程
  1）代码测试：测试代码是否符合相应的标准和规范；
  2）界面测试：主要测试软件的实际界面与需求中的说明是否符合；
  3）文档测试：主要测试用户手册和需求是否真正符合用户的实际需求。
• 动态测试：指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是程序是否运行。

5.1.3 按软件特性分

• 功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求
  1）逻辑功能测试
  2）界面测试
  3）易用性测试
  4）安装/卸载测试
  5）兼容性测试
• 性能测试：功能的另-一个指标，主要关注软件中的某功能在指定的时间、空间条件下，是否使用正常；软件的性能包括很多方面，主要有时间性能和空间性能两种。
• 安全性测试：验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。

5.1.4 按软件测试技术分

• 黑盒测试：通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子。完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
• 白盒测试：又称结构测试。通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
• 灰盒测试：介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，是通过一 些表征性的现象、事件、标志来判断内部的运行状态。

5.1.5 按运行主体分

• 手工测试：功能测试，点点点
• 自动化测试：利用工具软件、编写代码，测试被测软件。

5.1.6 其他测试

• 回归测试：是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例（一般在系统测试）
  1）验证之前版本产生的所有缺陷全部被修复；
  2）确认修复这些缺陷没有引发新的缺陷。
• 冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一 下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。
• 随机测试：是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。（一般在验收测试）
• 猴子测试：把自己当成不懂产品的笨蛋或者小动物随便乱点没有任何的主观意识和想法参与进来让些意想不到的操作造成错误的结果。（一般在验收测试）

5.2 软件测试原则

• 质量第一原则，时间要服从质量。
  1）测试时间不够的情况下，（还有大量内容没有测试），软件能不能发布/上线（×）
  2）严重bug没修复，但是赶着上线，能不能通融（×）
• 所有测试的标准建立在用户需求之上。
  1）需求重要吗？错误的需求对测试人员有什么影响？（很大）
• 软件一启动就是软件测试的开始，而不是等程序写完才开始测试。
• 穷举测试是不可能的。
  1）软件发布了，但是有缺陷是测试人员的错吗？（不一定，测试人员不可能发现所有缺陷）
• 第三方测试会更客观、有效。
• 测试计划是做好测试工作的基础。
• 测试用例的设计出来的，不是写出来的。所以要根据测试目的，采用相应的方法去设计测试用例，提高测试效率，更多的发现错误，提高程序的可靠性。
  1）设计和编写测试用例有什么区别？设计是一项脑力活动，编写的一项体力活动，将设计好的内容通过文字形式表现出来。
• 一般来说，一段程序中发现的错误数越多，其中存在的错误概率越大。
  1）针对已经发现缺陷的模块，如何进行深入测试？（对该模块使劲儿测，关联模块也需要测试）
• 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
• 把尽早测试和不断测试作为测试人员的座右铭。
  1）软件项目不着急的时候，测试任务完成了，你会干什么（继续测试，缺陷是找不完的）
• 回归测试的关联性要引起充分注意，修改一个错误而引起更多的错误。
  1）项目上线了还需要测试吗？（√）
• 测试应该从”小规模“开始，逐步转向大规模。
• 不可将测试用例置之度外，必须彻查每一个测试结果。
• 一定要注意测试中的错误集中现象，与程序员的编程水平和习惯有很大关系。
• 对测试错误结果一定要有一个确认的过程。
  1）缺点（语言表达能力、沟通能力、没耐心、粗心）