精华内容
参与话题
问答
  • 软件测试入门视频教程

    万人学习 2015-01-22 16:21:44
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • 1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及...
  • JMeter接口测试入门

    万次阅读 多人点赞 2018-07-16 16:23:08
    1、JMeter简介JMeter是Apache组织开发的基于Java的压力测试工具。具有开源免费、框架灵活、多平台支持等优势。除了压力测试外,JMeter在接口测试方面也有广泛的应用。2、JMeter安装访问JMeter官网:...

    1、JMeter简介

    JMeter是Apache组织开发的基于Java的压力测试工具。具有开源免费、框架灵活、多平台支持等优势。除了压力测试外,JMeter在接口测试方面也有广泛的应用。

    2、JMeter安装

    访问JMeter官网:https://jmeter.apache.org/download_jmeter.cgi,点击下载后解压缩,依次打开\apache-jmeter-4.0\JMeter\bin,运行jmeterw.cmd即可。(建议在桌面创建jmeterw.cmd的快捷方式,方便快速打开)

    3、使用JMeter完成单个接口测试

    3.1 添加线程组

    在“测试计划”上点击鼠标右键-->添加-->threads(Users)-->线程组。


    3.2 添加http请求

    在“线程组”打开鼠标右键-->添加-->sampler-->http请求

    添加完http请求后,填写对应的域名、接口以及请求参数,如下图所示:


    3.3 添加断言

    在每一个http请求下,都应该增加一层判断机制(response的关键字),即添加结果断言。

    在“http请求”打开鼠标右键-->添加-->Assertions-->response Assertion


    3.4 查看请求结果

    在“线程组”打开鼠标右键-->添加-->监听器-->察看结果树、断言结果、聚合报告


    1、查看结果树:打开察看结果树,绿色代表测试通过,红色代表测试失败。在此我们可以看到详细的请求头、响应时间、请求参数和返回结果;方便我们进行接口调试

    2、断言结果:断言结果是查看返回的数据是否符合给定的断言。

    3、查看聚合报告:

    Label:每个 JMeter 的 请求都有一个 Name 属性,这里显示的就是 Name 属性的值

    #Samples:表示本次测试中一共发出了多少个请求

    Average:平均响应时间

    Median:也就是 50% 用户的响应时间

    90%Line:90% 用户的响应时间

    Min:最小响应时间

    Max:最大响应时间

    Error%:本次测试中出现错误的请求的数量/请求的总数

    Throughput:吞吐量——默认情况下表示每秒完成的请求数

    KB/Sec:每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec

    4、使用JMeter完成多个接口组合

    以上,单个接口的请求已经完成。在接口测试中,是多个不同接口的组合,因此就会涉及到接口传值。我们可以使用正则表达式和 Json Path Extractor来获取接口返回值。

    4.1 正则表达式

    所谓正则表达式,即一个用来描述或者匹配一系列符合某个句法规则的字符串的单个字符串。

    在“http请求”打开鼠标右键-->添加-->post processions-->Regular Expression Extractor


    Name of created variable:正则表达式名称,我们使用${名称}来进行引用;

    Regular Expression:设置提取规则

    .  匹配任何字符

    +   一次或更多次

    ?    停止在第一个匹配成功时

    Templates:表示用哪个正则表达式模板获取的值 ,默认使用$1$,如果有多个正则表达式,则可以使用$2$,$3$等,表示解析到的第几个值给test。

    Match No.:-1表示全部,0随机,1第一个,2第二个

    Default value:如果没有取到值,则默认使用该值,可以为空

    4.2  Json Path Extractor

     使用Json Path Extractor需要下载第三方插件,访问https://jmeter-plugins.org/wiki/PluginsManager/下载plugin Manager,并将下载下来的jar包放到JMeter的lib/ext目录下,重启JMeter。

    重启后,在options菜单下点击“plugins Manager”,在available plugins中,搜索json path extractor,点击apply changes andrestart jmeter即可。







    展开全文
  • 测试入门

    2017-11-28 15:38:08
    测试入门软件测试是什么? 软件测试做什么? 软件测试怎么做? 软件测试是什么? 软件测试是使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间...

    测试入门

    软件测试是什么?
    软件测试做什么?
    软件测试怎么做?

    • 软件测试是什么?
      软件测试是使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
      软件测试是为了发现错误而执行程序的过程。或者说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程。
      V模型:强调了在整个软件项目开发中需要经历的若干个测试级别,并与每一个开发级别对应;忽略了测试的对象不应该仅仅包括程序,没有明确指出对需求、设计的测试
      V模型
      W模型:补充了V模型中忽略的内容,强调了测试计划等工作的先行和对系统需求和系统设计的测试;与V模型相同,没有对软件测试的流程进行说明
      W模型
      H模型:强调测试是独立的,只要测试准备完成,就可以执行测试
      H模型

    • 软件测试做什么
      这里写图片描述

    1.验证软件实现与需求的一致性
    2.检测软件漏洞即bug
    3.测试软件的稳定性、安全性等
    4.对软件的实施、维护、操作等进行评估
    5.对二次开发及维护进行评估

    测试用例设计方法
    黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
    白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖、程序变异。
    白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
    其他测试方法:
    回归测试、冒烟测试、α测试_Alpha测试、β测试_Beta testing、可移植性测试、用户界面(UI)测试、随机测试、本地化测试、国际化测试、安装测试、自动化测试、验收测试、动态测试、探索性测试、单元测试、集成测试、系统测试、健全测试、衰竭测试、负载测试、极限测试等。

    • 软件测试怎么做?
      功能测试
      Functional testing(功能测试),也称为behavioral testing(行为测试),根据产品特性、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试,通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
      功能测试也叫黑盒子测试或数据驱动测试,只需考虑各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发,按照需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。
      功能测试目的和内容
      1.程序安装、启动正常,有相应的提示框、错误提示等
      2.每项功能符合实际要求
      3.系统的界面清晰、美观
      4.菜单、按钮操作正常、灵活,能处理一些异常操作
      5.能接受正确的数据输入,对异常数据的输入可以进行提示、容错处理等
      6.数据的输出结果准确,格式清晰,可以保存和读取
      7.功能逻辑清楚,符合使用者习惯
      8.系统的各种状态按照业务流程而变化,并保持稳定
      9.支持各种应用的环境
      10.能配合多种硬件周边设备
      11.软件升级后,能继续支持旧版本的数据
      12.与外部应用系统的接口有效

    系统测试
    压力测试 (Stress test)
    容量测试 (Capacity test)
    性能测试 (Performance test)
    安全测试 (Security test)
    容错测试 (Recovery test)

    压力测试、容量测试和性能测试的测试目的虽然有所不同,但其手段和方法在一定程度上比较相似,通常会使用特定的测试工具,来模拟超常的数据量、负载等,监测系统的各项性能指标,如CPU和内存的使用情况、响应时间、数据传输量等。

    压力测试
    压力测试是在一种需要反常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。
    异常情况主要指的是峰值(瞬间使用高峰)、大量数据的处理能力、长时间运行等情况。压力测试总是迫使系统在异常的资源配置下运行。

    容量测试
    容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

    性能测试的目的: 为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的。

    性能测试指标的来源:用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验)

    主要的性能指标:服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间
    性能测试要点
    测试环境应尽量与用户环境保持一致,应单独运行尽量避免与其他软件同时使用。
    性能测试一般使用测试工具和测试人员编制测试脚本来完成。
    性能测试的重点在于前期数据的设计与后期数据的分析。
    性能测试的用例主要涉及到整个系统架构的问题,所以测试用例一旦生成,改动一般不大,所以做性能测试的重复使用率一般比较高。
    性能测试的方法和技巧
    两种负载类型
    “flat”测试
    ramp-up测试
    “Flat”测试: 对于一次给定的测试,应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户,然后在预定的时间段内持续运行。这称为“flat”测试。

    Ramp-up测试: 用户是交错上升的(每几秒增加一些新用户)。ramp-up测试不能产生精确和可重现的平均值,这是因为由于用户的增加是每次一部分,系统的负载在不断地变化。ramp-up测试的优点是,可以看出随着系统负载的改变,测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

    安全性测试
    根据ISO 8402的定义,安全性是“使伤害或损害的风险限制在可接受的水平内”。
    安全性测试是检查系统对非法侵入的防范能力。
    测试人员假扮非法入侵者,采用各种办法试图突破防线。例如:
    1.想方设法截取或破译口令;
    2.专门开发软件来破坏系统的保护机制;
    3.故意导致系统失败,企图趁恢复之机非法进入;
    4.试图通过浏览非保密数据,推导所需信息等等。
    理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值,此时非法侵入者已无利可图。

    可靠性测试
    可靠性(Reliability)是产品在规定的条件下和规定的时间内完成规定功能的能力,它的概率度量称为可靠度。
    软件可靠性是软件系统的固有特性之一,它表明了一个软件系统按照用户的要求和设计的目标,执行其功能的可靠程度。软件可靠性与软件缺陷有关,也与系统输入和系统使用有关。
    理论上说,可靠的软件系统应该是正确、完整、一致和健壮的。

    可靠性测试结果的评估
    成熟性度量可以通过错误发现率DDP(Defect Detection Percentage)来表现。在测试中查找出来的错误越多,实际应用中出错的机会就越小,软件也就越成熟。
    DDP=测试发现的错误数量/已知的全部错误数量
    已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。

    容错性测试
    容错性测试是检查软件在异常条件下自身是否
    具有防护性的措施或者某种灾难性恢复的手段。
    包括两个方面:
    输入异常数据或进行异常操作,而不会导致系统出错甚至崩溃。
    灾难恢复性测试。让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。

    回归测试的目的
    所做的修改达到了预定的目的,如错误得到了改正,新功能得到了实现,能够适应新的运行环境等;
    不影响软件原有功能的正确性。

    回归测试的方法
    再测试全部用例
    基于风险选择测试
    基于操作剖面选择测试
    再测试修改的部分

    ISTQB的“测试七项基本原则”:
    原则1:测试指出缺陷的存在——测试没有
    发现缺陷并不意味着不存在缺陷
    原则2:穷尽测试是不可能的
    原则3:测试要尽早介入
    原则4:缺陷集群性——大多数缺陷总是发
    生在少量模块/特性上
    原则5:杀虫剂悖论
    原则6:测试活动依赖于测试Context
    原则7:“Absence-of-errors ”(无错就是好)谬误

    • 心得
      IXIA
      这里写图片描述
      这里写图片描述
      这里写图片描述
      Spirent
      这里写图片描述
      这里写图片描述

    • 目前测试技术
      1、SIPP
      SIPp是一个测试SIP协议性能的工具软件,它包含了一些基本的SipStone用户代理工作流程(UAC和UAS),并可使用INVITE和BYE建立和释放多个呼叫。它也可以读XML的场景文件,即描述任何性能测试的配置文件。它能动态显示测试运行的统计数据(呼叫速率、信号来回的延迟,以及消息统计)。周期性地把CSV统计数据转储,在多个套接字上的TCP和UDP,利用重新传输管理的多路复用。在场景定义文件中可以使用正规表达式,动态调整呼叫速率。SIPp可以用来测试许多真实的SIP设备,如SIP代理,B2BUAs,SIP媒体服务器,SIP/x网关,SIP PBX,等等,它也可以模仿上千个SIP代理呼叫你的SIP系统。
      2、TESTCOMPLETE 7
      TestComplete是AutomatedQA公司开发的一套支持自动测试软件的工具。在当今的软件开发中,自动测试非常重要,大型软件开发公司很久以来就已经将其作为软件开发的一项重要环节。然而,自动测试软件一般成本较高而且不易使用,很难在小型公司内推广。 TestComplete为Windows、.NET、Java和Web应用程序提供了一个特性全面的自动测试环境。将开发人员和QA部门人员从繁琐耗时的人工测试中解脱出来。 TestComplete测试具有系统化、自动化和结构化特性,支持。NET,Java,Visual C++, Visual Basic, Delphi, C++Builder 和web应用程序。
      3、QTP
      QTP是quicktest Professional的简称,是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试,例如要测试那些功能、操作步骤、输入数据和期望的输出数据等

    • 目前性能与自动化测试方案
      RTP性能
      这里写图片描述
      测试流程:模拟240个SIP号码,120方呼叫120方
      测试功能点:注册数、并发数、呼损、接通时间等

    DispLDF稳定性
    这里写图片描述
    测试流程:SIPP发起方模拟用户呼叫接入号,SIPP接收方模拟调度员接听来电,每次呼入4个
    测试功能点:最大调度员在线稳定性

    领导台&Switch稳定性
    这里写图片描述
    测试流程:TestComplete/QTP录制组呼过程,SIPP作为组呼成员和绑定电话进行自动接听,进行循环组呼测试
    测试功能点:领导台和Switch的稳定性

    快捷键

    • 加粗 Ctrl + B
    • 斜体 Ctrl + I
    • 引用 Ctrl + Q
    • 插入链接 Ctrl + L
    • 插入代码 Ctrl + K
    • 插入图片 Ctrl + G
    • 提升标题 Ctrl + H
    • 有序列表 Ctrl + O
    • 无序列表 Ctrl + U
    • 横线 Ctrl + R
    • 撤销 Ctrl + Z
    • 重做 Ctrl + Y
    展开全文
  • IntelliJ IDEA单元测试入门

    万次阅读 多人点赞 2016-08-09 20:10:17
    参考文章地址地址:JUnit4单元测试入门教程 IDEA单元测试及代码覆盖率 IDEA添加jar包的三种方式 本文按以下顺序讲解JUnit4的使用 下载jar包单元测试初体验自动生成测试类执行顺序@Test的属性

    参考文章地址地址:JUnit4单元测试入门教程

                                    IDEA单元测试及代码覆盖率

                                                    IDEA添加jar包的三种方式

     

     

    本文按以下顺序讲解JUnit4的使用

    • 下载jar包
    • 单元测试初体验
    • 自动生成测试类
    • 执行顺序
    • @Test的属性
    • 代码覆盖率

    下载jar包

    在github上,把以下两个jar包都下载下来。下载地址:点击打开链接

     

    下载junit-4.12.jar,junit-4.12-javadoc.jar(文档),junit-4.12-sources.jar(源码)。

     

    下载hamcrest-core-1.3.jar,hamcrest-core-1.3-javadoc.jar(文档),hamcrest-core-1.3-sources.jar(源码)。

     

    最前面那个pom是Maven的配置文件,如果你需要的话也下载下来。

     

    单元测试初体验

    先创建个简单的项目体验下单元测试是怎么一回事吧。

    我创建一个项目叫JUnit4Demo,刚创建好的工程目录如下图,然后在External Libraries中导入刚下载的那两个jar包。

                            

    通过Libraries添加Jar包

    1.打开 File -> Project Structure ->Modules-> 在Dependencies 下添加jar包

                  

    2、+ -> Library... -> java -> 选择jar的路径添加。   添加jar包后如下图所示。

                       

    3、创建一个类com.hera.util.Math,然后输入一个求阶乘的方法:

                        

    4、创建一个队Math方法的单元测试:

            创建一个和src同级别的文件夹叫test(逻辑代码放src里,测试代码放test里是个好习惯)。
            接着在IntelliJ IDEA里还要把这个test文件夹要设置成测试文件的根目录,右键选中
            Mark Directory As - Test Sources Root。

                                         
               创建一个测试类:

                IntelliJ IDEA提供了一个快捷操作Cmd + Shift + T作为类和测试之间的导航。同时允许用户在那里创建一个测试类。IntelliJ IDEA提供了一个快捷操作Cmd + Shift + T作为类和测试之间的导航。同时允许用户在那里创建一个测试类。

              为测试类MathTest添加测试方法:

                  

                     

                    运行: run MathTest 。右下方一条绿色条说明测试通过,如果把120改成别的数字那么就会测试不通过显色红色条。JUnit4有一句话叫:“keeps the bar green to keep the code clean”。

            解释一下MathTest,就六个地方要讲:
                      第一,导入了org.junit.Test;和org.junit.Assert.*;这两个包,注意后者是静态导入import static。
                      第二,testFactorial是在要测试的方法名Factorial前加个test(这也是个好习惯)。
                      第三,所有测试方法返回类型必须为void且无参数。
                      第四,一个测试方法之所以是个测试方法是因为@Test这个注解。
                      第五,assertEquals的作用是判断两个参数是否相等,例子中120是预期结果,new Math().factorial(5)是实                              际结果。但是通常不应该只比较一个值,要测试多几个特殊值,特别是临界值。

                                例如Math().factorial(0)和Math().factorial(-1)等。
                     第六,assertEquals除了比较两个int,还重载了好多次可以比较很多种类型的参数。而且JUnit4包含一堆                                assertXX方法,assertEquals只是其中之一,这些assertXX统称为断言。刚不是下载了junit-4.12-                                 javadoc.jar这个文档吗,解压后打开index.html如下图还有一堆断言。

                       

          

    执行顺序

     

    JUnit4利用JDK5的新特性Annotation,使用注解来定义测试规则。
    这里讲一下以下几个常用的注解:

    • @Test:把一个方法标记为测试方法
    • @Before:每一个测试方法执行前自动调用一次
    • @After:每一个测试方法执行完自动调用一次
    • @BeforeClass:所有测试方法执行前执行一次,在测试类还没有实例化就已经被加载,所以用static修饰
    • @AfterClass:所有测试方法执行完执行一次,在测试类还没有实例化就已经被加载,所以用static修饰
    • @Ignore:暂不执行该测试方法

     

    我们来试验一下,我新建一个测试类AnnotationTest,然后每个注解都用了,其中有两个用@Test标记的方法分别是test1和test2,还有一个用@Ignore标记的方法test3。然后我还创建了一个构造方法,这个构造方法很重要一会会引出一个问题。
    具体代码如下:

    
    package com.xuhongchuan.util;
    
    import org.junit.*;
    import static org.junit.Assert.*;
    
    /**
     * Created by xuhongchuan on 2015/7/18.
     */
    public class AnnotationTest {
    
        public AnnotationTest() {
            System.out.println("构造方法");
        }
    
        @BeforeClass
        public static void setUpBeforeClass() {
            System.out.println("BeforeClass");
        }
    
        @AfterClass
        public static void tearDownAfterClass() {
            System.out.println("AfterClass");
        }
    
        @Before
        public void setUp() {
            System.out.println("Before");
        }
    
        @After
        public void tearDown() {
            System.out.println("After");
        }
    
        @Test
        public void test1() {
            System.out.println("test1");
        }
    
        @Test
        public void test2() {
            System.out.println("test2");
        }
    
        @Ignore
        public void test3() {
            System.out.println("test3");
        }
    
    }

    运行结果如下:

    BeforeClass
    构造方法
    Before
    test1
    After
    构造方法
    Before
    test2
    After
    AfterClass

     

            解释一下:@BeforeClass和@AfterClass在类被实例化前(构造方法执行前)就被调用了,而且只执行一次,通常用来初始化和关闭资源。@Before和@After和在每个@Test执行前后都会被执行一次。@Test标记一个方法为测试方法没什么好说的,被@Ignore标记的测试方法不会被执行,例如这个模块还没完成或者现在想测试别的不想测试这一块。
           以上有一个问题,构造方法居然被执行了两次。所以我这里要说明一下,JUnit4为了保证每个测试方法都是单元测试,是独立的互不影响。所以每个测试方法执行前都会重新实例化测试类。
          我再给你看一个实验:

     

     

     

     

          添加一个成员变量

     

     

    
    int i = 0;

     

    然后把test1改为:

        i++;
        System.out.println("test1的i为" + i);

    test2改为:

        i++;
        System.out.println("test2的i为" + i);

    执行结果:

    BeforeClass
    构造方法
    Before
    test1的i为1
    After
    构造方法
    Before
    test2的i为1
    After
    AfterClass

     

           可以看到test1和test2的i都只自增了一次,所以test1的执行不会影响test2,因为执行test2时又把测试类重新实例化了一遍。如果你希望test2的执行受test1的影响怎么办呢?把int i改为static的呗。

            最后关于这些注解还有一个要说明的就是,你可以把多个方法标记为@BeforeClass、@AfterClass、@Before、@After。他们都会在相应阶段被执行。

     

     

    @Test的属性

     

    最后来说一下@Test的两个属性

    • excepted
    • timeout
      excepted属性是用来测试异常的,我们回到Math类,拿其中的求阶乘方法factorial()来说。如果传进来一个负数我们是希望抛出异常的,那要测试会不会抛异常怎么办呢?
      我在测试类MathTest添加一个测试方法:    
    •                

              这个方法就是(expected = Exception.class)和fail("factorial参数为负数没有抛出异常");之间的配合。就是这个测试方法会检查是否抛出Exception异常(当然也可以检测是否抛出其它异常),如果抛出了异常那么测试通过(因为你的预期就是传进负数会抛出异常)。没有抛出异常则测试不通过执行fail("factorial参数为负数没有抛出异常");

     

     

             然后说下timeout属性,这个是用来测试性能的,就是测试一个方法能不能在规定时间内完成。
    回到Math类,我创建一个数组排序的方法,用的是冒泡排序。

     

     

            
    public void sort(int[] arr) {
        //冒泡排序
        for (int i = 0; i < arr.length - 1; i++) { //控制比较轮数
    
            for (int j = 0; j < arr.length - i - 1; j++) { //控制每轮的两两比较次数
                if (arr[j] > arr[j + 1]) {
                    int temp = arr[j];
                    arr[j] = arr[j + 1];
                    arr[j + 1] = temp;
                }
            }
        }
    }
          然后偶在测试类MathTest创建测试方法,随机生成一个长度为50000的数组然后测试排序所用时间。timeout的值为2000,单位和毫秒,也就是说超出2秒将视为测试不通过。
    @Test(timeout = 2000)
    public void testSort() throws Exception {
        int[] arr = new int[50000]; //数组长度为50000
        int arrLength = arr.length;
        //随机生成数组元素
        Random r = new Random();
        for (int i = 0; i < arrLength; i++) {
            arr[i] = r.nextInt(arrLength);
        }
    
        new Math().sort(arr);
    }
          运行结果测试不通过,且提示TestTimedOutException。
          那怎么办,修改代码提升性能呗。回到Math方法改为下sort()。这次我用快速排序,代码如下:
    public void sort(int[] arr) {
        //快速排序
        if (arr.length <= 1) {
            return;
        } else {
            partition(arr, 0, arr.length - 1);
        }
    }
    
    static void partition(int[] arr, int left, int right) {
        int i = left;
        int j = right;
        int pivotKey = arr[left]; //基准数
    
        while (i < j) {
            while (i < j && arr[j] >= pivotKey) {
                j--;
            }
    
            while (i < j && arr[i] <= pivotKey) {
                i++;
            }
    
            if (i < j) {
                int temp = arr[i];
                arr[i] = arr[j];
                arr[j] = temp;
            }
        }
    
        if (i != left) {
            arr[left] = arr[i];
            arr[i] = pivotKey;
        }
    
        if (i - left > 1) {
            partition(arr, left, i - 1);
        }
    
        if (right - j > 1) {
            partition(arr, j + 1, right);
        }
    
    }
             然后再运行一下测试类MathTest,绿色条出现了,测试通过妥妥的。

     

     

    编辑测试设置

           我们可以通过Run → Edit Configurations或工具栏上的标签来调整我们的测试运行配置。

            

     

           在Configuration选项卡,用户可以选择需要运行的测试。例如,您可以从一个类、程序包、测试套件或甚至模式中运行所有的测试。这里的Fork模式让用户在一个单独的进程运行每个测试。

     

            在代码覆盖标签你可以调整覆盖率设置。目前IntelliJ IDEA支持两种测量覆盖率引擎。默认情况下它使用自己的引擎,当然用户也可以选择JaCoCo引擎。用户也可以在这里选择覆盖率模式。Tracing{span{ mode模式会增加消耗,但测量会更精确。

                     

    运行覆盖

             收集覆盖率,用户需要通过Run → Run 'MyClassTest' with Coverage或工具栏上的选项运行特定模式的测试。

            当覆盖模式运行至少一个测试之后,IDE将会在Project工具窗口显示每个程序包、类的覆盖率数据,同时在Coverage工具窗和编辑器中也会显示。

             

     

    编辑器中的覆盖率

    如果用户添加另一个方法到MyClass,并运行覆盖率测MyClass,就会发现,没有被测试覆盖到的代码都将高亮显示为红色。覆盖的代码颜色则是绿色。如果一些代码是只覆盖部分,那没将显示为黄色。

     
     

     

           

     

    展开全文
  • 软件测试入门知识了解

    千次阅读 多人点赞 2018-09-05 14:59:58
    1.软件测试定义两面性 2.测试的生命周期 测试需求分析--&gt;测试设计--&gt;测试计划--&gt;测试执行--&gt;质量评估 3.软件测试过程: 需求评审和设计评审是验证软件产品的需求定义和设计...

    一.概述

    1.软件测试定义两面性

    2.测试的生命周期

    测试需求分析-->测试设计-->测试计划-->测试执行-->质量评估

    3.软件测试过程:

     

     

    需求评审和设计评审是验证软件产品的需求定义和设计实现,验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等阅读、讨论,从中发现软件需求工程和系统设计中所存在的问题 。 

    单元测试的对象是程序系统中的最小单元---模块或组件上,在编码阶段进行,针对每个模块进行测试,主要通过白盒测试方法,从程序的内部结构出发设计测试用例,检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试,通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成。

    集成测试,也称组装测试、联合测试、子系统测试,在单元测试的基础上,将模块按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的模块之间问题 两种集成方式:一次性集成方式和增殖式集成方式。

    功能测试一般须在完成集成测试后进行,而且是针对应用系统进行测试。功能测试是基于产品功能说明书,是在已知产品所应具有的功能,从用户角度来进行功能验证,以确认每个功能是否都能正常使用。

    系统测试是将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试,包括恢复测试、安全测试、强度测试和性能测试等。

    验收测试的目的是向未来的用户表明系统能够像预定要求那样工作,验证软件的功能和性能如同用户所合理期待的那样 。

    安装测试是指按照软件产品安装手册或相应的文档,在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中,进行一步一步的安装操作性的测试。

    软件测试与开发关系:

    二.需求和设计评审

    1. 产品需求审查是软件开发重要环节之一,也是测试活动之一,即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映,并使各类开发人员在需求理解上达成一致。

    2.测试需求:

    测试目标取决于软件质量需求,而这种需求分为功能性需求和非功能性需求,功能性的需求相对容易确定,非功能性的测试需求难以确定。

    •  在制定测试计划之前,必须清楚测试需求
    •  明确测试需求的优先级
    •  测试需求分解得越细,对测试用例的设计质量越有帮助
    •  详细的测试需求还是衡量测试覆盖率的重要依据  
    • 测试需求是规划具体项目资源和时间的基础。

    3.功能性测试需求

    (1)功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求,包括用户界面的友好性。

    • 程序安装、启动正常,有相应的提示框、错误提示
    • 各项功能符合设计要求,正常运行并输出正确结果
    • 功能逻辑合理,并能处理各种异常操作
    • 能接受正确的数据输入,输出结果准确,格式清晰
    • 系统的各种状态按照业务流程而变化并保持稳定

    支持各种应用环境,能配合硬件设备

    (2)功能测试需求分析

    了解需求范围-->明确目标用户-->分析功能步骤-->挖掘隐藏需求

    • 了解需求想要做什么,要完成哪些功能模块
    • 需求目标是谁?不同的用户角色,功能和权限是否一样?
    • 要完成功能,用户需要哪些步骤
    • 挖掘隐藏需求

    4.用户界面及其显示要求

    用户界面是和用户进行交互的窗口,其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验,简单、方便和明了,让用户舒畅、愉悦

    • 通用框架、浮动窗口和文字等整体布局合理
    •  文字显示正常,且内容格式正确、美观。
    •  色彩协调,风格前后一致,  文字标记和超链接可以打开和跳转成功

    5.非功能性需求

    非功能性质量需求,包括系统性能、安全性、兼容性、扩充性,其测试需求会因不同的项目类型差异较大。

    • 客户端软件,如字处理软件、媒体播放软件等占用较少资源,在容错性、兼容性等方面要求高。
    • Web应用系统对性能、安全性等有很高要求 客户端/服务器应用系统。
    • 大型复杂企业级系统。

    6.测试人员在需求评审中作用

    需求评审归为静态测试范畴,包含了文档评审和技术评审双重内容,通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用,检查需求定义是否合理和清楚。

    • 明确自己的角色和责任
    •  熟悉评审内容,为评审做好准备  
    • 针对问题阐述观点,而非针对个人
    •  从客户角度想问题,多问几个为什么
    •  在会前或会后提出自己建设性的意见
    •  对发现的问题跟踪到底
    •  针对需求文档等报告问题

    7.设计审查

    1)成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示,也就是保证产品规格说明书的质量。

    •  系统架构的审查
    •  设计规格说明书的审查
    •  系统部署设计的审查
    •  多层次审查:high-level  low-level

    2)系统架构设计的审查

    系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。

    3)组件设计的审查

    • 功能和接口定义正  
    •  算法的有效性和优化
    •  合理的数据结构、数据流和控制流
    •  可测试性 等

    4)系统部署设计的审查

    系统部署设计的审查是基于软件服务的质量目标,用来审查软件部署的目标、策略是否合理,是否得到彻底的执行

    •  着重是否服从和遵守部署设计的技术规范
    •  逻辑设计的审查
    •  物理设计的审查
    •  可用性设计的审查  
    • 可伸缩型设计的验证
    •  安全性设计的验证

    三.测试用例设计

    1.测试用例(test case)是可以被独立执行的一个过程,这个过程是一个最小的测试实体,不能再被分解。测试用例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。

    2.测试用例的元素:

    3.如何设计出高质量的测试用例

    • 客户需求导向的设计思路
    • 责任到人
    • 灵活的设计方法
    • 测试用例设计不能局限于输入数据 尽量避免含糊的、冗长的或复杂的测试用例
    • 尽量将具有相类似功能的测试用例抽象并归类

    4.良好测试用例的特征

    • 可以最大程度地找出软件隐藏的缺陷
    • 可以最高效率的找出软件缺陷
    • 可以最大程度地满足测试覆盖要求
    • 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定
    • 测试用例包含期望的正确的结果
    • 待查的输出结果或文件必须尽量简单明了
    • 不包含重复的测试用例
    • 测试用例内容清晰、格式一致、分类组织

    5.测试用例设计步骤

    6.测试用例的创建

    建立合适的、可扩展的测试用例框架,从而借助这个框架能有效地组织众多的测试用例,包括对测试用例的分类、清晰的层次结构等。

    7.测试用例套件

    测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合,已满足测试执行的特定要求。通过测试套件,将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来

    .

    四.单元测试

    1.单元测试方法:

    单元测试主要采用白盒测试方法,辅以黑盒测试方法。白盒测试方法应用于代码评审、单元程序检验之中,而黑盒测试方法则应用于模块、组件等大单元的功能测试之中。

    2.黑白盒测试方法:

    黑盒测试方法(Blake-box Testing),是把程序看作一个不能打开的黑盒子,不考虑程序内部结构和内部特性,而是考察数据的输入、条件限制和数据输出,完成测试。

    白盒测试方法(White-box Testing),也称结构测试或逻辑驱动测试。白盒测试方法是根据模块内部结构了解,基于内部逻辑结构,针对程序语句、路径、变量状态等来进行测试,检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。

    驱动程序(driver),对底层或子层模块进行(单元或集成)测试时所编制的调用被测模块的程序,用以模拟被测模块的上级模块

    桩程序(stub),也有人称为存根程序,对顶层或上层模块进行测试时,所编制的替代下层模块的程序,用以模拟被测模块工作过程中所调用的模块。 

     

    3.白盒测试方法的用例设计

    语句覆盖,使得程序中每一条可执行语句至少被执行一次

    分支覆盖,使得程序中每一个分支都至少被执行一次

                

    节点①

    N < 0 : 如N= -1, -2, …, -10, …

    N >= 0:  如N=1,2, …, 10, …

    节点③

    (K<N) and (R<=Max) 成立 (True)

    (K<N) and (R<=Max) 不成立 (False)

    节点⑤

    R<= Max 

    R> Max

    N= -2,Max = 10: 覆盖①②③④③④③⑥

    N= 5,Max = 1: 覆盖①②③④③④③⑦

    分支覆盖VS语句覆盖

    条件覆盖,程序中每一个条件至少有一次被满足

    条件覆盖 vs. 分支覆盖

    条件覆盖不能保证分支覆盖,例如设计两个测试用例N= 1、Max = -1和N= 0、Max = 1

        (K<N) and (R<=Max)=.T. 的分支没有被覆盖

    设计两个测试用例N= 3、Max = 10和N= -1、Max = 0,即覆盖了所有条件,也覆盖了所有分支  

    路径覆盖,对程序模块的所有独立的基本路径至少要测试一次

    路径覆盖就是设计所有的测试用例,来覆盖程序中的所有可能的执行路径。基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。设计出的测试用例要保证被测试程序的每个可执行语句至少被执行一次。

    示例:

    确定基本路径获得测试用例: 

    环路复杂性: 

    图形矩阵: 

    4.代码审查

    代码审查的目的就是为了产生合格的代码,检查源程序编码是否符合详细设计的编码规定,确保编码与设计的一致性和可追踪性 

    代码规范性的审查

    • 代码规范性的审查将助于更早地发现缺陷,代码质量的提高,而且可以帮助程序员遵守规则、养成好的习惯,以达到预防缺陷的目的
    • 代码风格和编程规则两者不可缺一,都应列入代码评审的范围里
    • 命名规则 、缩进与对齐 、注释 和函数处理 等。

    5.集成测试

    非渐增式测试模式

    采用大棒集成方法,先是对每一个子模块进行测试(单元测试阶段),然后将所有模块一次性的全部集成起来进行集成测试 。

    因为所有的模块一次集成的,所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用,适合在规模较小的应用系统中使用。 

    非渐增式测试模式:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。

    渐增式测试模式:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进

    驱动程序/驱动模块(driver),用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。

    桩程序/桩模块(stub),也有人称为存根程序,用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用,它们一般只进行很少的数据处理,例如打印入口和返回,以便于检验被测模块与其下级模块的接口来测试。

    自顶向下法(Top-down Integration)  

    自底向上法(Bottom-up Integration) 

    微软VSTS的单元测试 

    Visual Studio Team System(VSTS)是一套工具集,全面整合了软件设计、开发、测试、部署和人员协作工具,其开发版(Development Edition)提供了静态分析、代码剖析、代码涵盖以及其它单元测试所需的功能特性。

    •  创建单元测试项目。
    •  设置项目引用。  
    • 添加适当的测试类(一个或多个)。
    •  生成主干的单元测试框架(Unit Test Framework)类和属性。
    •  创建单个测试方法。
    •  创建适合特定接口的逻辑

    五.自动化测试

     自动化测试(automated test)是相对手工测试(manual test)而存在的一个概念,由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。 测试工具的使用是自动化测试的主要特征

    六.功能测试

    1.功能测试,依据产品设计规格说明书完成对产品功能进行操作,以验证系统是否满足用户的功能性需求

    2.等价类法

    等价类是某个输入域的子集,在该子集中每个输入数据的作用是等效的

    将程序可能的输入数据分成若干个子集,从每个子集选取一个代表性的数据作为测试用例

     在分析需求规格说明的基础上划分等价类,列出等价类表

    3.有效等价类是有意义的、合理的输入数据,可以检查程序是否实现了规格说明中所规定的功能和性能

    无效等价类和有效等价类相反,即不满足程序输入要求或者无效的输入数据构成的集合 

    (设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。)

    4.确定等价类的方法

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

    (2)边界值计方法

    程序的很多错误发生在输入或输出范围的边界上,因此针对各种边界情况设置测试用例,可以更有效地发现缺陷。

    设计方法: 确定边界情况(输入或输出等价类的边界) 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

    (3)因果图法

    在实际应用的测试之中,经常碰到多种条件及其组合的情况 通过因果图,可以建立输入条件和输出之间的逻辑模型,从而比较容易确定输入条件组合和输出之间的逻辑关系,有利于设计全面的测试用例

    输入与输出关系:

    E约束(异):多个条件中至少有一个条件不成立,即Ci不能同时为1。

    I约束(或):多个条件中至少有一个条件成立,即Ci不能同时为0。

    O约束(唯一);多个条件中必须有一个且仅有一个条件成立,即Ci中只有一个为1

    R约束(要求):一个条件对另一个条件有约束,如C1是1,C2也必须须是1。

    设计步骤:

    分析软件规格说明书中的输入输出条件并划分出等价类,将每个输入输出赋予一个标志符

    分析规格说明中的语义,通过这些语义来找出多个输入因素之间的关系。

    找出输入因素与输出结果之间的关系,将对应的输入与输出之间的关系关联起来,并将其中不可能的组合情况标注成约束或者限制条件,形成因果图。

    由因果图转化成决策表,任何由输入与输出之间关系构成的路径,形成决策表的一列 将决策表的每一列拿

    实例(1)

    根据因果图,就可以转化为判定表。这里根据条C2 与C3、C4与C5的E约束(互斥),可以减少组合

    决策表方法:

    一个决策表由“条件和活动”两部分组成,也就是列出了一个测试活动执行所需的条件组合。所有可能的条件组合定义了一系列的选择,而测试活动需要考虑每一个选择。

    条件桩,列出问题的所有条件

    动作桩:列出可能针对问题所采取的操作

    条件项:针对所列条件的具体赋值(可取真值和假值)

    动作项:列出在条件项组合情况下应该采取的动作

    规则:任何一个条件组合的特定取值及其相应要执行的操作

    功能图法:

    每个程序的功能通常由静态说明和动态说明组成,静态说明描述了输入条件和输出条件之间的对应关系,而动态说明描述了输入数据的次序或者转移的次序。

    功能图法就是为了解决动态说明问题的一种测试用例的设计方法

    功能图由状态迁移图(state transition diagram,STD)和逻辑功能模型(logic function model, LFM)构成

    状态迁移图,描述系统状态变化的动态信息——动态说明,由状态和迁移来描述,状态指出数据输入的位置(或时间),而迁移则指明状态的改变

    如何设计测试用例?

    功能图法设计测试用例,就是如何覆盖软件所表现出来的所有状态,可以转化为两个层次的测试用例

     从功能逻辑模型(决策表或因果图)导出局部测试用例,即设计测试用例覆盖某个状态的各种输入数据的组合

    从状态迁移图导出整体的测试用例,以覆盖系统(程序)控制的逻辑路径

    功能图法是综合运用黑盒方法和白盒方法来设计测试用例,即整体上选用白盒方法——路径覆盖、分支和条件覆盖等,而局部上选用的是黑盒方法——决策表或因果图方法

    七.系统测试

    1.用户的需求可以分为功能性需求和非功能性需求,而非功能性的需求被归纳为软件产品的各种质量特性,如安全性、兼容性和可靠性等 系统测试就是针对这些非功能特性展开的,就是验证软件产品符合这些质量特性的要求,从而满足用户和软件企业自身的非功能性需求。所以,系统测试分为负载测试、性能系统、容量测试、安全性测试、兼容性测试和可靠性测试等  

    2.负载测试过程

    • 确定所要模拟的角色及其对应的关键业务操作路径。
    • 确定输入/输出参数,制定负载测试方案。
    • 准备测试环境,并完成相应的测试脚本的开发。
    • 设计具体的测试场景,如负载水平、加载方式等。
    • 执行测试,监控输出参数,如数据吞吐量、响应时间、资源占有率等。
    • 对测试结果进行分析。
    • 结果不满意,需要调整测试场景,进入下一个循环。

    输入参数:

    负载测试是通过模拟用户的操作方式来考察系统的行为,所以人们肯定会问:如何模拟用户的行为?

    • 并发用户数、并发连接数等。
    • 思考时间(think time),用户发出请求之间的间隔时间 加载的循环次数或持续时间 每次请求发送的数据量。
    • 加载的方式或模式,如均匀加载、峰值交替加载等

    输出参数:

    • 数据传输的吞吐量(Transactions)
    • 数据处理效率(Transactions per second)
    • 数据请求的响应时间(Response time)
    • 内存和CPU使用率 连接时间(Connect Time)、发送时间(Sent Time)
    • 处理时间(Process Time)、页面下载时间
    • 第一次缓冲时间
    • 每秒(SSL)连接数
    • 每秒事务总数、每秒下载页面数
    • 每秒点击次数、每秒HTTP 响应数
    • 每秒重试次数

    3.一些常见的性能问题

    • 资源泄漏,包括内存泄漏
    • 资源瓶颈,内部资源(线程、放入池的对象)变得稀缺
    • CPU使用率达到100%、系统被锁定等
    • 线程死锁、线程阻塞等
    • 数据库连接成为性能瓶颈
    • 查询速度慢或列表效率低
    • 受外部系统影响越来越大

    4.压力测试:

    压力测试是在系统(如CPU、内存和网络带宽等)处于饱和状态下,测试系统是否还具有正常的会话能力、数据处理能力或是否会出现错误,以检查软件系统对异常情况的抵抗能力,找出性能瓶颈、功能不稳定性等问题

    5.兼容性测试

    是在特定的或不同的硬件、网络环境和操作系统平台上、不同的应用软件之间,验证软件系统能否正常地运行,以及能否正确存取原先版本的用户数据所进行的测试

    • 与硬件兼容
    •  与操作系统、平台的兼容
    •  与数据库系统的兼容  
    • 与浏览器的兼容
    •  与第三方系统的兼容
    •  与内部业务系统的兼容
    •  与自身系统的不同版本的用户数据兼容等

    向后兼容是指新发布的软件版本可以使用该软件的以前版本所产生的数据。

    向前兼容是指在设计和开发软件一个新版本时,考虑如何和未来版本的数据兼容。

    八.总结

           软件测试定义:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

      软件测试过程:通常按照测试阶段分为单元测试、集成测试、确认测试、系统测试、验收测试、回归测试、Alpha测试、Beta测试。

      单元测试,又称模块测试,是针对软件设计的最小单位 ─ 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

      1. 单元测试的内容

      (1) 模块接口测试

      * 在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括:

      – 调用本模块的输入参数是否正确;

      – 本模块调用子模块时输入给子模块的参数是否正确;

      – 全局量的定义在各模块中是否一致

      * 在做内外存交换时要考虑:

      – 文件属性是否正确;

      – OPEN与CLOSE语句是否正确;

      – 缓冲区容量与记录长度是否匹配;

      – 在进行读写操作之前是否打开了文件;

      – 在结束文件处理时是否关闭了文件;

      – 正文书写/输入错误,

      – I/O错误是否检查并做了处理。

      (2) 局部数据结构测试

      * 不正确或不一致的数据类型说明

      * 使用尚未赋值或尚未初始化的变量

      * 错误的初始值或错误的缺省值

      * 变量名拼写错或书写错

      * 不一致的数据类型

      * 全局数据对模块的影响

      (3) 路径测试

      * 选择适当的测试用例,对模块中重要的执行路径进行测试。

      * 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

      * 对基本执行路径和循环进行测试可以发现大量的路径错误。

      (4) 错误处理测试

      * 出错的描述是否难以理解

      * 出错的描述是否能够对错误定位

      * 显示的错误与实际的错误是否相符

      * 对错误条件的处理正确与否

      * 在对错误进行处理之前,错误条件是否已经引起系统的干预等

      (5) 边界测试

      * 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。

      * 如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。

      2. 单元测试的步骤

      * 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。

      – 驱动模块 (driver)

      – 桩模块 (stub) ── 存根模块

      * 如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试

      * 对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。

      集成测试,也叫组装测试、联合测试

      1. 一次性集成方式(big bang)

      * 它是一种非增殖式组装方式。也叫做整体拼装。

      * 使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。

      2. 增殖式集成方式

      * 这种集成方式又称渐增式集成

      * 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统

      * 在集成的过程中边连接边测试,以发现连接过程中产生的问题

      * 通过增殖逐步组装成为要求的软件系统。

      (1) 自顶向下的增殖方式

      * 这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。

      * 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。

      * 选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。

      (2) 自底向上的增殖方式

      * 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。

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

      * 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。

      * 一般来讲,一种方式的优点是另一种方式的缺点。

      (3) 混合增殖式测试

      * 衍变的自顶向下的增殖测试

      – 首先对输入/输出模块和引入新算法模块进行测试;

      – 再自底向上组装成为功能相当完整且相对独立的子系统;

      – 然后由主模块开始自顶向下进行增殖测试。

      * 自底向上-自顶向下的增殖测试

      – 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;

      – 然后对含写操作的子系统做自顶向下的组装与测试。

      确认测试,又成有效性测试。

      1. 进行有效性测试(黑盒测试

      * 有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。

      * 首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。

      * 通过实施预定的测试计划和测试步骤,确定

      – 软件的特性是否与需求相符;

      – 所有的文档都是正确且便于使用;

      – 同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试

      * 在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类:

      – 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。

      – 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。

      2. 软件配置复查

      软件配置复查的目的是保证软件配置的所有成分都齐全;

      各方面的质量都符合要求;

      具有维护阶段所必需的细节;

      而且已经编排好分类的目录。

      应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。

      系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。

      验收测试,以用户为主的测试

      应交付的文档有:

      – 确认测试分析报告

      – 最终的用户手册和操作手册

      – 项目开发总结报告。

      软件测试方法:是指测试软件的方法。如,兼容性测试、UI测试、冒烟测试、随机测试、本地化能力测试、国际化测试、安装测试、卸载测试、白盒测试、黑盒测试、自动化测试、端到端、性能测试、负载测试、压力测试、强迫测试、健全测试、衰竭测试、恢复测试、安全测试、接口测试。

      兼容性测试,指测试软件是否可以被成功移植到指定的硬件或软件平台上。

      1,浏览器兼容测试

      2,分辨率兼容测试

      硬件兼容:与整机兼容、与外设兼容

      软件兼容:操作系统/平台、应用软件之间的兼容、不同浏览器的兼容、数据库的兼容、软硬件配合兼容

      数据兼容:不同版本间的数据兼容、不同软件间的数据兼容

      UI测试,是指软件中的可见外观及其底层与用户交互的部分。

      用户界面的风格是否满足客户要求

      文字是否正确

      页面是否美观

      文字,图片组合是否完美

      操作是否友好

      包括菜单,对话框及对话框上所有按钮,文字,出错提示,帮助信息 (Menu 和Help content)等方面的测试。

      冒烟测试的对象是新编译的每一个需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

      随机测试,没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试,可以结合回归测试一起进行。

      本地化能力测试,指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。

      典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了固定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

      国际化测试,指验证软件程序在不同国家或区域的平台上也能够如预期的那样运行,而且还可以按照原设计尊重和支持使用当地常用的日期,字体,文字表示,特殊格式等等。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

      安装测试,是确保软件在正常情况和异常情况下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

      卸载测试,是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载,卸载是否干净,对系统有无更改,在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去。

      白盒测试,是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

      常用工具有:Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。

      黑盒测试,根据软件的规格对软件进行的测试,以用户的角度,通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷,而不关心程序具体如何实现的一种软件测试方法。

      常用工具有:Autorunner、winrunner

      自动化测试,使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本,然后执行这个测试脚本来实现测试过程的自动化。

      常用工具有QTP、Testcomplete、Autorunner和TAR等。

      端到端,涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试,一种集合了白盒测试和黑盒测试的优点的测试方法。

      性能测试,是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会出现内存泄露(memory leak)。比如,验证程序保存一个巨大的文件新版本不比旧版本慢。

      负载测试,测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

      压力测试,压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

      强迫测试,是在交替进行负荷和性能测试时常用的术语。也用于描述对象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

      健全测试,是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试能力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,不具备进一步测试的条件。

      衰竭测试,是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

      恢复测试,是测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件(或者硬件)出现故障来检测系统是否能正确的恢复,通常关注恢复所需的时间以及恢复的程度。恢复测试主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败,然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化(reinitialization)、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性;对于人工干预的恢复系统,还需估测平均修复时间,确定其是否在可接受的范围内。

      安全测试,是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。例如:

      ①想方设法截取或破译口令;

      ②专门定做软件破坏系统的保护机制;

      ③故意导致系统失败,企图趁恢复之机非法进入;

      ④试图通过浏览非保密数据,推导所需信息,等等。

      接口测试,测试系统组件间接口的一种测试。要进行接口,需要完善的文档进行保障,没有测试文档,接口测试将寸步难行,接口测试将增加开发过程规范化产出,而规范化产出也保证了项目质量

     

    展开全文
  • 接口测试入门

    万次阅读 2020-06-02 15:26:39
    说起接口测试,网上有很多例子,但是当初做为新手的我来说,看了不不知道他们说的什么,觉得接口测试,好高大上。认为学会了接口测试就能屌丝逆袭,走上人生巅峰,迎娶白富美。因此学了点开发知识后,发现接口测试...
  • 自动化测试入门(2)——自动化学习方向

    千次阅读 多人点赞 2019-03-15 15:22:35
    不管你们是打算学APP自动化测试或者web自动化测试,还是其他的自动化测,都有一个前置条件,那就是必须懂编程语言。 1.编程语言选择 如果你还没决定好方向,那么先去学习一门编程语言再好不过。 不要觉得学一门编程...
  • PHP单元测试入门

    2017-12-26 11:23:25
    PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP单元测试入门PHP...
  • 接口测试 | 接口测试入门

    万次阅读 多人点赞 2018-02-24 13:08:37
    接口测试讲义 1. 接口测试的类型 主要包含三种测试: Web接口测试, 应用程序接口(API, application programming interface)测试, 数据库测试。 实际上意义就是UI界面到数据库之间,数据流...
  • 内存测试入门

    千次阅读 2018-06-27 19:48:27
    1.1新手入门当软件实现了新功能后,准备发布版本前,往往需要进行一轮性能测试以确定没有性能问题,这类测试通常包括功能的流畅度,电量消耗和内存使用情况等。由于内存组成的复杂性,实际上并没有简单通用的方法就...
  • 性能测试入门教程.ppt

    2018-08-17 17:00:21
    性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试入门,性能测试...

空空如也

1 2 3 4 5 ... 20
收藏数 29,006
精华内容 11,602
热门标签
关键字:

测试入门