51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

12
返回列表 发新帖
楼主: lsekfe
打印 上一主题 下一主题

当前问题;如何提高软件的可测试性?(2012.3.18)(获奖名单已公布)

[复制链接]

该用户从未签到

21#
发表于 2013-3-1 16:23:33 | 只看该作者
看你站在一个什么角度去看待这个问题
对应于单元测试的话,提高可测性可以从使用合理的程序架构入手。使用先进的开发框架可以提高单元测试的可测性
对应于集成测试的话,提高可测性可以从冒烟测试开始。一下子就着火了,就打回去重新开发。
等等。。。。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    22#
    发表于 2013-3-3 11:20:11 | 只看该作者

        软件的可测试性是指在一定的时间和成本前提下,进行测试设计、测试执行以此来发现软件的问题,以及发现故障并隔离、定位其故障的能力特性。简单的说,软件的可测试性就是一个计算机程序能够被测试的容易程度。
        一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件,而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。


    特征
      1.可操作性:“运行得越好,被测试的效率越高。”
        1)系统的错误很少;
        2)没有阻碍测试执行的错误;
        3)产品在功能阶段的演化(允许同时的开发和测试)。
       
      2.可观察性:“你所看见的就是你所测试的。”
        1)每个输入有唯一的输出;
        2)系统状态和变量可见,或在运行中可查询;
        3)过去的系统状态和变量可见,或在运行中可查询(例如:事务日志);
        4)所有影响输出的因素都可见;
        5)容易识别错误输出;
        6)通过自测机制自动侦测内部错误;
        7)自动报告内部错误;
        8)可获取源代码。


      3.可控制性:“对软件的控制越好,测试越能够被自动执行与优化。”
        1)所有可能的输出都产生于某种输入组合;
        2)通过某种输入组合,所有的代码都可能被执行;
        3)测试工程师可直接控制软件和硬件的状态及变量;
        4)输入和输出格式保持一致且有结构;
        5)能够便利地对测试进行说明、自动化和再生;
        6)接口和模块易控制;
        7)业务流程和场景易控制。


      4.可分解性:“通过控制测试范围,能够更快地分解问题,执行更灵巧的再测试。”
        1)软件系统由独立模块构成;
        2)能够独立测试各软件模块;
        3)业务流程和场景易分解。


      5.简单性:“需要测试的内容越少,测试的速度越快。”
        1)功能简单性(例如:特性集是满足需求所需的最小集合);
        2)结构简单性(例如:将体系结构模块化以限制错误的繁殖);
        3)代码简单性(例如:采用代码标准为检查和维护提供方便)。


      6.稳定性:“改变越少,对测试的破坏越小。”
        1)软件的变化是不经常的;
        2)软件的变化是可控制的;
        3)软件的变化不影响已有的测试;
        4)软件失效后能得到良好恢复和隔离。


      7.易理解性:“得到的信息越多,进行的测试越灵巧。”
        1)设计能够被很好地理解并遵循行业规范;
        2)内部、外部和共享构件之间的依赖性能够被很好地理解;
        3)设计的改变被通知;
        4)可随时获取技术文档;
        5)技术文档组织合理;
        6)技术文档明确详细;
        7)技术文档精确性稳定;
        8)相关环境配置说明与操作指导。


    要提高软件的可测试性就需要从以上这7个方面去提升,以达到提高的目的

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    23#
    发表于 2013-3-6 10:13:33 | 只看该作者
    软件的可测试性主要取决于设计开发阶段而非测试阶段
    提高可测试性的方法:
    1.控制需求变更,尽量保证软件处于稳定或变化可控制,可有效的避免重复测试;
    2.软件设计时加入可测试性相关设计,如:没有阻碍连续执行的问题,开发阶段中进行部分测试活动,软件的众多模块可独立测试,输入输出结果可见且每个输入有唯一输出等;
    3.规范的设计文档编写,有助于设计的理解。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-11-25 15:40
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    24#
    发表于 2013-3-7 16:36:22 | 只看该作者
    如何提高软件的可测试性?

    由于企业及用户对软件质量的重视程度越来越高,使得测试在软件开发中的地位越来越重要。测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。但是在测试的实施过程中,由于软件设计本身存在的可测性性太差的问题。导致了测试的难度相当大,甚至出现了无法测试的情形。下面结合日常测试工作中遇到的问题简要的谈一下如何提高软件可测试性的问题。通常情形下,测试难以进行由以下几方面原因导致:     

    1、被测试对象需要传入的参数过多。     
    2、被测对象过多的调用了其他类或方法。     
    3、内部的逻辑判断过多(内部牵扯复杂)。     
    4、需要构造的作为参数的对象本省过于复杂。     
    5、和界面显示部分交互过于平凡(耦合性太强)。
       
    针对以上问题,建议在软件设计过程中遵循以下原则:     
    1、首先最重要的是坚持测试驱动设计(测试先于设计)的方法。     
    优先编写测试代码。这是标准的 XP 方法。这不是说您应该一次性编写全部测试代码后,再一次性全部实现。先写验收测试,再写单元测试,编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。     

    2、尽量做到每个操作对应一个方法,使方法小型化。   
    使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则,在测试这些方法时您将不得不构造额外参数。如果参数很大,那么将很快导致代码膨胀。更糟的是,它会诱使您编写比在其它情况下更少的测试。     

    3、对于显示部分(GUI),尽量做到显示与控制分离。     
    把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样,对 GUI 测试者来说,通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。     

    4、对于可能要作为参数的类,可以做一个接口,用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现改接口形成一个空类作为参数传入。特别是当该类还没有完全实现时,这种方法最为行之有效。

    5、最后,如果自己不负责测试工作,作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码?我如何才能以可测试方式编写这些代码”。

    答案整理自互联网,仅大家参考
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-11-25 15:40
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    25#
    发表于 2013-3-7 16:37:22 | 只看该作者
    如何提高软件的可测试性?

    由于企业及用户对软件质量的重视程度越来越高,使得测试在软件开发中的地位越来越重要。测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。但是在测试的实施过程中,由于软件设计本身存在的可测性性太差的问题。导致了测试的难度相当大,甚至出现了无法测试的情形。下面结合日常测试工作中遇到的问题简要的谈一下如何提高软件可测试性的问题。通常情形下,测试难以进行由以下几方面原因导致:     

    1、被测试对象需要传入的参数过多。     
    2、被测对象过多的调用了其他类或方法。     
    3、内部的逻辑判断过多(内部牵扯复杂)。     
    4、需要构造的作为参数的对象本省过于复杂。     
    5、和界面显示部分交互过于平凡(耦合性太强)。

    针对以上问题,建议在软件设计过程中遵循以下原则:     
    1、首先最重要的是坚持测试驱动设计(测试先于设计)的方法。     
    优先编写测试代码。这是标准的 XP 方法。这不是说您应该一次性编写全部测试代码后,再一次性全部实现。先写验收测试,再写单元测试,编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。     

    2、尽量做到每个操作对应一个方法,使方法小型化。   
    使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则,在测试这些方法时您将不得不构造额外参数。如果参数很大,那么将很快导致代码膨胀。更糟的是,它会诱使您编写比在其它情况下更少的测试。     

    3、对于显示部分(GUI),尽量做到显示与控制分离。     
    把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样,对 GUI 测试者来说,通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。     

    4、对于可能要作为参数的类,可以做一个接口,用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现改接口形成一个空类作为参数传入。特别是当该类还没有完全实现时,这种方法最为行之有效。

    5、最后,如果自己不负责测试工作,作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码?我如何才能以可测试方式编写这些代码”。

    答案整理自互联网,供大家参考
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2013-3-7 16:59:05 | 只看该作者
    可测试性主要是指被测实体具有如下特征:可控制性、可分解性、稳定性、易理解性、可观察性,该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试。
      1、可控制性设计需求
      1)全局变量的可控制性设计需求
      在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。
      2)接口的可控制性设计需求
      各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接,比如构造测试环境模拟接口对接,这里所指的开放接口主要是指相对于被测系统,即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
      3)模块的可控制性设计需求
      对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能,在测试运行期间模块异常时能够将其隔离而不影响测试。
      4)业务流程的可控制性设计需求
      在测试环境满足的情况下能够控制任一单独业务流程,各业务流程具有流通性。
      5)场景的可测性设计需求
      将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。
      2、可分解性设计需求
      1)业务流程的可分解性设计需求
      对于复杂的业务流程需合理设定分解点,在测试时能够对其进行分解。
      2)场景的可测性设计需求
      对于复杂的场景需合理设定分解点,在测试时能够对其进行分解。
      3、稳定性设计需求
      测试模块发布合理,不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。
      4、易理解性设计需求
      1)设计文档的易理解性
      设计参考标准
      内容描述主次要分清
      依赖关系描述明确
      2)接口的易理解性
      接口功能明确
      参数有意义
      3)业务的易理解性
      4)场景的易理解性
      5、可观察性设计需求
      1)业务执行状态和过程可观察性设计需求
      2)异常情况可观察性设计需求
      6、测试驱动和桩的设置
      为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
      7、适合增量式开发的可测性设计
      在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
      8、可查询设计
      对系统级别的全局变量或者状态设置查询接口;
      某一业务或场景调用接口设置接口路径查询。
      9、自愈合功能
      在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。
      10、输出结果
      对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等,不管是以什么方式表现,都要有依可寻,在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。

      11、提供统一的操作执行面板
      操作面板元素主要由输入和输出元素组成,如所执行的操作和对应的输出,但由于被测系统可能是一个比较复杂的系统,由多个可以独立的模块组成,涉及到的操作和输出比较多,各操作之间的关联也比较复杂。在设计时统一的做一个操作面板,该操作面板成为一个可以执行整个被测系统操作的独立模块,一种是以命令的形式执行操作,直接以printf语句的形式输出查看,另一种是以GUI的形式,输入(执行的操作)输出均在界面上执行和体现,这样比较直观。
      特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数,给出一系列可以分析的数据,该场景可以以执行过程分阶段监控,将监控范围内的数据输出以供测试人员分析。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2022-12-8 17:51
  • 签到天数: 256 天

    连续签到: 1 天

    [LV.8]测试军长

    27#
    发表于 2013-3-10 23:05:37 | 只看该作者
    1、环境配置问题:介入测试时,需保证测试环境正常,否则会减低测试效率,及反馈一些无效的bug;
    2、项目本身的质量:项目在送测前,开发是否对各模块集成后,进行了内测;
    3、版本控制性问题:每次更新的代码包括已修复的bug,开发需控制好版本,不要不断地引入新的bug;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
    发表于 2013-3-13 11:08:43 | 只看该作者
    软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。

       1、保证软件的可操作性。即在开展测试之前,确保开发提交的程序能够正常的运行起来,程序运行的越好,测试的效率也越高

       2、 对软件测试的过程控制越好,测试越能够被自动执行与优化;

       3 、分解性问题。通过控制测试范围,能够更好地分解问题,这能更好的定位故障,使测试更灵巧;

       4、增加项目成员的互动。不同的人员对相同的需求有不同的理解,为了减少大家对相同需求理解的偏差,应尽早介入项目参与需求讨论,参与需求评审,参与原型设计和软件详细设计评审;这样的话,测试人员得到的信息越多,开展的测试时也越灵巧,保证软件的以理解性。另外,将我们需求的讨论的结果,定期和客户沟通。同时也能保证软件的稳定性,因为大家对需求的理解偏差减少了,后期对功能的修改也会少一些,这样对测试的破坏性也会减少。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2016-8-27 20:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    29#
    发表于 2013-3-13 16:53:16 | 只看该作者
    回复 1# lsekfe


        路过
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2013-3-14 08:34:47 | 只看该作者

    TS02徕卡全站仪13911619321

    TS02是徕卡公司TS系列全站仪中一款最基本型的全站仪,配有标准的软件应用程序,能够满足一般测量作业的要求。无论是测量棱镜,还是直接测量目标,TS02,TS02 Power,TS02 Ultra中总有一款适用。
    TS02徕卡全站仪特点:
    1、锂电池工作时间长达20小时
    2、内存数据存储可达2.4万点
    3、有棱镜模式测距精度±1.5mm
    4、保证较高精度的领先补偿功能
    5、标准或字母数字键盘
    6、无棱镜模式测程>1000米
    7、完整的FlexField和FlexOffice软件解决方案,并配置符合本地化需求道路放样程序
    TS02徕卡全站仪参数:
    TS02全站仪|TS06全站仪|TS09全站仪|TS11全站仪TS15专业测量全站仪TS11i徕卡全站仪TS15i测量工程全站仪
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2013-3-17 17:18:36 | 只看该作者
    请问一下,测试需要有开发基础吗?开发跟测试是否有关联?目前我有考虑先转去开发,然后再转回测试,个人认为有开发的基础,测试会更全面,不知这种想法是否正确!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    32#
    发表于 2013-3-17 19:02:41 | 只看该作者
    回复 32# zbj793989849


        不太同意楼主的做法,测试与开发还是有区别的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2013-3-18 12:49:14 | 只看该作者
    回复 1# lsekfe


        要有一定的耐心、有步骤、有思路
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2016-10-31 17:44:45 | 只看该作者
    一个有信念者所开发出的力量,大于99个只有兴趣者。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-12-7 22:03
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    35#
    发表于 2016-11-5 15:16:32 | 只看该作者
       可测试性主要取决于需求
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-25 22:32 , Processed in 0.077291 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表