系统测试_系统测试方案 - CSDN
系统测试 订阅
系统测试,英文是System Testing。是对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善,能不能保证系统不受非法侵入。再例如,压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。 [1] 展开全文
系统测试,英文是System Testing。是对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善,能不能保证系统不受非法侵入。再例如,压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。 [1]
信息
主要步骤
制定系统测试计划、设计系统测试用例、 执行系统测试
外文名
System Testing
分    类
恢复测试、安全测试、压力测试
中文名
系统测试
目    的
验证最终软件系统是否满足用户规定的需求
主要内容
功能测试、健壮性测试
系统测试内容
系统测试是将经过集成测试的软件,作为计算机系统的一个部分,与系统中其他部分结合起来,在实际运行环境下对计算机系统进行的一系列严格有效地测试,以发现软件潜在的问题,保证系统的正常运行。流程如图1所示。系统测试的目的是验证最终软件系统是否满足用户规定的需求。 主要内容包括:功能测试。即测试软件系统的功能是否正确,其依据是需求文档,如《产品需求规格说明书》。由于正确性是软件最重要的质量因素,所以功能测试必不可少。健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义:一是容错能力,二是恢复能力
收起全文
精华内容
参与话题
  • 系统测试

    千次阅读 2018-01-03 23:52:08
    什么叫系统测试系统测试是对整个系统的测试,包括相关的软硬件平台、网络以及相关外设的测试。系统测试包含哪些类型的测试? 以下从质量的量子模型角度出发,得出系统测试包含以下几种类型: 功能性{密保安全...

    什么叫系统测试?
    系统测试是对整个系统的测试,包括相关的软硬件平台、网络以及相关外设的测试。

    系统测试包含哪些类型的测试?
    以下从质量的量子模型角度出发,得出系统测试包含以下几种类型:
    功能性{密保安全性,互操作性}–》安全性测试,功能测试
    可靠性{容错性,易恢复性}–》可靠性测试{容错性测试,易恢复性测试}
    易用性{易学性,易操作性,易吸引性}–》界面测试,文档测试
    效率性{时间性,空间资源}–》性能测试{强度测试、负载测试、压力测试},容量测试
    维护性{稳定性}–》稳定性测试
    可移植性{适应性,易安装性,共存性,易替换性}–》兼容性测试,安装测试,可替换性测试

    1) 安全性测试
    验证有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

    2) 可靠性测试
    a) 容错性测试
    测试在软件发生故障或违反指定接口的情况下,软件产品是否有维持自身规定性能级别的能力。 常见的,在输入非法数值检测系统能否处理就是容错性测试。
    b) 易恢复性测试
    测试在系统失效的情况下,软件产品重建规定的性能级别并恢复受直接影响的数据的能力。如遇到系统崩溃、硬件损坏或其他灾难性问题,系统能否在规定时间内自动重启并恢复损坏或丢失的数据。

    3) 界面测试
    这个没啥好说的,具体的参考“界面测试总结”文档

    4) 文档测试
    对用户文档如联机帮助、操作手册进行测试,验证文档的完整性、正确性、一致性、易理解性、易读性等。

    5) 性能测试
    为验证系统能否满足各项性能指标指标进行的测试。
    a) 负载测试
    保证系统能正常运行(通常是满足某些系统性能指标)的前提下,让被测对象承担不同的工作量,以评估被测对象的最大处理能力及存在缺陷而进行的测试

    b) 压力测试
    不保证系统能否正常运行的前提下,让被测对象承担不同工作量,以评估被测对象能提供的最大处理能力及存在缺陷而进行的测试

    a) 强度测试
    通常模拟系统在较差、异常资源配置下运行,如人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以评估被测对象在资源不足的情况下的工作状态
    注:疲劳强度测试是一类特殊的强度测试,主要测试系统长时间运行后的性能表现,例如7x24小时的压力测试。

    6) 容量测试
    测试系统对不同级别数据容量下的工作能力,意在获取系统的最佳数据处理容量和最大处理容量。
    注:容量测试主要关心how much,而负载测试主要关心how much 和how fast

    7) 稳定性测试
    测试系统的长期稳定运行的能力。同疲劳强度测试的区别是,稳定性测试的压力强度较小,一般趋向于客户现场日常状态下的压力强度,当然在时间不能保证稳定性的状态下,需要加大压力强度来测试,此时的压力强度则会高于正常值。

    8) 兼容性测试
    概念:在计算机术语上兼容是指几个硬件之间、几个软件之间或是软硬件之间的相互配合程度,如CPU、主板、显示卡等,如果在工作时能够相互配合、 稳定地工作,就说它们之间的兼容性比较好,反之就是兼容性不好。。

    兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。隐含的三层含义:相互配合(可能有互操作),相互共存(仅仅是在同一环境中驻留,互不影响),相互共享(测试软件系统之间是否可以不经过复杂的转换处理即可实现两者的数据共享)
    根据兼容性测试的概念及含义分为以下分类:
    a) 硬件兼容性测试(配合)
    1. 与整机兼容
    测试软件在整个硬件配置环境下能否正常运行,比如与打印机的兼容性测试。
    2. 与外设兼容
    测试软件对单一硬件如鼠标、键盘的支持

    a) 软件兼容性测试(配合与共存)
    1. 操作系统兼容
    测试软件是否能在不同操作系统或同一操作系统的不同版本上正常运行;
    2. 应用软件兼容:
    1.测试软件和其它软件如反病毒软件,共存在同一环境中能否正常运行
    2.测试软件的正常运行需要其它哪些应用软件的支持。
    3. 浏览器兼容
    测试软件在不同浏览器或不同分辨率的浏览器中是否正常运行
    4. 数据库兼容
    测试系统对不同数据库的支持,是否能直接从一数据库切换到另一数据库而不需要复杂的处理或者提供相关的转换工具。
    5. 软硬件配合兼容
    测试软件能否在不同类型的硬件配置上正常运行。

    c) 数据兼容性测试(共享)。
    1. 不同版本间的数据兼容
    如:当软件升级后可能定义了新的数据格式或文件格式,涉及到对原来格式的支持及更新,原来用户的记录在新的格式下依然可用,这里还要考虑转换过程中数据的完整性与正确性。
    注意:由此还可以引出向前兼容,向后兼容(向下兼容)的概念
    2. 不同软件间的数据兼容
    比如用winrar压缩的RAR文件,可以用好压软件进行解压,用好压软件压缩的ZIP文件也可以用winrar软件解压。

    d) 网络兼容
    测试软件在不同类型的网络下是否运行正常

        注:兼容的意义,提高产品质量,实现平台无关性。
    

    9) 安装测试
    针对那些用于在目标环境安装软件的安装程序所进行的测试。

    10) 替换性测试
    测试系统中软件组件能够被替换。

    11) 常规功能测试

    展开全文
  • 系统测试(学习笔记)

    千次阅读 2018-11-29 23:32:33
    系统测试是将经过集成测试后的软件,软件运行所依赖的硬件环境,外部设备,网络等其他元素结合起来,模拟软件产品实际运行的环境进行一系类的测试。 目的是验证系统是否满足软件规格需求说明书的定义,找出与需求...

    系统测试是将经过集成测试后的软件,软件运行所依赖的硬件环境,外部设备,网络等其他元素结合起来,模拟软件产品实际运行的环境进行一系类的测试。
    目的是验证系统是否满足软件规格需求说明书的定义,找出与需求规格不符或者与之矛盾的地方。

    简单系统测试例子:
    在这里插入图片描述

    展开全文
  • 一个系统测试的完整过程

    万次阅读 2018-11-23 19:36:18
    需求审查主要是我们对需求文档的理解,并熟透整个系统的每个功能和流程,对后期所有的测试建立思路,后续的工作基本依照需求进行操作,所以需求审查是一个很重要的一步。  对于初次进行需求审查,我采用我以前文章...

     

    转载自http://www.51testing.com/html/68/n-3724968.html

    一、需求审查方面

      首先我们从最开始接触的文档开始,那就是测需求文档;需求审查主要是我们对需求文档的理解,并熟透整个系统的每个功能和流程,对后期所有的测试建立思路,后续的工作基本依照需求进行操作,所以需求审查是一个很重要的一步。

      对于初次进行需求审查,我采用我以前文章的方向方法,看完每一个模块,就将这个模块的功能流程做成流程图。依次扩大,就将整个需求流程了解清楚,每次将流程图多浏览几次,差不多流程就这样熟透!

      1、 需求变更

      需求变更让我们测试人员,在其中吃透苦头,每次需求的变更导致我们前期的工作好多都需要重新开始(流程图,测试点的提取,测试用例)。导致后续工作难于开展或经常出现变更。

      2、 需求不明确

      对于青少年足球系统而言,需求全来自教育厅,里面同样有很多需求不明确,全过程尽量与教育厅的需求进行延伸,然后结合开发人员实际开发的效果,进行测试过程!

      二、提取测试需求的过程:

      测试点提取我们依据每个测试阶段的测试输入的文档(需求分析)结合前面的需求分析的审查,覆盖测试需求和隐藏的业务需求,我们后期的测试,全是建立在提取的测试点之上进行的,可以说测试点提取是后续工作进展必要必经路径。主要步骤就是,将每个模块可能存在的问题全部罗列出来,并对其最初可以输入或者流程路径的不同,将每个测试点细分,写成文档!

      测试点提取的方法:

      1、测试需求分析法

      2、功能点分析法

      3、业务流程分析法

      4、节点分析法

      5、顺序提取法

      6、流程判断法

      在测试点提取的过程中,测试人员主要存在的问题是,除了输入框,链接,按钮,文字显示等外,流程测试点是最难提取的(提取此处测试点需要了解整个流程),我们采取的方式是,多阅读需求书,并且按照我们的思路将流程图做出来,在提取测试点,最终交于指导老师处,一对一的修改,另一方面,就是对那些隐藏的测试点提取,对于初次做项目测试的我们,基本没有择,只能和指导老师一起寻找和编写!

      ●测试点提取不局限于任何一种特定的方法。

      ●很多时候测试点提取需求用到很多测试点提取方法

      ●测试点提取需要根据测试阶段,测试输入文档以及测试对象进行合理的方法选择。

      ●测试点提取完毕后不等于已经测试点提取完毕,还需要我们再次进行测试点的审查,以防有遗漏或者是泛泛的情况

      ●一份好的测试点提取文档不但能够覆盖所有业务分支和功能点,而且能够将相关隐藏需求体现出来

      三、测试用例设计

      测试用例是为特定的目的而设计的一组测试输入,执行条件和预期结果,以便测试某个程序路基和核实是否满足某个特定需求!

      在做功能测试时我们唯一能做的就是保证这个业务逻辑的正确性以及各个功能的尽可能的正确。业务和功能的正确性就要你自己去判断了,我只是简单写下输入、输出方面功能的测试。

      作为一位功能测试人员,主要的职能就是进行测试用例的设计上,并根据测试用例执行测试,通过全面的测试来验证产品的质量。因此测试用例提取,也从侧面反映了一个测试人员的测试思路的严密和发散性,要做好功能测试,测试用例的重要性无法忽视,现就对”四川省青少年校园足球信息化管理系统”设计测试用例的流程和思路进行总结:

      1)首先要对测试用例的组织结构进行划分

      在进行需求评审的时候,我们就应该根据需求对测试用例的结构进行分类,对于我们现在做的青少年足球系统相对较大型的管理系统,那么测试用例就可以根据功能模块来进行分类

      对测试用例的组织结构进行划分的思路,主要根据需求文档的测试切入点来进行参考。

      2)根据功能点细致地设计测试用例

      进行完需求评审后,我们将会根据需求文档及自己所负责的工作提交自己的设计文档来进行评审,可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例,如果是管理模块,首先可以将增删查改功能作为第一层功能点,然后再根据必填项非空判断、输入格式验证来作为第二层功能点;

      划分好功能点后,就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例,并且可以进行标注,这样对于后期的测试用例整理相当有帮助。

      3)执行完一轮测试之后,都要对测试用例进行补充和整理

      执行完一轮测试之后,都会对所测试的内容有进一步的了解,并且开发人员在实际开发过程中,会对某些功能的细节部分做出一些修改,测试人员应该根据变更和熟悉程度对之前编写的测试用例进行完善,主要是对测试步骤的修改和异常情况的补充,提高测试用例对需求的覆盖率,以便能发现更多的BUG。

    4)测试结束之后,根据测试用例整理出测试思路进行总结

      测试结束之后,测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期,在此期间,再看看被自己不断完善的测试用例,根据用例中的标注,可以将之前的测试思路很条理地整理出来,反思有哪些地方考虑不足,这就是经验积累。

      做好这些工作之后,在面对领导问你功能测试会测试到哪些功能,会测试哪些情况,执行一轮测试所需的大概时间问题时,测试人员就可以根据自己编写的测试用例进行流利回答。套用郭德刚的一句词:做科学的人都是很严谨的。大家作为都是有身份证的测试人员,只有工作做得细致严谨,自身的水平才能得到提高。

      A.测试用例该如何设计(总)

      在软件测试工作中,测试用例设计和编写时最重要的,测试用例是测试工作的指指导,是软件测试的必须遵循的原则,更是软件测试质量稳定的基本保障!

      1.     测试用例的测试

      个人认为,简单来说,就是方法+经验,即比较成熟的测试用例设计方法为指导,再加上设计人员个人的经验积累!

      设计入手:

      ü 菜单树

      ü 需求规格书,模块的详细规格图

      ü 软件的基本雏形

      ü 相关标准规格(软件规格书)

      设计步骤

      自我认为多看需求文档,多与需求设计人员沟通,至少保证覆盖需求规格说明书和菜单树的各项功能。

      ü 根据需求规格和菜单树得出基本功能测试用例;

      a)等价类划分法

      将输入范围进行划分,测试每个等价类的代表性数据等同于测试该类的其他数据。确定有效和无效等价类,一个等价类,如果有充足理由,可以再划分为多个更小一些的等价类。部分更小一些的等价类,就凭借个人经验和用户角度去考虑取舍。

      b)功能,路径混合分析法:即实现某功能,从进入功能实现——退出的各种路径的操作组合。

      进入:如果只有一种进入方式,则就没必要描述了,2种或者2种以上的进入方式,则需要分别描述。常见的进入方式:主菜单进入,链接进入!

      功能实现:通过主页导航界面进入并实现相关功能

      退出;为实现和已实现的功能退出

      ü  边界值测试用例(所谓边界条件,是指输入和输出等价类中那些恰好处于边界,或超出边界,或在边界一下的状态)

      a)输入值

      b)输出值

      c)边界状态

      在我们的足球管理系统中,对照片的缩放,就用到这一块!

      d)其他边界

      ü  容错测试用例(错误猜测主要是一项依赖于直觉的非正式的过程,其基本思想是列举出可可犯的错误或者错误易发生情况的清单)

      a)0或者空值

      b)负数

      c)删除源文件内容

      我们在赛事测试的过程中,设计上传参赛表明表,在测试过程中,我将部分信息删除,进行测试!

      ü  并行测试用例(即多个功能同时进行,比如:在青少年足球系统中,我们需要在发布赛事以后,同时进入公示,并且下级报名依然不能给报名)

      a)并行测试与交叉测试的区别

      1.交叉测试是当一个功能运行时,另一功能打断了原来事件的执行,属于被动;并行测试不会中断原有程序,是一个主动发起多功能。

      2.交叉测试发送在一瞬间,并行测试营同时运行一段时间。

      ü串行测试用例(主要是单个模块内一串深层次路径的测试,采用自顶而下的方法,从程序的顶部一直访问至程序顶部)

      比如:像我们青少年足球系统,我从首页进入赛事发布成功进入公示页面,然后再往上级返回到网页首页!

      ü  交叉测试用例(交叉测试,即是中断测试,当一个事件执行时,另一事件中断原有事件的执行。)

      a)两不写

      1.操作时间过短,如:我们按下首页的赛事发布管理按钮

      2.使用概论低的界面,如:我们青少年足球系统中,下面的脚码出的超链接,我们很少点击

      b)两必写

      1.操作时间长,如:在我们的青少年足球系统中,登陆账号后,30分钟对网页没有做任何处理,是否有报警触发。

      ü 极限测试用例(压力测试,就是个软件施加一定的压力,从而找出中的错误)

      这一块我在整个系统使用的很少,还处于学习阶段!

      a)测试用例的检查

      1.检查,写完后自己在重头到尾的检查一遍,然后再拿给我们的小伙伴一起查看

      2.试用,测试用例写完后应该有一个使用期,在我们使用的过程中发现漏写或者不合适的地方,应及时增加或者更改。

      b)“期望结果”与”测试方法”混淆,”期望结果”中出现原本该书写在”测试方法”的步奏

    b)“期望结果”与”测试方法”混淆,”期望结果”中出现原本该书写在”测试方法”的步奏

      c) 但是上面是错误的,应该按照下面方法进行设计编写

      B.再次总结测试用例设计的要点,注意事项

      测试用例设计是个不断思考的过程,首先要搞清楚自己所测试的软件系统的需求和功能,以及所有能变化的因素,将这些功能点列成一个设计框架,在分别细化各个功能点的测试方法和期望结果,细化过程中,通过等价类划分,正交矩阵等方法来详细各个测试点,保证覆盖的充分性,同时站在用户的角度,考虑用户常用和不常用的操作路径,依次来取舍测试要点,最后考虑设计步奏中的七种测试类型是否需要添加相应用例。

      测试用例设计也是个不断优化的过程,平时发现的bug,总结经验,积累更多的经验,测试用例也会更全面,软件品质也能得到更好的保障!

      四、测试报告缺陷的提交和编写

      A.强调这一块的重要性!

      下面就是我们在测试过程的满足的条件:

      精简的:缺陷的描述应该是清晰而简要的。

      正确的:提交的问题确实是一个缺陷。

      中立的:对缺陷及其特征进行实事求是的描述,避免夸张、幽默、讽刺的态度,避免在测试缺陷报告中带有个人感情色彩,因为这种感情色彩可能会影响团队之间的合作和沟通。

      准确的:准确而明白地描述问题,不仅对做了什么进行描述,而应该对发生或者发现了什么进行描述。

      隔离:尽量寻找简短的步骤复现缺陷,即将缺陷进行隔离。

      推广:确定系统其他部分是否可能也存在同样的问题,以及使用不同的数据时是否也会出现这种问题等。

      复现:确定系统是否可以复现这个问题,以及复现该缺陷的步骤。对于能够复现的问题,应该提供简单的步骤和输入

      证据:如同写测试用例需要测试条件一样,在缺陷报告中,需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距,以及提供测试的依据。

      评审:在提交缺陷报告之前,最好有一个有经验的测试人员阅读一遍。  

      缺陷报告编写的过程:

      B.缺陷报告的提交

      缺陷报告的提交,在测试过程中,我们采用了两种方式

      1、提交给我们的指导老师!接下来的工作就是指导老师与相关开发人员沟通(这种提交的方式是我们前期的提交方式)

      2、便是跳过我们的指导老师,直接将问题和呈现过程交于开发人员,并且让其快速修复!(这种方式比较快捷,能够快速的解决问题和加快开发的过程)

      C.如何编写好的(易读)的缺陷报告

      1、标题(简单明显,不需要含有修饰语)

      2、执行动作(步骤)

      3、预期与实际结果

      D.缺陷报告的返回,检验是否修改!

      此环节,主要在我们提交缺陷报告后,开发人员将缺陷报告再次返回与我们测试人员,测试人员主要是检查缺陷报告上面的问题是否已经修复,一遍我们能够提交缺陷报告和了解缺陷的修复情况!

      E.并描述与开发人员的交互过程

      在我们与开放人员交互的时候:交互过程中存在的问题,当部分子功能模块做出来的时候,我们测试人员开始测试子功能模块的时候,测出问题的时候,我们便直接与开发人员提出此问题,可能是刚开始合作,还有他们对自己写的代码还有强烈的自信感!对我们的问题采用避让的方式,在我们继续的讲述和演示功能的过程,才得以让他们信服。现在这些问题都不存在,都能够在规定的时间完成每个功能的修复!

      F.过程中的问题如何解决

      输入框和文字显示在此不做详细说明,我在项目中主要是承担逻辑很强的赛事模块,这块设计的逻辑和流程交互挺多,除此测试这块的时候很难把握流程问题,整个项目在随时改变和需求分析存在一定的差异,所以造成这块测试逻辑流程比较难以实施,为了更好的完成测试,我采用了,进行测试之前,然相关模块开发的人员演示一下流程,让我更好的进程下一步测试!

      G.最后对测试缺陷报告的综述(好方法,注意事项,怎样才能够做好测试缺陷报告)

      测试执行过程注意事项:

      注意前提条件和特殊说明

      测试用例要全部执行

      不要忽视任何偶然现象

      加强测试过程的记录

      详细预期与实际的不一致等

     

    性能测试:

    https://blog.csdn.net/zoulonglong/article/details/78696428

    展开全文
  • 文章目录系统测试概述功能测试性能测试负载测试压力测试性能测试、压力测试、负载测试的关系兼容性测试安全测试健壮性测试配置测试可用性测试文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为...

    系统测试概述

    • 系统测试的定义
      • 将已经集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行(使用)环境下, - 对计算机系统进行一系列测试活动。
    • 根本任务
      • 证明被测系统的功能和结构的稳定性;还要有一些非功能测试:性能测试、压力测试、可靠性测试等等。
    • 目的
      • 确保软件产品能够被用户或操作者接受。
    • 系统测试属于黑盒测试范畴,不再对软件的源代码进行分析和测试。
    • 系统测试的组织
      • 系统测试主要是由质量部门的测试工程师来主导工作。
        • 测试组组长:组织测试;
        • 测试分析员:负责设计和实现测试脚本和测试用例;
        • 测试者:负责执行测试脚本中记录的测试用例。
      • 系统测试员和用户
        • 相似的地方
          • 都是使用软件,一般不接触软件的代码
          • 都是假设软件应该正确实现说明书的功能
        • 不同的地方
          • 使用软件的目的
          • 对待错误
    • 系统测试的内容
      • 功能特性的测试:功能测试、用户界面测试、安装/卸载测试、可使用性测试。
      • 非功能特性的测试:性能测试、负载测试、压力测试、疲劳测试、安全测试、恢复测试、兼容性测试、可靠性测试、强度测试、容量测试、配置测试。

    功能测试

    功能测试(Functional Test)是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。

    • 目标
      • 检验产品功能是否正确实现
    • 内容
      • 正常功能、异常功能、边界测试、界面测试、接口测试、安全测试、错误处理测试等。
    • 依据
      • 需求规格说明书
    • 方法
      • 黑盒测试
        在这里插入图片描述

    性能测试

    性能测试(Performance Testing)通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

    • 目标
      • 对产品的性能进行测试,检验是否达标、是否能够保持。
    • 工具
      • 在需要大访问量时候尤其需要使用工具。
      • 并发性能测试工具 (load—负载)
        • LoadRunner、 QALoad、 SilkPerformer、 WebLoad
    • 用户视角的软件性能
      • 从用户角度来说,软件性能就是软件对用户操作的响应时间。
    • 系统管理员视角的软件性能
      • 系统的响应时间;
      • 系统运行时服务器的状态,如CPU利用情况、内存使用情况等;
      • 系统是否能够实现扩展;
      • 系统支持多少用户访问;
      • 系统性能可能的瓶颈在哪里;
      • 系统是否支持7*24小时的业务访问。
    • 软件性能指标
      • 并发用户
        • 一给定时间内,某个时刻与服务器同时进行会话操作的用户数。
      • 响应时间
        • 客户端发出请求到得到服务器返回结果的整个过程所经历的时间。
      • 吞吐量
        • 单位时间内系统处理的客户请求的数量
        • 一般来说,吞吐量用请求数/秒或页面数/秒来衡量。
        • 从业务的角度,吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。
        • 从网络的角度来说,也可以用字节数/天等单位来考察网络流量。
      • 资源利用率
        • 指系统资源的使用程度,比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。
    • 软件性能要素
      • 环境要素
        • 软件、硬件、网络
      • 业务要素
        • 用户数、执行功能、数据量
      • 在使用性能指标描述软件的性能特征时,应该给出明确的软件性能要素,否则,所给出的性能指标无法参考。
    • 性能测试用例的设计:主要是通过改变模拟的业务因素来测试软件的性能。
      • 并发用户数
        • 精算法
          在这里插入图片描述
        • 估算法
          在这里插入图片描述
        • 经验值
          • 对于一些系统,可以通过同类软件系统的用户数据来估算,这种估算可以通过类似系统的日志分析和问卷调查来进行。
      • 吞吐量
      • 基于业务的设计

    负载测试

    • 定义
      • 数据在超负荷环境下运行,测试软件系统是否能够承担。这种超负荷主要指多并发用户。
    • 方法
      • 人为生成大数据量,并利用工具模拟频繁并发访问
    • 工具
      • 一般需要使用自动化工具
    • 考察指标
      • 响应时间、交易容量、资源使用率等

    压力测试

    • 定义
      • 指系统不断施加越来越大的负载(并发,循环操作,多用户,网络流量)的测试。
    • 目标
      • 通过确定一个系统的瓶颈或者不能接收的性能点,来确定系统能提供的最大服务级别的测试。

    性能测试、压力测试、负载测试的关系

    • 性能测试是正常情况下的性能指标;
    • 压力测试是测试系统的瓶颈所在;
    • 负载测试是指系统重负荷性能指标;
    • 性能测试、压力测试、负载测试在广义上讲都是性能测试的内容,建议将三种测试结合起来并行进行。

    兼容性测试

    • 定义
      • 测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。
    • 目的
      • 检验被测软件对其他应用软件或者其他系统的兼容性。

    安全测试

    • 定义
      • 安全测试检测系统对非法入侵的防范能力。
    • 应用程序级别的安全性测试
    • 数据库安全性测试
    • 系统级别的安全性测试

    健壮性测试

    • 定义
      • 又称为容错测试。主要检查系统容错能力。当系统出错时,能否在指定的时间间隔内修正错误并重启系统。
    • 方法
      • 容错测试首先要通过各种手段让软件系统强制发生故障,然后验证系统能否快速恢复。

    配置测试

    • 定义
      • 配置测试将验证软件与其所依赖硬件环境的依赖程度。
    • 测试中的硬件环境指进行测试所必需的服务器、客户端、网络连接设备,以及打印机、扫描仪等辅助硬件设备所构成的环境。
    • 所有软件都需向用户说明其运行的硬件环境,对于多层结构的软件系统来说,需要分别说明其服务器、客户端以及网络所需的环境。

    可用性测试

    可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作,- - 同时观察员和开发人员在一旁观察,聆听,做记录。

    • 系统中是否存在繁琐的功能以及指令;
    • 安装过程是否复杂;
    • 错误信息提示内容是否详细;
    • GUI接口是否标准;
    • 登录是否方便;
    • 需要用户记住内容的多少;
    • 帮助文本是否详细;

    文档测试

    • 定义
      • 文档测试是对系统提交给文档进行验证,它要求检查系统的文档是否齐全。
    • 文档的种类
      • 包括联机帮助文档或用户手册,指南和向导,
      • 安装、设置指南,示例及模板,错误提示信息,
      • 用于演示的图像和声音,
      • 授权/注册登记表及用户许可协议,
      • 软件的包装、广告宣传材料等。
    展开全文
  • 系统测试流程介绍

    2019-03-18 14:07:07
    测试计划设计阶段:(测试经理和主管进行编写)简历中一般不要书写。 测试资源需求: 操作系统:Linux Windows Unix Mac。 数据库:Oracle MySQL SQLserver DB2。 web服务器:Tomcat weblogic。 硬件资源:...
  • 系统测试总结报告模板

    万次阅读 2019-02-11 14:38:28
    系统测试总结报告 1 引言 1.1 编写目的 编写该测试总结报告主要有以下几个目的 1. 通过对测试结果的分析,得到对软件质量的评价 2. 分析测试的过程,产品,资源,信息,为以后制定测试计划提供参考 3....
  • 如何完成系统测试

    千次阅读 2018-09-03 11:02:12
    软件系统测试意味着将软件系统或者应用程序做为一个整体进行测试。应用程序的系统测试从整体上检测软件大致的业务,操作以及最终用户需求的一致性。系统测试被归类为黑盒测试。 这就是为什么内部设计,架构或者代码...
  • 系统压力测试(一)

    万次阅读 2018-09-17 09:47:45
    《目录》 -------->认知,了解压测的一些参数,了解什么是...了解怎么给出压测人员出一份压测指标,计算自己系统的合理吞吐量 -------->怎么看压测报告,一份报告都有哪些重点 一、认知 首先明确...
  • 系统测试方案

    千次阅读 2019-04-10 17:19:01
    测试计划是从管理角度规划和控制测试活动。... 系统测试方案的核心内容: 系统测试策略选取 系统测试子项划分 测试策略(测试策略是如何用尽量少的资源来尽量好的完成测试): 单元测试策略(对应多...
  • 系统测试和集成测试的区别

    万次阅读 2009-09-15 16:50:00
    计划和用例编制的先后顺序 从V模型来讲,在需求阶段就要制定系统测试计划和用例,HLD的时候做集成测试计划和用例,有些公司的具体实践不一样,但是顺 序肯定是先做系统测试计划用例,再做集成 2.用例的粒度 系统测试...
  • 软件测试一般分为4个阶段:单元测试、集成测试、系统测试、验收测试。 一、单元测试  单元测试是对软件中的最小可验证单元进行检查和验证。比如对Java中的类和方法的测试。 测试原则:  1、尽可能保证测试...
  • 单元测试时针对每个单元的测试,是
  • 负载测试、压力测试和性能测试的异同

    万次阅读 多人点赞 2008-12-15 15:29:00
    负载测试(Load testing)、压力测试(Stress Test,应称为强度测试)和性能测试,这三个概念常常引起混淆,难以区分,从而造成不正确的理解和错误的使用。之前,也有不少讨论,比较有名的,应归为Grig Gheorghius的...
  • 单元测试  1、什么是单元测试? 单元测试是对程序中的单个子程序、子程序或过程进行测试,也就是说一开始的时候不是对整个程序进行测试,而是先将注意力集中构成整个程序的各个小单元的测试上。单元测试是编写一小...
  • 软件测试的四个阶段

    万次阅读 2016-08-22 21:46:55
    软件测试一般分为4个阶段:单元测试、集成测试、系统测试、验收测试。一、单元测试 单元测试是对软件中的最小可验证单元进行检查和验证。比如对Java中的类和方法的测试。测试原则: 1、尽可能保证测试用例相互独立...
  • 压力测试和负载测试的区别

    万次阅读 2019-01-10 10:29:57
    模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等,以检验系统的行为和特性,...
  • 确认测试和系统测试

    万次阅读 2012-11-04 10:28:13
    今天向大家介绍的是确认测试和系统测试。 首先来看确认测试,确认测试又称为有效性测试,他的任务是验证软件的功能和性能,以及验证其他是否与用户需求一致。那么什么时候开始进入确认测试呢?集成测试完成以后,...
  • 从系统上来说,软件测试的方法主要包括单元测试,集成测试,系统测试,确认测试。(重点说单元测试和集成测试) 单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否...
  • 系统测试的策略

    千次阅读 2017-11-19 11:17:19
    1.系统测试的环境是软件真实运行环境的最逼真的模拟 2.系统测试的对象是整个软件系统 确认测试一般包括有效性测试和软件配置复查 系统测试的策略: 是各类测试中最全面深入的一种,系统测试阶段要完成软件的各个...
  • 于开发人员来说,往往对各种测试方法感到疑惑。特别是在整合代码的时候,我们就能深刻感觉受到测试的重要性。很多开发人员只注重写代码,轻视测试的重要性。总是代码一写完提交然后就交给测试测试了,没多久测试组...
1 2 3 4 5 ... 20
收藏数 2,351,661
精华内容 940,664
关键字:

系统测试