软件测试的基本理论

测试

---shm

https://blog.csdn.net/weixin_42914706/article/details/117492183

1. 软件概述

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

1.1 软件测试周期

    软件产品从‘出生‘到’消亡‘过程叫做软件生命周期；

    生命周期分为6个阶段：问题定义-需求分析-软件设计-软件开发-软件测试-软件维护

• 问题定义：由软件开发与需求方共同讨论，主要是开发目标与设计的可行性；
• 需求分析：对软件需求进行深入分析，划出软件要实现的功能，并制定成需求文档，即需求文档说明书；
• 软件设计：在需求分析基础上，对系统进行设计，如，软件架构设计、数据库设计等；
• 软件开发：在软件设计基础上，选择一种语言进行开发编程，此处关注的是代码规范、程序可读性、以维护、可移植
• 软件测试：该阶段涵盖各个阶段，前期对需求文档测试、开发期间可白盒测试、软件开发过程中尽可能多的发现问题的缺陷与不足；
  软件测试过程：包括需求文档测试、单元测试、集成测试、系统测试
  软件测试方法：黑盒测试、灰盒测试、白盒测试；
• 软件维护：软件发布使用后需要对软件进行维护升级与修复bug等，包括纠错性维护、改进性维护并且耗时最久；

1.2 软件开发模型

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

    模型：瀑布模型、快速原型模型、迭代模型、螺旋模型、敏捷模型

1.2.1 瀑布模型

    阶段：

    软件定义阶段：计划-需求分析

    软件开发阶段：软件设计-软件设计-编码-测试

    软件运行维护：维护

    瀑布模型整个过程线性过程，优缺点明显

    瀑布模型优点

    1）为项目提供了按阶段划分的检查点。

    2）当前一阶段完成后，您只需要去关注后续阶段。

    3）可在迭代模型中应用瀑布模型。

    增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

    4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    瀑布模型缺点

    1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

    2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

    3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

    4）瀑布模型的突出缺点是不适应用户需求的变化

1.2.2 快速原型模型

    阶段：

    细化需求阶段：需求分析-构建原型-原型评价

                确定最终需求

                软件开发

    快速建立一个能反映用户主要需求的原型系统,完成软件核心功能，通过实践来了解目标系统的概貌.

    与瀑布模型相比，克服需求不明带来风险，适用于不能预先确定需求的软件项目，准确设计出软件有的难度，因为不利于对产品的扩展；

1.2.3 迭代模型（增量模型或演化模型）

    阶段：

    迭代一：需求分析-软件设计-编码-测试-第一个组件

    迭代二：需求分析-软件设计-编码-测试-第二个组件

    ......

    迭代n：需求分析-软件设计-编码-测试-第n个组件

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

1.2.4 螺旋模型

    在软件开发过程中及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。构建原型是一种能使某些类型的风险降至最低的方法

    螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

    四种象限
    （1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

    （2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

    （3）实施工程：实施软件开发和验证；

    （4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

    螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

1.2.5 敏捷模型

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

    敏捷模型2种开发模式： Scrum 与 Kanban

    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是一种高效管理软件开发过程的新技术;

    将工作细分成任务,将工作流程显示在“看板卡”上，每个人都能及时了解自己的工作任务及工作进度。

    每个成员都可以在“看板”上了解自己的工作任务及整个团队的工作进度。项目开始之后，从目前执行的任务和过程开始，团队会针对每个成员的工作做出持续、增量、渐进式的改变。

    几乎每个开发团队都在搞“敏捷”，很多团队都声称自己做的是Scrum，实际上他们做的介于Scrum和Kanban之间

2. 软件质量的概述

2.1 软件质量的概念

    指软件产品满足基本需求和隐式需求的程度。基本需求指能满足软件开发时所规定的需求特性-对软件产品最基本的质量要求；隐式需求指界面更美观、用户操作更简洁等；

    从软件质量规定：满足需求规定、满足用户需求、满足用户隐式需求；

2.2 软件质量模型

    全面客观的评价一个产品的质量并不容易；下面我们介绍下ISO/IEC 9126：1991来评价 一个软件的质量;不仅对软件质量进行了定义，而且还定制了软件测试的规范流程；

    ISO/IEC 9126 （1991年发布）是一个软件质量的评估标准，后来被最新的软件质量标准ISO/IEC 25010:2011（2011年发布）取代

2.2.1 ISO/IEC9126软件质量模型是一种评价软件质量的通用模型，包括3个层次：

    质量特性 质量子特性 度量指标

2.2.2 ISO9126包含了质量模型的六大特性和27个子特性

    (1）功能性（Functionality）：功能性是指与软件所具有的各项功能及其规定性质有关的一组属性，包括：

    a:适合性（Suitability）：与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。适合程度的例子是面向任务系统中，由子功能构成功能是否合适、表容量是否合适等。

    b:准确性（Accuracy）：于能否得到正确或相符的结果或效果有关的软件属性。此属性包括计算值所需的准确程度。

    c:互操作性（互用性，Interoperability）:与同其他指定系统进行交互的能力有关的软件属性。为避免可能与可替换性的含义相混淆，此处用互操作性（互用性）而不用兼容性。

    d:依从性（Compliance）:使软件遵循有关的标准、约定、法规及类似规定的软件属性。

    e:安全性（Security）：以防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。

    （2）可靠性（Reliability）:可靠性是指在规定运行条件下和规定时间周期内，与软件维护其性能级别的能力有关的一组属性。可靠性反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况：

    包括：

    a:成熟性（Maturity）：与由软件故障引起失效的频度有关的软件属性。

    b:容错性（Fault Tolerance）:与在软件故障或违反指定接口的情况下，维持规定的性能水平的能力有关的软件属性。指定的性能水平包括失效防护能力。

    c:可恢复性（Recoverability）:与在失效发生后重建其性能水平并恢复直接受影响数据的能力，以及为达此目的所需的事件和努力有关的软件属性。

    （3）可用性（Usability）:可用性是指根据规定用户或隐含用户的评估所做出的关于与使用软件所需要的努力程度有关的一组属性。包括：
    a:可理解性（Understandability）:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。

    b:易学性（Learnability）:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。

    c:可操作性（Operability）:与用户为操作和运行控制所需的努力有关的软件属性。

    4）效率（Efficiency）:效率是指在规定条件下，与软件性能级别和所使用资源总量之间的关系有关的一组属性。包括：
    a:时间特性（Time Behaviour）：与软件执行其功能时响应和处理事件及吞吐量有关的软件属性。

    b:资源特性（Resource Behaviour）：与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。

    （5）可维护性（Maintainability）：可维护性是指与软件进行修改的难易程度有关的一组属性。包括：
    a:可分析性（Analysability）:与为诊断缺陷 或失效原因及为判定待修改的部分所需努力有关的软件属性。

    b:可改变性（Changeability）：与进行修改、排除错误或适应环境变化所需努力有关的软件属性。

    c:稳定性（Stability）:与修改所造成的未预料结果的风险有关的软件属性。

    d:可测试性（Testability）:与确认已修改软件所需的努力有关的软件属性。此子特性的含义可能会被研究中的修改加以改变。

    （6）可移植性（Portability）:可移植性是指与一个软件从一个环境转移到另一个环境运行的能力有关的一组属性。包括：
    a:适应性（Adaptability）：与软件无须采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性。

    b:可安装性（Installability）:与在指定环境下安装软件所需努力有关的软件属性。

    c:依从性（一致性，Conformance）:使软件遵循与可移植性有关的标准或约定的软件属性。

    d:可替换性（Replaceability）:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性。为避免和互用性的含义混淆，此处用可替换性而不用兼容性。

2.3 影响软件质量的因素

    需求模糊、软件开发缺少规范性文件指导、软件开发人员、缺少软件质量控制管理与资源等都有相关影响

3. 软件缺陷管理

    是指对bug的管理。

3.1 软件缺陷产生原因

    总结归纳主要有以下几点

    1）需求不明确；需求不清或不明确开发无法理解导致偏离客户需求目标造成的软件功能和特性上的缺陷；

    2）软件结构复杂；结构复杂很难设计出很好的架构层次或组件框架，导致开发、维护、扩充上困难；

    3）编码问题；team成员的水平、开发缺少有效的沟通，会导致软件中存在很多缺陷；

    4）项目期限短;项目资源有限、时间成本与team压力都会是导致缺陷的潜在因素；

    5）新技术的运用；使用未健全或未获得充分实践的技术

    也可以从技术问题、软件本身、团队工作三个维度去分析；

3.2 软件缺陷的分类

    1）测试种类
    界面、功能、性能、安全性类兼容性

    2）严重程度
    严重、一般、次要、建议

    3）优先级
    立即解决、高优先级、正常排序、低优先级

    4）发生阶段
    需求阶段、架构阶段、设计阶段、编码阶段、测试阶段

3.3 软件缺陷处理流程

    1）提交：测试人员发现bug后，将缺陷提交给测试组长；

    2）分配：测试组长确认后可打回或移交到开发软件，一般为开发接口人统一分配

    3) 确认；开发人员或开发owner分配移交流程，并商讨如何解决缺陷；

    4）拒绝/延期：商议后可定位缺陷性质；非问题走回归、或缺陷安排解决根据优先级安排任务；

    5）处理：开发人员修改缺陷

    6）复测：修复后开发人员进行回归测试、复测

    7）关闭：经过测试重新测试，可进行关闭

3.4 缺陷测试报告

3.5 缺陷的构成

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

    主要有以下原因：

    1）非专业用户与开发和技术人员沟通存在困难，对产品理解不一致；

    2）软件产品还未设计、开发，对于有些特性不够清楚；

    3）需求的变化不一致性；需求在不段变化，而这些变化未在产品规格说明书中得到正确的描述；

    4）对规格说明书不够重视或在其设计与写作上投入人力、时间不足；

    5）整个团队未进行有效的沟通，有时只有项目经理获得比较多信息；

4. 软件测试的概述

4.1 测试目的

    结合软件开发、软件测试、客户需求归纳为以下几点：

    1）对于开发人员通过测试找到问题缺陷帮助开发定位、分析、解决问题预防下次缺陷的产生；

    2）对于测试，使用最少的资源尽可能多的找出软件存在缺陷保证软件的质量，为以后测试积累经验；

    3）对于客户，测试能够检验软件是否符合客户需求，对软件质量进行评估与度量，为客户评审软件提供有力证据；

4.2 测试分类

    软件测试分类取决于分类,可以从不同角度进行分类，例如：测试层次、测试方法、测试对象、测试目标、测试阶段等；通过分类可以理解测试全貌，对软件有一个完整认识。

4.2.1 测试层次划分

    分为4各层次：

    底层测试：单元测试Unit Testing

    接口测试：集成测试-Intergrating Testing,完成系统内单元接口之间和单元集成为一个完成的系统的测试；

    系统层次：系统测试-System Testing,

    用户层次：验收测试-Acceptance Testing,or Beta Testing,验证是否是用户真正需要的产品特性，验收测试，验收测试关注用户环境、用户数据,而用户也参与测试过程；

4.2.2 按被测试对象划分

    1）单元测试：包括组件测试-Component Testing、模块化测试-Modul Testing等；

    2）程序测试：Program Testing;

    3）系统测试：…

    4）文档测试：Documentation Testing,包括需求文档、设计文档、用户手册等；

    5）web 应用测试、客户端测试；

    6）数据库测试、服务器测试；

4.2.3 按测试阶段分

    根据传统的软件测试流程，一般分为，需求评审、设计评审、单元测试、集成测试、系统测试、验收测试、α测试、β测试等阶段；

    例如按照敏捷测试流程：分为-测试需求分析、迭代测试、持续的单元测试及系统测试、验收测试等。

    1）单元测试：软件开发的第一步测试，目的验证软件单元是否符合软件设计需求，大多为开发自测

    2）冒烟测试：软件版本初步建成后，对系统的核心、基本功能测试，重点是否完成了程序主要功能；测试结果关系到是否继续测试或重新修正，冒烟测试是对新构建版本进行的最基本测试；

    3）集成测试：在冒烟测试后，将已经测试过的单元组件和在一起测试之间接口，用于验证软件是否满足设计要求；

    4）系统测试：将经过测试的软件在实际环境中运行，并于其他系统成分-数据库-硬件-操作人员等组合在一起进行测试；

    5）验收测试：主要对软件产品说明进行验证，逐行逐字对照说明书的描述对软件进行测试，确保其符合客户的各项需求要求；

    6）α测试：软件上线前，开发人员、测试人员协助测试。α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；
    目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

    注意！α测试不能由程序员或测试员完成。

    7） β测试
    用户在不同场所进行测试。软件发布上线后
    β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

4.2.4 按照测试目的分类

    以下也可称为测试类型分类

    测试目的可分为：集成测试、功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等

     1）功能测试：Functionality Testiong :也称为正确性测试-Corrctness Testing,验证每一个功能是否按照事先定义要求进行工作；

     2）压力测试：Stress Testing，也称为负载测试-Load Testingg,它用来检验系统在不同负载（数据量、并发数、连接数）等条件下的系统运行情况，特别是高负载、极限负载下的系统运行情况、以发现系统不稳定、系统性能瓶颈、内存泄漏、CPU使用过高等情况；

     3）性能测试：Perforance Testing,测试系统在不同负载条件下的系统具体的性能指标；

     4）可靠性测试：Reliability Testing,检验系统是否能长期保持稳定、正常运行，如确定系统平均故障间隔时间-Mean Time Between Failaures;可靠性测试包括强壮性测试-Robustness Testing 和异常处理测试-Exception Handling Testiing;

     5）灾难恢复性测试：Recovery Testiing,在系统崩溃和他硬件故障或者其他灾难性发生时，重新恢复系统和数据的测试；

     6）安全性测试：Security Testing ,测试软件在没有授权的内部或外部用户的攻击和恶意破坏时如何进行处理，如何保证软件和数据的安全;

     7）兼容性测试：Compatibility Testing,测试系统在不同运行环境下的实际情况；

     8）回归测试：Regression Testing,为保证软件中新的变化不会对原有的功能正常使用造成影响测试，也就是为了排除新合入代码不会对原有功能产生影响；

     9）安装测试：Installion Testing,在一个真实或者接近用户环境中，验证系统是否能按照安装说明书步骤安装完成，其中要考虑不同设置及配置、安装文档的准确性;

     10）文档测试:以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

4.2.5 按照是否运行分类

    按照测试过程中软件是否被执行

    静态测试：对软件产品的需求和设计规格说明书的评审、对程序代码的审查及静态分析等；

    件评审的对象分类 ：管理评审、技术评审、文档评审、流程评审

    对于软件测试应包含：需求评审、设计评审、代码评审和文档评审；管理评审、流程评审则属于软件质量保证的组织和过程管理的活动内容；

    动态测试：是通过真正的运行程序发现错误，通过运行代码，来获取系统的运行行为、变量实时结果、内、堆栈、线程以及测试覆盖的各个方面，判断系统是否存在问题；

4.2.6 按照针对系统内部结构及算法实现完成测试

    黑盒测试、灰盒测试、白盒测试（透明盒测试）

4.2.7 是否使用工具分类

    1）手工测试
    测试人员一条一条执行代码完成测试，比较耗费时力

    2）自动化测试
    自动化是借助脚本、自动化测试工具等完成相应的测试工作，需要人工的参与，把操作步骤写成代码，通过脚本完成测试

4.2.8 其他分类

    1）随机测试：随机测试是在没有测试用例、检查列表、脚本或者指令的测试；主要根据自己的经验对软件的功能和性能进行抽查。是测试手段的补充，保证测试覆盖完整性的有效方式的过程。

    2）主动测试|被动测试

4.2.9 根据软件开发版本周期分类

    预览版本preview测试、内部测试版本Alpha测试、公测版本beta测试、候选版本Release测试，这些测试完成后软件版本就可以上线了。

5. 测试与开发

5.1 测试与开发关系

    软件 缺陷并不一定都是编码引起的，可能由前期的需求分析、软件设计阶段引入的，所以软件测试贯穿整个测试过程非常有必要。

    软件测试在各个阶段发挥作用：

    1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。

    2）需求分析阶段：确定测试需求分析，即确定项目中需要测什么，同时制定系统的测试计划

    3）概要设计与详细设计阶段：制定单元测试计划和集成测试计划

    4）编码测试：开发相应的测试与脚本测试。

    5）测试阶段：实施测试并提交相应的测试报告。

    软件测试与软件开发过程相反，自底向上，逐步集成过程，首先进行单元测试，排除模块间内部逻辑与功能上缺陷，然后按照软件设计需求进行集成测试排除子系统与模块上的错误，最后进行系统测试，检查其是否满足软件需求。

5.2 常见软件测试模型

    软件测试模型对软件测试由指导作用，对测试结果和质量有很大影响；

5.2.1 V模型

https://img-blog.csdnimg.cn/20210605224016158.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_70

    V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

    单元测试：是模块测试，验证软件的基本组成单位的正确性，是白盒测试

    集成测试：是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合）

    系统测试：系统测试包括：冒烟测试 系统测试 回归测试

    1）冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作

    2）系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑盒测试

    3）回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误

    验收测试：是确保软件的实现能否满足用户的需求或合同的要求

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

    测试与开发串行

5.2.2 W模型

https://img-blog.csdnimg.cn/20210605224319600.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_70

    优点：测试与开发并行，让测试今早介入开发环节，使测试今早发现问题今早解决。

    局限性：虽然开发与测试并行了，但是在整个开发阶段，仍然是串行的，上一阶段未完全完成无法进入下一阶段，不支持敏捷模式的开发。

5.2.3 H模型

https://img-blog.csdnimg.cn/20210605225244345.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_70

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

    H 模型提倡者认为测试是一个独立的过程中，所以在H 模型中并没有看到关于开发的过程，而是测试的一个流程，H 模型演示了在整个生命周期中某个层次上一次软件测试的“微循环”。

    在测试H 模型中有一个测试就绪点，也就是测试有一个准入条件

    通常情况下判断测试是否达到准入条件，应该检查以下几部分内容是否已经完成：

    该开发流程对应的测试策略是否完成;

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

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

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

    H 模型具有以下特征：

    1)测试是一个独立的过程;

    2)测试达到准入条件，才可以执行;

    3)测试对象是整个产品包，而不仅仅是程度、需求或相关说明书;

5.2.4 X模型

https://img-blog.csdnimg.cn/20210605230052181.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_70

    X 模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。

    左侧：X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试

    右侧：X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

    X 模型具有以下特征：

    1)公司可以根据自身的情况确定是否要做单元测试，还是直接做系统测试;

    2)测试应该是一个不断迭代的过程，直到封版发布;

    3)提倡探索性测试

6. 软件测试原则

    公认的6个基本原则

• 1）测试应基于客户需求：测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。

• 2）测试要尽早进行：软件的错误存在于软件生命周期的各个阶段，尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本，尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制订出完善的计划和方案，提高测试的效率

• 3）穷尽测试是不可能的：由于时间和资源的限制，进行完全(各种输入和输出的全部组合)的测试是不可能的测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡

• 4）遵循GoodEnough原则：GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费

• 5）测试缺陷要符合“二八”定理：缺陷的“二八”定理也称为Pareto原则、缺陷集群效应，一般情况下，软件80%缺陷会集中在20%模块中，缺陷并不是平均分布的。

• 6）避免缺陷免疫：试用例被反复使用，发现缺陷的能力就会越来越差;测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。

    克服这种情况，就要不断对测试用例进行修改和评审，不断增加新的测试用例，同时，测试人员也要发散思维，不能只是为了完成测试任务而做一些输入和输出的对比

6.1 软件测试基本流程

    为了是测试工作标准化、规范化、并且加速、高效、高质量的完成测试工作，需要定制具体的测试流程。

6.1.1 软件测试流程

    基本测试流程：分析测试需求–制定测试计划–设计测试用例–执行测试–编写测试报告

    a:分析测试需求

    测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，明确测试对象及测试工作的范围和测试重点。（获取些测试数据作为后面测试计划基本依据）

    此过程即软件需求测试，发现软件需求中不合理;如需求不清晰、需求优先级等，

    一般是根据软件开发需求文档制作软件需求规格说明书检查列表

    b:制定测试计划

    测试工作贯穿于整个软件开发生命周期，需要定制一个完善且详细的测试计划指导书；测试计划是整个测试工作导航图，测试计划是个根据需求不断完善、不断调整的过程。

    工作安排：
    1）确定测试范围：对哪些是需要测试，哪些不需要测试

    2）制定测试策略：将测试内容划分为不同的优先级，并确定测试重点；是测试计划中最重要部分；

    3）安排测试资源：通过衡量测试难度、时间、工作量等因素对测试资源进行合理分配，包括人员、工具配置等
    4）安排测试进度：根据软件开发计划、产品整体计划安排工作进度与各部分工作的变化并预留缓冲时间

    5) 预估测试风险：罗列出测试过程中可能出现的不确定因素，并制定应对策略；

    c:设计测试用例-test case

    测试用例是指一整套完整的测试方案；包括测试环境、测试步骤、测试数据、测试预期。
    用例原则：尽量以最少的用例达到最大的测试覆盖率。

    d:执行测试

    按照测试用例执行的过程，这是测试人员最主要活动阶段，执行测试时，根据测试优先级进行测试，每个用例都有可能出现缺陷，要做好测试记录与跟踪，衡量缺陷质量并编写报告；

    e:编写测试报告

    报告是对测试活动与项目测试过程的归纳，对测试数据进行统计，对项目质量进行客观的评价。

    测试报告包含：

    1）引言：描述测试报告编写目的、报告中出现的专业术语解释及参考资料

    2）测试概要：介绍项目背景、测试时间、测试地点人员信息

    3）测试内容及执行情况：描述本次测试模块的版本、类型、测试用例设计方法及测试通过率，依据测试通过率提供对策是执行过程的评估结论并给出测试活动的改进建议，以供后续测试执行活动的借鉴参考

    4）缺陷统计与分析：统计本次测试返现缺陷数目、类型等，分析缺陷产生原因，给出规避措施及建议，同时还要记录残留缺陷与为解决问题；

    5）测试结论及建议：从需求符合度、功能正确性、性能指标多个维度对质量进行整体的评估，给出具体明确的结论；

6.1.2 测试准入标准与准出标准

    不同公司标准不同，一般标准

• 1）测试准入标准
  开发人员编码结束，并已完成单元测试
  需求说明书规定的功能或开发人员提交的功能说明书的功能均已实现
  被测系统的基本流程可以走通，界面上的功能均实现，符合设计文档规定的功能。
  开发人员提交被测系统的最新版本，安装测试通过。
  开发人员向测试部提交《测试申请》。
• 2）测试准出标准
  项目进度达到项目规定的上线时间或下个阶段时间
  项目过程中Bug的提交数量和修复率满足要求
  严重的Bug全部修复，其他Bug评估不解或可以遗留到下个阶段解决
  测试未通过，但项目和产品经理特批上线

6.1.3 软件测试暂停、停止标准

    1）测系统在进行系统测试时，发现程序存在重大bug，堵塞测试

    2）被测项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据

    3）存在其他优先级更高的任务时，可向领导申请暂停测试

    4）被测项目在其开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据归档

    5）被测系统经过系统测试，达到系统测试准出标准，可以停止测试

    6）被测系统经过系统测试，并已产出系统测试总结报告，可以停止测试

6.2 demo实例

6.2.1 单车app开锁用车功能测试流程

https://img-blog.csdnimg.cn/20210606015458273.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_70

    单车app开锁用车功能测试流程

    1，骑行、分析测试需求

    测试功能：开锁用车
    方式：扫码与输入编号
    夜间：需要使用手电筒功能

    测试内容：
    a：扫二维码开锁
    b:输入编号开锁
    c:调用手电筒

    2，制定测试计划

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

    3，设计测试用例

    实际用法场景，
    1）白天：扫码
    2）白天：输入编码
    3）夜里：扫码+手电筒
    4）夜里：输入编码+手电筒

    对于订单正在使用考虑三个状态：正在骑行，未支付，未使用状态

    4，执行测试用例

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

    单车app开锁功能测试缺陷报告

    5，编写完整的测试报告

    本次测试结束后（包含回归测试），需要编写一个完整的测试报告，

    注意：一般为很多页的word或者在软件测试管理工具里写

    单车app用车测的测试报告

    一：引言
    1，目的
    2，术语
    3，参考资料
    二：测试概要
    1，项目简介
    2，测试环境
    3，测试时间、地点、人员
    三：测试内容及执行情况
    1，测试目标
    2，测试范围
    3，测试用例使用情况
    4，回归测试
    四：缺陷统计与分析
    1，缺陷数目与类别
    2，缺陷解决情况
    3，缺陷趋势分析
    五：测试分析
    1 ，测试覆盖率分析
    2，需求符合度分析
    3，功能正确性分析
    4，产品质量分析
    5，测试局限性
    六：测试总结
    1，遗留问题
    2，测试经验总结
    七：附件
    1，测试用例清单
    2，缺陷清单
    3，交付的测试工作产品
    4，遗留问题报告

6.2.2 什么是Sprint

    Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint

    Scrum的几个名词?

    backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

    sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

    sprint backlog:一个sprint周期内所需要完成的任务。

    scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。

    time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

    sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

    Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？　是否遇到了障碍？　即将要做什么？通过该会议，团队成员可以相互了解项目进度。

    Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。

    Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时

6.2.3 补充：测试理论知识

https://blog.csdn.net/weixin_42914706/article/details/117609959

https://blog.csdn.net/weixin_42914706/article/details/117492183