51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

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

 关闭 [复制链接]

该用户从未签到

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

评分

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

查看全部评分

回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-2-27 08:48
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    1282#
    发表于 2009-5-7 14:05:22 | 只看该作者
    Alpha测试(alpha testing)、Beta测试(beta testing)、组件测试(component testing)(也称为单元测试、模块测试或程序测试)、驱动器(driver)、现场测试(field testing)、功能需求(functional requirement)、集成(integration)、集成测试(integration testing)、非功能需求(non-functional requirement)、健壮性测试(robustness testing)、桩(stub)、系统测试(system testing)、测试级别(test level)、测试驱动开发(test-driven development)、测试环境(test environment)、用户验收测试(user acceptance testing)。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    1284#
    发表于 2009-5-7 15:12:10 | 只看该作者
    Screen shot(抓屏、截图):
    软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1285#
    发表于 2009-5-7 15:13:55 | 只看该作者
    Software life cycle(软件生命周期):
    开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1286#
    发表于 2009-5-7 15:55:13 | 只看该作者
    验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
              所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1287#
    发表于 2009-5-7 15:55:22 | 只看该作者
    验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
              所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1288#
    发表于 2009-5-7 15:56:38 | 只看该作者
    Structured query language(结构化查询语句,SQL):
    在一个关系数据库中查询和处理数据的一种语言。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1289#
    发表于 2009-5-7 15:57:16 | 只看该作者
    TBD(To be determined,待定):
    在测试文档中标是一项进行中的尚未最终确定的工作。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1290#
    发表于 2009-5-7 16:23:31 | 只看该作者
    输出值是一个步骤,在该步骤中,捕获您的测试或组件中某个特定点的一个或多
    个值,并在运行会话持续时间存储这些值。随后,在运行会话中的不同点,可以
    将这些值作为输入使用。

    评分

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

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1291#
    发表于 2009-5-7 16:28:54 | 只看该作者
    Test(测试):
    执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1292#
    发表于 2009-5-7 16:29:50 | 只看该作者
    Test case(测试用例):
    为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1293#
    发表于 2009-5-7 16:41:10 | 只看该作者
    测试流程:
    1.需求分析
    2.编写测试计划
    3,编写测试用例
    4.用例评审
    5,执行测试
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-1-18 16:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    1294#
    发表于 2009-5-7 16:58:29 | 只看该作者

    晕晕晕

    我哭死
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-1-18 16:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    1295#
    发表于 2009-5-7 16:58:43 | 只看该作者

    晕晕晕

    我哭死
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    1297#
    发表于 2009-5-7 17:29:45 | 只看该作者
    Testing coverage(测试覆盖):
    指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    1298#
    发表于 2009-5-7 17:30:29 | 只看该作者
    Testing environment(测试环境):
    进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    1300#
    发表于 2009-5-7 18:37:32 | 只看该作者
    1 、一个好的测试发现错误的可能性很高
    为了达到这个目标,测试者必需理解软件、并尝试设想软件如何才能失败,
    例如:在 GUI (图形用户界面)中有一种潜在的错误,即错误识别鼠标位置,
    那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
    2 、一个好的测试并不冗余
    测试的时间和资源是有限的,没有必要构造一个与其他测试用例完全相同的测试,
    每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如,软件 SafeHome 中
    有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,
    测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码( 4 个数字),
    然而,每一个有效 / 无效密码将只检测一种不同错误模式,例如一个将 8080 作为
    有效密码的系统将不会接受非法密码 1234 ,如果接受 1234 ,将产生错误,
    另一个测试输入 1235 ,与 1234 的测试意图相同,因此是冗余的,然而,
    非法输入 8081 或 8180 就有些细微的差异,即对与有效密码相近但并不相同的密码应该进行测试。
    3 、一个好的测试应该是 “ 最佳品种 ”
    在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,
    应该使用最可能找到所有错误的测试。
    4 、一个好的测试既不会太简单,也不会太复杂
    虽然有时会将一组测试组合到一个测试用例中,其副作用可能屏蔽错误,通常每一个测试应该独立执行。

    评分

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

    查看全部评分

    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-18 22:37 , Processed in 0.085736 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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