51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 默默巫
打印 上一主题 下一主题

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

 关闭 [复制链接]

该用户从未签到

1401#
发表于 2009-5-8 13:16:19 | 只看该作者
测试需求与测试用力的区别在哪里?
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    1402#
    发表于 2009-5-8 13:29:14 | 只看该作者
    判定表驱动分析方法
    一.    方法简介
    1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    1403#
    发表于 2009-5-8 13:29:40 | 只看该作者
    2.判定表的优点
    能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。
    在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1404#
    发表于 2009-5-8 13:48:44 | 只看该作者
    BUG的分类

    Bug严重级别(Severity,Bug级别):是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。
    A
    错误导致了死机、产品失败(“崩溃”)、系统悬挂无法操作;

    B
    功能未实现或导致一个特性不能运行并且不可能有替代方案(包括计算错误);

    C
    错误导致了一个特性不能运行但可有一个替代方案;

    D
    错误是表面化或微小的(提示信息不太准确友好、错别字、UI布局或罕见故障等),对功能几乎没有影响,产品及属性仍可使用;

    E
    建设性的意见或建议。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1405#
    发表于 2009-5-8 13:49:27 | 只看该作者
    Bug优先级(Priority):指缺陷必须被修复的紧急程度。由Bug分配者(开发组长/经理)指定。
    5
    阻止相关开发人员的进一步开发活动,立即进行修复工作;阻止与此密切相关功能的进一步测试

    4
    必须修改,发版前必须修正

    3
    必须修改,不一定马上修改,但需确定在某个特定里程碑结束前须修正

    2
    如果时间允许应该修改

    1
    允许不修改
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1406#
    发表于 2009-5-8 13:53:03 | 只看该作者
    灰盒测试,介于白盒测试与黑盒测试之间,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1407#
    发表于 2009-5-8 13:53:33 | 只看该作者
    性能测试工具OpenSTA介绍:
    OpenSTA是专用于B/S结构的、免费的性能测试工具。它的优点除了免费、源代码开放的优点外,还能对录制的测试脚本进行,按指定的语法进行编辑。测试工程师在录制完测试脚本后,只需要了解该脚本语言的特定语法知识,就可以对测试脚本进行编辑,以便于再次执行性能测试时获得所需要的参数,之后进行特定的性能指标分析。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1408#
    发表于 2009-5-8 13:54:16 | 只看该作者
    灰盒测试,介于白盒测试与黑盒测试之间,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1409#
    发表于 2009-5-8 13:54:25 | 只看该作者
    灰盒测试,介于白盒测试与黑盒测试之间,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1410#
    发表于 2009-5-8 13:54:29 | 只看该作者
    软件测试按开发阶段分:


    单元测试
    集成测试
    系统测试

    评分

    参与人数 1综合技术指数 +15 收起 理由
    默默巫 + 15 楼层尾数为5的参与奖

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1411#
    发表于 2009-5-8 13:55:15 | 只看该作者
    迭代-增量开发模型(iterative-incremental development model)由需求建立、设计、构建和测试等一系列相对较短的开发周期构成。比如:原型开发、快速应用开发(RAD)、统一软件开发过程(RUP)和敏捷开发模型等。作为其开发的一部分,迭代产生的系统需在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中,形成一个渐渐增大的系统,这个系统同样需要进行测试。在完成第一次迭代后,对所有的迭代进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1412#
    发表于 2009-5-8 13:55:41 | 只看该作者
    Deployment(部署):
    也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。 Dynamic testing(动态测试),通过执行软件的手段来测试软件
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1413#
    发表于 2009-5-8 13:56:02 | 只看该作者
    测试驱动开发(Test Driven Development,英文缩写TDD)是极限编程的一个重要组成部分,它的基本思想就是在开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。
    概括起来,测试驱动开发的基本过程如下:
      (1) 明确当前要完成的功能。可以记录成一个 TODO 列表。
      (2) 快速完成针对此功能的测试用例编写。
      (3) 测试代码编译不通过。
      (4) 编写对应的功能代码。
      (5) 测试通过。
      (6) 对代码进行重构,并保证测试通过。
      (7) 循环完成所有功能的开发。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1414#
    发表于 2009-5-8 13:56:18 | 只看该作者
    灰盒测试,介于白盒测试与黑盒测试之间,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1415#
    发表于 2009-5-8 13:56:35 | 只看该作者
    灰盒测试,介于白盒测试与黑盒测试之间,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1416#
    发表于 2009-5-8 13:56:57 | 只看该作者
    Build(工作版本):
    软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1417#
    发表于 2009-5-8 13:57:23 | 只看该作者
    所谓漏测,是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里,却最终被用户所发现。如果产品在用户那里出现问题,产生的后果是非常严重的。在软件开发过程中,缺陷越早被发现,发现和解决缺陷所花的成本就越小。如果缺陷是在测试组测试中发现的而不是被用户使用时发现的,那么所花的成本将小得多。如果缺陷是被开发组在开发过程中发现的,那么所花的代价将更小。因此,进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现,是非常有意义的,它有利于降低软件产品成本、提高软件产品质量。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1418#
    发表于 2009-5-8 13:58:26 | 只看该作者
    loadrunner的内部编译器采用ANSI C,它有三种类型的变量:

    1、基于堆栈的变量
    这类变量的定义如下:
    int intSample;
    char charSample[5];
    这类变量作用范围就是某个action或者你定义的函数。

    2、基于heap的变量
    这类变量的定义如下:
    int *intSample;
    char *charSample;
    它们必须被明确的分配内存,也需要用free()函数释放。

    3、参数(lr自己管理的变量)
    这类变量可以用web_reg类的函数定义,也可以用lr_save_string定义,用lr_eval_string获取它的值,它的作用范围为整个脚本(类似全局变量)。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1419#
    发表于 2009-5-8 13:58:38 | 只看该作者
    loadrunner的内部编译器采用ANSI C,它有三种类型的变量:

    1、基于堆栈的变量
    这类变量的定义如下:
    int intSample;
    char charSample[5];
    这类变量作用范围就是某个action或者你定义的函数。

    2、基于heap的变量
    这类变量的定义如下:
    int *intSample;
    char *charSample;
    它们必须被明确的分配内存,也需要用free()函数释放。

    3、参数(lr自己管理的变量)
    这类变量可以用web_reg类的函数定义,也可以用lr_save_string定义,用lr_eval_string获取它的值,它的作用范围为整个脚本(类似全局变量)。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1420#
    发表于 2009-5-8 13:58:45 | 只看该作者
    可用性测试是指在设计过程中被用来改善易用性的一系列方法。我们为用户提供一系列操作场景和任务让他们去完成,这些场景和任务与您的产品或服务密切相关。通过观察,我们来发现过程中出现了什么问题、用户喜欢或不喜欢哪些功能和操作方式,原因是什么。针对问题所在,我们会提出改进的建议。

    评分

    参与人数 1综合技术指数 +15 收起 理由
    默默巫 + 15 楼层尾数为5的参与奖

    查看全部评分

    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-18 18:43 , Processed in 0.079405 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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