软件测试月总结
2012-10-12 13:59:54 wuxiaokaixinguo 阅读数 1898
 

                                                        软件测试的总结

1.软件测试的目的

(1)测试是程序的执行过程,目的在于发现错误

(2)一个好的测试用例在于能发现至今为止未发现的错误

(3)一个成功的测试是发现了至今未发现的错误的测试

2.测试设计的方法

测试大牛James Bach总结出了一套测试设计的方法论

FDSFSCURA - CIDTESTD - SFDPOT - CRUSSPIC - STMPL

(1)结构(Structure)---->所有组成产出物的东西。

   代码,界面,接口,硬件,非可执行文件,附属物件。

(2)功能(Functions)---->所有产品所实现的功能

   用户界面,系统接口,应用,计算,时间相关性功能,变化(如改变字体),

   开启/关闭,多媒体,错误处理,交互,可测性

(3)数据(Data--->所有产品处理的数据

   输入,输出,预设值,持久数据,序列,大小数量变化,噪声数据,生命周期等

(4)平台(Platform)--->所有被测软件所依赖的外部事物

   外部硬件,外部软件,内部组建

(5)操作(Operation)--->所有产品可执行的操作

   用户,环境,常见操作,非正常操作,极限操作

(6)时间(Time---->所有与产品相关的时间指标

   输入/输出,快/慢,并发,变化率

3.自己总结的测试方法

3.1静态测试

  静态文本测试

3.2动态测试

1)主要功能测试

2)各个功能测试

3)快捷键,TAB键测试

4)响应时间测试-->最好绘制成图

5)断网,断电测试

(6)分辨率大小测试

7)杀毒软件测试

8)典型的操作系统平台测试

9)大数据量测试

10)极限条件下测试

4.测试用例的格式

备注:

测试用例的编写规范

软件名称: 项目中文全称(或者项目英文全称)

软件版本: 项目软件版本

需求编号: 软件需求编号或测试需求编号

需求描述: 描述软件需求或测试需求 ,有测试需求时描述测试需求否则描述软件需求

用例设计者: 该测试用例设计者

测试人员: 使用该测试用例的测试人员

用例ID 该测试用例编号

用例级别: “高、中、低”,根据测试用例的级别进行选择

前置用例: 执行该用例必须先执行的用例

前置条件: 执行该用例必须先具备的条件

步骤: 步骤1、步骤2……等

输入/动作: 对用例如何执行的描述。对应所操作步骤的描述,应清晰准确,包括登陆系统,输入什么值等

测试项: 一般为所测试的模块

输入:     对用例如何执行的描述。对应所操作步骤的描述,应清晰准确,包括登陆系统,输入什么值等

预期输出/相应 按步骤中描述操作后所应该得到结果

允许偏差:   应该得到结果与实际得到结果的允许偏差范围

实际输出/相应: 按步骤中描述操作后所实际得到结果

测试结论: 根据测试结果得出测试结论:OK/NG/NTOK:通过,NG:不通过,NT:未执行

备注: 必要的备注说明

5.软件测试所需要的文档

需求文档

策划文档

立项文档

工作量分配文档

测试计划

测试用例文档

测试报告

测试总结

2015-05-03 21:55:00 weixin_30215465 阅读数 1

  为期8周的软件测试课程,让我学会了关于测试的很多知识,测试是一门需要细心的大工程,测试分为很多的内容,也许有人认为测试容易,但其实不然。

  从我做的两次实验来看,仅仅是一个非常简单非常小的应用就可以做很长的时间,而做出一个好的测试报告也需要付出很多的时间来写好写完整。

  现在需要很多软件测试的人才,我们也很有必要好好学习软件测试这个模块。

  以下是具体的体会整理:

  体会一:软件测试在整个软件周期中的重要性。
             它存在于整个项目周期,在项目开始之初需求调研的时候就开始了,在形成需求规格说明书的时候就需要针对文档进行测试。

             这个环节在后续整个项目中占了很大的比重,能主导整个项目的走向,成败与否全在于开始阶段的决策。 
  体会二:软件测试的真正意义在于发现错误,而不在于验证软件是正确的。 再严密的测试也不能完全发现软件当中所有的错误,

             但是测试还是能发现大部分的错误,能确保软件基本是可用的,所以在后续使用的过程中还需要加强快速响应的环节。

             结合软件测试的理论,故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。

 

  自己也做了一个软件测试内容大的方面的总结为软件测试课程画上一个句号:

  一:系统测试,集成测试,单元测试

 

  

      二:1.几个黑盒测试常用的方法:

       等价类划分法

       边界值分析法

       因果图法

       决策表法

       错误值推测法

       2.测试案例设计方法选择的综合策略
       在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
       必要时用等价类划分方法补充一些测试用例。
       用错误推测法再追加一些测试用例。
       对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准,应当再补充足够的测试用例。
       如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

 

       三:几个白盒测试常用的覆盖准则:

            1.

         2.还有一个重要的路径覆盖准则!!

         四:Peer  Review

         1.同行评审的关键点:

         moderator

         inspector

         author

         reader

         recorder

         2.The organizational form of PR
             技术评审(Technical review )
             正规检视(Formal Inspection)
             走读(Walkthroughs)
             管理评审(Management Review)

         3.关键过程:

        

     4.区别阶段评审的与同行评审

     同行评审目的:发现小规模工作产品的错误,只要是找错误;
     阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性
     同行评审人数:3-7人 人员必须经过同行评审会议的培训,由SQA指导
     阶段评审人数:5人左右 评审人必须是专家 具有系统评审资格
     同行评审内容:内容小 一般文档 < 40页, 代码 < 500行
     阶段评审内容: 内容多,主要看重点
     同行评审时间:一小部分工作产品完成
     阶段评审时间: 通常是设置在关键路径的时间点上

     5.同行评审的意义:

              1.成功的同行评审是提高质量和生产率的重要因素,不管人们喜欢与否,审查过程会迫使每个人在一种开放式的环境中工作。

           一旦人们懂得了他们的工作都要接受同行评审,他们就会越早地将他们的工作公之于众,以待监督。

           在同级评审上的投入把组织的一些质量成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。

           更重要的是,工作产品的作者学到了如何将工作做得更好,从而避免了缺陷。

               2.固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量,但这些可以在测试中节省更多。从经济角度考虑,

           许多缺陷是在早期阶段注入的,越早消除缺陷就越能降低开发成本。据统计,对于保存精确记录的大系统,

           一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。这样一来,即使在综合考虑了同行评审活动成本的情况下,

           同行评审活动也会使测试成本下降50%~80%。同时,通过同行评审,开发人员能够及时地得到专家的帮助和指导,

           加深对工作成果的理解,更好地预防缺陷,在一定程度上提高了开发生产率。再者,消除工作成果的缺陷,可以提高产品质量,提高客户满意度。

      

转载于:https://www.cnblogs.com/lvlm/p/4474707.html

2015-10-05 16:38:42 kgy_zq 阅读数 576

一 第一章

软件定义:程序+数据+文档

   软件危机:落后的软件生产方式无法满足迅速增长的计算机软需               

             求,从而导致软件开发与维护过程中出现严重问题。

 软件工程: 方法+工具+过程

    软件生命周期模型: 瀑布模型,v模型,迭代模型

软件生命周期: 定义—设计—实施—测试—部署—运行—维护

二  第二章

软件测试的定义:是对软件需求分析,设计,编码的最终复查的一系 

                    列过程,是软件质量保证的关键步骤。

    软件测试的目的:1.尽可能发现并改正被测软件中的错误,提高软件的可靠性

                    2.为了保证软件的质量

软件测试原则:1.显示缺陷的存在

  2.穷尽测试是不可能的

3.测试尽早介入

4.缺陷群集性

5.杀虫剂桲论

6.测试活动依赖测试背景

7.不存在缺陷的谬论

软件测试流程:1.测试计划和控制

2.测试需求分析和用例设计

3.实现和执行测试用例

4.评估出口准则和报告

5.测试活动结束

        控制:资源整合

              风险分析

三 第三章

基于生命周期的软件测试的过程:

需求分析—测试计划—用例设计—执行用例—缺陷追踪—测试报告

生命周期各阶段测试内容:

1.需求阶段 确认定义的需求复合机构要求

2.设计和编程阶段 验证设计的程序实现了需求

3.测试和安装阶段 检查实现的系统符合系统规格说明书

4.维护阶段 重新测试确定改变的部分和未改变的部分能继续工作

    测试计划:

        内容:描述测试活动的范围、方法、资源和进度的文档

        对象:测试项、被测特性、测试任务、任务执行者、各种可能风险

        作用:有效预防计划的风险,保障计划的顺利实施

    测试准入原则:

各方面资源准备就绪

    测试准出原则:

软件各模块正常运行

风险:

    定义:测试活动中所有可预测或者不可预测的对测试进度发生影响的因素

    目的:保证测试按预期执行

四 第四章

测试分类:

     是否关心内部结构:                  开发过程级别:

         白盒测试                         单元测试

         黑盒测试                        集成测试  

         灰盒测试                        系统测试

                                          验收测试

     是否执行程序:                      执行过程是否需要人工干预:

         静态测试                        手工测试

         动态测试                        自动化测试

    

测试实施组织:

         开发测试

         用户测试

         第三方测试

  五 第五章     

        缺陷的定义:

            一般符合下列五个规则之一,就是缺陷:

                软件未实现产品说明书要求的功能

                软件出现了产品说明书指明不应该出现的错误

                软件实现了产品说明书未提到的功能

                软件未实现产品说明书虽未明确提及但应该实现的目标

软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

       软件缺陷原因:

1.需求定义不完善,甚至没有需求文档

2.人员之间的沟通交流不够

3.软件需求的不断变化

4.软件复杂程度高,缺陷很难避免

5.开发人员能力有限

6.开发人员出现编码错误

7.不符合文档编制和编码规定

8.工期短任务中开发和测试工作不充分

9.文档编制错误

        软件缺陷描述

1. 可追踪信息

2. 缺陷的基本信息

3. 缺陷的详细描述

4. 测试环境说明

5. 必要的附件

6. 从统计的角度出发

5C原则:

(Correct)准确 (Clear )清晰  (Consistent)一致   

            (Concise)简洁 (Complete)

        软件缺陷报告

            主要内容:

                问题报告编号    标题    报告人  报告日期    程序的名称  版本号              配置    缺陷的类型    严重性  优先级  关键词  缺陷描述   

                重现步骤    结果对比   

六 第六章

        V模型:不同测试阶段和开发过程期间各阶段的对应关系

优点:

1.  既有底层测试又有高层测试。底层:单元测试。高层:系统测试。

2.  将开发阶段清楚的表现出来,便于控制开发的过程。当所有阶段都结束时,软件开发结束了

            缺点:

1.  容易让人误解为测试是在开发完成之后的一个阶段。

2.  由于它的顺序性,当编码完成之后,正式进入测试时,这时发现的一些BUG可能不容易找到其根源,并且代码修改起来很困难。

3.  实际中,由于需求变更较大,导致要重复变更需求、设计、编码、测试。返工量大。

        W模型:增加了软件开发阶段中应同步进行的验证和确认活动

                基于“尽早的和不断的进行测试”的原则

                测试过程主要内容:

优点:

1.  将测试贯穿到整个软件的生命周期中,且除了代码要测试,需求、设计等都要测试。

2.  更早的介入到软件开发中,能尽早的发现缺陷进行修复。

3.  测试与开发独立起来,并与开发并行。

缺点:

1.  对有些项目,开发过程中根本没有文档产生,故W模型无法使用。

2.  对于需求和设计的测试技术要求很高,实践起来很困难。

软件测试过程中的活动及内容

 

七 第七章

 

静态测试概念:是不实际运行被测软件,而只是静态地检查程序代码界面或文档中可能存在的错误的过程。

内容:

对于代码测试,主要测试代码是否符合相应的标准和规范。

对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。

对于文档测试,主要测试用户手册和需求说明是否符合用户的实际需求。

常用方法:

最常用而且最主要的方法是同行评审。

同行评审概念:开发软件产品作者以外的其他人检查工作,已发现缺陷并寻找改进的机会

同行评审根据正式程度(由低到高)可以划分为5种评审方法:临时评审、桌面评审、走查、小组审查、审查。其中临时评审、桌面评审、走查无标准的流程,正式程度越高,发现的错误越多,成本也越高,一般这5种方法中使用最多的是临时评审

 

八 第八章

动态测试概念:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。

 

⑴白盒测试概念:又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法

 

① 逻辑覆盖概念:是一种以程序内部的逻辑结构为基础的测试方法,属于白盒测试

 

②逻辑覆盖种类:

 

a.语句覆盖:是最起码的测试要求,要求设计足够多的测试用例,使得每条语句至少被执行一次

 

b.判定覆盖:又叫分支覆盖,要求设计足够多的测试用例,使得程序中的每一个分支至少通过一次,即每一条分支语句的“真值”和“假值”都至少执行一次

 

c.条件覆盖:使程序中每个判定的每个条件的所有可能条件取值至少执行一次

 

d.判定/条件覆盖:设计若干个测试用例,运行被测程序,使程序中每个判定的每个条件的所有可能条件取值至少执行一次,同时每个判定的所有可能判定取值至少执行一次。即要求同时满足判定覆盖和条件覆盖

 

e.条件组合:设计若干个测试用例,运行被测程序,使程序中每一个判定的所有可能的条件取值组合至少执行一次

 

f.路径覆盖:设计若干个测试用例,运行被测程序,覆盖程序中的所有可能路径

 

⑵黑盒测试概念:把测试对象当作看不见内部的黑盒、在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性

 

黑盒测试方法:

 

①等价类划分法:

    1、等价类可以划分为有效等价类和无效等价类。

  a.有效等价类

  有效等价类指对于程序规格说明来说,是合理的、有意义的输入数据构成的集合。有效等价类可以是一个,也可以是多个,根据系统的输入域划分若干部分,然后从每个部分中选取少数有代表性数据当做数据测试的测试用例,等价类是输入域的集合。

  b.无效等价类

  无效等价类和有效等价类相反,无效等价类是指对于软件规格说明而言,没有意义的、不合理的输入数据集合。

  2、等价类划分的方法和原则

  a.等价类划分的方法有:

  按区间划分。

  按数值划分。

  按数值集合划分。

  按限制条件或规划划分。

  按处理方式划分。

  b、等价类划分的原则:

  在输入条件规定的取值范围或值的个数的情况下,可以确定一个有效等价类和两个无效等价类。

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

在规定输入数据必须遵守的规则的情况下,可以确定一个有效等价类和若干个无效等价类。

  在输入条件规定了输入值的集合或规定了“必须如何”的条件下,可以确定一个有效等价类和一个无效等价类。

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

  3、等价类表的建立  

a、在分析需求规格说明的基础上划分等价类,列出等价类表,为每一个等价类规定一个唯一的编号。

b、将程序可能的输入数据分成若干个子集,从每个子集中选取一个有代表性的数据作为测试用例。等价类是某个输入域的子集,在该子集中的每个输入数据的作用都是等效的。

c、设计新的测试用例,使其尽可能多地覆盖未覆盖的有效等价类,按照这一步骤重复进行,直到所有的有效等价类都被覆盖为止。

d、设计新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,按照这一步骤重复进行,直到所有的无效等价类都被覆盖为止。

②边界值分析法:

边界值分析法(BVA,Boundary Value Analysis)是用于对输入或输出的边界值进行测试的一种黑盒测试方法。

边界值分析法和等价类划分法两者的区别:

前者专注于每个等价类的边界值,后者在等价类中随机选取一个测试点

边界值分析法仅用于考察正处于等价划分边界或边界附近的状态,考虑输出域边界产生的测试情况。

注意问题:

  1、选择边界值测试原则

  选择边界值测试主要考虑以下几条原则:

  a、如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数小一的数、比最大个数大一的数作为测试数据。

  b、如果输入条件规定了值的范围,则应取刚达到这个范围边界的值,以及刚刚超过这个范围边界的值作为测试输入数据。

  c、如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

  d、如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

  e、分析程序规格说明,找出其他可能的边界条件。

③因果图法 :

因果图法也是较常用的一种黑盒测试方法。

能直观地表明输入条件和输出动作之间的因果关系,比采用等价分类法的测试效率更高,但这种方法的操作步骤比较复杂。

  因果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法。因果图法一般和判定表结合使用。因果图法最终生成的就是判定表。

  采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例,同时,还能指出程序规范中存在什么问题,鉴别和制作因果图。

1、关系符号

  a、恒等

恒等关系符号如图

 

恒等关系符号图 

  b、非

 

    非关系符号如图

 

非关系符号图

 

   c、或

      或关系符号如图

                或关系符号图

  d、与

与关系符号如图

 

 与关系符号图

 

通常在因果图中,用Ci表示原因,ei表示结果,Ci和ei的状态可用0或1表示,0表示某状态不出现,1表示某状态出现。

2、约束

  输入状态还存在着某些依赖关系,这种关系称为约束。

约束符号如图所示。

    E约束(异):a和b中最多有一个可能为1,即a和b不能同时为1。

  I 约束(或):a、b、c中至少有一个必须为1,即 a、b、c不能同时为0。

  O约束(唯一):a和b必须有一个且仅有一个为1。

  R约束(要求):a是1时,b必须是1,即a为1时,b不能为0。

  M约束(强制):若结果a为1,则结果b强制为0。

    3、利用因果图导出测试用例的基本步骤

a、分析软件规格说明的描述中哪些是原因,哪些是结果。原因是输入或输入条件的等价类,结果是输出条件。给每个原因和结果并赋予一个标识符,根据这些关系,画出因果图。

  b、因果图上用一些记号表明约束条件或限制条件。

  c、对需求加以分析并把它们表示为因果图之间的关系图。

  d、把因果图转换成判定表。

  e、将判定表的每一列作为依据,设计测试用例。

 

④随机数法:

即测试用例的参数是随机数。它可以自动生成,因此自动化程度高。使用大量随机测试用例测试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实际

⑤猜错法:

错误推测法是基于以往的经验和直觉,参照以往的软件系统出现的错误,推测程序中所有可能存在的各种缺陷和错误,从而有针对性地设计测试用例。

错误推测法的基本思路是:列举出程序中所有可能的错误和容易发生错误的特殊情况,根据可能出现的错误情况选择测试用例。

2013-10-17 12:35:00 u012427309 阅读数 477

一、基本概念

软件中BUG的定义
       软件的bug指的是软件中(包括程序与文档)不符合用户需求的问题。这个定义使我们判断一个软件问题是否是bug的唯一标准
软件测试的最终目的
       是检验实际的软件系统是否符合用户的需求,所以不能为了发现错误而发现错误。

测试环境
              测试环境 = 软件+硬件+网络
              软件主要是指软件运行的操作系统。

软件环境的分类
               软件开发环境:软件在开发过程中使用的环境
               软件生产运行环境:最终用户使用环境
               软件测试环境要与软件生产运行环境保持一致,要从开发环境中独立出来。

测试用例
          测试用例 = 输入+输出+测试环境(+测试步骤)
          输入:测试数据和操作步骤
          输出:期望结果
          测试环境:系统环境设置
          编写测试用例的唯一标准是用户需求,具体参考资料是《系统需求规格说明书》和软件原型。
          优点:便于团队交流,便于重复测试,便于跟踪统计,便于用户自测。

二、软件测试分类

 黑盒测试与白盒测试——按是否查看源代码划分
          黑盒测试:把被测的软件看做是一个黑盒子,不关心盒子里面的结构是什么样子的,只关心软件的输入数据和输出结果。
          白盒测试:把盒子盖打开,去研究里面的源代码和程序结构,查看程序的源代码具体是怎么实现的。

静态测试与动态测试:——按是否运行程序划分
          静态测试:static testing 不实际运行被测软件,而只是静态的检查程序代码(包括检查注释),界面或者文档中可能存在的错误的过程。
          动态测试:dynamic testing 实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符。
         判断一个测试属于动态测试还是静态测试,唯一的标准是看是否运行程序。

单元测试、集成测试、系统测试、验收测试:——按阶段划分
          时间比例1:2:4:2
          单元测试:unit testing 对软件中的最小可测单元进行检查和验证(单元是指认为规定的最小被测功能模块)
                          依据:源程序,《详细设计文档》
                          一般步骤:1.编译运行程序
                                           2.静态测试(检查代码是否符合规范)
                                           3.动态测试
                          桩模块和驱动模块
                                   桩模块:stub 模拟被测模块所调用的模块
                                    驱动模块:driver 用来接收测试数据,启动被测模块并输出结果
          集成测试:integration testing 单元测试的下一阶段,将通过测试的单元模块组装成系统或子系统,再进行测试,重点测试不同模块的接口,检查各个单元模块结合到一起能否协同配合,正常运行。
                         依据:单元测试的模块以及《概要设计文档》
          系统测试:system testing 将整个软件系统看做一个整体进行测试,包括对功能,性能,以及软件所运行的软硬件环境进行测试。
                          需要花大量时间和精力去完成的,也是软件交给用户进行验收测试的最后一道关卡。
                         依据:《系统需求规格说明书》
           验收测试:acceptance testing 系统测试的后期,以用户测试为主,或有测试人员等质量保障人员共同参与的测试。
                              分为 a(a fa)测试 【由用户,测试人员,开发人员等共同参与的内部测试】和 b (be ta)测试【内测后的公测,完全交给最终用户的测试】

功能测试盒性能测试:——属于黑盒测试
          功能测试:function testing  检查实际软件的功能是否符合用户的需求
                         功能测试又可以细分为很多种:逻辑功能测试logic function testing,界面测试UI testing,易用性测试usability,安装测试installation,兼容性测   试compatibility等。
           性能测试:performance testing 一般要使用自动化测试工具。软件性能主要包括时间性能和空间性能。
                           性能测试分为:一般性能测试,稳定性测试,负载测试,压力测试
                                   一般性能测试:让被测系统在正常的软硬件环境下运行,不向其施加任何压力的性能测试。
                                   稳定性测试:reliability 也叫做可靠性测试。连续运行被测系统,检查系统运行时的稳定程度。
                                   负载测试:load 让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。
                                   压力测试:stress  持续不断的给被测系统增加压力,只要将被测系统压垮为止,用来测试系统所能承受的最大压力。

回归测试,冒烟测试,随机测试:
          回归测试:regression 对软件的新的版本测试时,重复执行上一个版本测试时的用例。
          冒烟测试:smoke 是指对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。
          随机测试:random 测试中所有的输入数据都是随机生成的,其目的是模拟用户的真是操作,并发现一些边缘性的错误

三、软件测试基本原则
        1.zero bug 和good enough原则
               zero bug : 软件没有任何的错误
               good enough:只要软件达到一定的质量要求,就可以停止测试了。(过分的测试浪费资源)
          2.不要试图穷举测试
          3.开发人员不能既是运动员又是裁判
          4.软件测试要尽早执行
          5.软件测试应该追溯需求
          6.缺陷的二八定理
               一般情况下,软件80%的缺陷集中在20%的模块
          7.缺陷具有免疫性
2008-12-24 16:11:00 zymaxs 阅读数 1070
 通用公式:
计算平均的并发用户数: C = nL/T
C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。
并发用户数峰值: C’ ≈ C+3根号C
C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例:
假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则C = 400*4/8 = 200
C’≈200+3*根号200 = 242

F=VU * R / T
其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间
R = T / TS
TS为用户思考时间
计算思考时间的一般步骤:
A、 首先计算出系统的并发用户数
C=nL / T F=R×C
B、 统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、 统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R


缺陷检测有效性百分比DDE=TDFT/(TDFC+TDFT)×100%
其中:TDFT=测试过程中发现的全部缺陷(即由测试组发现的),TDFC=客户发现的全部缺陷(在版本交付后一个标准点开始测量,如,半年以后)

缺陷排除有效性百分比DRE=(TDCT/TDFT)×100%
其中:TDCT=测试中改正的全部缺陷,TDFT=测试过程中发现的全部缺陷

测试用例设计效率百分比TDE=(TDFT/NTC)×100%
其中:TDFT=测试过程中发现的全部缺陷,NTC=运行的测试用例数

以下公式较适用于白盒测试
功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 (功能点)
需求覆盖率= 被验证到的需求数量 /总的需求数量 (需求)
覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 (测试用例)
语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
判定覆盖率= 判定结果被评价的次数 / 判定结果总数
条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
路径覆盖率= 至少被执行一次的路径数/程序总路径数

如果谁知道还有其他的计算公式请帮忙留言补充或给我发消息,谢谢
以上内容由zymaxs收集整理~~

软件测试基础总结

阅读数 648

没有更多推荐了,返回首页