zoukankan      html  css  js  c++  java
  • 软件测试中的定义汇总

    一、软件可靠性

    1. 软件可靠性 (software reliability )是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件,或统称为软件运行时的外部输入条件;规定的时间区间是指软件的实际运行时间区间;规定功能是指为提供给定的服务,软件产品所必须具备的功能。软件可靠性不但与软件存在的缺陷和(或)差错有关,而且与系统输入和系统使用有关。软件可靠性的概率度量称软件可靠度

    2. 定义:长期运行的稳定性(鲁棒性) 
               输出数据的正确性 
               异常情况的可记录性

    3.影响软件可靠性的因素

    1)  需求分析定义错误 
        由于分析失误,从开始就走上了错误的路线,向着错误的目标前进,以后实现中的错误在所难免。

    2) 设计质量 
        设计水平的高低与设计者的水平有着直接的联系,但可以通过人文方法提高设计水平,但不仅限于此。影响设计质量因素主要有: 对需求的理解程度、对软件环境的理解程度、设计人员的设计水平等。

    3) 编码质量 
        编码的过程实际上是影响软件可靠性的一个关键因素,影响这个过程的因素有很多,如:程序语言的选择、程序员对语言特性的掌握以及编码水平、编码质量检查与评审制度及执行情况、代码的复用率

    4) 无效的测试 
        如果在进行单元测试或者集成测试时,如果测试用例设计不合理,测试不完整,容易使测试失效,使得软件在某些未经测试的情况下故障。

    5) 文档错误 
        如果文档(包括正式的设计文档以及程序的注释)不完整、不一致,会导致阅读者对设计或代码理解产生偏差,从而有可能导致下一步的软件错误。

    4.如何提高软件可靠性

    提高软件可靠性可以从多个角度入手,主要分为几类:改进制度制定规范、软件重用、提高员工素质、加强测试、及时有效的跟踪

    1)  改进制度制定规范 
        通过公司制度对开发方法的选择、分析及设计文档的编写、编码规范、代码评审制度等对软件开发的各个过程进行控制,从而提高软件可靠性。

    2) 软件重用 
        对通用模块进行抽象、封装,不断积累团队自己的开发库,不仅可以为以后的开发减少开发任务,缩短开发周期,而且这些通用模块,在不断的重用中,其存在的BUG会不断被发现,然后被不断改进,随着这些通用模块的持续改进,使用这些模块构建的软件的可行性也在不断提高。

    3) 提高员工素质 
        所有的软件都是“人”开发的,人才是提高软件可靠性的最关键的因素,通过对员工进行必要的公司制度、开发方法、软件相关知识、编程技巧等方面的培训,提高员工的单兵作战能力,再加上良好的团队管理模式,将会明显提高软件的可行性。

    4) 加强测试 
        任何设计都不是完美的,任何程序都不可能没有BUG,良好的测试是发现这些问题的有效方法,通过加强对软件的测试,尽可能地解决软件中存在的问题,从而提高软件的可靠性。加强测试,并不是简单的测试得次数越多越好,也需要一些技巧,如程序员本不人写自己程序的测试代码,认真设计测试用例并对测试用例进行不断的跟踪与改进。

    5) 及时有效的跟踪 
        所有的软件,经过再严密的测试都不可能没有BUG,都不可能百分百地可靠,通过用户反馈的BUG进行对症下药修改BUG是最有效地改进软件可靠性的方法之一,每修改一次就会提高一些可靠性。但它是有效的,但不是效率最高的,其修改效率反而是最低的,但这在产品发布以后是持续提高软件质量的有效方法。

    二、鲁棒性

    鲁棒是Robust的音译,也就是健壮和强壮的意思。它是在异常和危险情况下系统生存的关键。比如说,计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下,能否不死机、不崩溃,就是该软件的鲁棒性。所谓“鲁棒性”,是指控制系统在一定(结构,大小)的参数摄动下,维持其它某些性能的特性。根据对性能的不同定义,可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。

    三、鲁棒性与稳定性的区别

    所谓“鲁棒性”,是指控制系统在一定(结构,大小)的参数摄动下,维持其它某些性能的特性

    所谓“稳定性”,是指控制系统在使它偏离平衡状态的扰动作用消失后,返回原来平衡状态的能力。

    稳定性是指系统受到瞬时扰动,扰动消失后系统回到原来状态的能力,而鲁棒性是指系统受到持续扰动能保持原来状态的能力。

    四、软件安全性

    软件安全(Software Security)就是使软件在受到恶意攻击的情形下依然能够继续正确运行及确保软件被在授权范围内合法使用的思想。

    软件安全性主要考虑的是非法入侵和入侵后得到的回报之间的平衡,即非法入侵代价与被保护代价。例如支付宝,如果有人进行非法入侵去获得他人的账单或者查看账户钱财,但他花费的代价

    很大,跟获得的回报相差太大。这样就不需要对用户的账户钱财上安全性测试花费太多了。

    软件的安全可靠性是衡量软件好坏的一个重要标准,安全性指与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性,可靠性指与在规定的一段时间和条件下,软件能维持其性能水平能力有关的一组属性。具体我们可以从以下几个方面来判断:

    1.用户权限限制。软件是否按功能模块划分用户权限,权限划分是否合理,考察超级用户对各个用户的权限管理是否合理,包括修改用户的登录资料等。

    2.用户和密码封闭性。软件对用户名和密码有无校验,有无保护措施,尤其对密码有无屏蔽功能。

    3.系统对用户错误登录的次数限制。软件对用户错误登录有无次数限制,一般做法是连续三次登录失败就退出系统。

    4.留痕功能。软件是否提供操作日志,比如某用户登录的时间,查询、修改或删除的动作以及离开的时间等。

    5.屏蔽用户操作错误。考察对用户常见的误操作的提示和屏蔽情况,例如可否有效避免日期的录入错误或写入无效的日期。

    6.错误提示的准确性。当用户操作错误或软件发生错误时,能否有准确清晰的提示,使用户知道造成错误的原因。例如当用户未输入完有效信息时存盘,系统应当给出关于未输入项的提示。

    7.错误是否导致系统异常退出。考察软件运行的稳定性,当软件发生一般错误或严重错误时,软件是否会自动退出。

    8.数据备份与恢复手段。主要针对有数据存储需要的软件,有的软件依靠数据库操作系统本身的备份与恢复机制,这需要用户具备一定的操作知识;好的软件会提供备份与恢复的操作,不需要用户直接对数据库系统进行操作。

    9.输入数据有效性检查。当用户输入的数据有错时,软件应能判断数据的有效性,避免无效数据的生成。

    10.异常情况的影响。在程序运行过程中进行掉电等试验,考查数据和系统的受影响程度;若受损,是否提供补救工具,补救的情况如何。

    11.网络故障对系统的影响。当网络中断连接时,是否会造成数据的丢失。

    以上一些方面是中国软件评测中心在大量的软件测试实践中提炼出来的比较有共性的项目,对于不同类型的软件,在安全可靠性方面还有更多的评测指标,并且依据实际情况侧重点有所不同。

     五、验收测试

    验收测试是在软件产品完成了功能测试和系统测试之后,产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,也成为交付测试,通过了验收测试产品就会进入发布阶段。主要包括易用性测试,兼容性测试、安装测试,文档测试。验收测试是针对需求分析。

    验收测试的作用是验证是否达到了用户需求规格说明书中的要求 ,测试试图尽可能地发现软件中存留的缺陷,从而为软件进一步改善提供帮助。并保证系统或软件产品最终被用户接受。

    1. 测试步骤

    (1)建立测试计划

    (2)建立测试环境

    (3)准备测试数据

    (4)分析测试结果,验收测试结果经常会有4中情况

      #测试项目通过验收

      #测试项目没有通过验收,但问题不大,可以通过双方沟通或变通的解决问题

      #测试项目没有通过验收,并且不存在变通的方法,需要很大的修改

      #测试项目无法评估或者无法给出完整的的评估结果,此时必须找到其深层次的原因,如果是该测试项目没有说明清楚,应该修改验收测试计划

    2.通过标准

      #完全执行了验收测试计划中的每个测试用例

      #在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留到下一版本中修改

      #完成软件验收测试报告

    3.注意事项

      #必须编写正式的、单独的验收测试计划

      #验收测试必须在实际运行环境中或尽可能模拟实际的环境中进行

      #验收测试一般需要有用户和测试部门共同完成

    4.用户界面要求有7要素:符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性。

     

    软件测试中遇到的问题

    1.软件项目需求分析不完整或没有需求分析?

    2.交付测试时,离项目完成时间很短?

    3.开始测试时,项目已经完成?

    这三个问应该是软件测试中非常棘手的问题:

    三个问题连在一起是最难的

    1. 如果需求分析不完整需要首先跟开发人员讨论确定测试的范围。

    2. 可以根据经验不需要需求文档,测试项目容易出错的定法或者风险大的地方

    3. 可能的话,可以与用户交流协商项目交付时间

    4. 时间紧可以设计主要的测试用例。

    5.时间来不及,测试用例不用太细,

    6. 如果测试时,项目已经完成,优势是可以看到项目的真实运行情况不用再假设,这样可以直接进行主要功能测试(根据需求开发文档)。

  • 相关阅读:
    Nim or not Nim? hdu3032 SG值打表找规律
    Maximum 贪心
    The Super Powers
    LCM Cardinality 暴力
    Longge's problem poj2480 欧拉函数,gcd
    GCD hdu2588
    Perfect Pth Powers poj1730
    6656 Watching the Kangaroo
    yield 小用
    wpf DropDownButton 源码
  • 原文地址:https://www.cnblogs.com/ya-qiang/p/9001016.html
Copyright © 2011-2022 走看看