【软件测试】软件测试学习笔记（一）

一、软件测试基础

1.1、软件概述

1.1.1、软件生命周期

1.1.2、软件开发模型

• 需求分析：研发分析需求说明书，判断需求的可实现性。
• 概要设计：用到具体的技术点，大致模块划分
• 详细设计：详细到可以为编码做支持，类和类关系,类的设计，函数设计，各个接口的细节、数据库 表的关系,字段关系
• 编码：依托于详细设计进行编码操作。
• 测试：
• 维护：上线后也是需要持续维护

1.1.2.1、瀑布模型

1.1.2.1.1、瀑布模型的特点

(1）是线性模型的一种，在所有模型中占有重要地位，是所有其他模型的一个基础
(2）每一个阶段执行一次，文档驱动（每—步都有文档产出），按线性顺序进行软件开发。

1.1.2.1.2、瀑布模型的优缺点

优点:
(1)开发的各个阶段比较清晰。
(2)当前一阶段完成后，只需关注后续阶段。

缺点:
(1)依赖于早期的需求调查，不适应需求的变化。
(2)风险往往延至后期才显露，失去及早纠正的机会。

1.1.2.2、快速原型模型

在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

1.1.2.2.1、快速原型模型的特点

(1)快速得构建软件的原型
(2)支持用户参与

1.1.2.2.2、快速原型模型的优缺点

优点:
(1)克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。
缺点:
(1)不适合大型系统的开发(适合开发小型的、灵活性高的系统)。

1.1.2.3、螺旋模型

1.1.2.3.1、螺旋模型的特点

(1)引进了风险分析活动

1.1.2.3.2、螺旋模型的优缺点

优点:
(1)螺旋模型很大程度上是一种风险驱动的方法体系。
缺点:
(1)采用螺旋模型需要具有相当丰富的风险评估经验和专门知识。

1.1.2.4、迭代模型

1.1.2.4.1、迭代模型的特点

迭代模型又称为增量模型或演化模型，它将一个完整的软件拆分成不同的组件，然后逐个组件地开发测试，每完成一个组件就展现给客户，让客户确认这一部件功能和性能是否达到客户需求，最终确定无误，将组件集成到软件体系结构中。整个开发工作被组织为一系列短期、简单的小项目，称为一系列迭代，每一个迭代都需要经过需求分析→软件设计→编码→测试的过程

1.1.2.4.2、迭代模型的优缺点

优点:
·在较小的迭代中进行测试和调试很容易。
·并行开发可以计划。
·对于不断变化的项目需求而言, 这是很容易接受的。
·在迭代过程中识别并解决风险。
·在文档上花费的时间有限, 在设计上花费了额外的时间。
缺点:
·它不适用于较小的项目。
·可能需要更多资源。
·由于不完善的要求, 可以一次又一次地更改设计。
·需求变更可能会导致预算超支。
·由于需求变更, 未确认项目完成日期。

1.1.2.5、敏捷模型

敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

1.1.2.5.1、敏捷模型的特点

·需要频繁更改时。
·有一支高素质和经验丰富的团队。
当客户准备好一直与软件团队开会时。
·当项目规模较小时。

1.1.2.5.2、敏捷模型的优缺点

优点
·频繁交货
·与客户面对面的交流。
·高效的设计并满足业务需求。
·随时可以接受更改。
·它减少了总的开发时间。

缺点
·由于缺少正式文件, 因此会造成混乱, 并且各个团队成员随时可能会误解贯穿各个阶段做出的重要决定。
·由于缺乏适当的文档, 一旦项目完成并且开发人员被分配到另一个项目, 完成的项目的维护就会变得很困难。

1.1.3、软件质量概述

软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性，其次是软件产品满足隐式需求的程度

实际需求 :是用户的目的
隐式需求 :是用户未表达的而对产品的期待
显示需求 :是用户对产品需求的表达。

比如顾客来买摩托车。
显示需求:是摩托车
隐式需求:客户未表达而对摩托车的期待
实际需求:见女孩。

影响软件质量的因素:

• 需求模糊
• 软件开发缺乏规范性文件指导
• 软件开发人员问题
• 缺乏软件质量控制管理

eg:对一次性纸杯进行测试，可以测试哪些方面

1.2、软件缺陷管理

1.2.1、软件缺陷产生的原因

1. 需求不明确
2. 软件结构复杂
3. 开发人员水平有限
4. 项目期限短
5. 使用新技术

1.2.2、软件缺陷的分类

1.2.3、软件缺陷的处理流程

每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。

1.2.4、缺陷报告

测试人员在提交软件测试时都会按照公司规定的模板( Word 、 Excel、缺陷管理软件等）将缺陷的详细情况记录下来生成缺陷报告，每个公司的缺陷报告模板并不相同，但一般都会包括缺陷的编号类型、严重程度、优先级、测试环境等，有时还会有测试人员的建议。

编写缺陷报告要注意以下事项:

• 每个缺陷都有一个唯一的编
• 缺陷要有重现步骤
• 一个缺陷生成一份报告
• 缺陷报告要整洁、完整

1.3、软件测试概述

1.3.1、软件测试的目的

• 对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。
• 对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。
• 对于客户需求来说，软件测试能够检验软件是否符合客户需求对软件质量进行评估和度量，为客户评审软件提供有力的依据。

1.3.2、软件测试的分类

1. 按照测试阶段分类
   单元测试:验证软件单元是否符合软件需求与设计，开发人员自测。
   冒烟测试∶软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。
   集成测试︰冒烟测试之后，将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。
   系统测试:将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。
   验收测试︰主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

2. 按照测试技术分类
   黑盒测试︰把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。
   白盒测试:测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。
   
   总结︰相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。

3. 按照软件质量特性分类
   功能测试︰测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。
   性能测试∶测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

4. 按照自动化程度分类
   手工测试︰测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。
   自动化测试︰借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

5. 按照测试项目分类
   界面类测试:验证软件界面是否符合客户需求。
   安全性测试:试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。
   文档测试:以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

6. 其他分类
   α测试:软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。
   β测试︰软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。
   回归测试:对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。
   随机测试︰没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。

1.4、软件测试模型

1.4.1、V形模型

• V模型是最具有代表意义的测试模型，最早是由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果;
• V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。
• V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。

1.1.1.1、V模型的优缺点

优点:
(1)测试v模型即包含了底层测试又包含了高层测试;
(2)包含了底层和高层的测试过程
(3)每个步骤都是文档驱动的

缺点:
(1)当需求变更时将会导致阶段反复，返工量非常大，模型灵活性比较低。

1.4.2、W形模型

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

1.4.2.1、W模型的优缺点

优点:
(1)强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试:(2)更早地介入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复。
缺点:
(1)使用起来技术复杂度高，对于需求和设计的测试要求高，实践起来困难.

1.4.3、X模型

X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。

1.5、软件测试原则

1. 测试应基于客户需求
2. 测试要尽早进行
3. 穷尽测试是不可能的]
4. 遵循GoodEnough原则
5. 测试缺陷要符合“二八”定理
6. 避免缺陷免疫。

1.6、软件测试基本流程

不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。
虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的

被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

(2)制定测试计划
测试计划一般要做好以下工作安排。
确定测试范围:明确哪些对象是需要测试的，哪些对象不是需要测试的。
制定测试策略︰测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型(（如功能测试、性能测试）选定测试环境和测试方法(如人工测试、自动化测试)。
安排测试资源:通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。
安排测试进度根据软件开发计划、产品的整体计划来安排测试工作的进度，同时丕要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
预估测试风险:罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略
(3）设计测试用例
测试用例(Test Case )指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。
测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率

软件测试学习笔记（一）

软件测试学习笔记（一）

软件测试学习笔记（三）

软件测试学习笔记（三）