软件测试的基本理论

软件测试的基本理论

• 一. 软件测试概述
• • 1.软件概述
  • • 软件测试周期
    • 软件开发模型
    • • a:瀑布模型
      • b:快速原型模型
      • c:迭代模型（增量模型或演化模型）
      • d:螺旋模型
      • e:敏捷模型
    • 软件质量的概述
    • • 1,软件质量的概念
      • 2，软件质量模型
      • • 1，ISO/IEC9126软件质量模型是一种评价软件质量的通用模型，包括3个层次：
        • 2，ISO9126包含了质量模型的六大特性和27个子特性
        • • (1）功能性（Functionality）：功能性是指与软件所具有的各项功能及其规定性质有关的一组属性，包括：
          • （2）可靠性（Reliability）:可靠性是指在规定运行条件下和规定时间周期内，与软件维护其性能级别的能力有关的一组属性。可靠性反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况：
          • （3）可用性（Usability）:可用性是指根据规定用户或隐含用户的评估所做出的关于与使用软件所需要的努力程度有关的一组属性。包括：
          • （4）效率（Efficiency）:效率是指在规定条件下，与软件性能级别和所使用资源总量之间的关系有关的一组属性。包括：
          • （5）可维护性（Maintainability）：可维护性是指与软件进行修改的难易程度有关的一组属性。包括：
          • （6）可移植性（Portability）:可移植性是指与一个软件从一个环境转移到另一个环境运行的能力有关的一组属性。包括：
        • 3,影响软件质量的因素
  • 2.软件缺陷管理
  • • 1，软件缺陷产生原因
    • 2，软件缺陷的分类
    • 3，软件缺陷处理流程
    • 4，缺陷测试 告
    • 4，缺陷的构成
  • 3.软件测试的概述
  • • 测试目的
    • 测试分类
    • • 1. 测试层次划分
      • 2. 按被测试对象划分
      • 3. 按测试阶段分
      • 4. 按照测试目的分类
      • 5. 按照是否运行分类
      • 6. 按照针对系统内部结构及算法实现完成测试
      • 7. 是否使用工具分类
      • 8. 其他分类
      • 9. 根据软件开发版本周期分类
  • 4.测试与开发
  • • 测试与开发关系
    • 常见软件测试模型
    • • 1，V模型
      • 2，W模型
      • 3，H模型
      • 4，X模型
  • 5.软件测试原则
  • • 软件测试基本流程
    • • 1，软件测试流程
      • • a:分析测试需求
        • b:制定测试计划
        • c:设计测试用例-test case
        • d:执行测试
        • e:编写测试 告
      • 2，测试准入标准与准出标准
      • 3，软件测试暂停、停止标准
    • demo实例
    • • 单车app开锁用车功能测试流程
      • 1，骑行、分析测试需求
      • 2，制定测试计划
      • 3，设计测试用例
      • 4，执行测试用例
      • 5，编写完整的测试 告
      • • **题外话：什么是Sprint*
        • 补充：测试理论知识

由于长时间专项某一项工作，现在整理归纳下测试过程与理论知识，此资料作为工作级基础资料都有自己的理解，如有错误请指正，谢谢

一. 软件测试概述

1.软件概述

相对于硬件而言，按照一定顺序组织计算机数据与指令的集合。

软件测试周期

软件产品从‘出生‘到’消亡‘过程叫做软件生命周期；
生命周期分为6个阶段：

问题定义-需求分析-软件设计-软件开发-软件测试-软件维护

各个阶段涉及的问题：
问题定义：由软件开发与需求方共同讨论，主要是开发目标与设计的可行性；

需求分析：对软件需求进行深入分析，划出软件要实现的功能，并制定成需求文档，即需求文档说明书；

软件设计：在需求分析基础上，对系统进行设计，如，软件架构设计、数据库设计等；

软件开发：在软件设计基础上，选择一种语言进行开发编程，此处关注的是代码规范、程序可读性、以维护、可移植

软件测试：该阶段涵盖各个阶段，前期对需求文档测试、开发期间可白盒测试、软件开发过程中尽可能多的发现问题的缺陷与不足；
软件测试过程：包括需求文档测试、单元测试、集成测试、系统测试
软件测试方法：黑盒测试、灰盒测试、白盒测试；

软件维护：软件发布使用后需要对软件进行维护升级与修复bug等，包括纠错性维护、改进性维护并且耗时最久；

软件开发模型

软件开发模型：规定了软件开发遵循的步骤；是软件开发的导航图，能够清晰表法在开发的全过程、以及每个阶段进行的活动与要完成的任务；
模型：瀑布模型、快速原型模型、迭代模型、螺旋模型、敏捷模型

a:瀑布模型

阶段：计划-需求分析-软件设计-软件设计-编码-测试-维护
瀑布模型整个过程线性过程，优缺点明显
瀑布模型优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化

c:迭代模型（增量模型或演化模型）

迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺（Sprint）阶段，而每一个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都会包含下面四个阶段：初始阶段，细化阶段，构建阶段，交付阶段。在初始阶段中，确认本次冲刺的范围，边界，系统选择的架构，计划，以及所需要的资源等信息

e:敏捷模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
敏捷模型2种开发模式： Scrum 与 Kanban

a:Scrum
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作,其模式含义是-就是响应变化，它能够尽快地响应变化
Scrum开发流程中的三大角色:

产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果.

流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team)
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

进行Scrum开发过程：
1）确定一个Product Backlog（按优先顺序排列的一个产品需求列表-Product Owner 负责）
2)Scrum Team根据Product Backlog列表，做工作量的预估和安排
3)Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog
4)Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）
5)在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇 你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）
6)做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；
7)当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议
8)最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

Kanban (看板)
Kanban是一种高效管理软件开发过程的新技术;
将工作细分成任务,将工作流程显示在“看板卡”上，每个人都能及时了解自己的工作任务及工作进度。
每个成员都可以在“看板”上了解自己的工作任务及整个团队的工作进度。项目开始之后，从目前执行的任务和过程开始，团队会针对每个成员的工作做出持续、增量、渐进式的改变。

4，缺陷测试 告

软件缺陷 告

4，缺陷的构成

按照需求分析结果-规格说明书、系统设计结果、编程代码等归类；结果规格说明书是软件缺陷最多的阶段；
主要有以下原因：

1. 非专业用户与开发和技术人员沟通存在困难，对产品理解不一致；
2. 软件产品还未设计、开发，对于有些特性不够清楚；
3. 需求的变化不一致性；需求在不段变化，而这些变化未在产品规格说明书中得到正确的描述；
4. 对规格说明书不够重视或在其设计与写作上投入人力、时间不足；

局限性：V模型是基于瀑布模型的，V模型有一个缺点，就是将测试放在整个开发的最后阶段，没有让测试今早介入开发，没有在需求阶段就进入测试。
测试与开发串行

2，W模型

W模型是由两个V模型组成，一个是开发阶段，一个测试阶段
W模型中开发和测试是并行的关系


通常情况下判断测试是否达到准入条件，应该检查以下几部分内容是否已经完成：
该开发流程对应的测试策略是否完成;

? 测试方案是否完成;
? 测试用例是否完成;
? 测试环境是否搭建好;
? 相关输入件、输出件是否明确。

也就是说，通常我们要检查上面一些内容是否完成，再确定我们是否需要进入下一个阶段的测试。当测试条件成熟，并且测试准备工作已经完成，进入了测试就绪点，测试执行活动才可以进行。

H 模型的核心是将软件测试过程独立出来，并贯穿产品的整个生命周期，与开发流程并行进行，不需要等到程序全部开发完成才开始执行测试，这充分体现了软件测试要尽早准备、尽早执行的原则。

H 模型具有以下特征：

1)测试是一个独立的过程;
2)测试达到准入条件，才可以执行;
3)测试对象是整个产品包，而不仅仅是程度、需求或相关说明书;

4，X模型

X 模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。
左侧：
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试
右侧：
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。


1，骑行、分析测试需求

测试功能：开锁用车
方式：扫码与输入编
夜间：需要使用手电筒功能
测试内容：
a：扫二维码开锁
b:输入编 开锁
c:调用手电筒

2，制定测试计划

测试计划的安排，制定测试计划书。
单车开锁功能测试计划（表格测试计划其中一部分）

软件版本	V2.2.1
模块	开锁用车
负责人	测试组长
测试人员	测试人员1、2
测试计划	2021.6.6-2-21.7.6
测试用例	001–12
回归测试时间	2021.7.7-2021.7.13

3，设计测试用例

实际用法场景，
1）白天：扫码
2）白天：输入编码
3）夜里：扫码+手电筒
4）夜里：输入编码+手电筒
对于订单正在使用考虑三个状态：正在骑行，未支付，未使用状态
单车app开锁功能

序	用例说明	前置操作	操作	预期结果	备注
001	开锁	无运行订单、无待支付订单	白天+扫码	进入解锁界面
002	开锁	正在运行订单	白天+扫码	无法开锁，提示正在骑行并支付
003	开锁	待支付订单	白天+扫码	无法开锁，提示支付
004	开锁	无运行订单、无待支付订单	白天+输入编码	进入解锁界面
005	开锁	正在运行订单	白天+输入编码	无法开锁，提示正在骑行并支付
006	开锁	待支付订单	白天+输入编码	无法开锁，提示支付
007	开锁	无运行订单、无待支付订单	夜里+扫码+手电筒	进入解锁界面
008	开锁	正在运行订单	夜里+扫码+手电筒	无法开锁，提示正在骑行并支付
009	开锁	待支付订单	夜里+扫码+手电筒	无法开锁，提示支付
010	开锁	无运行订单、无待支付订单	夜里+输入编码+手电筒	进入解锁界面
011	开锁	正在运行订单	夜里+输入编码+手电筒	无法开锁，提示正在骑行并支付
012	开锁	待支付订单	夜里+输入编码+手电筒	无法开锁，提示支付

4，执行测试用例

执行测试用例，对测试过程记录与跟踪。对于缺陷整理成缺陷 告。上述012 测试为符合预期，即整理成缺陷 告
单车app开锁功能测试缺陷 告

缺陷ID	20210505-app-open-lock-012
测试软件名称	单车app
软件测试版本	V2.2.1
缺陷发现日期	20210606
测试人员	XXX
缺陷描述	前置条件：有待支付订单，1，夜里+输入编码+手电筒，2，提示锁已打开
附件	截图或者 错信息
缺陷类型	功能性
缺陷严重程度	严重
缺陷优先级	立即解决
测试环境	手机版本、手机配置、操作系统
重现步骤	有未完成订单，1，进入app扫码开锁 2，输入编码+手电筒 ，点击使用开锁 ，提示锁已打开

5，编写完整的测试 告

本次测试结束后（包含回归测试），需要编写一个完整的测试 告，
注意：一般为很多页的word或者在软件测试管理工具里写

单车app用车测的测试 告

• 一：引言
  • 1，目的
  • 2，术语
  • 3，参考资料
• 二：测试概要
  • 1，项目简介
  • 2，测试环境
  • 3，测试时间、地点、人员

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！