51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

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

[活动]迎五一,庆周年,盖高楼(活动结束)

 关闭 [复制链接]
  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    21#
    发表于 2009-4-28 17:41:07 | 显示全部楼层
    2、白盒测试

      白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    22#
    发表于 2009-4-28 17:41:55 | 显示全部楼层
    单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    23#
    发表于 2009-4-28 18:32:32 | 显示全部楼层
    在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括:
      1 误解或用错了算符优先级;
      2混合类型运算;
      3变量初值错;
      4精度不够;
      5表达式符号错。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    24#
    发表于 2009-4-28 18:33:56 | 显示全部楼层
    比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误:
      1不同数据类型的对象之间进行比较;
      2错误地使用逻辑运算符或优先级;
      3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;
      4比较运算或变量出错;
      5循环终止条件或不可能出现;
      6迭代发散时不能退出;
      7错误地修改了循环变量。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    25#
    发表于 2009-4-28 18:59:42 | 显示全部楼层
    广义上讲,测试是指软件产品生存周期内所有的检查、评审和确认活动。如:设计评审、系统测试。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    26#
    发表于 2009-4-28 18:59:55 | 显示全部楼层
    狭义上讲,测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题,同时对产品质量进行客观的评价。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    27#
    发表于 2009-4-28 19:12:15 | 显示全部楼层
    (1)木桶原理


      在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说,测试是提高产品质量的必要条件,也是提高产品质量最直接、最快捷的手段,但决不是一种根本手段。反过来说,如果将提高产品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    28#
    发表于 2009-4-28 19:12:21 | 显示全部楼层
    2)Bug的80-20原则。


      一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug,而系统测试又能找出其余Bug中的80%,最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误,无法保证能够发现所有的错误。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    29#
    发表于 2009-4-28 19:16:37 | 显示全部楼层
    软件测试的目的
    首先,测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时,这种分析也能帮助我们设计出有针对性地检测方法,改善测试的有效性。

    其次,没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如 Bev Littlewood发现一个经过测试而正常运行了n小时的系统有继续正常运行n小时的概率。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    30#
    发表于 2009-4-28 19:24:12 | 显示全部楼层
    覆盖评测


      覆盖指标提供了"测试的完全程度如何?"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之,测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)或所有代码行的执行(基于代码的)。


      系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的,指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。


      如果需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了 75% 的性能测试需求。


      如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。


      两种评测都可以手工得到(公式如下所示)或通过测试自动化工具计算得到。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    31#
    发表于 2009-4-28 19:27:24 | 显示全部楼层
    好了,不抢楼位了。

    基于代码的测试覆盖


      基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效,例如,数据元素在使用之前是否已作定义。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-4 10:10 , Processed in 0.076270 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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