单元测试文档 软件测试_软件单元测试文档 - CSDN
精华内容
参与话题
  • 软件测试单元测试

    千次阅读 2017-01-13 17:40:14
     单元测试是对软件基本组成单元进行的测试。 时机:  一般在代码完成后由开发人员完成,QA人员辅助. 概念:  模块, 组件, 单元    1.2 为何要进行单元测试? 尽早发现错误 错误发现越早,成本越低. 开发人员...

    1.什么是单元测试?


    1.1  单元测试的定义


    定义:

        单元测试是对软件基本组成单元进行的测试。

    时机:

        一般在代码完成后由开发人员完成,QA人员辅助.

    概念:

        模块, 组件, 单元 
                  

    1.2  为何要进行单元测试?

    • 尽早发现错误

    错误发现越早,成本越低.

    开发人员过于自信,后期复杂

    度高,发现解决BUG困难.

    • 检查代码是否符合设计和规范
    1.3  单元测试的背景

    开发流程时间表与修改Bug代价的关系图如下:



    编程过程中,每写100行代码会犯150个错误
    编程与编译运行结束后,每100行代码中大约残留有1-3个Bug
    寻找与修改程序错误的代价占总体开发投资的40%-80%
    Bug在整个研发流程中被发现的越早,修改的代价就越低

    2.单元测试的目标和任务


    2.1   单元测试的目标

    目标是单元模块被正确编码
    • 信息能否正确地流入和流出单元;
    • 在单元工作过程中,其内部数据能否保持其完整性,包括内部数据的形式、内容及相互关系不发生错误,也包括全局变量在单元中的处理和影响。 
    • 在为限制数据加工而设置的边界处,能否正确工作。
    • 单元的运行能否做到满足特定的逻辑覆盖。 
    • 单元中发生了错误,其中的出错处理措施是否有效

    2.2  单元测试的任务

    2.2.1    任务1:模块接口测试

    检查模块接口是否正确,checklist:
    •  输入的实际参数与形式参数是否一致。
    个数、属性、量纲
    •  调用其他模块的实际参数与被调模块的形参是否一致。
    个数、属性、量纲
    •  全程变量的定义在各模块是否一致。
    •  外部输入、输出
    文件、缓冲区、错误处理
    •  其它
    2.2.2  任务2: 模块局部数据结构测试

    检查局部数据结构完整性
    Checklist:
    •  不适合或不相容的类型说明。
    •  变量无初值。
    •  变量初始化或默认值有错。
    •  不正确的变量名或从来未被使用过。
    •  出现上溢或下溢和地址异常。
    •  其它

    2.2.3  任务3: 模块边界条件测试

    检查临界数据处理的正确性
    Checklist:
    •  普通合法数据的处理。
    •  普通非法数据的处理。
    •  边界值内合法边界数据的处理。
    •  边界值外非法边界数据的处理。
    •  其它

    2.2.4  任务4: 模块独立执行通路测试

    检查每一条独立执行路径的测试。保证每条语句被至少执行一次。
    Checklist:
    •  算符优先级。
    •  混合类型运算。
    •  精度不够。
    •  表达式符号。
    •  循环条件,死循环。
    •  其它
    2.2.5  任务5:模块的各条错误处理通路测试

    预见、预设的各种出错处理是否正确有效。
    Checklist:
    •  输出的出错信息难以理解。
    •  记录的错误与实际不相符。
    •  程序定义的出错处理前系统已介入。
    •  异常处理不当。
    •  未提供足够的定位出错的信息。
    •  其它

    2.3  Microsoft对单元测试的理解

    2.3.1  单元测试具体分类

    • 验证产品实现符合功能规格书
    • 验证产品代码运行的正确性
    • 边缘条件测试
    • 产品安全性测试
    • 从已有Bug增加的回归测试
    • 产品代码覆盖度测试(Code Coverage)
    • 产品代码注射测试(Code Injection)
    • 异常测试
    • 产品速度性能的比较测试
    • 产品极限情况测试
    • 产品与国际标准的兼容性测试
    • 产品与以前版本的操作系统,文件格式的兼容测试
    • 同一产品不同版本共同运行的兼容性测试
    • 产品在不同语言操作系统下的运行测试
    2.3.2  单元测试具体流程

    • 测试过程从产品设计开始
    Spec Review 非常重要
    微软产品Spec Review演示
    Sharepoint Server的应用
    • 测试代码编写由软件开发设计者(SDE)自己开始
    DRT (Developer Regression Test)的重要性
    没有相随的DRT, Feature Area不算开发完
    DRT不全部编译并100%通过,不允许Check-in
    测试组的测试不100%编译并100%通过0级测试(BVT), 70%通过1级测试,不允许Check-in
    • 测试代码主体由软件测试工程师(SDET,STE)编写
    • 测试从写软件测试规格书(Test Spec)开始
    • Test Spec必须通过PM,Dev与同组Tester共同开会研究通过
    • 测试代码根据不同测试的情景分为0-4级的优先级
    • 0级测试称为BVT (Build Verification Test)
    • 在Dev主要的功能实现Check-in前,0-1级测试代码必须已由测试工程师完成
    • 在Dev进行Check-in时,0级测试必须100%通过
    • 在Dev进行Check-in时,1级测试必须至少有70%通过
    • Dev进行产品代码的Check-in
    • Test进行测试代码的Check-in
    • 产品编译由Build团队每日进行
    • Test编译由测试团队在产品编译完成后进行
    • 测试编译完成后,由测试自动化系统进行测试
    • 在随后的代码优化与稳定期内,测试工程师编写2-4级测试代码,并报告产品Bug,Dev负责修改Bug,稳定并优化产品

    3.静态测试技术的运用


    3.1 静态测试技术的概念

    静态测试技术: 不运行被测试程序,对代码通过检查、阅读进行分析。

    三步曲:
    •  走查 (Walk Through)。
    •  审查 (Inspection)。
    •  评审 (Review)

    3.2  编码的标准和规范

    标准:建立起来必须遵守的规则。
    规范:建议最佳做法,推荐更好方式。

    实施标准和规范的原因:
    •  可靠性。
    •  可读性和可维护性。
    •  可移植性。

    3.3  走查 (Walk Through)

    定义:采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
    注意:
    •  引导小组成员在走查前通读设计和编码。
    •  限时,避免跑题。
    •  发现问题适当记录,避免现场修改。
    •  检查要点是代码是否符合标准和规范,是否有逻辑错误。

    3.4 走查与审查的比较



    3.5  评审 (Review)

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

    注意:
    •  充分审查了所规定的代码,并且全部编码准则被遵守。
    •  审查中发现的错误已全部修改。

    4.动态测试技术的运用


    4.1  动态测试技术的概念

    动态测试需要真正将程序运行起来,需要设计系列的测试用例保证测试的完整性和有效性。

    •  白盒测试
    •  黑盒(灰盒)测试

    4.2  白盒测试方法

    主要是逻辑驱动法和基本路径法。

      语句覆盖。
      判定覆盖。
      条件覆盖。
      判定/条件覆盖。
      条件组合覆盖。
      路径覆盖。


    4.3  黑盒测试方法

    运行单元程序有时需要基于被测单元的接口,开发相应的驱动模块和桩模块。

     驱动模块(drive):对底层或子层模块进行测试所编写的调用这些模块的程序。
     桩模块(stub):对顶层或上层模块进行测试时所编写的替代下层模块的程序。


    4.4  黑盒常用方法

     等价类划分法                   
     边界值分析法                     三种数据:
     错误推测法                             -- 正常数据
     因果图法                                -- 错误数据
     功能图法                                -- 边缘数据


    另外还得考虑接口测试、性能测试、内存测试
     性能分析
     内存分析

    5.调试与评估

    调试与测试的对象及采用的方法有很大程度上的相似,调试还用到断点控制等排错方法,但其目的却完全不同。测试是为了找出软件中存在的缺陷,而调试是为了解决存在的缺陷。 

    •  软件单元功能与设计需求一致。 
    •  软件单元接口与设计需求一致。 
    •  能够正确处理输入和运行中的错误。 
    •  在单元测试中发现的错误已经得到修改并且通过了测试。 
    •  达到了相关的覆盖率的要求。 
    •  完成软件单元测试报告 


    6.单元测试的过程与文档管理


    6.1 单元测试的过程

    过程:
    1. 在详细设计阶段完成单元测试计划。 
    2. 建立单元测试环境,完成测试设计和开发。 
    3. 执行单元测试用例,并且详细记录测试结果。 
    4. 判定测试用例是否通过。 
    5. 提交《单元测试报告》。



    6.2  单元测试的文档
    1. 《软件需求规格说明书》、《软件详细设计说明书》 ----> 《单元测试计划》 
    2. 《单元测试计划》、《软件详细设计说明书》 ----> 《单元测试用例》 
    3. 《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》 ---> 《缺陷跟踪报告》/《缺陷检查表》  
    4. 《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》 ---> 《单元测试检查表》 
    5. 评估---> 《单元测试报告》 


    7. 单元测试常用工具简介

    7.1  工具分类

     静态分析工具
     代码规范审核工具
     内存和资源检查工具
     测试数据生成工具
     测试框架工具
     测试结果比较工具
     测试度量工具
     测试文档生成和管理工具

    展开全文
  • 软件测试入门视频教程

    万人学习 2019-06-25 10:59:08
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • (1)定义:单元测试(又称为模块测试)是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程...

    整体的角度可以分为单元测试、集成测试、系统测试、确认测试。

    下面内容来自网络相关资料的整理:

    1.单元测试

    (1)定义:单元测试(又称为模块测试)是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。

    (2)单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。


    模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。

    测试接口正确与否应该考虑下列因素:

    1 输入的实际参数与形式参数的个数是否相同;
    2 输入的实际参数与形式参数的属性是否匹配;
    3 输入的实际参数与形式参数的量纲是否一致;
    4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
    5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;
    6 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;
    7 调用预定义函数时所用参数的个数、属性和次序是否正确;
    8 是否存在与当前入口点无关的参数引用; 
    9 是否修改了只读型参数;
    10 对全程变量的定义各模块是否一致;
    11 是否把某些约束作为参数传递。

    如果模块内包括外部输入输出,还应该考虑下列因素:
      1 文件属性是否正确;
      2 OPEN/CLOSE语句是否正确;
      3 格式说明与输入输出语句是否匹配;
      缓冲区大小与记录长度是否匹配;
      文件使用前是否已经打开;
      是否处理了文件尾;
      是否处理了输入/输出错误;
      输出信息中是否有文字性错误;


    检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:
      1 不合适或不相容的类型说明;
      2 变量无初值;
      3 变量初始化或省缺值有错;
      4 不正确的变量名(拼错或不正确地截断); 
      5 出现上溢、下溢和地址异常。
      除了局部数据结构外,如果可能,单元测试时还应该查清全局数据(例如FORTRAN的公用区)对模块的影响。

    在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括:
      1 误解或用错了算符优先级;
      2混合类型运算;
      3变量初值错;
      4精度不够;
      5表达式符号错。
      比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误: 
      1不同数据类型的对象之间进行比较;
      2错误地使用逻辑运算符或优先级
      3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;
      4比较运算或变量出错;
      5循环终止条件或不可能出现;
      6迭代发散时不能退出;
      7错误地修改了循环变量。
      一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题:
      1输出的出错信息难以理解;
      2记录的错误与实际遇到的错误不相符;
      3在程序自定义的出错处理段运行之前,系统已介入;
      4异常处理不当;
      5错误陈述中未能提供足够的定位出错信息。


    边界条件测试是单元测试中最后,也是最重要的一项任务。众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。


    (3)单元测试过程
      一般认为单元测试应紧接在编码之后,当源程序编制完成并通过复审和编译检查,便可开始单元测试。测试用例的设计应与复审工作相结合,根据设计信息选取测试数据,将增大发现上述各类错误的可能性。在确定测试用例的同时,应给出期望结果。
      应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”,它接收测试数据并将这些数据传递到被测试模块,被测试模块被调用后,“主程序”打印“进入-退出”消息。
      驱动模块和桩模块是测试使用的软件,而不是软件产品的组成部分,但它需要一定的开发费用。若驱动和桩模块比较简单,实际开销相对低些。遗憾的是,仅用简单的驱动模块和桩模块不能完成某些模块的测试任务,这些模块的单元测试只能采用下面讨论的综合测试方法。
      提高模块的内聚度可简化单元测试,如果每个模块只能完成一个,所需测试用例数目将显著减少,模块中的错误也更容易发现。集成测试:在单元测试的基础上,将模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。



    2.集成测试

    (1)定义: 集成测试也叫组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上,将所有模块按照概要设计要求组装成为子系统或系统。

    (2)集成测试的关注点:

      1.在把各个模块连接起来时,穿越模块接口的数据是否会丢失。

      2.各个子功能组合起来,能否达到预期的要求的父功能。

      3.一个模块的功能是否会对另一个模块的功能产生不利的影响。

      4.全局数据结构是否有问题,会不会被异常修改。

      5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。

    (3)集成测试的模式:

         ① 非增殖式集成方式。先分别测试每个模块,再把所有模块按设计要求一次全部组装起来所要的系统,然后进行整体测试。使用这种方式可能发现一大堆错误,但为每个错误定位和纠正非常困难,并且在改正一个错误的同时又可能引入新的错误,新旧错误混杂,更难断定出错的原因和位置。
      ② 增殖式集成方式。又称渐增式集成方式。首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。 常用的增殖方法有:自顶向下集成测试、自底向上集成测试、核心集成测试等。

      自顶向下的增殖方式:将模块按系统程序结构,沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中,判断常出现在较高的层次,较早就能遇到。如果主要控制有问题,尽早发现它能够减少以后的返工。

      自底向上的增殖方式:从程序结构的最底层模块开始组装和测试。因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

        自顶向下增殖的方式和自底向上增殖的方式各有优缺点。自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入/输出的模块一般在底层,它们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。自底向上增殖方式的缺点是“程序一直未能做为一个实体存在,直到最后一个模块加上去后才形成一个实体”。就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。但这种方式的优点是不需要桩模块,而建立驱动模块一般比建立桩模块容易,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试。

      核心集成测试:核心系统先行集成测试法的思想是先对核心软件部件进行集成测试,在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线,直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线,代表产品逐步定型的过程。  ③ 混合增殖式测试


    3. 系统测试

    (1)定义:系统测试是在所有单元、集成测试后,对系统的功能及性能的总体测试。

    (2)系统测试内容:系统不仅仅包括软件本身,而且还包括计算机硬件及其相关的外围设备、实际运行时大批量数据、非正常操作(如黑客攻击)等。通常意义上的系统测试包括压力测试、容量测试、性能测试、安全测试、容错测试等。

      · 压力测试(s"esstest):也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件,来测试被测系统的性能、可靠性、稳定性等。压力测试的目的就是在软件投入使用以前或软件负载达到极限以前,通过执行可重复的负载测试,了解系统硼J靠性、性能瓶颈等,以提高软件系统的可靠性、稳定性,减少系统的宕机时间和因此带来的损失。
      · 容量测试(c印ac时test):预先分析出反映软件系统应用特征的某项指标的极限值,如某个web站点可以支持多少个并发用户的访问量、网络在线会议系统的与会者人数。知道了系统的实际容量,如果不能满足要求,就应该寻求新的解决方案, 以提高系统的容量。若一时没有新的解决方案,就有必要在产品发布说明书上明确这些容量的限制,避免引起软件产品使用上的纠纷。如果实际容量已满足要求,就能帮助用户建立对产品的信心。

      · 性能测试(pe晌nllance test):通过测试确定系统运行时的性能表现,如得到运行速度、响应时间、占有系统资源等方面的系统数据。对丁那些实时或嵌入式系统,系统有时满足了功能要求,但未必能够满足性能要求,如某个}{_9站可以被访问, 而且司以提供预先设定的功能,但每打开一个页面都需要1~2分钟,用户不可忍 受,其结果没有用户愿意使用这个网站所提供的服务。

      · 安全测试(securhyten):检查系统对非法侵入的防范能力。安全测试期间。测试人员假扮非法入侵者,采用各种办法试图突破防线。系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值。

      · 容错测试(recovervtest):主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容错测试首先要通过各种手段,让软件强制性地发生故障,然后验证系统是否能尽快恢复。对于自动恢复需验证熏新初始化、检查点、数据恢复和重新启动等机制的正确性


    4.确认测试

     (1)定义:确认测试又称有效性测试。有效性测试是在模拟的环境下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定,它包含的信息就是软件确认测试的基础。

          确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是确认测试的任务,即软件的功能和性能如同用户所合理期待的那样。

     (2)基本方法:

       通过集成测试之后,软件已完全组装起来,接口方面的错误也已排除,确认测试即可开始。确认测试应检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。

      1. 确认测试标准

      实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程,测试计划应规定测试的种类和测试进度,测试过程则定义一些特殊的测试用例,旨在说明软件与需求是否一致。无论是计划还是过程,都应该着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整、准确人机界面和其他方面(例如,可移植性、兼容性、错误恢复能力和可维护性等)是否令用户满意。

      确认测试的结果有两种可能,一种是功能和性能指标满足软件需求说明的要求,用户可以接受;另一种是软件不满足软件需求说明的要求,用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正,因此必须与用户协商,寻求一个妥善解决问题的方法。

      2. 配置复审

      确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序,并且包括软件维护所必须的细节。

      3. α、β测试

      事实上,软件开发人员不可能完全预见用户实际使用程序的情况。例如,用户可能错误的理解命令,或提供一些奇怪的数据组合,亦可能对设计者自认明了的输出信息迷惑不解,等等。因此,软件是否真正满足最终用户的要求,应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试,也可以有计划、有系统的测试。有时,验收测试长达数周甚至数月,不断暴露错误,导致开发延期。一个软件产品,可能拥有众多用户,不可能由每个用户验收,此时多采用称为α、β测试的过程,以期发现那些似乎只有最终用户才能发现的问题。

      α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试,试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。


    展开全文
  • IEEE 软件单元测试标准

    千次阅读 2017-02-08 22:01:12
    这个标准的首要目的是定制一个软件单元测试的标准方法以作为声音软件工程实践的基础。 第二个目标是描述基于这个标准方法的软件工程的概念和测试假设。 第三个目标是提供指导和资源信息以辅助实施和使用标准单元...

    目标

    这个标准的首要目的是定制一个软件单元测试的标准方法以作为声音软件工程实践的基础。

    第二个目标是描述基于这个标准方法的软件工程的概念和测试假设。

    第三个目标是提供指导和资源信息以辅助实施和使用标准单元测试方法。这个信息包含在附录A,C,D。注意这些附录不属于这个标准的一部分。

    动机

    声音单元测试的一个共识定义为评估特定方法提供了基准。它也通过提供一个单元测试过程的标准分解以帮助沟通。

    听众

    首要听众是单元测试者和单元测试管理者。这个标准被开发出来以辅助那些需要管理、监控和评估单元测试的人。

    与其他软件工程标准的关系

    这个标准属于一个系列中的一员,其目的是建立软件工程领域的专业实践。任何其他同系列的软件工程标准可以与其一同使用。

    概览

    单元测试过程由三个阶段组成,其被区分成总共8个基础行为,如下:

    • 1) 完成测试计划
      • a) 为通用方法、资源和调度制定计划
      • b) 决定需要测试的特性
      • c) 精炼通用计划
    • 2) 获取测试集
      • a) 设计测试集
      • b) 实施和精炼计划和设计
    • 3) 测量单元
      • a) 执行测试过程
      • b) 终止检查
      • c) 评估测试工作量和单元

    各阶段的主要数据流入和流出图如下:
    这里写图片描述

    在每个阶段内,各个标准行为与它自己的输入集和输出集有关,且由一系列任务组成。这个标准制定了每个行为的输入、任务和输出。

    所有行为的输出集必须包含有效信息以创建至少两个文件——测试设计规范和测试概述记录。这两个文件必须符合ANSI/IEEE Std 829-1983规范。

    1. 范围和参考

    1.1 范围内的

    软件单元测试是一个流程,包含履行测试计划、获取测试集、根据测试要求测量测试单元。测试意味着使用采样数据以测试单元,以及对比单元实际行为与在单元需求文档中制定的需求行为之间的不同。

    这个标准定义了一个集成的方法以系统化和文档化单元测试。这个方法使用单元设计和单元实施信息,而不是单元需求,以决定测试的完整性。

    这个标准描述一个测试流程,包括各阶段的层次结构、行为、任务和为每个行为定义一个最小数量的任务集。额外的任务可以被添加到任何行为。

    这个标准需要每个行为的履行。对每个行为内的任务而言,这个标准需要认真被履行,或之前的结果是可用且可重现的。这个标准也需要准备两个ANSI/IEEE Std 829-1983制定的文档。这些文档是测试设计规范和测试概述记录。

    通用单元测试计划应发生于整个测试计划期间。这个通用单元测试计划行为被包含在这个标准内,虽然整个测试计划流程的平衡性已经超出这个标准的范围。

    这个标准可以被应用在任何数字计算机软件或固件的单元测试。然而这个标准不能制定其必须应用在某种软件或固件的类型,也不能制定哪些软件或固件的类型必须有单元测试。这个标准应用在较新的测试开发和单元修改。

    无论单元测试者是否也是开发者,这个标准都是可用的。

    范围外的

    一些整体测试计划的任务的结果可以应用在所有测试等级(例如身份加密和隐私限制)。这些任务不被视为单元测试流程的一部分,虽然他们直接影响了单元测试。

    当标准识别到一个需要错误分析的信息和软件错误更正,不需要制定一个软件调试流程。

    这个标准不需要涉及一个完整的单元确认和合法性流程的其他元件,例如评论(例如演练和检查)、静态分析(一致性检查,数据流分析)或格式分析(正确性证明,符号执行)。

    这个标准不需要使用专门的测试设备和工具。这个标准不暗示任何特别方法的文件控制,配置管理,质量保证或测试过程管理。

    1.3 参考

    这个标准应联合如下刊物:
    ANSI/IEEE Std 729-1983,IEEE 标准软件工程术语表。
    ANSI/IEEE Std 829-1983,IEEE 标准软件测试文档。

    3. 单元测试行为

    这个章节制定了有关单元测试过程的行为且描述了相关的输入、任务和输出。

    当多于1个单元需要被测试(例如他们联合组成一个软件项目),行为的计划应涉及整个测试单元集且每个测试单元都不应重复。每个单元的行为必须完成至少一次。

    在通常情况下,这些行为是有序的初始化,除了执行和检查,如下图。执行计划以外的任何活动时,前者的活动或外部事件(例如时间表、需求或设计变更)可能导致需要重做一个或多个前面的活动,然后回到正在执行的行为。
    这里写图片描述

    在测试过程期间,测试设计规范和测试概述记录需要被开发。其他测试文件也可被开发。所有测试文件必须符合ANSI-IEEE Std 829-1983。此外,所有测试文件必须能识别作者和日期。

    测试设计规范将从决定、精炼和设计行为中采集信息。测试概述记录将从所有行为中采集信息。

    3.1 计划通用方法、资源和时间表

    通用单元测试计划应在所有测试计划前发生,且应记录在相关的计划文档内。

    3.1.1 计划输入
    • 1) 项目计划
    • 2) 软件需求文档
    3.1.1 计划任务

    (1)制定一个通用单元测试方法。识别测试要解决的风险领域。在特性描述中制定限制(必须测试的特性),测试设计或测试实施(必须的测试集)。

    识别已存在的输入、输出和状态数据的来源(测试文件、生产文件、测试数据生成器)。识别数据验证的通用技术。识别输出记录、收集、还原和验证的通用技术。描述被测单元与应用软件之间的直接接口。

    (2)制定完整度需求。识别单元测试集覆盖的区域(特性、过程、状态、功能、数据特征、指令)和每个区域需要覆盖的程度。

    当在软件开发期间内测试一个单元时,每个软件的特性必须被一个测试用例或一个批准的例外覆盖,除了模块包含的已经被另外单元测试的指令。软件维护期间的单元测试的实施应保持相同的程序语言。

    (3)制定终止需求。制定单元测试过程的普通终止需求。终止需求必须包括满足完整度需求。

    识别任何可能导致单元测试过程异常终止的条件(检测到主要设计错误,达到时间表截止时间)。

    (4)确定资源要求。估算测试集采集、初始化执行和紧接着的重复测试行为所需的资源。需要考虑硬件、访问时间、通信和系统软件、测试工具、测试文件和其他内容。也需要考虑不常用的大量的形式和供应。

    识别所需准备的资源和负责方。安排这些资源,包括需要大量交付时间的资源请求,例如定制的测试工具。

    识别单元测试和单元调试的责任方。识别技能、数量和周期等需求。

    (5)制定通用时间表。为所有单元测试行为制定一个受到资源和测试单元可行性限制的时间表。

    3.1.3 计划输出

    (1)生成单元测试计划信息(3.1.2的(1)~(5))
    (2)单元测试通用资源需求——从3.1.2的(4)

    3.2 确定需要测试的特性

    3.2.1 确定输入

    (1)单元需求文档
    (2)软件架构设计文档

    3.2.2 确定任务

    (1)学习功能需求。学习单元需求文档内描述的每个功能。确保每个功能有一个唯一的标识。必要时,要求澄清要求。

    (2)标识额外需求和相关程序。标识需求而不是与软件特性相关的功能(性能、属性或设计限制),这样在单元测试层面的测试会更有效。标识任何只与单元测试相关的用途或操作流程。确保内个额外的需求和流程有一个唯一的标识。必要时,要求澄清要求。

    (3)标识单元状态。如果单元需求文档特指或隐含多种状态(不活动、等待接收、处理)软件,标识每个状态和每个状态转换。确保每个状态和状态转换有唯一标识。必要时,要求澄清要求。

    (4)标识输入和输出数据特征。标识待测单元的输入和输出数据结构。对每个结构而言标识出特征,例如通过率,格式,值范围和域值之间的关系。对每个特征而言,制定有效范围。确保每个特征有唯一值。必要时要求澄清要求。

    (5)选择需要包含入测试的元素。选择相关的流程,相关状态,相关状态转换和相关数据特征。需要选择无效和有效输入数据。当完整的测试是不切实际的时候,有关单元使用的信息应被用来确定选项。识别与未选中元素有关的风险。

    单元测试设计规范的待测特性章节中需要输入被选特性、流程、状态、状态转换和数据特征。

    3.2.3 确定输出

    (1)包含在测试内的元素清单
    (2)单元需求澄清要求——从3.2.2(1)到(4)来

    3.3 精炼通用计划

    3.3.1 精炼输入

    (1)包含在测试内的元素清单(3.2.2(5))
    (2)通用单元测试计划信息(3.1.2的(1)到(5))

    3.3.2 精炼任务

    (1)精炼方法。考虑标识现有的测试用例和测试过程的使用。标识任何专门的技术用作数据验证。标识任何专门的技术用于输出记录、收集、减少和验证。

    在单元测试设计规范的方法精炼章节记录精炼方法。

    (2)制定特定资源需求。标识任何在测试单元时需要的特定资源(与单元直接接口的软件)。为被标识资源开展准备工作。

    在单元测试设计规范的方法精炼章节记录特定资源需求。

    (3)制定一个详细的时间表。制定一个基于支持软件、特定资源、单元可用性和集成计划的单元测试时间表。在单元测试设计规范的方法精炼章节记录时间表。

    3.3.3 精炼输出

    (1)特定单元测试计划信息(从3.3.2(1)到(3))
    (2)单元测试特定资源需求(从3.3.2(2))

    3.4 设计测试集

    3.4.1 设计输入

    (1)单元需求文档
    (2)测试内包含的元素清单(3.2.2(5))
    (3)单元测试计划信息(3.1.2(1)、(2)和3.2.2(1))
    (4)单元设计文档
    (5)先前测试的测试规范

    3.4.2 设计任务

    (1)设计测试集的架构。基于待测特性以及专门的或隐含的被选定的相关元素(流程、状态转换、数据特征),设计一个逐层分解的测试目标集,这样每个最低等级的目标可以用一些测试用例直接测试。选择合适的已有测试用例。相关测试用例组用最低级目标作标识。记录目标的层级和相关的测试用例,这些用例标识在单元测试设计规范的测试标识章节。

    (2)获得所需的明确的测试流程。一个有着单元需求文档、测试计划信息和测试用例规范的组合可以隐式地指定单元测试流程,因而最小化所需的明确规范。选择那些可以被修改的或不需要修改的已有的测试流程。

    可以在单元测试设计规范的补充单元或另一个流程规范文档中制定任何额外的流程。无论哪种选择都必须符合ANSI/IEEE Std 829-1983需求的信息。如果测试用例和流程的相关性不明显,开发一个他们之间的关系表并添加到单元测试设计规范中。

    (3) 获得测试用例规范。制定新的测试用例。已有的规范可作为参考。

    可以直接记录规范,也可以参考单元测试设计规范的补充单元或另一个文档。

    (4)基于设计信息按需增加测试用例集规范。基于单元设计的信息,依据3.4.2(1)按需更新测试集的架构。仔细考虑所选算法特性和内部数据结构。

    标识控制流和必须记录的内部数据改变。预料可能发生的特定的记录困难,例如需要在复杂算法内跟踪控制流或需要跟踪内部数据结构的改变(栈或树)。必要时需要增强单元设计(格式化的数据结构转储能力)以增加单元的可测试性。

    基于单元设计的说明,制定任何新的被标识的测试用例,并依据3.4.2(3)完成测试集规范的任何部分。

    (5)完成测试设计规范。根据ANSI/IEEE Std 829-1983完成单元测试设计规范。

    3.4.3 设计输出

    (1)单元测试设计规范(3.4.2(5))
    (2)分隔测试流程规范(3.4.2(2))
    (3)分隔测试用例规范(3.4.2(3)或(4))
    (4)单元设计增强需求(3.4.2(4))

    3.5 实施精炼后的计划和设计

    3.5.1 实施输入

    (1)单元测试计划信息(3.1.2(1)、(4)、(5),3.3.2(1)到(3))
    (2)单元测试设计规范或分隔文档的测试集规范(3.4.2(3)和(4))
    (3)软件数据结构描述
    (4)测试支持资源
    (5)测试项目
    (6)之前测试行为的测试数据
    (7)之前测试行为的测试工具

    3.5.2 实施任务

    (1)获得并验证测试数据。获得一个需要修改的或无须修改的已存在的测试数据。生成任何新的所需数据。包括额外的重要数据以确保数据一致性和诚信。认证所有在软件数据结构规范内的数据。当测试用例和数据集之间的相关性不明显,开发一个记录这种关系的表并保护在单元测试设计规范中。

    (2)获得特定资源。获得3.3.2(2)指定的测试支持资源

    (3)获得测试项目。收集测试项目,包括可用的手册、操作系统流程、控制数据和电脑程序。获得测试计划中与测试单元直接对接的软件标识。

    当使用一个程序语言实施单元测试时,确保执行跟踪信息将可用于评估基于代码完整性要求的满意度。

    在单元测试概要记录的概要章节记录每个项目的标识。

    3.5.3 实施输出

    (1)验证后的测试数据(3.5.2(1))
    (2)测试支持资源(3.5.2(2))
    (3)配置测试项目(3.5.2(3))
    (4)初始化概要信息(3.5.2(3))

    3.6 执行测试流程

    3.6.1 执行输入

    (1)验证后的测试数据(3.5.2(1))
    (2)测试支持资源(3.5.2(2))
    (3)配置测试项目(3.5.2(3))
    (4)测试用例规范(3.4.2(3)和(4))
    (5)测试流程规范(3.4.2(2))
    (6)错误分析结果(调试阶段)

    3.6.2 执行任务

    (1)运行测试。配置测试环境,运行测试集。在单元测试概览记录的结果概览章节记录所有测试事件。

    (2)确定结果。对每个测试用例而言,基于用例描述的需求结果规范确定单元测试成功或失败。在单元测试概览记录中的概览结果章节记录通过或失败结果。在记录的概览行为章节记录资源消耗数据。当使用一个程序语言测试单元时,收集执行跟踪概览信息并附加到记录中。

    对每个失败而言,分析失败原因并将失败信息记录到测试概览记录的概览结果章节。然后选择可用的用例并完成相关动作:

    • 用例1:测试规范或测试数据的错误。手机错误,在测试概览记录中记录错误更正,然后重新运行失败的测试用例。

    • 用例2:测试流程执行的错误。重新运行不正确的执行流程。

    • 用例3:测试环境的错误(系统软件)。修正环境,在测试概览记录的概览行为章节记录错误更正并重新运行测试或在测试概览记录的概览行为章节记录不能纠正环境的原因并准备异常终止,然后继续检查终止。

    • 用例4:单元实施的错误。更正单元或在测试概览记录的概览行为章节记录错误更正并重新运行所有测试或在测试概览记录的概览行为章节记录不能纠正单元的原因并准备异常终止,然后继续检查终止。

    • 用例5:单元设计的错误。更正单元和设计,修改测试规范和数据,在测试概览记录的概览行为章节记录错误更正并重新运行所有测试或在测试概览记录的概览行为章节记录不能纠正设计的原因并准备异常终止,然后继续检查终止。

    注意:执行和检查的任务周期必须一直持续直到满足3.1.2(3)定义的终止条件。执行行为的控制流如下图:
    这里写图片描述
    这里写图片描述

    执行输出

    (1)执行信息录入测试概览记录,包括测试结果、测试事件描述、失败分析结果、失败更正行为、不正确失败原因、资源消耗数据,实施程序语言、跟踪概览信息(3.6.1(1)和(2))
    (2)修改测试规范(3.6.2(2))
    (3)修改测试数据(3.6.2(2))

    3.7 检查终止

    3.7.1 检查输入

    (1)完整性和终止要求(3.1.2(2)和(3))
    (2)执行信息(3.6.1(1)和(2))
    (3)测试规范(3.4.2(1)到(3))
    (4)软件数据架构描述

    3.7.2 检查任务

    (1)检查测试过程的一般终止。确定基于完整性要求或有关失败历史的的额外测试。对实施程序语言而言,分析执行跟踪概览信息(变量、流)

    如果不需要额外测试,在测试概览记录的概览行为章节记录一般终止并继续评估测试效果和单元。

    (2)检查测试过程的异常终止。如果满足异常终止的条件(不正确的组主要失败、超时),确保导致终止的特定情况、未完成的测试和任何不能更正的失败都被记录在测试概览记录的概览行为章节。然后继续评估测试效果和单元。

    (3)补充测试集。当需要额外的测试且异常终止条件并不满足,按照如下步骤补充测试集。
    - (a)根据3.4.2(1)更新测试集架构且根据3.4.2(3)获取额外测试集
    - (b)根据3.4.2(2)修改测试流程规范
    - (c)根据3.5.2(1)获得额外测试数据
    - (d)在测试概览记录的概览行为章节记录例外情况
    - (e)执行额外测试

    3.7.3 检查输出

    (1)检查信息记录在测试概览记录,包括终止条件和任何额外测试用例行为
    (2)额外或更正的测试规范(3.7.2(3))
    (3)额外的测试数据(3.7.2(3))

    3.8 评估测试效果和单元

    3.8.1 评估输入

    (1)单元测试设计规范(3.4.2(5))
    (2)执行信息(3.6.2(1)和(2))
    (3)检查信息(3.7.2(1)到(3))
    (4)分隔测试用例规范(3.4.2(3)和(4))

    3.8.2 评估任务

    (1)描述测试状态。在测试概览记录的差异章节记录测试计划和测试规范的差异。

    对所有异常终止而言,识别测试不能有效覆盖的区域并在测试概览记录的全面性评估章节记录原因。

    标识不能解决的测试事件和原因作为缺陷原因并记录在测试概览记录的概览结果章节。

    (2)描述单元状态。在测试概览记录的差异章节记录测试时显露的单元本身与它的需求文档之间的不同。

    基于测试结果和失败信息评估单元设计和实施时与需求的不同。在测试概览记录中记录评估信息。

    (3)完成测试概览记录。根据ANSI/IEEE Std 829-1983完成单元测试概览记录。

    (4)确保测试产品的保存。确保测试产品被收集、组织,并存储以用作参考和重新使用。这些产品包括测试设计规范、分隔测试用例规范、分隔测试流程规范、测试数据、测试数据生成流程、测试驱动和存根、测试概览记录。

    3.8.3 评估输出

    (1)完整的测试概览记录(3.8.2(3))
    (2)完成、存储收集测试产品(3.8.2(4))

    展开全文
  • 软件测试文档

    2019-09-17 16:14:41
    什么是软件测试 通过手工和自动化工具对被测对象进行检测,验证实际结果和预期结果之间的差异。 软件测试的原则 1 测试是为了证明软件存在缺陷 2 测试应该尽早介入 3 注意测试缺陷的群集效应80-20 4 杀虫剂现象 5 ...

    什么是软件测试
    通过手工和自动化工具对被测对象进行检测,验证实际结果和预期结果之间的差异。
    软件测试的原则
    1 测试是为了证明软件存在缺陷
    2 测试应该尽早介入
    3 注意测试缺陷的群集效应80-20
    4 杀虫剂现象
    5 合法数据和不合法数据和边界值,网络异常和电源断电等
    6 回归测试防止出现更多问题
    7 妥善保存一切测试文档

    软件测试的目的
    1 暴露软件中的缺陷和BUG
    2 记录软件运行中产生的一些数据,为开发提供改良的数据支持

    为什么需要软件测试
    1 功能实现且正确执行
    2 软件运行的信息数据
    如果一个产品开发完成之后发现了很多问题,说明此软件开发过程很可能是有缺陷的,因此,软件测试的目的是保证整个软件开发过程是高质量的。

    测试分类
    1 单元测试 分单元
    2 集成测试 多个单元
    3 系统测试 用户角度-功能主体
    4 验证测试 α测试-内测 β测试-公测 UAT测试-客户验收使用
    系统测试分类
    1 功能测试
    2 性能测试
    3 安全测试
    4 兼容性测试

    测试方法
    1 按照测试对象分类
    白盒测试
    黑盒测试
    灰盒测试
    2 按照测试对象是否执行分类
    静态测试
    动态测试
    3 按照测试手段进行分类
    手工测试 灵活改变测试操作和环境
    自动化测试 1 自己写脚本 2 第三方工具进行测试

    软件质量
    1 维护性
    2 移植性
    3 效率性
    4 可靠性
    5 易用性
    6 功能性

    软件测试流程
    1 需求分析
    2 设计用例
    3 评审用例
    4 配置环境 操作系统+ 服务器+数据库 +软件依赖
    5 执行用例
    6 回归测试及缺陷跟踪
    7 输出测试报告
    8 测试结束

    软件架构
    BS browser浏览器 + server服务器
    CS client客户端 + server服务器
    1 标准上 BS是在服务器和浏览器都存在的基础上开发
    2 效率 BS中负担在服务器上 CS中的客户端会分担,CS效率更高
    3 安全 BS数据依靠http协议进行明文输出 不安全
    4 升级上 bs更简便
    5 开发成本 bs更简单 cs需要客户端 安卓和ios

    软件开发模型
    瀑布模型
    1 需求分析
    2 功能设计
    3 编写代码
    4 功能实现 切入点

    5 软件测试 需求变更
    6 完成
    7 上线维护

    是一种线性模型的一种,是其他开发模型的基础
    测试的切入点 要留下足够的时间 可能导致测试不充分,上线后才暴露

    优点
    开发的各个阶段比较清晰
    需求调查 适合需求稳定的产品开发
    当前一阶段完成后,您只需要去关注后续阶段
    可在迭代模型中应用瀑布模型
    可以节省大量的时间和金钱
    缺点
    1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4)瀑布模型的突出缺点是不适应用户需求的变化
    瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。
    快速原型模型
    部分需求 - 原型- 补充 - 运行 外包公司
    预先不能明确定义需求的软件系统的开发,更好的满足用户需求并减少由于软件需求不明确带来的项目开发风险。
    不适合大型系统的开发,前提要有一个展示性的产品原型,在一定程度上的补充,限制开发人员的创新。

    螺旋模型
    每次功能都要先进行风险评估,需求设计-测试
    很大程度上是一种风险驱动的方法体系,在每个阶段循环前,都进行风险评估。
    需要有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,很有必要,多次迭代,增加成本。

    软件测试模型
    在这里插入图片描述
    需求分析-概要设计-详细设计-开发-单元测试-集成测试-系统测试-验收测试
    优点
    清楚标识软件开发的阶段 包含底层测试 和高层测试
    采用自顶向下 逐步求精的方式把整个开发过程分成不同的阶段,每个阶段的工作都很明确,便于控制开发过程。

    缺点
    程序已经完成,错误在测试阶段发现或没有发现,不能及时修改
    而且需求经常变化 导致V步骤反复执行,工作量很大。

    W模型
    开发一个V 测试一个V
    在这里插入图片描述
    用户需求 验收测试设计
    需求分析 系统测试设计
    概要设计 集成测试设计
    详细设计 单元测试设计
    编码 单元测试
    集成 集成测试
    运行 系统测试
    交付 验收测试

    优点
    测试更早的介入,可以发现开发初期的缺陷,降低成本
    对每个阶段都进行测试,包括文档,便于控制项目过程

    缺点
    依赖文档,没有文档的项目无法使用,复杂度很高,实践需要很强的管理

    H模型把测试活动完全独立出来,将测试准备和测试执行体现出来
    测试准备 - 测试执行
    就绪点
    其他流程 ----------设计等
    v模型适用于中小企业 需求在开始必须明确,不适用变更需求
    w模型适用于中大企业 包括文档也需要测试(需求分析文档 概要设计文档 详细设计文档 代码文档)测试和开发同步进行H模型对公司参与人员技能和沟通要求高

    测试阶段
    单元测试-集成测试-系统测试-验证测试
    是否覆盖代码
    白盒测试-黑盒测试-灰盒测试
    是否运行
    静态测试-动态测试
    测试手段
    人工测试-自动化测试
    其他测试
    回归测试-冒烟测试

    功能测试
    一般功能测试-界面测试-易用性测试-安装测试-兼容性测试
    性能测试
    稳定性测试-负载测试-压力测试-时间性能-空间性能

    负载测试 确定在各种工作负载下,系统各项指标变化情况

    压力测试:通过确定一个系统的刚好不能接受的性能点。获得系统能够提供的最大服务级别

    测试用例
    为特定的目的而设计的一组测试输入,执行条件和预期结果,以便测试是否满足某个特定需求。
    通过大量的测试用例来检测软件的运行效果,它是指导测试工作进行的依据。

    等价类划分法
    将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性。
    有数据输入的地方,可以使用等价类划分法。
    从大量数据中挑选少量代表数据进行测试
    有效等价类:符合需求规格说明书规定的数据用来测试功能是否正确实现
    无效等价类:不合理的输入数据集合—用来测试程序是否有强大的异常处理能力(健壮性)
    使用最少的测试数据,达到最好的测试质量

    边界值分析法
    对输入或输出的边界值进行测试的一种黑盒测试方法。
    是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
    边界点
    1、边界是指相对于输入等价类和输出等价类而言,稍高于、稍低于其边界值的一些特定情况。
    2、边界点分为上点、内点和离点。

    如果是范围[1,100] 需要选择0,1,2,50,99,100,101
    如果是个数最多20个 [0,20] 需要测 0,10,20,-1,21

    因果图分析法
    用画图的方式表达输入条件和输出结果之间的关系。
    1 恒等
    2 与
    3 或
    4 非
    5 互斥 1个或者不选
    6 唯一 必须是1个
    7 包含 可以多选 不能不选
    8 要求 如果a=1,则要求b必须是1,反之如果a=0时,b的值无所谓
    9 屏蔽关系 当a=1时,要求b必须为0;而当a=0时,b的值不一定

    判定表法
    根据因果来制定判定表
    组成部分
    1 条件桩:所有条件
    2 动作桩: 所有结果
    3 条件项: 针对条件桩的取值
    4 动作项:针对动作桩的取值

    不犯罪,不抽烟是好男人,不喝酒是好男人,只要打媳妇就是坏男人
    条件桩 1 不犯罪 1 1 0
    2 不抽烟 1 0 1
    3 不喝酒 0 1 1
    动作桩 好男人 1 1
    坏男人 1

    场景法
    模拟用户操作软件时的场景,主要用于测试系统的业务流程
    先关注功能和业务是否正确实现,然后再使用等价类和边界值进行检测。

    基本流 正确的业务流程来实现一条操作路径
    备选流 模拟一条错误的操作流程
    用例场景要从开始到结束便利用例中所有的基本流和备选流。

    流程分析法
    流程-路径
    针对路径使用路径分析的方法设计测试用例
    降低测试用例设计难度,只要搞清楚各种流程,就可以设计出高质量的测试用例,而不需要太多测试经验

    1 详细了解需求
    2 根据需求说明或界面原型,找出业务流程的哥哥页面以及流转关系
    3 画出业务流程axure
    4 写用例,覆盖所有路径分支

    错误推断法
    利用经验猜测出出错的可能类型,有针对性列出所有可能的错误和容易发生错误的情况。
    多考虑异常,反面,特殊输入,以攻击者的态度对台程序。

    正交表
    对可选项多种可取值进行均等选取组合,最大概率覆盖测试用例
    1 根据控件和取值数选择一个合适的正交表
    2 列举取值并编号,生成取值表。
    3 把取值表与选择的正交表进行映射
    控件数
    Ln(取值数 ) 3个控件 5个取值 5的3次幂

    混合正交表
    当控件的取值数目水平不一致时候,使用allpairs工具生成

    1 等价类划分法 划分值
    2 边界值分析法 边界值
    3错误推断法 经验
    4 因果图分析法 关系
    5 判定表法 条件和结果
    6流程图法 流程路径梳理
    7 场景法 主要功能和业务的事件
    8 正交表

    先关注主要功能和业务流程,业务逻辑是否正确实现,考虑场景法
    需要输入数据的地方,考虑等价类划分法+边界值分析法,发现程序错误的能力最强
    存在输入条件的组合情况,考虑因果图判定表法
    多种参数配置组合情况,正交表排列法
    采用错误推断法再追加测试用例。

    需求分析
    场景法 分析主要功能
    输入的 等价类 边界值
    输入的 各种组合 因果图判定表
    多种参数配置 正交表
    错误推断法 经验

    软件缺陷
    软件产品中存在的问题,用户所需要的功能没有完全实现,没有满足用户的需求
    1 未达到需求规格说明书表明的功能
    2 出现了需求规格说明书指明不会出现的错误
    3 软件功能超出了需求规格说明书指明的范围
    4 软件质量不够高
    维护性 移植性 效率性 可靠性 易用性 功能性 健壮性等
    5 软件未达到软件需求规格说明书未指出但是应该达到的目标
    计算器没电了 下次还得能正常使用
    6 测试或用户觉得不好

    软件缺陷的表现形式
    1 功能没有完全实现
    2 产品的实际结果和所期望的结果不一致
    3 没有达到需求规格说明书所规定的的性能指标等
    4 运行出错 断电 运行终端 系统崩溃
    5 界面排版重点不突出,格式不统一
    6 用户不能接受的其他问题

    软件缺陷产生的原因
    需求错误
    需求记录错误
    设计说明错误
    代码错误
    兼容性错误
    时间不充足

    缺陷的信息
    缺陷id
    缺陷标题
    缺陷严重程度
    缺陷的优先级
    缺陷的所属模块
    缺陷的详细描述
    缺陷提交时间

    缺陷的严重程度划分
    1 blocker 系统瘫痪 异常退出 计算错误 大部分功能不能使用 死机
    2 major 功能点不符合用户需求 数据丢失
    3 normal 独立功能 特定调点 断断续续
    4 Trivial 细小的错误

    优先级划分
    紧急


    展开全文
  • 软件测试的对象包括软件需求、概要设计、详细设计、软件运行环境、可运行程序和软件源代码等。软件测试包括质量、人员、资源、技术和流程五大要素,以及测试覆盖率和测试效率两个目标。 软件测试一般分为4个阶段...
  • 软件测试按照研发阶段一般分为5个部分:单元测试、集成测试、确认测试、系统测试、验收测试,下面将不同阶段需要的一些工作内容做一下梳理希望可以帮助到大家。 单元测试(是指对软件中的最小可测试单元进行检查和...
  • 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。又称为模块测试 测试阶段:编码后 测试对象:最小模块 测试人员:白盒测试工程师或开发工程师...
  • 一份标准的软件测试计划文档 | 新手可以拿走

    万次阅读 多人点赞 2018-06-26 16:09:23
    简介1.1目的项目名称>的这一“测试计划”文档有助于实现以下目标:[确定现有项目的信息和应测试软件构件。列出推荐的测试需求(高级需求)。推荐可采用的测试策略,并对这些策略加以说明。确定所需的资源,并对...
  • 单元测试案例模板

    千次阅读 2019-01-04 17:29:28
    项目组里面突然说,开发人员要进行单元测试,并且要编写单元测试报告,然后才能放到测试环境,让测试去进行内部测试,否则连测试环境都不能上,  作为一名开发,对自己开发的功能进行单元测试是十分有必要的。千万...
  • 软件测试V模型,单元测试软件测试的基础,四个方面看出单元测试的重要性: 1.时间方面—系统集成节约很多的时间 2.测试效果--单元测试是测试阶段基石,能够发现深层次的问题 3.测试成本--单元测试阶段问题容易发现 4...
  • 菜鸟学Java——如何更好的进行单元测试——JUnit

    万次阅读 多人点赞 2018-10-05 11:22:31
    软件测试有很多分类,从测试的方法上可分为:黑盒测试、白盒测试、静态测试、动态测试等;从软件开发的过程分为:单元测试、集成测试、确认测试、验收、回归等。   在众多的分类中,与开发人员关系最紧密的莫过于...
  • 关于软件测试中的单元测试-----mock讲解:“ java的mock测试框架 无论是敏捷开发、持续交付,还是测试驱动开发(TDD)都把单元测试作为实现的基石。随着这些先进的编程开发模式日益深入人心,单元...
  • 单元测试与集成测试

    千次阅读 2019-10-06 22:42:02
    按测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试。 按软件系统工程,测试是软件质量保证的最后的一关。 高质量的程序取决于以下几个方面: 高质量的设计 规范的编码 有效的测试 开发部...
  • 这是我们最亲密的测试,我们平常写课程设计,当然谈不上商业级的测试,往往就一个单元测试占据了测试。有些人习惯先搭起框架,然后再单元测试;也有些人在完成了一个功能模块后即着手进行该模块的测试。但殊途同归,...
  • 如何进行单元测试

    千次阅读 2013-09-17 09:19:30
    摘要:单元测试软件测试的基础,本文详细的论述了单元测试的两个步骤人工静态检查法与动态执行跟踪法,所需执行的工作项目及相关的策略和方法。通过对这两个步骤的描述作者将多年的单元测试经验及测试理论注入于...
  • 前端单元测试之Jest

    千次阅读 2018-11-09 15:50:20
    单元测试:在计算机编程中,单元测试(英语:Unit Testing)又称为模块测试, 是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个...
  • 软件测试过程中主要涉及的文档及其内容 文档名 作用 主要内容 测试计划 描述为完成软件特性的测试而采用的测试方法的细节藐视测试活动的安排和管理 测试范围和策略:包括被测对象,应测试的特性....
  • 嵌入式软件测试参考书籍

    千次阅读 2019-06-17 19:18:32
    嵌入式软件测试的几本参考书籍: 1、《嵌入式软件测试》; 2、《嵌入式软件测试 方法、案例与模板详解》; 3、《嵌入式软件测试实用技术》; 4、《嵌入式系统软件测试》 1、《嵌入式软件测试》 《嵌入式...
  • 软件测试详细的基本流程

    万次阅读 2019-06-24 15:13:04
    单元测试(模块测试):针对软件设计最小的单位-程序模块,进行正确性检查的测试工作 单元测试需要从程序内部结构出发设计测试用例,多个模块可以平行的独立进行单元测试 单元定义:C中个一个函数,Java中的一个类在图像...
1 2 3 4 5 ... 20
收藏数 83,332
精华内容 33,332
关键字:

单元测试文档 软件测试