精华内容
下载资源
问答
  • 测试理论

    万次阅读 2020-06-04 16:30:08
    定义:软件测试是为了发现错误而执行程序的过程,“寻找错误”是测试的目的 使用人工或自动手段运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是否弄清预期结果与实际结果之间的差别 软件测试是一...

    一、基本概念
    定义:软件测试是为了发现错误而执行程序的过程,“寻找错误”是测试的目的
               使用人工或自动手段运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是否弄清预期结果与实际结果之间的差别
              软件测试是一种重要的软件质量保证活动,测试过程中的活动包括分析软件和运行软件,是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。

    测试:找错误(证明程序有错)
    调试:该错误(使程序正确)

    软件测试的目的:
           (1)测试是程序执行的过程,目的在于发现错误
           (2)一个好的测试用例在于能发现至今未发现的错误
           (3)一个成功的测试是发现至今未发现的错误的测试
           (测试的成功与失败在于能否发现错误,测试不能表能软件中不存在错误,只能说明软件中存在错误)

            通过对软件错误的原因和分布进行归纳,来发现并排除当前软件产品的缺陷,对在需求和设计过程中存在的问题查缺补漏,从而确保软件产品的质量;

    软件测试的原则:
            (1)所有的测试都应追索到用户的需求:系统中最严重的错误是导致程序无法满足用户需求的错误;
            (2)尽早的和不断的进行软件测试:需求和设计时初心的缺陷占很大的比例;缺陷的修改成本随着阶段的推移而急剧上升;缺陷具有放大的特点

             (3)不可能完全的测试
             (4)80-20原则:测试发现的错误80%很可能起源于20%的模块中,应孤立这些疑点模块重点测试。
             (5)注意测试中的群集现象:在所测程序段中,若发现错误数目多,则残存数目也比较多
             (6)避免测试自己的程序
             (7)设计周密的测试用例
                      软件测试的本质就是针对要测试的内容确定一组测试用例
                      测试用例至少包括:
                      执行测试用例前:应满足的前提条件
                      输入
                      预期输出
                      设计测试用例时应包括合理的输入条件和不合理的输入条件
             (8)回归测试:程序修改错误后必须进行回归测试,避免引入新的错误
             (9)严格执行测试计划:排除测试的随意性

    软件测试的对象:
               (1)软件测试贯穿于定义与开发的整个期间
               (2)软件测试的对象
                        需求规格说明
                        概要设计规格说明
                        详细设计规格说明
                        源程序
    软件测试分类
     
    是否执行被测试软件:

    静态测试:不运行被测程序本身,而是通过在对软件进行分析、检查和审阅达到测试目的

          方法:代码审查;代码走查;桌面检查;技术评审

    动态测试:值通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能。由三部分组成:编写测试用例、执行测试结果、分析程序的输出结果。


    黑盒测试:功能测试/数据驱动测试,是在已知产品所应对应具有的功能的前提下,通过测试来检测每个功能是否都能正常使用。

    白盒测试:结构测试/逻辑驱动测试,是在知道产品内部工作过程的前提下,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。

    按照软件测试的策略和过程分(都是动态测试):

    单元测试:单元测试的对象软件设计的最小单位——模块。单元测试的依据是详细设计描述,单元测试应对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。单元测试多采用白盒测试技术,系统内多个模块可以并行的进行。

    集成测试:组装软件的系统测试技术,按设计要求把通过单元测试的各个模块组装在一起之后,进行集成测试以便发现与接口有关的各种错误。

    系统测试:是在真实或模拟系统运行的环境下,为验证和确认系统是否达到需求规格说明书规定的需求而对集成的硬件和软件系统进行的测试

    验收测试:按照项目任务书或合同、供需双方约定的验收依据文档进行的整个系统的评测,决定是否接受或拒绝系统

    按测试内容分:

    功能测试:根据功能需求进行测试,以确定软件与软件功能需求的一致,功能遗缺和多余

    性能测试:评价一个产品或组件与性能需求是否符合的测试

    一、性能测试类型

      性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。

      2.负载测试(Load Testing)

      在给定的测试环境下,通过在被测系统上不断增加压力,直到性能指标超过预定指标或某种资源使用已经达到饱和状态,目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点,寻找系统能够支持的最大用户、业务等处理能力的约束。
      负载测试是在固定测试环境,在其它测试角度(负载方面)不变的情况下,变化一个测试角度并持续增加压力,查看系统的性能曲线和处理极限,以及是否有性能瓶颈存在(拐点)。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况,配合性能调优。测试角度可以是并发用户数、业务量、数据量等不同方面的负载。


      3.压力测试(Stress Testing)

      测试系统在一定饱和状态下系统能够处理的会话能力,以及是否出现错误,一般用于稳定性测试。

      可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下,系统能否正常运行,是一种在极端压力下的稳定性测试。其主要意义是通过测试、调优保证系统即使在用户的极端压力下也不会出错甚至系统崩溃。

      压力测试的目的是调查系统在其资源超负荷的情况下的表现,尤其是对系统的处理时间有什么影响。这类测试在一种需要在反常数量、频率或资源的方式下执行系统。目标是通过极限测试方法,发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性。

      4.配置测试(Configuration Testing)

      通过对被测系统的软硬件环境的调整,了解各种不同环境对性能影响的程度,从而找到系统各项资源的最有分配原则。

      主要用于性能调优,在经过测试获得了基准测试数据后,进行环境调整(包括硬件配置、网络、操作系统、应用服务器、数据库等),再将测试结果与基准数据进行对比,判断调整是否达到最佳状态。

      5.并发测试(Concurrency Testing)

      模拟并发访问,测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题,如内存泄漏、线程锁、资源争用问题。

      6.可靠性测试(Reliability Testing)

      通过给系统加载一定的业务压力的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

      需要和压力测试区分开,两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错,可靠性测试强调在 一定的业务压力下长时间(如24×7)运行系统,关注系统的运行情况(如资源使用率是否逐渐增加、响应时间是否越来越慢),是否有不稳定征兆。

    eg:

    负载测试:测试一个应用在重负荷下的表现,例如测试一个web站点在大量负荷下,何时系统的响应会退化或失败

    压力测试:用来评估在超越最大负载的情况下系统将应如何进行

                      压力测试的目标就是发现在高负荷条件下应用程序的缺陷

    疲劳测试:采用系统稳定运行情况下能够支持的最大并发用户数,持续一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大量强度性能的过程

    兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下性能如何

    安全性测试:针对程序中危险防止和危险处理设施进行的测试,以验证其是否有效

    安装性测试

    可用性测试:对“用户友好性”的测试

                        主观的:取决于目标最终用户和可和

                        用户面谈、调查、用户对话的路线和其他一些技术

                        程序员和测试员通常都不宜做可用性测试员

    注:功能的重点在于能做什么;性能在于做的如何

    缺陷:最终产品和用户的期望不一致

               功能错误

               功能遗漏

               超出需求的部分

               性能不符合要求

    二、测试模型与过程

           1-1 软件生命周期

           a.大棒开发法

           b.边改边写法

                  优点:能够较为迅速的展现结果,适合需要快速制作并且用完就扔的小项目,如示范程序、演示程序等。

                  缺点:其编码和测试可能是将长期的循环往复的过程

           c.  瀑布法:将软件生命周期的各项活动,规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品

           优点:易于理解;调研开发的阶段性;强调早期计划及需求调查;确定何时能交付产品及何时进行评审与测试;

           缺点:需求调查分析只进行一次,不能适应需求变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复与迭代性;没有包含类型的风险评估;开发中出现的问题直到开发后期才暴露(测试在后期阶段),因此失去及早纠正的机会。

           d. 快速原型法

           根据客户需求在较短的时间内解决用户最迫切解决的问题,完成可演示的产品。这个产品只实现最重要的功能,在得到客户更加明确的需求之后,原型将丢弃

           e. 螺旋瀑布法

           将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

                  (1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件

                  (2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;

                  (3) 实施工程:实施软件开发和验证;

                  (4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。

      螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:
      (1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。
      (2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。
      (3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
      一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。
    优点:严格的全过程风险管理;强调个开发阶段的质量;提供机会评估项目是否有价值继续下去。

    2.软件测试模型

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

           局限性:把测试作为最后一个活动,需求分析前期产生的错误直到后期的验收测试才能发现。

           该模型容易使人理解主要是针对程序进行测试寻找错误

           实际中,由于需求变更较大,导致要重复变更需求、设计、编码、测试。返工量大。主要用在快速程序的开发

           在V模型中增加软件开发各开发阶段应同步进行的测试,演化为W模型

           开发的是V,测试是与此并行的V;相对于V模型,W模型更科学,强调的是测试伴随整个软件开发周期,并且测试的对象不仅仅是程序,需求、功能、和设计同样要测试。测试和开发是同步进行的,有利于尽早的发现问题

           缺点:W和V都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支撑迭代、自发性以及变更挑战

                      主要应用在一些中型软件并且业务逻辑关联非常紧密的项目中

           H模型中,软件测试活动完全独立,贯穿于整个产品的周期,与其他流程并发的进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

           软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发进行

           H模型指出软件测试要尽早准备,尽早执行,不同的测试活动可以是按照某次序先后进行,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。

           很好的处理测试与开发的交接过程,交接的过程是一个时间段,而不是一个点。

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

           已通过集成测试的产品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的部分,多根并行的曲线表示变更可以在各个部分发生

           X模型还定位了探索性测试,这是不进行实现计划的特殊测试,给有经验的测试人员在测试计划外发现更多软件缺陷

    三、 黑盒测试常用方法

    1. 边界值测试:

           1-1 边界

                   a. 数值边界值:数值范围

                  b. 字符边界值 :ASCII表

                   c. 其他边界条件:默认值、空白、空值、零值、无输入等情况

           1-2 基本思想

                   使用输入变量的最小值、略大于最小值、正常值、略小于最大值和最大值来设计测试用例(min,min+,nom,max-,maz)

                  单缺陷假设:只让一个变量取边界值,其余变量取正常值

                  多缺陷假设:同时让多个变量取边界值

                  (1)边界值分析(单缺陷)(4N+1)

                  (2)健壮性边界值分析(在异常情况下,软件还具有正常运行的能力)(增加一个取异常值,其他都正常值的测试用例,6N+1)

                  (3)最坏情况测试(多个变量出现极值,最最小值,略大于最小值,正常值,最大值,略小于最大值做笛卡尔乘积,5N)

               (3)健壮性最坏情况测试(7N)

    2. 等价类测试

           2-1 等价类划分

                 划分是指互不相交的一组子集,这些子集的并是整个集合

           2-2 有效等价类

                  是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以验证程序是否实现了规格说明中的功能和性能。

           2-3 无效等价类

                  对程序的规格说明来说是不合理的或无意义的输入数据所构成的集合。为了验证程序做其不应做的事情。

           2-4 等价类划分方法

                 (1)按照区间划分。在输入条件规定了取值范围或值得个数的情况下,则可以确立一个有效等价类和两个无效等价类。

                  (2)按照数值划分。在规定了输入数据的一组值(假定n),并且程序要对每一个输入值分别处理的该情况下,可确立n个有效等价类和一个无效等价类。

                 (3)按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的情况下,可确立一个有效等价类和一个无效等价类。

                  (4)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

                  (5)进一步细分等价类。在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步地划分为更小的等价类。

                  (6)等价类划分还应特别默认值、空值、NULL、零值的情况。

           2-5 等价类的特点

                  (1)完备性(全集)(2)无冗余性(互不相交的子集) (3)等价性

           2-6 等价类测试类型

                  单/多缺陷:弱/强等价类

                 是/否考虑无效等价类:健壮性/一般等价类测试

                 eg  a≤x1≤d,区间为 [a,b) [b,c) [c,d];e≤x2≤g ,区间为 [e,f)  [f,g]

                  (1)弱一般等价类测试:单缺陷,要求选取的测试用例覆盖所有的有效等价类

    (2)弱一般等价类测试:多缺陷,要求将每个变量的有效等价类做笛卡尔积,设计测试用例覆盖笛卡尔积的每个元素。

    (2)弱健壮性等价类测试:弱指基于单缺陷假设,健壮性指考虑了无效值。对有效输入,使用每个有效等价类的一个值;对无效输入,测试用例将拥有一个无效值。补充输入域边界以外的值(略小于最小值min-1,略大于与最大值max+1)

    (3)基于多缺陷假设,并考虑无效输入

    3 基于判定表的测试

    3-1 判定表

    (1)条件桩:列出了问题的所有条件。

    (2)动作桩:列出了问题规定可能采取的操作。(1、2的排列顺序通常没有约束)

    (3)条件项:列出针对它的左列条件的取值

    (4)动作项:列出在条件项的各种取值情况下应该采取的动作

    4.其他测试方法

    4-1 因果图方法:从用自然羽然书写的程序规格说明的描述中找出因(输入条件)和果(输入或程序状态的改变)之间的关系绘制出因果图,然后通过因果图转换为判定表。

    4-2 正交实验设计法:使用已经造好的正交表来安排适应并进行数据分析的一种方法,目的使用最小的测试用例达到最高的测试覆盖率。

    4-3 错误推测设计方法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例

    四、 白盒测试常用方法

    1.逻辑覆盖测试:根据被测试程序的逻辑结构设计测试用例。

    2. 语句覆盖:测试时设计若干测试用例,运行被测试程序,使程序中的每条可执行语句至少执行一次。

    优点:检查所有语句;结构简单的代码测试效果好;容易实现自动测试;代码覆盖率高;如果是程序块覆盖,则不涉及程序块中的源代码。

    缺点:不能检查出条件语句错误、循环语句错误;语句率覆盖率看似很高,却有严重缺陷(分支覆盖率)

    3. 判定覆盖/分支覆盖:设计若干测试用例,运行被测试程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断的真假值均曾被满足。(while/switch/异常处理/跳转语句)

    判定覆盖率:已取过“真”和“假”两个值的判定程序占程序中所有条件判定个数的百分比

    优点:分支覆盖比语句覆盖查错能力强一些:执行了分支覆盖,实际也就执行了语句覆盖

    缺点:不能查出条件语句错误/逻辑运算错误/循环次数错误/循环条件错误

    4. 条件覆盖:设计若干测试用例,执行被测程序后,要使每个判断中每个条件的可能取值至少满足一次,即每个条件至少有一次为真值,有一次为假值

    优点:能够检查所有的条件错误;

    缺点:不能实现对每个分支的检查,用例数量的增加

    做到了完全的条件覆盖,并不能保证达到完全的判定覆盖。

    做到了完全的判定覆盖也并不能保证达到了完全的条件覆盖==》条件和分支兼顾

    5. 判定-条件覆盖:将判定覆盖和条件覆盖结合起来,即设计足够的测试用例,使得判断条件中的每个条件的所有可能取值至少执行一次,并且每个判断本身的可能判定结果也至少执行一次。

    优点:既考虑了每一个条件,又考虑了每一个分支,发现错误能力强于分支覆盖和条件覆盖。

    缺点:并不能全面覆盖所有路径;用例数量增加


    6. 条件组合覆盖:设计足够的测试用例,运行被测程序,使得所有可能的条件取值组合至少执行一次

    优点:满足了判定覆盖、条件覆盖和条件-判定覆盖

    缺点:不能全面覆盖所有路径

    7. 路径覆盖:设计足够多的测试用例来覆盖程序中所有可能的路径(不可能:循环、、、、)

    8.路径测试

    1. 基路径测试:把覆盖的路径数压缩到一定限度内,例如程序中的循环体只执行0次和1次

    1-1 程序环路复杂性

    a. 设E为控制流图的边数,N为图的节点数,则定义环路复杂性为V(G)=E-N+2

    b. 设P为控制流图中的判定节点数,则由V(G)=P+1

    c. 将环路复杂性定义为控制流图中的区域数(控制流图外面也要算一个区域)

    2-1 独立路径:包括一组以前没有处理的语句或条件的一条路径

    3-1 基本路径集:控制流图中所有独立路径的集合(路径数=环路复杂性)

    4-1 基路径测试法:通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。设计出的测试用例要保证在测试中的每个可执行语句至少执行一次(路径数=环路复杂性)。

    缺点:测试覆盖并不充分(循环)

    2. 循环测试:针对循环的测试

    3.数据流测试:基于程序的控制流,从建立的数据目标状态的序列中发现异常的结构测试方法,数据的定义/引用缺陷。

    三、 单元测试

            单元:一个可独立运行的代码段

            独立运行:这个工作不受前一次或接下来的程序运行的结果影响,即不与上下文发送关系。

            单元测试方法:静态/动态

            静态测试:不需要运行单元代码,而是对代码进行逐行的检测

            动态测试:需要运行被测单元代码,由于被测单元需要调用其他单元,或者会被其他单元调用。

    3-1   单元测试的环境

             静态测试:无需搭建测试环境

             动态单元测试:用一些辅助模块来模拟与所测模块相联系的其他模块,需要在测试之前搭建相应测试环境

              辅助模块分两种:

             (1)驱动模块(Driver):相当于所测模块的主程序

             (2)桩模块(stub):用于代替所测模块调用的子模块

              单元测试三个步骤:模拟输入->执行单元->检查验证输出

    3-2   单元测试的策略和方法

             1、静态代码分析

                   代码走读:一种交叉检查,就是自己的代码由他人来检查

                   代码审查:以会议的形式展开,由大家根据缺陷检查表共同审核代码的质量

                   代码评审:通常在审查会后进行,审查小组根据记录和报告进行评估

              2、单元结构测试(主要采用白盒测试)

                    关注代码内部的执行情况,关注代码执行的覆盖率。

                    基于路径的测试、基于数据流测试。

              3、单元功能测试(基本方法时黑盒测试)

                    常用测试方法:边界测试、等价类测试、因果图测试

    四、集成测试

         4-1. 基本概念

                集成:把多个单元组合起来形成更大的单元

                集成测试:在假定各个软件单元已经通过单元测试的前提下,检查各个软件单元之间的相互接口是否正确,也叫组装测试或联合测试

                                 具体检测包括:功能性验证、接口测试、全局数据结构的测试以及计算精度检测等在集成测试时可能出现的错误

         4-2. 方法策略

        非增量型集成测试:将所有软件统一集成后才进行整体测试(大棒集成)

        增量型集成测试:从一个模块开始,测一次添加一个模块,边组装边测试,以发泄与结构相联系的问题(需要驱动程序或桩程序)

         4-3.基于功能分解的集成

               (1) 自顶向下集成:从最具控制力的主控模块开始,按照软件的控制层次结构,以深度优先或广度优先的策略,向系统中增加模块,直至实现整个系统, 需要设计桩模块

              优点:有助于最大限度减少对驱动程序的需求

              缺点:不能很好地支持有限功能的早期发布

              桩       模块不能反映真实情况,重要数据不能及时会送到上层模块,则测试可能并不充分

               (2)自底向上继承:从程序模块结构中最底层的模块开始组装,按控制层次增强的顺序向系统中增加模块并测试,直至实现整个系统,不需要再编制桩模块

           优点:减少了对桩模块的需求

                      自底向上增值的方式可以实施多个模块的并行测试,提高测试效率,且管理方便,测试人员能较好地锁定软件故障所在位置。

           缺点:对驱动程序的需求使得测试管理变得复杂起来。高级别的逻辑和数据流在晚期测试,只有程序最后一个模块加入时才具有整体形象。

                     不能很好地支持有限功能的早期发布。

               (3) 三明治集成:1和2的结合

         4-4.基于调用图的集成:以功能分解树为基础

    七、案例

    5-1 如何测试一个杯子

           5-2 测试web登录界面

           5-3 自动贩售机

           5-4 CP命令设计测试用例

               主要从异常、功能、性能三方面考虑

               (1)异常

                        参数异常:源和目标参数异常;包含特殊字符;参数超长;指定的位置实际不存在

                        拷贝对象异常:非法的执行权限;存储介质有破坏;非法的文件格式和内容;

                        执行过程异常:拷贝到一半断电;拷贝过程中硬盘满;拷贝过程中源或目的被删除

                (2)功能

                         文件:不同的文件大小:1k,2k,10k...;不同的文件类型:文本,二进制,设备文件

                         目录:包含各种文件类型;包含子目录,目录深度;目录文件数量很多;针对文件和目录分别验证拷贝的准确性,完整性

                 (3)性能

                          场景:拷贝大文件;拷贝目录中存在很多小文件

                                     跨文件系统间拷贝;跨存储介质间拷贝(硬盘到U盘);构造源的各种磁盘分布(硬盘扇区分布);并发的执行拷贝

                          关注的性能点:拷贝时间、CPU、内存、磁盘IO


    一、基本概念
    定义:软件测试是为了发现错误而执行程序的过程,“寻找错误”是测试的目的
               使用人工或自动手段运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是否弄清预期结果与实际结果之间的差别
              软件测试是一种重要的软件质量保证活动,测试过程中的活动包括分析软件和运行软件,是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。

    测试:找错误(证明程序有错)
    调试:该错误(使程序正确)

    软件测试的目的:
           (1)测试是程序执行的过程,目的在于发现错误
           (2)一个好的测试用例在于能发现至今未发现的错误
           (3)一个成功的测试是发现至今未发现的错误的测试
           (测试的成功与失败在于能否发现错误,测试不能表能软件中不存在错误,只能说明软件中存在错误)

            通过对软件错误的原因和分布进行归纳,来发现并排除当前软件产品的缺陷,对在需求和设计过程中存在的问题查缺补漏,从而确保软件产品的质量;

    软件测试的原则:
            (1)所有的测试都应追索到用户的需求:系统中最严重的错误是导致程序无法满足用户需求的错误;
            (2)尽早的和不断的进行软件测试:需求和设计时初心的缺陷占很大的比例;缺陷的修改成本随着阶段的推移而急剧上升;缺陷具有放大的特点

             (3)不可能完全的测试
             (4)80-20原则:测试发现的错误80%很可能起源于20%的模块中,应孤立这些疑点模块重点测试。
             (5)注意测试中的群集现象:在所测程序段中,若发现错误数目多,则残存数目也比较多
             (6)避免测试自己的程序
             (7)设计周密的测试用例
                      软件测试的本质就是针对要测试的内容确定一组测试用例
                      测试用例至少包括:
                      执行测试用例前:应满足的前提条件
                      输入
                      预期输出
                      设计测试用例时应包括合理的输入条件和不合理的输入条件
             (8)回归测试:程序修改错误后必须进行回归测试,避免引入新的错误
             (9)严格执行测试计划:排除测试的随意性

    软件测试的对象:
               (1)软件测试贯穿于定义与开发的整个期间
               (2)软件测试的对象
                        需求规格说明
                        概要设计规格说明
                        详细设计规格说明
                        源程序
    软件测试分类
     
    是否执行被测试软件:

    静态测试:不运行被测程序本身,而是通过在对软件进行分析、检查和审阅达到测试目的

          方法:代码审查;代码走查;桌面检查;技术评审

    动态测试:值通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能。由三部分组成:编写测试用例、执行测试结果、分析程序的输出结果。


    黑盒测试:功能测试/数据驱动测试,是在已知产品所应对应具有的功能的前提下,通过测试来检测每个功能是否都能正常使用。

    白盒测试:结构测试/逻辑驱动测试,是在知道产品内部工作过程的前提下,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。

    按照软件测试的策略和过程分(都是动态测试):

    单元测试:单元测试的对象软件设计的最小单位——模块。单元测试的依据是详细设计描述,单元测试应对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。单元测试多采用白盒测试技术,系统内多个模块可以并行的进行。

    集成测试:组装软件的系统测试技术,按设计要求把通过单元测试的各个模块组装在一起之后,进行集成测试以便发现与接口有关的各种错误。

    系统测试:是在真实或模拟系统运行的环境下,为验证和确认系统是否达到需求规格说明书规定的需求而对集成的硬件和软件系统进行的测试

    验收测试:按照项目任务书或合同、供需双方约定的验收依据文档进行的整个系统的评测,决定是否接受或拒绝系统

    按测试内容分:

    功能测试:根据功能需求进行测试,以确定软件与软件功能需求的一致,功能遗缺和多余

    性能测试:评价一个产品或组件与性能需求是否符合的测试

    一、性能测试类型

      性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。

      2.负载测试(Load Testing)

      在给定的测试环境下,通过在被测系统上不断增加压力,直到性能指标超过预定指标或某种资源使用已经达到饱和状态,目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点,寻找系统能够支持的最大用户、业务等处理能力的约束。
      负载测试是在固定测试环境,在其它测试角度(负载方面)不变的情况下,变化一个测试角度并持续增加压力,查看系统的性能曲线和处理极限,以及是否有性能瓶颈存在(拐点)。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况,配合性能调优。测试角度可以是并发用户数、业务量、数据量等不同方面的负载。


      3.压力测试(Stress Testing)

      测试系统在一定饱和状态下系统能够处理的会话能力,以及是否出现错误,一般用于稳定性测试。

      可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下,系统能否正常运行,是一种在极端压力下的稳定性测试。其主要意义是通过测试、调优保证系统即使在用户的极端压力下也不会出错甚至系统崩溃。

      压力测试的目的是调查系统在其资源超负荷的情况下的表现,尤其是对系统的处理时间有什么影响。这类测试在一种需要在反常数量、频率或资源的方式下执行系统。目标是通过极限测试方法,发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性。

      4.配置测试(Configuration Testing)

      通过对被测系统的软硬件环境的调整,了解各种不同环境对性能影响的程度,从而找到系统各项资源的最有分配原则。

      主要用于性能调优,在经过测试获得了基准测试数据后,进行环境调整(包括硬件配置、网络、操作系统、应用服务器、数据库等),再将测试结果与基准数据进行对比,判断调整是否达到最佳状态。

      5.并发测试(Concurrency Testing)

      模拟并发访问,测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题,如内存泄漏、线程锁、资源争用问题。

      6.可靠性测试(Reliability Testing)

      通过给系统加载一定的业务压力的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

      需要和压力测试区分开,两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错,可靠性测试强调在 一定的业务压力下长时间(如24×7)运行系统,关注系统的运行情况(如资源使用率是否逐渐增加、响应时间是否越来越慢),是否有不稳定征兆。

    eg:

    负载测试:测试一个应用在重负荷下的表现,例如测试一个web站点在大量负荷下,何时系统的响应会退化或失败

    压力测试:用来评估在超越最大负载的情况下系统将应如何进行

                      压力测试的目标就是发现在高负荷条件下应用程序的缺陷

    疲劳测试:采用系统稳定运行情况下能够支持的最大并发用户数,持续一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大量强度性能的过程

    兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下性能如何

    安全性测试:针对程序中危险防止和危险处理设施进行的测试,以验证其是否有效

    安装性测试

    可用性测试:对“用户友好性”的测试

                        主观的:取决于目标最终用户和可和

                        用户面谈、调查、用户对话的路线和其他一些技术

                        程序员和测试员通常都不宜做可用性测试员

    注:功能的重点在于能做什么;性能在于做的如何

    缺陷:最终产品和用户的期望不一致

               功能错误

               功能遗漏

               超出需求的部分

               性能不符合要求

    二、测试模型与过程

           1-1 软件生命周期

           a.大棒开发法

           b.边改边写法

                  优点:能够较为迅速的展现结果,适合需要快速制作并且用完就扔的小项目,如示范程序、演示程序等。

                  缺点:其编码和测试可能是将长期的循环往复的过程

           c.  瀑布法:将软件生命周期的各项活动,规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品

           优点:易于理解;调研开发的阶段性;强调早期计划及需求调查;确定何时能交付产品及何时进行评审与测试;

           缺点:需求调查分析只进行一次,不能适应需求变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复与迭代性;没有包含类型的风险评估;开发中出现的问题直到开发后期才暴露(测试在后期阶段),因此失去及早纠正的机会。

           d. 快速原型法

           根据客户需求在较短的时间内解决用户最迫切解决的问题,完成可演示的产品。这个产品只实现最重要的功能,在得到客户更加明确的需求之后,原型将丢弃

           e. 螺旋瀑布法

           将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

                  (1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件

                  (2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;

                  (3) 实施工程:实施软件开发和验证;

                  (4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。

      螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:
      (1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。
      (2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。
      (3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
      一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。
    优点:严格的全过程风险管理;强调个开发阶段的质量;提供机会评估项目是否有价值继续下去。

    2.软件测试模型

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

           局限性:把测试作为最后一个活动,需求分析前期产生的错误直到后期的验收测试才能发现。

           该模型容易使人理解主要是针对程序进行测试寻找错误

           实际中,由于需求变更较大,导致要重复变更需求、设计、编码、测试。返工量大。主要用在快速程序的开发

           在V模型中增加软件开发各开发阶段应同步进行的测试,演化为W模型

           开发的是V,测试是与此并行的V;相对于V模型,W模型更科学,强调的是测试伴随整个软件开发周期,并且测试的对象不仅仅是程序,需求、功能、和设计同样要测试。测试和开发是同步进行的,有利于尽早的发现问题

           缺点:W和V都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支撑迭代、自发性以及变更挑战

                      主要应用在一些中型软件并且业务逻辑关联非常紧密的项目中

           H模型中,软件测试活动完全独立,贯穿于整个产品的周期,与其他流程并发的进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

           软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发进行

           H模型指出软件测试要尽早准备,尽早执行,不同的测试活动可以是按照某次序先后进行,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。

           很好的处理测试与开发的交接过程,交接的过程是一个时间段,而不是一个点。

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

           已通过集成测试的产品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的部分,多根并行的曲线表示变更可以在各个部分发生

           X模型还定位了探索性测试,这是不进行实现计划的特殊测试,给有经验的测试人员在测试计划外发现更多软件缺陷

    三、 黑盒测试常用方法

    1. 边界值测试:

           1-1 边界

                   a. 数值边界值:数值范围

                  b. 字符边界值 :ASCII表

                   c. 其他边界条件:默认值、空白、空值、零值、无输入等情况

           1-2 基本思想

                   使用输入变量的最小值、略大于最小值、正常值、略小于最大值和最大值来设计测试用例(min,min+,nom,max-,maz)

                  单缺陷假设:只让一个变量取边界值,其余变量取正常值

                  多缺陷假设:同时让多个变量取边界值

                  (1)边界值分析(单缺陷)(4N+1)

                  (2)健壮性边界值分析(在异常情况下,软件还具有正常运行的能力)(增加一个取异常值,其他都正常值的测试用例,6N+1)

                  (3)最坏情况测试(多个变量出现极值,最最小值,略大于最小值,正常值,最大值,略小于最大值做笛卡尔乘积,5N)

               (3)健壮性最坏情况测试(7N)

    2. 等价类测试

           2-1 等价类划分

                 划分是指互不相交的一组子集,这些子集的并是整个集合

           2-2 有效等价类

                  是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以验证程序是否实现了规格说明中的功能和性能。

           2-3 无效等价类

                  对程序的规格说明来说是不合理的或无意义的输入数据所构成的集合。为了验证程序做其不应做的事情。

           2-4 等价类划分方法

                 (1)按照区间划分。在输入条件规定了取值范围或值得个数的情况下,则可以确立一个有效等价类和两个无效等价类。

                  (2)按照数值划分。在规定了输入数据的一组值(假定n),并且程序要对每一个输入值分别处理的该情况下,可确立n个有效等价类和一个无效等价类。

                 (3)按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的情况下,可确立一个有效等价类和一个无效等价类。

                  (4)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

                  (5)进一步细分等价类。在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步地划分为更小的等价类。

                  (6)等价类划分还应特别默认值、空值、NULL、零值的情况。

           2-5 等价类的特点

                  (1)完备性(全集)(2)无冗余性(互不相交的子集) (3)等价性

           2-6 等价类测试类型

                  单/多缺陷:弱/强等价类

                 是/否考虑无效等价类:健壮性/一般等价类测试

                 eg  a≤x1≤d,区间为 [a,b) [b,c) [c,d];e≤x2≤g ,区间为 [e,f)  [f,g]

                  (1)弱一般等价类测试:单缺陷,要求选取的测试用例覆盖所有的有效等价类

    (2)弱一般等价类测试:多缺陷,要求将每个变量的有效等价类做笛卡尔积,设计测试用例覆盖笛卡尔积的每个元素。

    (2)弱健壮性等价类测试:弱指基于单缺陷假设,健壮性指考虑了无效值。对有效输入,使用每个有效等价类的一个值;对无效输入,测试用例将拥有一个无效值。补充输入域边界以外的值(略小于最小值min-1,略大于与最大值max+1)

    (3)基于多缺陷假设,并考虑无效输入

    3 基于判定表的测试

    3-1 判定表

    (1)条件桩:列出了问题的所有条件。

    (2)动作桩:列出了问题规定可能采取的操作。(1、2的排列顺序通常没有约束)

    (3)条件项:列出针对它的左列条件的取值

    (4)动作项:列出在条件项的各种取值情况下应该采取的动作

    4.其他测试方法

    4-1 因果图方法:从用自然羽然书写的程序规格说明的描述中找出因(输入条件)和果(输入或程序状态的改变)之间的关系绘制出因果图,然后通过因果图转换为判定表。

    4-2 正交实验设计法:使用已经造好的正交表来安排适应并进行数据分析的一种方法,目的使用最小的测试用例达到最高的测试覆盖率。

    4-3 错误推测设计方法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例

    四、 白盒测试常用方法

    1.逻辑覆盖测试:根据被测试程序的逻辑结构设计测试用例。

    2. 语句覆盖:测试时设计若干测试用例,运行被测试程序,使程序中的每条可执行语句至少执行一次。

    优点:检查所有语句;结构简单的代码测试效果好;容易实现自动测试;代码覆盖率高;如果是程序块覆盖,则不涉及程序块中的源代码。

    缺点:不能检查出条件语句错误、循环语句错误;语句率覆盖率看似很高,却有严重缺陷(分支覆盖率)

    3. 判定覆盖/分支覆盖:设计若干测试用例,运行被测试程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断的真假值均曾被满足。(while/switch/异常处理/跳转语句)

    判定覆盖率:已取过“真”和“假”两个值的判定程序占程序中所有条件判定个数的百分比

    优点:分支覆盖比语句覆盖查错能力强一些:执行了分支覆盖,实际也就执行了语句覆盖

    缺点:不能查出条件语句错误/逻辑运算错误/循环次数错误/循环条件错误

    4. 条件覆盖:设计若干测试用例,执行被测程序后,要使每个判断中每个条件的可能取值至少满足一次,即每个条件至少有一次为真值,有一次为假值

    优点:能够检查所有的条件错误;

    缺点:不能实现对每个分支的检查,用例数量的增加

    做到了完全的条件覆盖,并不能保证达到完全的判定覆盖。

    做到了完全的判定覆盖也并不能保证达到了完全的条件覆盖==》条件和分支兼顾

    5. 判定-条件覆盖:将判定覆盖和条件覆盖结合起来,即设计足够的测试用例,使得判断条件中的每个条件的所有可能取值至少执行一次,并且每个判断本身的可能判定结果也至少执行一次。

    优点:既考虑了每一个条件,又考虑了每一个分支,发现错误能力强于分支覆盖和条件覆盖。

    缺点:并不能全面覆盖所有路径;用例数量增加


    6. 条件组合覆盖:设计足够的测试用例,运行被测程序,使得所有可能的条件取值组合至少执行一次

    优点:满足了判定覆盖、条件覆盖和条件-判定覆盖

    缺点:不能全面覆盖所有路径

    7. 路径覆盖:设计足够多的测试用例来覆盖程序中所有可能的路径(不可能:循环、、、、)

    8.路径测试

    1. 基路径测试:把覆盖的路径数压缩到一定限度内,例如程序中的循环体只执行0次和1次

    1-1 程序环路复杂性

    a. 设E为控制流图的边数,N为图的节点数,则定义环路复杂性为V(G)=E-N+2

    b. 设P为控制流图中的判定节点数,则由V(G)=P+1

    c. 将环路复杂性定义为控制流图中的区域数(控制流图外面也要算一个区域)

    2-1 独立路径:包括一组以前没有处理的语句或条件的一条路径

    3-1 基本路径集:控制流图中所有独立路径的集合(路径数=环路复杂性)

    4-1 基路径测试法:通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。设计出的测试用例要保证在测试中的每个可执行语句至少执行一次(路径数=环路复杂性)。

    缺点:测试覆盖并不充分(循环)

    2. 循环测试:针对循环的测试

    3.数据流测试:基于程序的控制流,从建立的数据目标状态的序列中发现异常的结构测试方法,数据的定义/引用缺陷。

    三、 单元测试

            单元:一个可独立运行的代码段

            独立运行:这个工作不受前一次或接下来的程序运行的结果影响,即不与上下文发送关系。

            单元测试方法:静态/动态

            静态测试:不需要运行单元代码,而是对代码进行逐行的检测

            动态测试:需要运行被测单元代码,由于被测单元需要调用其他单元,或者会被其他单元调用。

    3-1   单元测试的环境

             静态测试:无需搭建测试环境

             动态单元测试:用一些辅助模块来模拟与所测模块相联系的其他模块,需要在测试之前搭建相应测试环境

              辅助模块分两种:

             (1)驱动模块(Driver):相当于所测模块的主程序

             (2)桩模块(stub):用于代替所测模块调用的子模块

              单元测试三个步骤:模拟输入->执行单元->检查验证输出

    3-2   单元测试的策略和方法

             1、静态代码分析

                   代码走读:一种交叉检查,就是自己的代码由他人来检查

                   代码审查:以会议的形式展开,由大家根据缺陷检查表共同审核代码的质量

                   代码评审:通常在审查会后进行,审查小组根据记录和报告进行评估

              2、单元结构测试(主要采用白盒测试)

                    关注代码内部的执行情况,关注代码执行的覆盖率。

                    基于路径的测试、基于数据流测试。

              3、单元功能测试(基本方法时黑盒测试)

                    常用测试方法:边界测试、等价类测试、因果图测试

    四、集成测试

         4-1. 基本概念

                集成:把多个单元组合起来形成更大的单元

                集成测试:在假定各个软件单元已经通过单元测试的前提下,检查各个软件单元之间的相互接口是否正确,也叫组装测试或联合测试

                                 具体检测包括:功能性验证、接口测试、全局数据结构的测试以及计算精度检测等在集成测试时可能出现的错误

         4-2. 方法策略

        非增量型集成测试:将所有软件统一集成后才进行整体测试(大棒集成)

        增量型集成测试:从一个模块开始,测一次添加一个模块,边组装边测试,以发泄与结构相联系的问题(需要驱动程序或桩程序)

         4-3.基于功能分解的集成

               (1) 自顶向下集成:从最具控制力的主控模块开始,按照软件的控制层次结构,以深度优先或广度优先的策略,向系统中增加模块,直至实现整个系统, 需要设计桩模块

              优点:有助于最大限度减少对驱动程序的需求

              缺点:不能很好地支持有限功能的早期发布

              桩       模块不能反映真实情况,重要数据不能及时会送到上层模块,则测试可能并不充分

               (2)自底向上继承:从程序模块结构中最底层的模块开始组装,按控制层次增强的顺序向系统中增加模块并测试,直至实现整个系统,不需要再编制桩模块

           优点:减少了对桩模块的需求

                      自底向上增值的方式可以实施多个模块的并行测试,提高测试效率,且管理方便,测试人员能较好地锁定软件故障所在位置。

           缺点:对驱动程序的需求使得测试管理变得复杂起来。高级别的逻辑和数据流在晚期测试,只有程序最后一个模块加入时才具有整体形象。

                     不能很好地支持有限功能的早期发布。

               (3) 三明治集成:1和2的结合

         4-4.基于调用图的集成:以功能分解树为基础

    七、案例

    5-1 如何测试一个杯子

           5-2 测试web登录界面

           5-3 自动贩售机

           5-4 CP命令设计测试用例

               主要从异常、功能、性能三方面考虑

               (1)异常

                        参数异常:源和目标参数异常;包含特殊字符;参数超长;指定的位置实际不存在

                        拷贝对象异常:非法的执行权限;存储介质有破坏;非法的文件格式和内容;

                        执行过程异常:拷贝到一半断电;拷贝过程中硬盘满;拷贝过程中源或目的被删除

                (2)功能

                         文件:不同的文件大小:1k,2k,10k...;不同的文件类型:文本,二进制,设备文件

                         目录:包含各种文件类型;包含子目录,目录深度;目录文件数量很多;针对文件和目录分别验证拷贝的准确性,完整性

                 (3)性能

                          场景:拷贝大文件;拷贝目录中存在很多小文件

                                     跨文件系统间拷贝;跨存储介质间拷贝(硬盘到U盘);构造源的各种磁盘分布(硬盘扇区分布);并发的执行拷贝

                          关注的性能点:拷贝时间、CPU、内存、磁盘IO
     

    展开全文
  • 测试理论测试

    2017-09-23 17:54:14
    测试理论测试
    测试理论测试
    
    展开全文
  • 测试理论再来一次

    万次阅读 2020-08-24 16:10:49
    (一)测试的定义1.IEEE(电子和电气工程师协会,全称Institute of Electrical and Electronics Engineers)的定义 通过人工或者自动化手段来运行或检查某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期...

    一、概述

    (一)测试的定义
    1.IEEE(电子和电气工程师协会,全称Institute of Electrical and Electronics Engineers)的定义
    通过人工或者自动化手段来运行或检查某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距
    2.自己理解的定义
    (1)软件测试是一个过程;
    (2)软件测试可以人工方式也可借助工具;
    (3)进行软件测试可以运行软件也可以不运行软件;
    (4)软件测试就是证明程序有错,而不是证明程序无错;
    (5)软件测试的目的不仅仅是为了发现错误;
    (6)以最少的人力、物力、时间找到软件中的缺陷并修改,从而回避商业风险。
    (二)测试的目的
    1. 根本目的
    提高软件的质量,给用户带来更好的体验
    2.目的
    (1)证明:证明软件在受控条件下可用;
    (2)检验:检查产品中的缺陷,检验产品中的质量信息;
    (3)预防:通过尽早的测试发现问题,修复问题,避免问题延续到后续阶段扩大化,通过测试发现问题,并找出问题的原因并加以改进,避免同类问题在次发生。
    (三)软件中的缺陷(BUG)
    1.软件中为什么会引入缺陷(bug)?
    (1)开发过程中缺乏有效的沟通;
    (2)软件复杂度越来越高;
    (3)编程中产生的错误;
    (4)需求不断变更;
    (5)项目进度压力;
    (6)不重视开发文档;
    (7)开发工具本身存在问题。
    2.软件缺陷类型
    未按照软件需求规格说明书(SRS)而出现的以下几种缺陷:
    (1)遗漏 (2)错误 (3)冗(rǒng)余 (4)提高/建议
    (四)测试工程师的主要工作

    1. 测试计划、测试方案、需求评审、设计评审
    2. 编写测试用例、用例评审
    3. 执行测试
    4. 测试日报
    5. 测试报告

    (五)软件测试流程
    1.需求分析
    2.测试需求
    3.测试计划
    4.测试方案
    5.测试用例
    6.执行测试
    7.测试报告

    二、软件的生命周期

    一个软件的生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用、8个阶段
    (一)制定计划阶段
    1. 计划阶段的工作内容
    (1)确定软件开发总目标;
    (2)给出软件的功能、性能、可靠性以及接口等方面的设想;
    (3)研究完成该项目的可行性,探讨问题解决方案(三峡工程);
    (4)对可供开发使用的资源、成本、可取得的效益和开发进度做出评估(还包括风险);
    (5)指定完成开发任务的实施计划。
    2. 举例(以研发计算器为例)
    (1)研发一个计算器;
    (2)支持加、减、乘、除,所有运算都在一定时间之内完成;
    (3)该项目目前不存在任何技术问题;
    (4)需要在三个月之内完成所有开发项目和测试工作,并推向市场;
    (5)具体计划参见一般项目一级计划。
    (二)软件需求分析阶段
    1. 需求分析阶段的工作内容
    对开发的软件进行详细的定义,由需求分析人员和用户共同讨论决定哪些需求是可以满足的,并且给予确切的描述,写出软件说明书(SRS)。
    软件研发的类型(产品/项目)不同,需求的来源也不同、用户也不同。
    2. 举例(以分析计算器为例)
    (1)功能需求:十进制加、减、乘、除;八进制;二进制;十六进制。
    (2)性能需求:十进制加法需在1s内完成;十六进制乘法需在3s内完成。
    (三)软件设计阶段
    设计是软件工程的技术核心,这个阶段需要完成设计说明书。
    1. 分类
    概要设计(HLD):英文缩写High Level Design (顶层设计) 在设计阶段把各项需求转换成相应的体系结构,每一部分是功能明确的模块。
    详细设计(LLD):英文缩写Low Level Design (底层设计) 对每个模块要完成的工作进行具体的描述。
    2. 举例(以设计计算器为例)
    (1)概要设计
    整个软件分成六个模块:界面模块、主控模块、加法模块、减法模块、乘法模块、除法模块等(主控模块调用后四个模块)。
    加法模块包含五个主函数:加法主函数、十进制主函数、二进制主函数、八进制加法主函数、十六进制加法主函数(加法主函数调用后面四个主函数)。
    (2)详细设计
    加法主函数的主流程图或者伪代码

    三、软件测试的原则

    (一)应尽早地和不断地进行软件测试;
    (二)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成;
    (三)程序员应当避免检查自己的程序;
    (四)在设计测试用例时,应当包括合理的输入条件和不合理的输入条件;
    (五)充分注意测试中的群集现象(二八理论:80%的错误出现在20%的模块中);
    (六)严格执行测试计划,排除测试的随意性;
    (七)应当对每一个测试结果做全面检查;
    (八)妥善保存测试计划、测试用例、出错和最终分析报告,为维护提供方便。
    (九) 杀虫剂现象:同样的一个测试用例不能执行多次,因为软件会对它产生免疫

    四、软件测试的分类

    (一)按照开发阶段(过程)划分
    单元测试(详细设计说明书)、集成测试(概要设计明说书)、系统测试(需求规格说明书)、验收测试、产线验证。
    1. 单元测试的概念
    是对软件的基本组成单位进行的测试,测试对象是一个方法(函数)或者是一个类,目的是检测软件模块对详细设计说明书的符合程度。
    2. 集成测试的概念
    是在单元测试的基础上,将所有模块按照概要设计要求组装称子系统或者系统,验证组装后的功能以及模块间的接口是否正确的测试,目的是检测软件模块对概要设计说明书的符合程度。
    3. 系统测试的概念
    将已经集成好的软件系统,做为计算机系统的一个元素,连同硬件、外部设施、人员等做为一个整体进行的测试,目的是检验软件系统对软件需求规格说明书的符合程度。
    4. 单元测试、集成测试与系统测试之间的比较
    (1)测试方法不同:单元测试属于白盒测试的范畴;集成测试属于灰盒测试的范畴;系统测试属于黑盒测试的范畴。
    (2)考查范围不同:单元测试主要测试单元内部的数据结构、逻辑控制、异常处理;集成测试主要测试模块之间的接口和接口之间的数据传递关系,以及模块组合后的整体功能;系统测试主要测试整个系统相对于需求的符合度。
    (3)评估基准不同:单元测基准主要是逻辑覆盖率;集成测试基准主要是接口覆盖率;系统测试基准主要是测试用例对于需求规格的覆盖率。(覆盖的意思可理解为执行)
    在这里插入图片描述
    (二)按照测试技术(方法)划分
    1. 黑盒测试
    把软件看成一个黑色的盒子,不了解程序的内部结构,也叫基于功能(规格)的测试。
    以用户的观点,从输入数据与输出数据的对应关系,即根据程序外部特性进行测试,而不考虑内部结构及工作情况。
    2. 白盒测试
    把软件看成一个透明的盒子,了解程序的内部结构,只根据程序的内部结构进行测试,也叫基于结构(逻辑驱动)的测试。在这里插入图片描述
    3. 灰盒测试
    介于黑盒和白盒之间的测试,可理解为接口测试。
    灰度测试:一般指先在一个范围或有权限的特定用户进行的测试。

    五、软件测试停止的标准

    (一)第一类标准:测试超过了预定时间,则停止测试。
    (二)第二类标准:执行了所有的测试用例,但并没有发现故障,则停止测试。
    (三)第三类标准:使用特定的测试方案作为判断测试停止的基础。
    (四)第四类标准:正面指出停止测试的具体要求,即停止测试的标准可定义为查出某一预订数目的故障。
    (五)第五类标准:根据单位时间内查出故障的数量决定是否停止测试。

    六、软件测试的过程

    **书面上的流程:**测试计划—测试设计—测试执行—测试总结
    我公司的流程:
    ① 需求评审。发起人:产品(产品经理);参与人:开发、测试、UI设计人员(视觉人员);目的:了解需求、讨论
    ② 编写用例
    ③ 用例评审。发起人:测试人员;参与人:产品、开发、UI;目的:讨论、查漏补缺
    ④ 提测。通俗的说是告诉测试人员,软件开发完以后可以进行测试。
    ⑤ 测试执行。参照测试用例进行执行
    ⑥ 冒烟测试
    ⑦ 系统测试
    ⑧ 回归测试
    ⑨ 产线验证
    ⑩ 测试报告。发送形式:邮件里面说明或word文档
    (一)测试计划
    **输入:**软件测试任务书(或合同)和被测软件的需求规格说明(SRS),是开展软件测试计划的基础和依据。(任务书是指实现什么功能、在什么时间完成)
    **输出:**软件测试计划
    1.软件测试计划的制定
    需求分析、测试策略、工作量估算、进度安排、度量标准、风险评估、子计划制定、计划评审
    2.软件测试计划的内容要素
    软件测试的范围、软件测试的策略、软件测试的需求、软件测试的资源要求、软件测试的人员要求、软件测试的进度
    (二)测试设计
    编写测试用例
    输入:软件测试计划;输出:测试用例和测试数据
    1. 测试用例的定义
    通常讲是对一项测试任务的描述,包含输入数据,操作步骤,预期结果等。
    2. 测试用例八大基本要素
    测试编号,测试项目,测试标题,重要级别,前置条件,输入数据,操作步骤,预期结果。
    3. 用例管理工具
    禅道、TestLink、QC、自定义(公司自己开发的),一般我们用Excel写用例
    4. 使用测试用例的好处
    (1)可以避免盲目测试并提高测试效率;
    (2)令软件测试的实施重点突出、目的明确;
    (3)在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期;
    (4)试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。
    5. 设计测试用例的基本准则
    (1)测试用例的代表性
    能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
    (2)测试结果的可判定性
    测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。
    (3)测试结果的可再现性
    对同样的测试用例,系统的执行结果应当是相同的。
    6. 测试用例设计方法(黑盒测试方法)
    **常用:**等价类划分、边界值分析、流程分析法(场景分析法)
    **其他:**错误推测法、因果图、判定表、正交试验法
    (1)★等价类划分法
    ① 概念
    等价类划分法是把所有可能的输入数据,即程序的输入域划分为若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。
    ② 进行等价类划分的依据
    I. 按照区间划分。 在输入条件规定了取值范围或值的个数的情况下,可以确定一个有效等价类和两个无效等价类。
    II. 按照数值划分。 在规定了一组输入数据(假设包括 n个输入值),并且程序要对每一个输入值分别进行处理的情况下,可确定 n 个有效等价类(每个值确定一个有效等价类)和一个无效等价类(所有不允许的输入值的集合)。
    III. 按照数值集合划分。 在输入条件规定了输入值的集合或规定了“必须如何”的条件下,可以确定一个有效等价类和一个无效等价类(该集合有效值之外)。
    IV. 按照限制条件或规则划分。 在规定了输入数据必须遵守的规则或限制条件的情况下,可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。
    V. 细分等价类。 在确知已划分的等价类中各元素在程序中的处理方式不同的情况下,则应再将该等价类进一步划分为更小的等价类,并建立等价类表。
    (2)★边界值分析法
    边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
    (3)决策表(判定表)
    决策表是分析和表达多逻辑条件下执行不同操作的情况的工具
    组成:条件桩、条件项、动作桩、动作项
    有n个条件的决策表有2n个规则(每个条件取真、假值)
    (4)正交试验设计法
    从大量的试验点中挑选出适量的、有代表性的点,应用依据迦罗卡瓦理论导出的“正交表”,合理的安排试验的一种科学的试验设计方法
    (5)★流程分析法(场景分析法)
    通过描述流经用例路径来确定的过程,这个流经过程要从用例开始到结束遍历其中所有基本流 :直黑线表示基本流,是最基本、最简单的路径;(软件功能按照正确的事件流实现的一条正确流程无任何错,程序从开始直到结束)在这里插入图片描述
    (6)错误推测法
    ① 概念:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
    ② 基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试用例。
    (三)测试执行
    输入:测试用例和测试数据;输出:软件测试记录
    (四)测试总结(测试报告)
    输入:软件测试计划、测试用例、软件测试记录;输出:测试报告
    测试报告的内容:
    1. 首页
    报告名称(软件名称+版本号+XX测试报告)、报告委托方、报告责任方、报告日期、版本变化历史、密级
    2. 引言
    (1)编写目的

    实例:本测试报告为XXX项目的测试报告,目的在于总结测试阶段的测试以及分析测试结果,描述系统是否符合需求(或达到XXX功能目标)。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
    (2)项目背景
    对项目目标和目的进行简要说明,必要时包括简史。这部分基本不需要脑力劳动,直接从需求或者招标文件中拷贝即可。
    (3)系统简介
    如果设计说明书有此部分,照抄。注意必要的框架图和网络拓扑图能吸引眼球。
    (4)术语和缩略语
    列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚,以便阅读时不会产生歧义。
    (5)参考资料
    需求、设计、测试用例、手册以及其他项目文档;测试使用的国家标准、行业指标、公司规范和质量手册等等。
    3. 测试概要
    (1)测试的概要介绍
    包括测试的一些声明、测试范围、测试目的等等,主要是测试情况简介。
    (2)用例设计方法
    例如:等价类划分、边界值、因果图
    (3)测试环境与配置
    (4)测试方法与工具
    主要是黑盒测试,测试方法可以写上测试的重点和采用的测试模式,这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项,当使用到测试工具和相关工具时,要说明。
    4. 测试结果与缺陷分析
    (1)测试执行情况与记录
    描述测试资源消耗情况,记录实际数据。
    (2)测试组织
    可列出简单的测试组架构图,包括:测试组架构(如存在分组、用户参与等情况)、测试经理(领导人员)、主要测试人员、参与测试人员。
    (3)测试时间
    列出测试的跨度和工作量,最好区分测试文档和活动的时间。数据可供过程度量使用。
    例如 XXX子系统/子功能:实际开始时间-实际结束时间;总工时/总工作日;任务 开始时间 结束时间 总计。
    (4)测试版本
    给出测试的版本,如果是最终报告,可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度,对于多次回归的子系统/子模块将引起开发者关注。
    (5)覆盖分析
    ① 需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值,通常情况下要达到100%的目标。
    ② 测试覆盖:需求/功能(或编号) 用例个数 执行总数 未执行 未/漏测分析和原因。
    (6)缺陷分析
    本部分对上述缺陷和其他收集数据进行综合分析
    缺陷综合分析
    缺陷发现效率 = 缺陷总数/执行测试用时
    可到具体人员得出平均指标
    用例质量 = 缺陷总数/测试用例总数 ×100%
    缺陷密度 = 缺陷总数/功能点总数
    缺陷密度可以得出系统各功能或各需求的缺陷分布情况,开发人员可以在此分析基础上得出那部分功能/需求缺陷最多,从而在今后开发注意避免并注意在实施时予与关注,测试经验表明,测试缺陷越多的部分,其隐藏的缺陷也越多。
    测试曲线图
    描绘被测系统每工作日/周缺陷数情况,得出缺陷走势和趋向
    (7)残留缺陷和未解决的问题
    ① 残留缺陷
    编号:BUG号
    缺陷概要:该缺陷描述的事实
    原因分析:如何引起缺陷,缺陷的后果,描述造成软件局限性和其他限制性的原因
    预防和改进措施:弥补手段和长期策略
    ② 未解决问题
    功能/测试类型:
    测试结果:与预期结果的偏差
    评价:对这些问题的看法,也就是这些问题如果发出去了会造成什么样的影响
    5. 测试结论与建议
    (1)测试结论
    ① 测试执行是否充分(可以增加对安全性、可靠性、可维护性和功能性描述)
    ② 对测试风险的控制措施和成效
    ③ 测试目标是否完成
    ④ 测试是否通过
    ⑤ 是否可以进入下一阶段项目目标
    (2)建议
    ① 对系统存在问题的说明,描述测试所揭露的软件缺陷和不足,以及可能给软件实施和运行带来的影响
    ② 可能存在的潜在缺陷和后续工作
    ③ 对缺陷修改和产品设计的建议
    ④ 对过程改进方面的建议
    6. 附录
    缺陷列表、缺陷等级定义标准、测试通过标准等

    七、软件质量模型

    在这里插入图片描述(一)功能性

    1. 适合性:提供了相应的功能
    2. 准确性:正确(用户需要的)
    3. 互操作性:产品与产品之间交互数据的能力
    4. 保密安全性:允许经过授权的用户和系统能够正常的访问相应的数据和信息,禁止未授权的用户访问…
    5. 功能性的依从性:国际/国家/行业/企业 标准规范一致性
      (二)可靠性
      产品在规定的条件下,在规定的时间内完成规定功能的能力
    6. 成熟性:防止内部错误导致软件失效的能力
    7. 容错性:软件出现故障,自我处理能力
    8. 易恢复性:失效情况下的恢复能力
    9. 可靠性的依从性
      (三)易用性
      在指定使用条件下,产品被理解、 学习、使用和吸引用户的能力
    10. 易理解性
    11. 易学性
    12. 易操作性
    13. 吸引性
    14. 易用性的依从性
      (四)效率性
      在规定台条件下,相对于所用资源的数量,软件产品可提供适当性能的能力
    15. 时间特性:平均事务响应时间,吞吐率,TPS(每秒事务数)
    16. 资源利用性:CPU 内存 磁盘 IO 网络带宽 队列 共享内存
    17. 效率依从性
      (五)软件维护性
      “四规”:在规定条件下,规定的时间内,使用规定的工具或方法修复规定功能的能力。
    18. 易分析性:分析定位问题的难易程度
    19. 易改变性:软件产品使指定的修改可以被实现的能力
    20. 稳定性:防止意外修改导致程序失效
    21. 易测试性:使已修改软件能被确认的能力
    22. 维护性的依从性
      (六)软件可移植性
      从一种环境迁移到另一种环境的能力
    23. 适应性:适应不同平台
    24. 易安装性:被安装的能力
    25. 共存性
    26. 易替换性
    27. 可移植性的依从性

    八、CMM能力成熟度模型

    有以下五个等级:
    (一)初始级
    软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。
    (二)可重复级
    建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功。
    包括:需求管理、软件项目策划、软件项目跟踪与监控、软件子合同管理、软件质量保证、软件配置管理
    (三)已定义级
    已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
    包括:组织过程定义、组织过程焦点、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审
    (四)定量管理级
    收集对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。
    包括:定量过程管理、软件质量管理
    (五)优化级
    过程的量化反馈和先进的新思想、新技术促使过程不断改进。
    包括:缺陷预防、技术变更管理、过程变更管理

    每个等级都被分解为三个层次加以定义,这三个层次是关键过程区域、共同特征和关键实践。每个等级都有几个关键过程区域组成,这几个关键过程域共同形成一种软件过程能力。每个关键过程域,都有一些特定的目标,通过相应的关键实践来实现这些目标。每个关键过程域按五个共同特征加以组织。当一个关键过程域的所有关键实践都按要求得到实施,就能实现该关键过程域的目标

    九、缺陷管理

    (一)软件缺陷严重性和优先级

    1. 严重级
      (1)严重:系统崩溃、数据丢失、数据损坏
      (2)较严重:操作性错误、错误结果、遗漏功能
      (3)一般:小问题、错别字、UI布局、罕见故障
      (4)建议:不影响使用的瑕疵或更好的实现
    2. 优先级
      (1)最高优先级:立即修复,停止进一步测试
      (2)次高优先级:在产品发布之前必须修复
      (3)中等优先级:如果时间允许应该修复
      (4)最低等优先级:可能会修复,不修复也能发布

    一般严重性和优先级的划分用数字1~4表示,有的小数字表示的级别最高,而有的用大数字表示级别高。另外严重级和优先级的划分并不唯一,可适当修改。
    3. 缺陷等级划分
    在这里插入图片描述
    (二)缺陷跟踪管理
    为了正确跟踪每个软件缺陷的处理过程,通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统。
    bug管理工具:RTC、jira、禅道、QC、Bugzilla等。
    作为一个缺陷跟踪管理系统,需要正确的记录错误信息和错误处理信息的全部内容。
    1. Bug记录信息
    测试软件名称、测试版本号、测试人名称、测试用例、标题、测试软件和硬件配置环境、发现软件错误的类型、错误严重等级、详细步骤、必要的附图、发生错误的模块…
    2. Bug处理信息
    处理者姓名、处理时间、处理步骤、缺陷记录的当前状态
    (三)软件缺陷状态
    新建(New): 测试中新报告的软件缺陷;
    打开(Open): 被确认并分配给相关开发人员处理;
    修正(Fixed): 开发人员已完成修正,等待测试人员验证;
    拒绝(Declined): 拒绝修改缺陷;
    延期(Deferred): 不在当前版本修复的错误,下一版修复
    关闭(Closed): 错误已被修复。
    (四)缺陷管理流程(缺陷生命周期)

    1. 测试人员提交新发现的缺陷入库,缺陷状态为“New”
    2. 高级测试人员验证错误
      如果确认是错误,则分配给相应的开发人员,设置状态为“Open”
      如果不是错误,则拒绝,设置为“Declined”状态
    3. 开发人员查询状态为“Open”的缺陷,对其进行处理
      如果不是错误,则状态置为“Declined”
      如果是错误,则修复并置状态为“Fix”
      如果不能解决,要留下文字说明并保持缺陷状态仍为“Open”
      对于不能解决或者延期解决的缺陷,不能由开发人员自己决定,一般要通过某种会议(评审会)才能认可
    4. 测试人员查询状态为“Fix”的缺陷,验证缺陷是否已解决,做如下处理
      如果问题解决了,置缺陷的状态为“Closed”
      如果问题没有结果,则置状态为“Reopen”
      (五)缺陷数据分析
    5. 缺陷数据分析的重要性
      (1)统计未修复的缺陷数目(特别是严重性高的缺陷),预计软件是否可以如期发布。
      (2)分析缺陷的类型分布,发现存在较多缺陷的程序模块,找出原因,进行软件开发过程改进。
      (3)根据测试人员报告缺陷的数量和准确性,评估测试有效性和测试技能。
      (4)根据报告的缺陷修复是否及时,改进软件开发与测试的关系,使测试与开发更有机的配合。
    6. 缺陷数据分析的数据指标
      (1)每天/周报告的新缺陷数目;
      (2)每天/周修复的缺陷数;
      (3)累计报告的缺陷数目;
      (4)累计修复的缺陷数;
      (5)不同严重性类型的缺陷数;
      (6)程序模块与发现的缺陷的对应关系;
    展开全文
  • 软件测试理论

    2019-01-11 23:08:15
    软件测试理论篇 一、为什么软件要做软件测试 纵观历史事件说明软件测试的重要性 二、软件测试的概念 1、测试是为了发现错误而执行程序的过程 ; 2、在规定条件下,对程序进行操作,以发现错误,以软件质量进行评估 ; ...
  • 接口测试理论

    2018-09-06 11:01:57
    接口测试理论学习PPT,讲解了接口的定义,接口功能,性能开展的方法。文件密码:www.seulw.com
  • 测试理论及测试用例

    2020-12-16 20:28:28
    测试理论: 测试用例:

    测试理论:在这里插入图片描述
    在这里插入图片描述
    测试用例:
    在这里插入图片描述

    展开全文
  • 软件测试理论基础测试题一 2012 年 11 月 14 日 说明试题共分两大题目总分 150本试题请闭卷 一 选择题每题 1 分 下列文档中不是文档测试需要测试的内容是A A合同文档 B管理文档 C开发文档 D用户文档 下列逻辑覆盖...
  • 软件测试的基本方法和测试理论.doc
  • 测试理论PPT.zip

    2019-08-13 20:01:59
    测试理论PPT及流程图,测试知识点总结及注意事项
  • 软件测试理论基础.pdf

    2020-08-18 13:33:24
    软件测试理论基础.pdf
  • 测试理论相关
  • 软件测试理论.xmind

    2020-06-21 23:25:53
    这作者在学习完测试理论之后所画的思维导图,希望能帮到和作者一样刚刚跨入软件测试这行业的人,内容可能有些不足。望大家理解
  • 02软件测试理论.pdf

    2020-07-11 20:49:31
    02软件测试理论笔记: 什么是软件测试; 软件测试的目的: 软件测试的定义; 软件测试的原则; 软件质量模型等
  • 测试理论笔记

    千次阅读 2019-03-18 15:04:07
    1.测试理论基础: 2.熟练使用数据库sql: 3.熟悉linux命令: 二、接口测试技术 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要...
  • 软件测试理论进阶

    2020-04-03 23:36:33
    第二章 软件测试理论进阶 本章重点 1、了解软件测试复杂性与经济性 2、掌握软件测试的阶段 3、掌握软件测试的方法 4、掌握软件测试的分类 5、理解常见软件测试过程模型 一、软件测试复杂性与经济性 软件测试...
  • 测试理论基础——测试用例测试用例测试用例编号用例的元素必要元素非必要元素测试用例的优缺点用例的设计原则 测试用例 QQ我们经常在用,那么如果让我们来测试QQ的登录界面,如何去测试呢? 将软件测试的行为活动,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,708
精华内容 5,483
关键字:

测试理论