发布新日志

  • 转载：(十一)软件测试技术——安全性测试

    2009-01-31 21:27:03

    发布时间: 2008-6-18 15:46    作者: 陈能技    来源: 51Testing软件测试网
    本文选自《软件测试大全：测试技术、流行工具、项目实战》

      安全性测试是一项迫切需要进行的测试，测试人员需要像黑客一样攻击软件系统，找到软件系统包含的安全漏洞。
    1．网页安全漏洞检测
            一些设计不当的网站系统可能包含很多可以被利用的安全漏洞，这些安全漏洞如同给远程攻击者开了一个后门，让攻击者可以方便地进行某些恶意的攻击。例如，公共漏洞和披露网站CVE（Common Vulnerabilities and Exposures）公布了Element InstantShop中的Web网页add_2_basket.asp的一个漏洞项，允许远程攻击者通过隐藏的表单变量“price”来修改价格信息。这个表单的形式如下所示：

    <INPUT TYPE = HIDDEN NAME = "id" VALUE = "AUTO0034">
    <INPUT TYPE = HIDDEN NAME = "product" VALUE = "BMW545">
    <INPUT TYPE = HIDDEN NAME = "name" VALUE = "Expensive Car">
    <INPUT TYPE = HIDDEN NAME = "price" VALUE = "100">

            利用这个漏洞，不怀好意者可以任意设定price字段的值，然后提交给InstantShop网站的后台服务器，从而可能用100美元就可以获得一部BMW545。
            技巧：发现类似的安全漏洞的最好方法是进行代码审查。除了代码审查，测试人员还可以利用一些测试工具进行检查，例如：Paessler Site Inspector、Web Developer等。

    2．SQL注入
            SQL注入是另外一个经常忽略的安全漏洞，但是SQL注入同时也是一种非常普遍的代码漏洞，它会导致数据库端的敏感数据泄漏，或者服务器受到黑客的控制。例如，下面的一段代码就存在SQL语句的注入漏洞。

    SqlConnection sqlcon = sqlconnA;

    //打开连接
    sqlcon.Open();

    //组合一条查询语句
    SqlCommand cmd = "select count(*) from User where LogonName = ‘" + this.textBox1.Text +”’ and Password = ‘”+this.textBox2.Text;

    SqlDataAdapter adpt = new SqlDataAdapter(cmd, sqlcon);

    DataSet ds = new DataSet();
    adpt.Fill(ds);
    //关闭连接
    sqlcon.Close();

    //如果返回数据不为空，则验证通过
    If(ds.Tables[0].Rows.Count>0)
    {
       retuen true;
    }
    else
    {
       Return false;
    }

            这段代码从textBox1获得用户输入的用户名，从textBox2获得用户输入的密码，然后执行数据库查询操作。假设在textBox1的输入框输入一个已知的用户名，然后再做一些手脚，则可以不输入密码也能登录系统。这个字符串利用了SQL Server对单引号的处理方式，只要简单地组合成类似下面的字符串并输入到textBox1的输入框中即可。

    Admin' or '1' = '1

            这样就可以利用已知的Admin账号，不输入密码就能登录系统。因为给预期的SQL语句注入了额外的语句，所以实际上提交到SQL Server数据库执行的语句变成了如下所示的语句：

    select count(*) from user where LogonName = 'Admin' or '1'='1' and Password=''

            由于1=1是恒等的，因此返回的结果肯定为真，从而干扰了用户信息的正常验证，导致能绕过密码验证而登录系统。
            技巧：检查是否存在SQL语句注入漏洞的最好办法是代码审查，查看所有涉及SQL语句提交的地方，是否正确处理了用户输入的字符串。

    3．缓冲区溢出
            不仅仅是连上Internet的软件系统才会有安全问题，个人软件系统或公司内部的软件系统也存在安全问题，这些安全问题不会导致信用卡密码的泄漏，但是可能导致工作成果的丢失。如果软件系统是采用C语言这类容易产生缓冲区溢出漏洞的语言开发的话，作为测试人员就要注意检查可能造成系统崩溃的安全问题了。
            例如，下面的两行C语言代码就可能造成缓冲区的溢出问题：

    char buf[20];
    gets(buf);

            如果使用gets函数来从stdin读入数据，则可能出现缓冲区溢出的问题。另外一个例子如下：

    char buf[20];
    char prefix[] = "http://";
    strcpy(buf,prefix);
    strncat(buf,path,sizeof(buf));

            这里问题出现在sizeof的参数不应该是整个buf的大小，而是buf的剩余空间大小。
            技巧：测试人员需要对每一个用户可能输入的地方尝试不同长度的数据输入，以验证程序在各种情况下正确地处理了用户的输入数据，而不会导致异常或溢出问题。或者通过代码审查来发现这些问题。还可以利用一些工具来帮助检查这类问题，例如AppVerifier等。

    查看(423) 评论(0) 收藏 分享 管理

  • 决心要考软件评测师了

    2008-09-22 16:45:42

    最近一段时间有点不思进取。冷静下来，感觉还害怕。便给自己订了个目标，冲刺09年度的软件评测师的资格考试，坦然说不仅仅为了资格证书，为的是在冲刺过程中学习和积累的知识。

    查看(514) 评论(0) 收藏 分享 管理

  • 那刹那，我哭了

    2008-03-27 13:19:03

    当他说出从今以后不再为我停留时，我哭了。。。

    每年的生日，小米（刘若英饰）都坐立不安地等待着一封风雨不改的E-mail，一封从小南（古天乐饰），一个她从来无法忘记的人寄来的生日E-mail。10年后，滂沱大雨之下，这封E-mail迟了36个小时……但小南真的忘了“生日快乐”这个祝福的承诺吗？

    　　小米与小南从大学开始就被公认是完美的一对，但他们却一直保持着比好朋友更好的暧昧关系。小南在每年生日对小米的问候，变成一种爱情的牵引。小米是个因为害怕失去而没有安全感的女孩，如果再勇敢、再有自信一点，她的爱情或许就会一切改观；小南是个受欢迎的男孩，他一心爱着小米，然而他从不能搞懂小米的想法。他们就像是两种奇怪的生物，如此的相互需要、相互吸引，却又是如此的不能共存。小南出国深造后，二人分手了，却仍然保持着在感情上相互取暖的矛盾关系。无论彼此身边出现多少情人，朋友还是深信，总有一天他们会幸福地走在一起。

    　　然而多年后，他们盼望的幸运却没有来临，小南竟然跟她说自己将要结婚了！小米这才醒觉，这一次，她是真真正正的失去小南。10年聚散，他天天都挂念着她，却只能一年用E-mail跟她说一次生日快乐，因为一个秘密，守护着彼此也伤害彼此。

    查看(374) 评论(0) 收藏 分享 管理

  • http response

    2008-01-25 13:07:14

     

    在性能测试过程中，服务器经常回给我们返回404或者500的错误；或者我们在分析测试结果时，对200、302、304这些返回代码表示什么意思弄不懂，下面是解释。

    HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
        通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。

    HTTP服务器状态代码定义（Status Code Definitions）
    1**----消息类
    该类状态代码用于表示临时回应。
    2**----成功类
    表示客户端请求被成功接收、理解、接受。
        例如：200---OK  表示请求成功。
    3**----重定向类
    该类状态码表示用户代理要想完成请求，还需要发出进一步的操作。
        例如：302---Moved Temporarily  请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改，客户端应继续用请求URI来发出以后的请求。
                304---Not Modified    如果客户端成功执行了条件GET请求，而对应文件自If-Modified-Since域所指定的日期以来就没有更新过，服务器应当回应此状态码，而不是将实体主体发送给客户端。
    4**----客户端错误类
        例如：404---Not Found    服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是永久性的.
    5**----服务器错误类
        例如：500---Internal Server Error    服务器碰到了意外情况，使其无法继续回应请求。

    查看(899) 评论(0) 收藏 分享 管理

  • 火气好大，好想爆发出来

    2008-01-16 16:35:11

    最近两天心情好不爽，昨天被无缘无故的被开发的同事凶了一顿，说我找bug ，不能抓住一个不放。可是这个bug确实存在，并且我感觉这个bug的问题跟系统功能设计上又很大的关系。虽然我做的是黑盒，但是我明显感觉到这个bug 不是很容易解决。但是开发人员知道bug后，口气也不能这么不好，谁能受的了。难道开发人员比测试人员高一等，真lj。

    沟通，沟通，难道开发人员就不能很好的和测试人员沟通，再说了测试人员找bug 又不是和谁谁作对，最终都是为了开发出更好的系统。我感觉其实我的沟通已经很有耐心了，可是还是发现沟通不够好，要不我给他们找出bug的时候，开发人员怎会如此。。。难道所有软件公司的测试人员都是和我一样，在开发人员的臭言恶语下工作。

    真想知道开发人员到底是什么心态：讨厌被发现bug，害怕被发现bug，还是。。。，可是不管什么心态，为什么要狂妄呢。。。

    其实我认为整个被发现bug，修复bug的过程是成长进步的过程

    我倒是很希望有个测试前辈给我提出我测试方法过程等的bug，虽然当别人给自己提出bug的时候，心情会沉重些，可是我会默默的仔细聆听，那样人生才会有进步。

    人生不气馁，一切往前看，我的脚步不会停留在现在。

    努力学习白盒测试中。。。

    查看(530) 评论(2) 收藏 分享 管理

  • 测试专业术语

    2008-01-14 17:42:13


    前言
    此术语表为国际软件测试认证委员会（ISTQB）发布的标准术语表。此表历经数次修改、完善，
    集纳了计算机行业界、商业界及政府相关机构的见解及意见，在国际化的层面上达到了罕有的
    统一性及一致性。参与编制此表的国际团体包括澳大利亚、比利时、芬兰、德国、印度、以色
    列、荷兰、挪威、葡萄牙、瑞典、英国和美国。
    多数软件测试工程师使用1998年发布的BS 7925-1标准。英国信息系统考试委员会(ISEB)也以此
    标准作为基础级别和从业级别认证的首要参考标准。BS 7925-1标准最初是围绕着单元测试撰写
    的，自发布之后许多旨在改进和扩展此标准，以覆盖更广义范围的软件测试领域的新概念和提
    议不断涌现。最新版的BS 7925-1标准中的软件测试词汇吸纳、融合了上述概念和提议。此国际
    软件测试认证委员会（ISTQB）发布的标准术语表即是以最新版的BS 7925-1标准为基础制定的
    国际化软件测试标准术语。
    1 简介
    行业界、商业界、政府及学术机构曾经花费大量精力和时间以解释和区分一些常见的软件测试
    专业术语以期在各社会部门或机构之间达成交流，例如：语句覆盖(statement coverage) 和条件
    覆盖(decision overage)； 测试套件(test suite)、 测试规格说明书(test specification)和测试计划(test
    plan)等。上述机构与专职机构定义的同名术语在含义上又往往有很大偏差。
    2 范畴
    本文档旨在提供概念、条款、和定义为软件测试及相关从业人员进行有效交流的平台。

    3 结构
    术语表中的词汇按字母顺序排列。术语如有同义词汇，本术语表解释最通用的词汇，其同义词
    汇会的仅被列出，不予重复解释。例如结构测试(structural testing) 和白盒测试(white box testing)。
    此类同义词在术语表中用“参见”列出，以便读者检索。“参见”往往连接着广义和狭义词或
    含义重叠的词汇。
    4 标准参考
    至截稿日期，此标准有效版本为1.2。如所有其他标准一样，本术语表仍需根据以下相关标准的
    最新版本不断修正。此标准由IEC 和 ISO 成员根据目前有效的国际相关标准进行更新。
    - BS 7925-2:1998. Software Component Testing.
    - DO-178B:1992. Software Considerations in Airborne Systems and Equipment
    Certification, Requirements and Technical Concepts for Aviation (RTCA SC167).
    - IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology.
    - IEEE 829:1998. Standard for Software Test Documentation.
    - IEEE 1008:1993. Standard for Software Unit Testing.
    - IEEE 1012:1986. Standard for Verification and Validation Plans
    - IEEE 1028:1997. Standard for Software Reviews and Audits.
    - IEEE 1044:1993. Standard Classification for Software Anomalies.
    - IEEE 1219:1998. Software Maintenance.
    - ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms.
    - ISO 9000:2000. Quality Management Systems – Fundamentals and Vocabulary.
    - ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1:
    Quality characteristis and sub-characteristics.
    - ISO/IEC 12207:1995. Information Technology – Software Life Cycle Processes.
    - ISO/IEC 14598-1:1996. Information Technology – Software Product Evaluation - Part
    1: General Overview.
    A
    abstract test case 抽象测试用例 参见high level test case.
    acceptance 验收 参见acceptance testing.
    acceptance criteria 验收准则
    为了满足组件或系统使用者、客户或其他授权实
    体的需要，组件或系统必须达到的准则。[IEEE
    610]
    acceptance testing 验收测试
    一般由用户/客户进行的确认是否可以接受一个
    系统的验证性测试。是根据用户需求，业务流程
    进行的正式测试以确保系统符合所有验收准则。
    [与IEEE 610 一致]
    accessibility testing 可达性测试
    可达性测试就是测试残疾人或不方便的人们
    使用软件或者组件的容易程度[Gerrard]。即
    被测试的软件是否能够被残疾或者部分有障
    碍人士正常使用，这其中也包含了正常人在
    某些时候发生暂时性障碍的情况下正常使
    用，如怀抱婴儿等。
    accuracy 准确性
    软件产品的提供的结果的正确性、一致性和精确
    程度的能力。[ISO9126] 参见functionality
    testing
    actual outcome 实际结果 参见actual result
    actual result 实际结果 组件或系统测试之后产生或观察到的行为
    ad hoc review 临时评审 非正式评审（和正式的评审相比）
    ad hoc testing 随机测试
    非正式的测试执行。即没有正式的测试准备、规
    格设计和技术应用，也没有期望结果和必须遵循
    的测试执行指南。
    adaptability 适应性
    软件产品毋需进行额外修改，而适应不同特定环
    境的能力。[ISO9126] 参见 protability
    agile testing 敏捷测试
    对使用敏捷方法，如极限编程(Extreme
    programming)开发的项目进行的软件测试，强调
    测试优先行的设计模式，见test driven
    development
    algorithm test [TMap] 算法测试 参见branch testing
    alpha testing Alpha 测试
    由潜在用户或者独立的测试团队在开发环境下或
    者模拟实际操作环境下进行的测试,通常在开发
    组织之外进行。通常是对现货软件(COTS)进行内
    部验收测试的一种方式。
    analyzability 可分析性
    软件产品缺陷或运行失败原因可被诊断的能力，
    或对修改部分的可识别能力。[ISO 9126] 参见
    maintainability.
    analyzer 分析器 参见 static analyzer

    anomaly 异常
    任何和基于需求文档、设计文档、用户文档、标
    准或者个人的期望和预期之间偏差的情况，都可
    以称为异常。异常可以在但不限于下面的过程中
    识别：评审(review)、测试分析(test analysis)、
    编译(compilation)、软件产品或应用文档的使用
    等。参见defect, deviation, error, fault,
    failure, incident, problem
    arc testing 弧测试 参见 branch testing
    attractiveness 吸引力
    软件产品吸引用户的能力.[ISO9126]参见
    usability
    audit 审计
    对软件产品或过程进行的独立评审，来确认产品
    是否满足标准、指南、规格说明书以及基于客观
    准则的步骤等，包括下面的文档：(1)产品的内容
    与形式(2)产品开发应该遵循的流程(3)度量符合
    标准或指南的准则。[IEEE1028]
    audit trail 审计跟踪
    以过程输出作为起点，追溯到原始输入（例如：
    数据）的路径。有利于缺陷分析和过程审计的开
    展。[与TMap 一致]
    automated testware 自动测试件 用于自动化测试中的测试件，如，工具脚本
    availability 可用性
    用户使用系统或组件的可操作和易用的程度，通
    常以百分比的形式出现。[IEEE 610]
    B
    back-to-back testing 比对测试
    用相同的输入，执行组件或系统的两个或多个变
    量，在产生偏差的时候，对输出结果进行比较和
    分析。
    baseline 基线
    通过正式评审或批准的规格或软件产品。以它作
    为继续开发的基准。并且在变更的时候，必须通
    过正式的变更流程来进行。[与IEEE 610 一致]
    basic block 基本块
    一个或多个连续可执行的语句块，不包含任何分
    支语句。
    basis test set 基本测试集
    根据组件的内部结构或规格说明书设计的一组测
    试用例集。通过执行这组测试用例可以保证达到
    100％的指定覆盖准则(coverage criterion)的
    要求。
    bebugging 错误散播 参见error seeding
    behavīor 行为 组件或系统对输入值和预置条件的反应。
    benchmark test 基准测试
    (1)为使系统或组件能够进行度量和比较而制定
    的一种测试标准；(2)用于组件或系统之间进行的
    比较或和（1）中提到的标准进行比较的测试。[与
    IEEE 610 一致]
    bespoke software 定制软件
    为特定的用户定制开发的软件。与之对比的是现
    货软件(off-the-shelf software)。
    best practice 最佳实践
    在界定范围内，帮助提高组织能力的有效方法或
    创新实践，通常被同行业组织视最佳的方法或实践。
    beta testing Beta 测试
    用户在开发组织外，没有开发人员参与的情况下
    进行的测试，检验软件是否满足客户及业务需求。
    这种测试是软件产品获得市场反馈进行验收测试
    的一种形式。
    big-bang testing 大爆炸测试
    非增量集成测试的一种方法，测试的时候将软件
    单元、硬件单元或者两者同时,而不是阶段性的，
    集成到组件或者整个系统中去进行测试。[与IEEE
    610 一致]参见integration testing。
    black-box technique 黑盒技术 参见black box test design technique
    black-box testing 黑盒测试
    不考虑组件或系统内部结构的功能或非功能测
    试。
    black-box test design
    technique 黑盒测试设计技术
    基于系统功能或非功能规格说明书来设计或者选
    择测试用例的技术，不涉及软件内部结构。
    bottom-up testing 自底向上测试
    渐增式集成测试的一种，其策略是先测试底层的
    组件，以此为基础逐步进行更高层次的组件测试，
    直到系统集成所有的组件。参见integration
    testing。
    boundary value 边界值
    通过分析输入或输出变量的边界或等价划分
    (equivalence partition)的边界来设计测试用
    例，例如，取变量的最大、最小值、中间值、比
    最大值大的值、比最小值小的值等。
    boundary value analysis 边界值分析
    一种黑盒设计技术(black box test design
    technique)，基于边界值进行测试用例的设计。
    boundary value
    coverage 边界值覆盖
    执行一个测试套件(test suite)所能覆盖的边界
    值(boundary value)的百分比。
    boundary value testing 边界值测试 参见boundary value analysis。
    branch 分支
    在组件中，控制从任何语句到其它任何非直接后
    续语句的一个条件转换，或者是一个无条件转换。
    例如: case, jump, go to, if-then-else 语句.
    branch condition 分支条件 参见条件(condition)
    branch condition
    combination coverage 分支条件组合覆盖 参见 multiple condition coverage.
    branch condition
    combination testing 分支条件组合测试 参见 multiple condition testing.
    branch condition
    coverage 分支条件覆盖 参见 condition coverage.
    branch coverage 分支覆盖
    执行一个测试套件(test suite)所能覆盖的分支
    (branch)的百分比。100%的分支覆盖(branch
    coverage)是指100%判定条件覆盖(decision
    covergate) 和100%的语句覆盖(statement
    covergage)。
    bug 缺陷 参见defect。
    bug report 缺陷报告 参见defect report。
    business process-based
    testing 基于业务过程测试
    一种基于业务描述和/或业务流程的测试用例设
    计方法。

    C
    Capability Maturity
    Model (CMM) 能力成熟度模型
    描述有效的软件开发过程关键元素的一个五个等
    级的框架，能力成熟度模型包含了在软件开发和
    维护中计划、工程和管理方面的最佳实践(best
    practice)，缩写为CMM。[CMM]
    Capability Maturity
    Model Integration
    (CMMI)
    能力成熟度模型集
    成
    描述有效的软件产品开发和维护过程的关键元素
    框架，能力成熟度模型集成包含了软件开发计划、
    工程和管理等方面的最佳实践，是CMM 的指定
    的继承版本。
    capture/playback tool 捕获/回放工具
    一种执行测试工具，能够捕获在手工测试过程中
    的输入，并且生成可执行的自动化脚本用于后续
    阶段的测试（回放过程）。这类工具通常使用在
    自动化回归测试(regression test)中。
    capture/replay tool 捕获/回放工具 参见capture/playback tool
    CASE 计算机辅助软件工
    程
    Computer Aided Software Engineering 的首字
    母缩写。
    CAST 计算机辅助软件测
    试
    Computer Aided Software Testing 的首字母缩
    写，参见test automation。在测试过程中使用
    计算机软件工具进行辅助的测试。
    cause-effect graph 因果图
    用来表示输入（原因）与结果之间关系的图表，
    因果图可以用来设计测试用例。
    cause-effect graphing 因果图技术
    通过因果图(case-effect graph)设计测试用例
    的一种黑盒测试设计技术。
    cause-effect analysis 因果分析 参见因果图技术(case-effect graphing)。
    cause-effect decision
    table 因果决策表 参见决策表 (decision table)。
    certification 认证
    确认一个组件、系统或个人具备某些特定要求的
    过程，比如通过了某个考试。
    changeability 可变性
    软件产品适应修改的能力，[ISO 9126] 参见
    maintainability
    change control 变更控制 参见configuration control
    change control board 变更控制委员会
    CCB
    参见configuration control board
    checker 检验员 参见评审员(Reviewer)
    chow's coverage metrics N 切换覆盖度量 参见N 切换覆盖(N-switch coverage)[Chow]
    classification tree
    method 分类树方法
    运用分类树法而进行的一种黑盒测试设计技术，
    通过输入和/或输出域的组合来设计测试用例
    [Grochtmann]
    code 代码
    计算机指令和数据定义在程序语言中的表达形式
    或是汇编程序、编译器或其他翻译器的一种输出
    形式。
    code analyzer 代码分析器 参见静态分析器(static code analyzer)

    code coverage 代码覆盖
    一种分析方法，用于确定软件的哪些部分被测试
    套件(test suite)覆盖到了，哪些部分没有。例
    如：语句覆盖(statement covergage)，判定覆盖
    (decision coverage)和条件覆盖(condition
    covergate)。
    code-based testing 基于代码的测试 参见white box testing
    co-existence 共存性
    软件产品与通用环境下与之共享资源的其它独立
    软件之间共存的能力。[ISO 9126] 参见可移植性
    (portability)。
    commercial off-the-shelf
    software 商业现货软件 参见现货软件(off-the shelf software)
    comparator 比较器 参见test comparator。
    compiler 编译器
    将高级命令语言编写的程序翻译成能运行的机器
    语言的工具[IEEE 610].
    complete testing 完全测试 参见穷尽测试(exhaustive testing)
    completion criteria 完成准则 参见退出准则(exit criteria)
    complexity 复杂性
    系统或组件的设计和/或内部结构难于理解、维护
    或验证的程度。参见cyclomatic complexity.
    compliance 一致性
    软件产品与法律和类似规定的标准、惯例或规则
    的一致性方面的能力。[ ISO9126]
    compliance testing 一致性测试 确定组件或系统是否满足标准的测试过程。
    component 组件 一个可被独立测试的最小软件单元。
    component integration
    testing 组件集成测试
    为发现集成组件接口之间和集成组件交互产生的
    缺陷而执行的测试。
    component specification 组件规格说明
    根据组件的功能定义为特定输入而应该产生的输
    出规格进行的功能性和非功能性行为的描述。例
    如：资源使用(resource utilization).
    compound condition 复合条件
    通过逻辑操作符(AND, OR 或者 XOR)将两个或
    多个简单条件连结起来：如，“A>0 AND B<1000”
    concrete test case 具体测试用例 参见低阶测试用例(low level test case).
    concurrency testing 并发测试
    测试组件或系统的两个或多个活动在同样的间隔
    时间内如何交叉或同步并发。[与IEEE 610 一致]
    condition 条件
    一个可被判定为真、假(true,false)的逻辑表达
    式。例如： A>B.
    condition combination
    coverage 条件组合覆盖
    参见多条件覆盖(multiple condition
    coverage).
    condition combination
    testing 条件组合测试 参见多条件测试(multiple condition testing).
    condition coverage 条件覆盖
    执行测试套件(test suite)能够覆盖到的条件百
    分比。100%的条件覆盖要求测试到每一个条件语
    句真、假(true,false)的条件。
    condition determination
    coverage 条件决定覆盖
    执行测试套件(test suite)覆盖到的能够独立影
    响判定结果的单个条件的百分比。100%的条件决
    定覆盖意味着100%的判定条件覆盖。
    condition determination
    testing 条件决定测试
    一种白盒测试技术，是对能够独立影响决策结果
    的单独条件的测试。
    condition testing 条件测试
    一种白盒测试技术，设计测试用例以执行条件的
    结果。

    condition outcome 条件结果 条件判定的结果，为真或假。
    confidence test 置信测试 参见冒烟测试(smoke testing)
    configuration 配置
    根据定义的数值、特性及其相关性综合设置一个
    组件或者系统。
    configuration auditing 配置审核
    对配置库及配置项的内容进行检查的过程，比如
    检查标准的一致性。 [IEEE 610]
    configuration control 配置控制
    配置管理的一个方面，包括在正式配置完成之后
    对配置项进行评价、协调、批准或撤消、以及变
    更修改的控制。 [IEEE 610]
    configuration control
    board (CCB) 配置控制委员会
    负责评估、批准或拒绝配置项修改的组织，此组
    织应确保被批准的配置修改的执行。 [IEEE 610]
    configuration
    identification 配置标识
    配置管理的要素之一，包括选择配置项，并在技
    术文档中记录其功能和物理特性。[IEEE 610]
    configuration item 配置项
    配置管理中的硬件、软件或软、硬件结合体的集
    合，在配置管理过程中通常被当做一个实体。
    [IEEE 610]
    configuration
    management 配置管理
    一套技术和管理方面的监督原则，用于确定和记
    录一个配置项的功能和物理属性、控制对这些属
    性的变更、记录和报告变更处理和实现的状态、
    以及验证与指定需求的一致性。[IEEE 610]
    configuration
    management tool 配置管理工具
    支持对配置项进行识别、控制、变更管理、版本
    控制和发布配置项基线(baseline)的工具.[IEEE
    610]
    configuration testing 配置测试 参见可移植性测试(portability testing)
    confirmation testing 确认测试 参见再测试(re-testing)
    conformance testing 一致性测试 参见符合性测试(compliance testing)。
    consistency 一致性
    在系统或组件的各组成部分之间和文档之间无矛
    盾，一致，符合标准的程度。[IEEE 610]
    control flow 控制流
    执行组件或系统中的一系列顺序发生的事件或路
    径。
    control flow graph 控制流图
    通过图形来表示组件或系统中的一系列顺序发生
    的事件或路径。
    control flow path 控制流路径 参见路径(path)
    conversion testing 转换(移植）测试
    用于测试已有系统的数据是否能够转换到替代系
    统上的一种测试。
    COTS 现货软件
    Commercial Off-The-Shelf software 的首字母
    缩写。参见Off-The-Shelf software
    coverage 覆盖
    用于确定执行测试套件所能覆盖项目的程度，通
    常用百分比来表示。
    coverage analysis 覆盖分析
    对测试执行结果进行特定的覆盖项分析，判断其
    是否满足预先定义的标准，是否需要设计额外的
    测试用例。
    coverage item 覆盖项
    作为测试覆盖的基础的一个实体或属性：如等价
    划分(equivalent partitions)或代码语句(code
    statement)等。
    coverage tool 覆盖工具
    对执行测试套件(test suite)能够覆盖的结构元
    素如语句(statement)、分支(branch)等进行客观
    测量的工具。
    custom software 定制软件 参见bespoke software。

    cyclomatic complexity 圈复杂度
    程序中独立路径的数量。一种代码复杂度的衡量
    标准,用来衡量一个模块判定结构的复杂程度,数
    量上表现为独立现行路径条数,即合理的预防错
    误所需测试的最少路径条数,圈复杂度大说明程
    序代码可能质量低且难于测试和维护，根据经验，
    程序的可能错误和高的圈复杂度有着很大关系。
    圈复杂度=L-N + 2P,其中L 表示为结构图（程序
    图）的边数；N 为结构图（程序图）的节点数目；
    P 为无链接部分的数目。[与McCabe 一致]
    cyclomatic number 圈数 参见cyclomatic complexity。
    D
    daily build 每日构建
    每天对整个系统进行编译和链接的开发活动，从
    而保证在任何时候包含所有变更的完整系统是可
    用的。
    data definition 数据定义 给变量赋了值的可执行语句。
    data driven testing 数据驱动测试
    将测试输入和期望输出保存在表格中的一种脚本
    技术。通过这种技术，运行单个控制脚本就可以
    执行表格中所有的测试。像录制/回放这样的测试
    执行工具经常会应用数据驱动测试方法。
    [Fewster and Graham],参见keyword driven
    testing.
    data flow 数据流
    数据对象的顺序的和可能的状态变换的抽象表
    示，对象的状态可以是：创建、使用和销毁。
    [Beizer]
    data flow analysis 数据流分析
    一种基于变量定义和使用的静态分析(static
    analysis)模式。
    data flow coverage 数据流覆盖
    执行测试套件(test suite)能够覆盖已经定义数
    据流的百分比。
    data flow testing 数据流测试
    一种白盒测试设计技术：设计的测试用例用来测
    试变量的定义和使用路径。
    data integrity testing 数据完整性测试 参见database integrity testing。
    database integrity
    testing 数据库完整性测试
    对数据库的存取和管理进行测试的方法和过程，
    确保数据库如预期一样进行存取、处理等数据功
    能，同时也确保数据在存取过程中没有出现不可
    预料的删除、更新和创建。
    dead code 死代码 参见unreachable code。
    debugger 调试器 参见debugging tool。
    debugging 调试 发现、分析和去除软件失败根源的过程。
    debugging tool 调试工具
    程序员用来复现软件失败、研究程序状态并查找
    相应缺陷的工具。调试器可以让程序员单步执行
    程序、在任何程序语句中终止程序和设置、检查
    程序变量。
    decision 判定
    有两个或多个可替换路径控制流的一个程序控制
    点。也是连接两个或多个分支的节点。

    decision condition
    coverage 判定条件覆盖
    执行测试用例套件(test suite)能够覆盖的条件结
    果(condition outcomes)和判定结果(decision
    outcomes)的百分比，100%的判定条件覆盖意味着
    100%的判定覆盖和100%的条件覆盖。
    decision condition
    testing 判定条件测试
    一种白盒测试(white box)设计技术，设计的测试
    用例用来测试条件结果(condition outcoems)和
    判定结果(decision outcomes)。
    decision coverage 判定覆盖
    执行测试套件能够覆盖的判定结果(decsion
    outcomes)的百分比。100％的判定覆盖(decision
    converage)意味着100 的分支覆盖(branch
    coverage)和100％的语句覆盖(statement
    coverage)。
    decision table 决策表
    一个可用来设计测试用例的表格，一般有条件桩、
    行动桩和条件规则条目和行动规则条目组成。
    decision table testing 决策表测试
    一种黑盒测试设计技术，设计的测试用例用来测
    试判定表中各种条件的组合。[Veenendaal]
    decision testing 决策测试
    白盒测试设计技术的一种，设计测试用例来执行
    判定结果。
    decision outcome 判定结果 判定的结果（可以来决定执行哪条分支）。
    defect 缺陷
    可能会导致软件组件或系统无法执行其定义的功
    能的瑕疵，例如：错误的语句或变量定义。如果
    在组件或系统运行中遇到缺陷，可能会导致运行
    的失败。
    defect density 缺陷密度
    将软件组件或系统的缺陷数和软件或者组件规模
    相比的一种度量（标准的度量术语包括，如每千
    行代码、每个类或功能点存在的缺陷数）。
    Defect Detection
    Percentage (DDP) 缺陷发现百分比
    在一个测试阶段发现的缺陷数除以在测试阶段和
    之后其他阶段发现的缺陷总数所得的百分比数。
    defect management 缺陷管理
    发现、研究、处置、去除缺陷的过程。包括记录
    缺陷、分类缺陷和识别缺陷可能造成的影响。[与
    IEEE 1044 一致]
    defect management tool 缺陷管理工具
    一个方便记录和跟踪缺陷的工具，通常包括以缺
    陷修复操作流程为引导的任务分配、缺陷修复、
    重新测试等行为的跟踪和控制，并且提供文档形
    式的报告。参见 incident management tool.
    defect masking 缺陷屏蔽
    一个缺陷阻碍另一个缺陷被发现的情况[与IEEE
    610 一致]
    defect report 缺陷报告
    对造成软件组件或系统不能实现预期功能的缺陷
    进行描述的报告文件。
    defect tracking tool 缺陷跟踪工具 参见defect management tool
    definition-use pair 定义-使用对
    变量在程序中定义和使用的相关性，变量使用包
    括变量计算（比如：乘）或者变量引导程序执行
    一条路径（预定义）。
    deliverable 交付物 过程中生成的交付给客户的（工作）产品。
    design-based testing 基于设计的测试
    根据组件或系统的构架或详细设计设计测试用例
    的一种测试方法（例如：组件或系统之间接口的
    测试）。
    desk checking 桌面检查
    通过手工模拟执行来对软件或规格说明而进行的
    测试。参见 static analysis.
    development testing 开发测试
    通常在开发环境下，开发人员在组件或系统实现
    过程中进行的正式或非正式的测试。[与IEEE 610
    一致]

    deviation 偏离 参见incident。
    deviation report 偏离报告 参见incident report。
    dirty testing 负面测试 参见negative testing。
    documentation testing 文档测试
    关于文档质量的测试，例如:对用户手册或安装手
    册的测试。
    domain 域 一个可供有效输入和/或输出值选择的集合。
    driver 驱动器
    代替某个软件组件来模拟控制和/或调用其他组
    件或系统的软件或测试工具。[与TMap 一致]
    dynamic analysis 动态分析
    组件或系统的执行过程中对其行为评估的过程,
    例如对内存性能、CPU 使用率等的估算。[与IEEE
    610 一致]
    dynamic analysis tool 动态分析工具
    为程序代码提供实时信息的工具。通常用于识别
    未定义的指针，检测指针算法和内存地址分配、
    使用及释放的情况以及对内存泄露进行标记。
    dynamic comparison 动态比较
    在软件运行过程中（例如用测试工具执行），对
    实际结果和期望结果的比较。
    dynamic testing 动态测试 通过运行软件的组件或系统来测试软件。
    E
    efficiency 效率
    一定条件下根据资源的使用情况，软件产品能够
    提供适当性能的能力。[ISO 9126]
    efficiency testing 效率测试 确定测试软件产品效率的测试过程。
    elementary comparison
    testing 基本比较测试
    一种黑盒测试设计技术：根据判定条件覆盖的理
    念，设计测试用例来测试软件各种输入的组合。
    [TMap]
    emulator 仿真器
    一个接受同样输入并产生同样输出的设备、计算
    机程序或系统。[IEEE 610]参见simulator
    entry criteria 入口准则
    进入下个任务（如测试阶段）必须满足的条件。
    准入条件的目的是防止执行不能满足准入条件
    的活动而浪费资源[Gilb and Graham] 。
    entry point 入口点 一个组件的第一个可执行语句。
    equivalence class 等价类 参见equivalence partition。
    equivalence partition 等价类划分
    根据规格说明，输入域或输出域的一个子域内的
    任何值都能使组件或系统产生相同的响应结果。
    equivalence partition
    coverage 等价划分覆盖 执行测试套件能够覆盖到的等价类的百分比。
    equivalence partitioning 等价类划分技术
    黑盒测试用例设计技术：该技术从组件的等价类
    中选取典型的点进行测试。原则上每个等价类中
    至少要选取一个典型的点来设计测试用例。
    error 错误
    人为的产生不正确结果的行为。[与IEEE 610 一
    致]

    error guessing 错误推测
    根据测试人员以往的经验，猜测在组件或系统中
    可能出现的缺陷以及错误，并以此为依据来进行
    特殊的用例设计以暴露这些缺陷。
    error seeding 错误散播
    在组件或系统中有意插入一些已知缺陷（defect）
    的过程，目的是为了得到缺陷的探测率和除去率，
    以及评估系统中遗留缺陷的数量。[IEEE 610]
    error tolerance 容错
    组件或系统存在缺陷的情况下保持连续正常工作
    状态的能力。[与IEEE 610 一致]
    evaluation 评估 参见testing。
    exception handling 异常处理
    组件或系统对错误输入的行为反应。错误输入包
    括人为的输入、其他组件或系统的输入以及内部
    失败引起的输入等。
    executable statement 可执行语句
    语句编译后可以转换为目标代码，同时在程序运
    行的时候可以按步骤执行并且可以对数据进行相
    应的操作。
    exercised 被执行
    测试用例运行后被执行的语句、判定和程序的结
    构元素
    exhaustive testing 穷尽测试
    测试套件包含了软件输入值和前提条件所有可能
    组合的测试方法。
    exit criteria 出口准则
    和利益相关者达成一致的系列通用和专门的条
    件，来正式的定义一个过程的结束点。出口准则
    的目的可以防止将没有完成的任务错误地看成任
    务已经完成。测试中使用的出口准则可以来报告
    和计划什么时候可以停止测试。[与Gilb 和
    Graham 一致]
    exit point 出口点 组件中最后一个可执行语句。
    expected outcome 预期结果 参见expected result。
    expected result 预期结果
    在特定条件下根据规格说明或其他资源说明，组
    件或系统预测的行为。
    experienced-based test
    design technique
    基于经验的测试设
    计技术
    根据测试人员的经验、知识和直觉来进行用例设
    计和/或选择的一种技术。
    exploratory testing 探索性测试
    非正式的测试设计技术：测试人员能动的设计一
    些测试用例，通过执行这些测试用例和在测试中
    得到的信息来设计新的更好的测试用例。[和Bach
    一致]
    F
    fail 失败
    假如测试的实际结果与预期结果不一样，我们就
    认为这个测试的状态为失败。
    failure 失效
    组件/系统与预期的交付、服务或结果存在的偏
    差。[与Fenton 一致]
    failure mode 失效模式
    失效在物理上或功能上的表现。例如，系统在失
    效模式下，可能表现为运行缓慢、输出错误或者
    执行的彻底中断。[IEEE 610]

    Failure Mode and Effect
    Analysis (FMEA)
    失效模式和影响分
    析 （FMEA）
    一个系统的进行风险识别和标识可能的失效模式
    的系统方法，用来预防失效的发生。
    failure rate 失效率
    指定类型中单位度量内发生失效的数目。例如，
    单位时间失效数、单位处理失效数、单位计算机
    运行失效数。[IEEE 610]
    fault 故障 参见 defect。
    fault density 故障密度 参见 defect density。
    Fault Detection
    Percentage (FDP) 故障发现率（FDP） 参见 Defect Detection Percentage (DDP)。
    fault masking 故障屏蔽 参见 defect masking。
    fault tolerance 故障容限
    软件产品存在故障或其指定接口遭到破坏时，继
    续维持特定性能级别的能力。[ISO 9126] 参见
    reliability。
    fault tree analysis 故障树分析 分析产生故障原因的一种方法。
    feasible path 可达路径
    可通过一组输入值和入口条件而执行到的一条路
    径。
    feature 特性
    需求文档指定的或包含的一个组件或者系统的属
    性（例如：reliability, usability 或者 design
    constraints）。 [与IEEE 1008 一致]
    field testing 现场测试 参见 beta testing
    finite state machine 有限状态机
    包含有限数目状态和状态之间转换的一种计算模
    型，同时可能伴随一些可能的（触发）行为。[IEEE
    610]
    finite state testing 有限状态测试 参见 state transition testing。
    formal review 正式评审
    对评审过程及需求文档化的一种特定的评审。例
    如，检视(inspection)。
    frozen test basis 冻结测试基准
    测试基准文档，只能通过正式的变更控制过程进
    行修正。参见baseline
    Functional Point
    Analysis (FPA) 功能点分析
    对信息系统功能进行规模度量的一种方法。该度
    量独立于具体的技术实现，可以作为生产率度量、
    资源需求估算和项目控制的基础。
    functional integration 功能集成
    合并组件/系统以尽早实现基本功能的一种集成
    方法。参见integration testing。
    functional requirement 功能需求
    指定组件/系统必须实现某项功能的需求。[IEEE
    610]
    functional test design
    technique 功能测试设计技术
    通过对组件或系统的功能规格说明分析来进行测
    试用例的设计和/或选择的过程，该过程不涉及软
    件的内部结构。参见 black box test design
    techinque。
    functional testing 功能测试
    通过对组件/系统功能规格说明的分析而进行的
    测试。参见 black box testing。
    functionality 功能性
    软件产品在规定条件下使用时，所提供的功能达
    到宣称的和隐含需求的能力。[ISO 9126]
    functionality testing 功能性测试 判断软件产品功能性的测试过程。

    G
    glass box testing 玻璃盒测试 参见 white box testing
    H
    heuristic evaluation 启发式评估
    一种静态可用性测试技术，判断用户接口和公认
    的可用性原则的符合度。
    high level test case 概要测试用例
    没有具体的（实现级别）输入数据和预期结果的
    测试用例。实际值没有定义或是可变的，而用逻
    辑概念来代替。参见 low level test case。
    horizontal traceability 水平可追踪性
    一个测试级别的需求和相应级别的测试文档（例
    如测试计划、测试设计规格、测试用例规格和测
    试过程规格或测试脚本）之间的可追踪性。
    I
    impact analysis 影响分析
    对需求变更所造成的开发文档、测试文档和组件
    的修改的评估。
    incident 事件 任何有必要调查的事情。[与IEEEE 1008 一致]
    incident logging 事件日志
    记录所发生的（例如，在测试过程中）事件的详
    细情况。
    incident management 事件管理
    识别、调查、采取行动和处理事件的过程。该过
    程包含对事件进行记录、分类并辨识其带来的影
    响。 [IEEE 1044]
    incident management
    tool 事件管理工具
    辅助记录事件并对事件进行状态跟踪的工具。这
    种工具常常具有面向工作流的特性，以跟踪和控
    制事件的资源分配、更正和再测试，并提供报表。
    参见 defect management tool
    incident report 事件报告
    报告任何需要调查的事件(如在测试过程中需要
    调查的事件)的文档。[IEEE 829]

    incremental
    development model 增量开发模型
    一种开发生命周期：项目被划分为一系列增量，
    每一增量都交付整个项目需求中的一部分功能。
    需求按优先级进行划分，并按优先级在适当的增
    量中交付。在这种生命周期模型的一些版本中（但
    不是全部），每个子项目均遵循一个“微型的V
    模型”，具有自有的设计、编码和测试阶段。
    incremental testing 增量测试
    每次集成并测试一个或若干组件/系统，直到所有
    组件/系统都已经被集成或测试的一种测试。
    independence 独立 职责分离，有助于客观地进行测试。 [DO-178b]
    infeasible path 不可达路径 通过任何输入都无法执行到的路径。
    informal review 非正式评审 一种不基于正式（文档化）过程的评审。
    input 输入
    被组件读取的变量（无论存储于组件之内还是之
    外）。
    input domain 输入域 有效输入的集合。参见domain
    input value 输入值 输入的一个实例。参见input
    inspection 审查
    一种同级评审，通过检查文档以检测缺陷，例如
    不符合开发标准，不符合更上层的文档等。这是
    最正式的评审技术，因此总是基于文档化的过程。
    [IEEE 610, IEEE 1028] 参见 peer review
    inspection leader 审查负责人 参见 moderator
    inspector 检视人/审查员 参见 reviewer
    installability 可安装性
    软件产品在指定环境下进行安装的性能。 [ISO
    9126] 参见 portability
    installability testing 可安装性测试
    测试软件产品可安装性的过程。 参见
    portability testing
    installation guide 安装指南
    帮助安装人员完成安装过程的使用说明，可存放
    在任何合适的介质上。可能是操作指南、详细步
    骤、安装向导或任何其他类似的过程描述。
    installation wizard 安装向导
    帮助安装人员完成安装过程的软件，可存放在任
    何合适的介质上。它通常会运行安装过程、反馈
    安装结果，并提示安装选项。
    instrumentation 探测
    在程序中插入附加代码，以便在程序执行时收集
    其执行信息。例如，用于度量代码覆盖。
    instrumenter 探测工具 用于执行探测的软件工具。
    intake test 预测试
    冒烟测试的一种特例，用于决定组件/系统是否能
    够进行更深入的测试。通常在测试执行的初始阶
    段实施。
    integration 集成 把组件/系统合并为更大部件的过程。
    integration testing 集成测试
    一种旨在暴露接口以及集成组件/系统间交互时
    存在的缺陷的测试。参见 component
    integration testing, system integration
    testing
    integration testing in the
    large 系统集成测试 参见 system integration testing
    integration testing in the
    small 组件集成测试 参见 component integration testing
    interface testing 接口测试
    一种集成测试类型，注重于测试组件/系统之间的
    接口。

    interoperability 互操作性
    软件产品与一个或多个指定组件/系统进行交互
    的能力。 [ISO 9126] 参见 functionality
    interoperability testing 互操作性测试
    判定软件产品可交互性的测试过程。参见
    functionality testing
    invalid testing 无效性测试
    使用应该被组件/系统拒绝的输入值进行的测试。
    参见 error tolerance
    isolation testing 隔离测试
    将组件与其周边组件隔离后进行的测试。如果有
    必要，使用桩(stubs)或驱动器(drivers)来模拟
    周边程序。
    item transmittal report 版本发布报告 参见 release note
    iterative development
    model 迭代开发模型
    一种开发生命周期：项目被划分为大量迭代过程。
    一次迭代是一个完整的开发循环，并（对内或对
    外）发布一个可执行的产品，这是正在开发的最
    终产品的一个子集，通过不断迭代最终成型的产
    品。
    K
    key performance
    indicator 关键性能指标 参见 performance indicator
    keyword driven testing 关键字驱动测试
    一种脚本编写技术，所使用的数据文件不单包含
    测试数据和预期结果，还包含与被测程序相关的
    关键词。用于测试的控制脚本通过调用特别的辅
    助脚本来解释这些关键词。
    L
    LCSAJ LCSAJ
    （Linear Code Sequence And Jump）线性代码序
    列和跳转。包含以下三项（通常通过源代码清单
    的行号来识别）：可执行语句的线性序列的开始、
    结束以及在线性序列结尾控制流所转移到的目标
    行。
    LCSAJ coverage LCSAJ 覆盖
    测试套件所检测的组件的 LCSAJ 百分比。 LCSAJ
    达到100％意味着决策覆盖(decision coverage)
    为100％。
    LCSAJ testing LCSAJ 测试
    一种白盒测试设计技术，其测试用例用于执行
    LCSAJ。
    learnability 易学性
    软件产品具有的易于用户学习的能力。[ISO
    9126] 参见usability
    level test plan 级别测试计划
    通常用于一个测试级别(test level)的测试计
    划。参见 test plan

    link testing 组件集成测试 参见 component integration testing
    load testing 负载测试
    一种通过增加负载来测量组件或系统的测试方
    法。例如：通过增加并发用户数和（或）事务数
    量来测量组件或系统能够承受的负载。参见
    stress testing
    logic-coverage testing 逻辑覆盖测试 参见 white box testing [Myers]
    logic-driven testing 逻辑驱动测试 参见 white box testing
    logical test case 逻辑测试用例/抽
    象测试用例
    参见 high level test case
    low level test case 详细测试用例
    具有具体的（实现级别implementation level）
    输入数据和预期结果的测试用例。抽象测试用例
    中所使用的逻辑运算符被替换为对应于逻辑运算
    符作用的实际值。参见 high level test case
    M
    maintenance 维护
    软件产品交付后对其进行的修改，以修正缺陷，
    改善性能或其他属性，或者使其适应新的环境。
    [IEEE 1219]
    maintenance testing 维护测试
    针对运行系统的更改，或者新的环境对运行系统
    的影响而进行的测试。
    maintainability 可维护性
    软件产品是否易于更改，以便修正缺陷、满足新
    的需求、使以后的维护更简单或者适应新的环境。
    [ISO 9126]
    maintainability testing 可维护性测试 判定软件产品的可维护性的测试过程。
    management review 管理评审
    由管理层或其代表执行的对软件采购、供应、开
    发、运作或维护过程的系统化评估，包括监控过
    程、判断计划和进度表的状态、确定需求及其系
    统资源分配，或评估管理方式的效用，以达到正
    常运作的目的。[IEEE 610, IEEE 1028]
    master test plan 主测试计划
    通常针对多个测试级别的测试计划。参见 test
    plan
    maturity 成熟度
    （1）组织在其过程和工作实践上的有效性和高效
    性的能力。 参见 Capability Maturity Model,
    Test Maturity Model。（2）软件产品在存在缺
    陷的情况下避免失效的能力。 [ISO 9126] 参见
    reliability
    measure 测量
    测度时赋予实体某个属性的数值或类别。[ISO
    14598]
    measurement 测度
    给实体赋予一个数值或类别以描述其某个属性的
    过程。 [ISO 14598]
    measurement scale 度量标准 约束数据分析类型的标准。
    memory leak 内存泄漏
    程序的动态存储分配逻辑存在的缺陷，导致内存
    使用完毕后不能收回而不可用，最终导致程序因
    为内存缺乏而运行失败(fail)。

    metric 度量
    测量所使用的方法或者度量标准(measurement
    scale)。 [ISO 14598]
    migration testing 移植测试 参见 conversion testing
    milestone 里程碑
    项目过程中预定义的（中间的）交付物和结果就
    绪的时间点
    mistake 错误 参见 error
    moderator 主持人 负责检视或其他评审过程的负责人或主要人员
    modified condition
    decision coverage
    改进的条件判定覆
    盖
    参见 condition determination coverage
    modified condition
    decision testing
    改进的条件判定测
    试
    参见 condition determination coverage
    testing
    modified multiple
    condition coverage
    改进的复合条件覆
    盖
    参见 condition determination coverage
    modified multiple
    condition testing
    改进的复合条件测
    试
    参见 condition determination coverage
    testing
    module 模块 参见 component
    module testing 模块测试 参见 component testing
    monitor 监测器/监视器
    与被测组件/系统同时运行的软件工具或硬件设
    备，对组件/系统的行为进行监视、记录和分析。
    [IEEE 610]
    monitoring tool 监测工具/监视工
    具
    参见 monitor
    multiple condition 复合条件/多重条
    件
    参见 compound condition
    multiple condition
    coverage 复合条件覆盖
    测试套覆盖的一条语句内的所有单条件结果组合
    的百分比。100％复合条件覆盖意味着100％条件
    判定覆盖(condition determination coverage)。
    multiple condition
    testing 复合条件测试
    一种白盒测试设计技术，测试用例用来覆盖一条
    语句中的单条件所有可能的结果组合。
    mutation analysis 变异分析
    一种确定测试套件完整性的方法，即判定测试套
    件能够区分程序与其微变体之间区别的程度。
    mutation testing 变异测试 参见 back-to-back testing
    N
    N-switch coverage N 切换覆盖
    N+1 个转换的序列在一个测试套件中被覆盖的百
    分比。[Chow]
    N-switch testing N 切换测试
    一种状态转换测试的形式，其测试用例执行N+1
    个转换的所有有效序列。 [Chow] 参见 state
    transition testing

    negative testing 逆向测试
    一种旨在表现组件/系统不能正常工作的测试。逆
    向测试取决于测试人员的想法，态度，而与特定
    的测试途径或测试设计技术无关，例如使用无效
    输入值测试或在异常情况下进行测试。 [Beizer]
    non-conformity 不一致 没有实现指定的需求。 [ISO 9000]
    non-functional
    requirement 非功能需求
    与功能性无关，但与可靠性(reliability)、高效
    性(efficiency)、可用性(usability)、可维护性
    (maintainability)和可移植性(portability)等
    属性相关的需求。
    non-functional testing 非功能测试
    对组件/系统中与功能性无关的属性（例如可靠
    性、高效性、可用性、可维护性和可移植性）进
    行的测试。
    non-functional test
    design techniques
    非功能测试设计技
    术
    推导或选择非功能测试所需测试用例的过程，此
    过程依据对组件/系统的规格说明进行分析，而不
    考虑其内部结构。参见 black box test design
    technique
    O
    off-the-shore software 现货软件
    面向大众市场（即大量用户）开发的软件产品，
    并且以相同的形式交付给许多客户。
    operability 可操作性
    软件产品被用户操作或控制的能力。 [ISO 9126]
    参见 usability
    operational environment 运行环境
    用户或客户现场所安装的硬件和软件产品，被测
    组件/系统将在此环境下使用。软件可能包括操作
    系统、数据库管理系统和其他应用程序。
    operational profile
    testing 运行概况测试
    对系统运作模型（执行短周期任务）及其典型应
    用概率的统计测试。[Musa]
    operational testing 运行测试
    在组件/系统的运作环境下对其进行评估的一种
    测试。 [IEEE 610]
    oracle 基准 参见 test oracle
    outcome 结果 参见 result
    output 输出
    组件填写的一个变量（无论存储在组件内部还是
    外部）。
    output domain 输出域 可从中选取有效输出值的集合。参见 domain
    output value 输出值 输出的一个实例/实值。参见 output

    P
    pair programming 结对编程
    一种软件开发方式，组件的代码（开发和/或测试）
    由两名程序员在同一台计算机上共同编写。这意
    味着实时地执行代码评审。
    pair testing 结对测试
    两个人员，比如两个测试人员、一个开发人员和
    一个测试人员或一个最终用户和一个测试人员，
    一起寻找缺陷。一般地，他们使用同一台计算机
    并在测试期间交替操控。
    partition testing 划分测试 参见 equivalence partitioning [Beizer]
    pass 通过
    如果一个测试的实际结果与预期结果相符，则认
    为此测试通过。
    pass/fail criteria 通过/失败准则
    用于判定测试项（功能）或特性通过或失败的决
    策规则。[IEEE 829]
    path 路径
    组件/系统从入口(entry point)到出口(exit
    point)的一系列事件（例如，可执行语句）。
    path coverage 路径覆盖
    测试套件执行的路径所占的百分比。100％的路径
    覆盖意味着100％的线性代码序列和跳转(LCSAJ)
    覆盖。
    path sensitizing 路径感知 选择一组输入值，以强制执行某指定路径。
    path testing 路径测试
    一种白盒测试设计技术，设计的测试用例用于执
    行路径。
    peer review 同行评审
    由研发产品的同事对软件产品进行的评审，目的
    在于识别缺陷并改进产品。例如，审查
    (inspetion)、技术评审(technical review)和走
    查(walkthrough)。
    performance 性能
    组件/系统在给定的处理周期和吞吐率
    (throughput rate)等约束下，完成指定功能的程
    度。 [IEEE 610] 参见 efficiency
    performance indicator 性能指标
    一种有效性(effectiveness)和/或高效性
    (efficiency)的高级(抽象)度量单位，用于指导
    和控制开发进展。例如，软件交付时间的偏差
    (lead-time slip for software devlopment)。
    [CMMI]
    performance testing 性能测试
    判定软件产品性能的测试过程。参见 efficiency
    testing
    performance testing tool 性能测试工具
    一种支持性能测试的工具，通常有两个功能：负
    载生成(load gerneartion)和测试事务(test
    transation)测量。负载生成可以模拟多用户或者
    大量输入数据。执行时，对选定的事务的响应时
    间进行测量并被记录。性能测试工具通常会生成
    基于测试日志的报告以及负载－响应时间图表。
    phase test plan 阶段测试计划
    通常用于一个测试阶段的测试计划。参见 test
    plan
    portability 可移植性
    软件产品在不同硬件或软件环境之间迁移的简易
    性。[ISO 9126]
    portability testing 可移植性测试 判定软件产品可移植性的测试过程。
    postcondition 后置条件
    执行测试或测试步骤后必须满足的环境和状态条
    件。
    post-execution
    comparison 执行后比较 实际值与预期值的比较，在软件运行结束后执行。
    precondition 前置条件
    对组件/系统执行特定测试或测试步骤之前所必
    须满足的环境和状态条件。
    predicted outcome 预期结果 参见 expected result
    pretest 预测试 参见 intake test
    priority 优先级 赋予某项（业务）重要性的级别，如，缺陷。
    probe effect 探测影响
    在测试时由于测试工具（例如，性能测试工具或
    监测器）对组件/系统产生的影响。比如，使用性
    能测试工具可能会使系统的性能有小幅度降低。
    problem 问题 参见 defect
    problem management 问题管理 参见 defect management
    problem report 问题报告 参见 defect report
    process 过程
    一组将输入转变为输出的相关活动。 [ISO
    12207]
    process cycle test 过程周期测试
    一种黑盒测试设计技术，设计的测试用例用于执
    行业务流程或过程。 [TMap]
    product risk 产品风险 与测试对象有直接关系的风险。参见 risk
    project 项目
    一个项目是一组以符合特定需求为目的的，相互
    协同的，具有开始和结束时间的受控活动。这些
    特定需求包括限定的周期、成本和资源。 [ISO
    9000]
    project risk 项目风险
    与（测试）项目的管理与控制相关的风险。参见
    risk
    program instrumenter 程序插装器 参见 instrumenter
    program testing 程序测试 参见 component testing
    project test plan 项目测试计划 参见 master test plan
    pseudo-random 伪随机
    一个表面上随机的序列，但事实上是根据预定的
    序列生成的。
    Q
    quality 质量
    组件、系统或过程满足指定需求或用户/客户需要
    及期望的程度。 [IEEE 610]
    quality assurance 质量保证
    质量管理的组成部分，提供达到质量要求的可信
    程度。 [ISO 9000]
    quality attribute 质量属性 影响某项质量的特性或特征。 [IEEE 610]
    quality characteristic 质量特征 参见质量属性（quality attribute）。
    quality management 质量管理
    在质量方面指导和控制一个组织的协同活动。通
    常包括建立质量策略和质量目标、质量计划、质
    量控制、质量保证和质量改进。 [ISO 9000]

    R
    random testing 随机测试
    一种黑盒测试设计技术，选择测试用例以匹配某
    种运行概貌情况（可能使用伪随机生成算法）.
    这种技术可用于测试非功能性的属性，比如可靠
    性和性能。
    recorder 记录员 参见 scribe
    record/playback tool 录制/回放工具 参见 capture/playback tool
    recoverability 可恢复性
    软件产品失效(faliure)后，重建其特定性能级别
    以及恢复数据的能力。 [ISO 9126] 参见
    reliability
    recoverability testing 可恢复性测试
    判定软件产品可恢复性的测试过程。参见
    reliability testing
    recovery testing 恢复测试 参见 recoverability testing
    regression testing 回归测试
    测试先前测试过并修改过的程序，确保更改没有
    给软件其他未改变的部分带来新的缺陷
    (defect)。软件修改后或使用环境变更后要执行
    回归测试。
    regulation testing 规范性测试 参见 compliance testing
    release note 发布说明
    标识测试项、测试项配置、目前状态及其他交付
    信息的文档，这些交付信息是由开发、测试和可
    能的其他风险承担者在测试执行阶段开始的时候
    提交的。[ISO 9126]
    reliability 可靠性
    软件产品在一定条件下(规定的时间或操作次数
    等)，执行其必需的功能的能力。 [ISO 9126]
    reliability testing 可靠性测试 判定软件产品可靠性的测试过程。
    replaceability 可替换性
    在相同环境下，软件产品取代另一指定软件产品
    以达到相同目的的能力。 [ISO 9126] 参见
    portability
    requirement 需求
    系统必须满足的，为用户解决问题或达到目的，
    条件或者能力。通过系统或者系统的组件的运行
    以满足合同、标准、规格或其它指定的正式文档
    定义的要求。[IEEE 610]
    requirements-based
    testing 基于需求的测试
    根据需求推导测试目标和测试条件以设计测试用
    例的方法。例如,执行特定功能的测试或探测诸如
    可靠性和可用性等非功能性属性的测试。
    requirements
    management tool 需求管理工具
    一种支持需求记录、需求属性（例如，优先级)
    和注解的工具，能够通过多层次需求和需求变更
    管理达到可追踪性。一些需求管理工具还支持静
    态分析，如一致性检查以及预定义的需求规则之
    间的冲突。
    requirements phase 需求阶段
    在软件生命周期中定义和文档化软件产品需求的
    阶段。 [IEEE 610]

    resource utilization 资源使用
    软件产品在规定的条件下执行其功能时，使用适
    当数量和类型资源的能力。例如，程序使用的主
    存储器和二级存储器容量，需要的临时或溢出文
    件的大小。 [ISO 9126] 参见 efficiency
    resource utilization
    testing 资源使用测试
    判定软件产品资源使用的测试过程。参见
    efficiency testing
    result 结果
    测试执行的成果，包括屏幕输出、数据更改、报
    告和发出的通讯消息。参见 actual result,
    expected result
    resumption criteria 继续准则
    在重新启动被中断(或者延迟)的测试时，必须重
    复执行的测试活动。 [After IEEE 829]
    re-testing 再测试
    重新执行上次失败的测试用例，以验证纠错的正
    确性。
    review 评审
    对产品或产品状态进行的评估，以确定与计划的
    结果所存在的误差，并提供改进建议。例如，管
    理评审(management review)、非正式评审
    (informal review)、技术评审(technical
    review)、审查(inspection)和走查
    (walkthrough)。 [After IEEE 1028]
    reviewer 评审人
    参与评审的人员，辨识并描述被评审产品或项目
    中的异常。在评审过程中，可以选择评审人员从
    不同角度评审或担当不同角色。
    review tool 评审工具
    对评审过程提供支持的工具。典型的功能包括计
    划评审、跟踪管理、通讯支持、协同评审以及对
    具体度量（单位）收集与报告的存储库。
    risk 风险
    将会导致负面结果的因素。通常表达成可能的（负
    面）影响。
    risk analysis 风险分析
    评估识别出的风险以估计其影响和发生的可能性
    的过程。
    risk-based testing 基于风险的测试
    倾向于探索和提供有关产品风险信息的测试。
    [After Gerrard]
    risk control 风险控制
    为降低风险到或控制风险在指定级别而达成的决
    议和实施防范（度量）措施的过程。
    risk identification 风险识别
    使用技术手段（例如，头脑风暴(brainstorming)、
    检验表(checklists)和失败历史记录（faliure
    history））标识风险的过程。
    risk management 风险管理
    对风险进行标识、分析、优先级划分和控制所应
    用的系统化过程和实践。
    risk mitigation 风险缓解 参见 risk control
    robustness 健壮性
    在出现无效输入或压力环境条件下，组件/系统能
    够正常工作的程度。 [IEEE 610] 参见
    error-tolerance, fault-tolerance
    robustness testing 健壮性测试 判定软件产品健壮性的测试。
    root cause 根本原因
    导致不一致的根本因素，并具有通过过程改进彻
    底清除的可能。
    S
    safety 安全性
    软件产品在特定的使用环境中，达到对人、业务、
    软件、财产或环境可接受的危害风险级别的能力
    [ISO 9126]。
    safety testing 安全性测试 判定软件产品安全性的测试。
    sanity test 健全测试 参见冒烟测试(smoke test)。
    scalability 可扩展性
    软件产品可被升级以容纳更多负载的能力
    [Gerrard]
    scalability testing 可扩展性测试 判定软件产品可扩展性的测试。
    scenario testing 场景测试 参见用例测试(use case testing)。
    scribe 记录员
    在评审会议中将每个提及的缺陷和任何过程改进
    建议记录到日志表单上的人员，记录员要确保日
    志表单易于阅读和理解。
    scrīpting language 脚本语言
    一种用于编写可执行测试脚本（这些脚本被测试
    执行工具使用，如录制/回放工具）的编程语言。
    security 安全性
    软件产品防止对程序和数据未授权访问（无论是
    有意的还是无意的）的能力的属性。 [ISO 9126]。
    参见功能性(functionality)。
    security testing 安全性测试
    判定软件产品安全性的测试，参见功能性测试
    (functionality testing)。
    security testing tool 安全性测试工具 测试安全特性和脆弱性的工具。
    security tool 安全性工具 提高运行安全性的工具。
    serviceability
    testing
    服务能力测试 参见维护能力测试(maintainability test)
    severity 严重性
    缺陷对组件/系统的开发或运行造成的影响程度。
    [IEEE 610]
    simulation 模拟
    一个实际或抽象系统的特定行为特征由另一个系
    统来代表。 [ISO 2382/1]
    simulator 模拟器
    测试时所使用的设备、计算机程序或者系统，当
    提供一套控制的输入集时它们的行为或运行与给
    定的系统相似。 [IEEE 610 DO178b]。参见模拟
    器(emulator)
    site acceptance
    testing
    现场验收测试
    用户/客户在他们现场进行的验收测试，以判定组
    件/系统是否符合他们的需求和业务流程，通常包
    括软件和硬件。
    smoke test 冒烟测试
    所有定义的/计划的测试用例的一个子集，它覆盖
    组件/系统的主要功能，以确保程序的绝大部分关
    键功能正常工作，但忽略细节部分。每日构建和
    冒烟测试是业界的最佳实践。参见预测试(intake
    test)。
    software 软件
    计算机程序、过程和可能与计算机系统运行相关
    的文档和数据。
    software feature 软件特性 参见特性(feature)。

    software quality 软件质量
    软件产品的功能和特性总和，能够达到规定的或
    隐含的需求。 [ISO 9126]
    software quality
    characteristic
    软件质量特性 参见质量属性(quality attribute)
    software test incident 软件测试事件 参见事件(incident)
    software test incident
    report
    软件测试事件报告 参见事件报告(incident report)
    Software Usability
    Measurement
    Inventory(SUMI)
    软件可用性度量调
    查表
    一种基于调查表的可用性测试技术，以评估组件/
    系统的可用性，如用户满意度。[Veenendaal]
    source statement 源语句 参见语句(statement)
    specification 规格说明
    说明组件/系统的需求、设计、行为或其他特征的
    文档，常常还包括判断是否满足这些条款的方法。
    理想情况下，文档是以全面、精确、可验证的方
    式进行说明的。
    specification-based
    testing
    基于规格说明的测
    试
    参见黑盒测试(black box testing)
    specification-based
    test design technique
    基于规格说明的测
    试设计技术
    参见黑盒测试设计技术(black box test design
    technique)
    specified input 特定的输入 在规格说明中预测结果的输入。
    stability 稳定性
    软件产品避免因更改后导致非预期结果的能力。
    (ISO9126) 参见可维护性(maintainability)
    standard software 标准软件 参见现货软件(off-the-shelf software)
    standards testing 标准测试 参见一致性测试(compliance testing)
    state diagram 状态图
    一种图表， 描绘组件/系统所能呈现的状态，并
    显示导致或产生从一个状态转变到另一个状态的
    事件或环境。
    state table 状态表
    一种表格，显示每个状态的有效和无效的转换及
    可能的伴随事件。
    state transition 状态转换 组件/系统的两个状态之间的转换。
    state transition
    testing
    状态转换测试
    一种黑盒测试设计技术，所设计的测试用例用来
    执行有效和无效的状态转换。参见N-切换测试
    (N-switch testing)
    statement 语句
    编程语言的一个实体，一般是最小的、不可分割
    的执行单元。
    statement coverage 语句覆盖 由测试套件运行的可执行语句的百分比。
    statement testing 语句测试
    一种白盒测试设计技术，所设计的测试用例用来
    执行语句。
    static analysis 静态分析
    分析软件工件（如：需求或代码），而不执行这
    些工作产品。
    static analysis tool 静态分析工具 参见静态分析器(static analyzer)
    static analyzer 静态分析器 执行静态分析的工具。
    static code analysis 静态代码分析 分析软件的源代码而不执行软件。

    static code analyzer 静态代码分析器
    执行静态代码分析的工具。工具对源代码的一些
    特性进行检查，例如，对编码规范的遵循、质量
    度量或数据流异常等。
    static testing 静态测试
    对组件/系统进行规格或实现级别的测试，而不是
    执行这个软件。比如，代码评审或静态代码分析。
    statistical testing 统计测试
    用输入的统计分布模型来构造有代表性的测试用
    例的一种测试设计技术。参见运行概貌测试
    (operational profile testing)。
    status accounting 状态记录
    配置管理的一个要素,包括纪录和报告有效地管
    理配置所需的信息。这些信息包括被认可的配置
    标识的列表、提议的配置变更的状态和被认可的
    变更的实施状态。[IEEE 610]
    storage 存储 参见资源利用(resource utilization)
    storage testing 存储测试
    参见资源利用测试(resource utilization
    testing)
    stress testing 压力测试
    在规定的或超过规定的需求条件下测试组件/系
    统，以对其进行评估。[IEEE 610] 参见(load
    testing)
    structure-based
    techniques
    基于结构的技术
    参见白盒测试设计技术(white box test design
    technique)
    structural coverage 结构覆盖 基于组件/系统内部结构的覆盖度量
    structural test design
    technique
    结构测试设计技术
    参见白盒测试设计技术(white box test design
    technique)
    structural testing 结构测试 参见白盒测试(white box testing)
    structured
    walkthrough
    结构走查 参见走查(walkthrough)
    stub 桩
    一个软件组件框架的实现或特殊目的实现，用于
    开发和测试另一个调用或依赖于该组件的组件。
    它代替了被调用的组件。 [IEEE 610]
    subpath 子路径 组件中的可执行语句序列。
    suitability 适用性
    软件产品为特定任务和用户目标提供一套合适功
    能的能力。 [ISO 9126]。 参见功能性
    (functionality)
    suspension criteria 暂停准则
    用来（暂时性地）停止对测试条目进行的所有或
    部分测试活动的准则。[IEEE 829]
    syntax testing 语法测试
    一种黑盒测试设计技术，测试用例的设计是以输
    入域和（或）输出域的定义的依据。
    system 系统
    组织在一起实现一个特定功能或一组功能的一套
    组件。[IEEE 610]
    system integration
    testing
    系统集成测试
    测试系统和包的集成；测试与外部组织（如：电
    子数据交换、国际互联网）的接口
    system testing 系统测试
    测试集成系统以验证它是否满足指定需求的过
    程。 [Hetzel]
    T
    technical review 技术评审
    一种同行间的小组讨论活动，主要为了对所采用
    的技术实现方法达成共识。[Gilb 和 Graham,
    IEEE 1028] 参见同行评审(peer review)。
    test 测试 一个或更多测试用例的集合 [IEEE 829]。
    test approach 测试方法
    针对特定项目的测试策略的实现，通常包括根据
    测试项目的目标和风险进行评估之后所做的决
    策、测试过程的起点、采用的测试设计技术、退
    出准则和所执行的测试类型。
    test automation 测试自动化
    应用软件来执行或支持测试活动，如测试管理、
    测试设计、测试执行和结果检验。
    test basis 测试依据
    能够从中推断出组件/系统需求的所有文档。测试
    用例是基于这些文档的。只能通过正式的修正过
    程来修正的文档称为固定测试依据。 [TMap]
    test bed 测试台 参见测试环境(test environment)
    test case 测试用例
    为特定目标或测试条件(例如，执行特定的程序路
    径，或是验证与特定需求的一致性)而制定的一组
    输入值、执行入口条件、预期结果和执行出口条
    件。[IEEE 610]
    test case design
    technique
    测试用例设计技术 参见测试设计技术(test design technique)
    test case
    specification
    测试用例规格说明
    为测试项指定一套测试用例（目标、输入、测试
    动作、期望结果、执行预置条件）的文档。[IEEE
    829]
    test case suite 测试用例集 参见测试套(test suite)
    test charter 测试章程
    对测试目标的陈述，还可能包括关于如何进行测
    试的测试思路。测试章程通常用在探索测试中。
    参见探索测试(exploratory testing)
    test closure 测试结束
    从已完成的测试活动中收集数据，总结基于测试
    件及相关事实和数据的测试结束阶段，包括对测
    试件的最终处理和归档，以及测试过程评估(包含
    测试评估报告的准备)。参见测试过程(test
    process)。
    test comparator 测试比较器 执行自动测试比较的测试工具。
    test comparison 测试对比
    区分被测组件/系统产生的实际结果和期望结果
    的差异的过程。测试对比可以在测试执行时进行
    （动态比较），或在测试执行之后进行。
    test completion
    criteria
    测试完成准则 参见退出准则(exit criteria)。
    test condition 测试条件
    组件/系统中能被一个或多个测试用例验证的条
    目或事件。例如，功能、事务、特性、质量属性
    或者结构化元素。
    test control 测试控制
    当监测到与预期情况背离时,制定和应用一组修
    正动作以使测试项目保持正常进行的测试管理工作。参见测试管理(test management)
    test coverage 测试覆盖 参见覆盖(coverage)
    test cycle 测试周期
    针对一个可分辨的测试对象发布版本而执行的测
    试过程。
    test data 测试数据
    在测试执行之前存在的数据（如在数据库中），
    这些数据与被测组件/系统相互影响。
    test data preparation
    tool
    测试数据准备工具
    一种测试工具，用于从已存在的数据库中挑选数
    据，或创建、生成、操作和编辑数据以备测试。
    test design 测试设计
    参见测试设计规格说明(test design
    specification)
    test design
    specification
    测试设计规格说明
    为一个测试条目指定测试条件（覆盖项）、具体
    测试方法并识别相关高层测试用例的文档
    test design technique 测试设计技术 用来衍生和/或选择测试用例的步骤。
    test design tool 测试设计工具
    通过生成测试输入来支持测试设计的工具。 测试
    输入可能来源于CASE 工具库（如需求管理工具）
    中包含的规格，工具本身包含的特定测试条件。
    test driver 测试驱动器 参见驱动器(driver)。
    test driven
    development
    测试驱动开发
    在开发软件之后，运行测试用例之前，首先开发
    并自动化这些测试用例的一种软件开发方法
    test environment 测试环境
    执行测试需要的环境，包括硬件、仪器、模拟器、
    软件工具和其他支持要素。
    test evaluation report 测试评估报告
    在测试过程的结尾用来总结所有的测试活动和结
    果的文档。也包括测试过程的评估和吸取的教训。
    test execution 测试执行
    对被测组件/系统执行测试，产生实际结果的过
    程。
    test execution
    automation
    测试执行自动化
    使用软件（例如捕捉/回放工具）来控制测试的执
    行、实际结果和期望结果的对比、测试预置条件
    的设置和其它的测试控制和报告功能。
    test execution phase 测试执行阶段
    软件开发生命周期的一个阶段，在这个阶段里执
    行软件产品的组件，并评估软件产品以确定是否
    满足需求。
    test execution
    schedule
    测试执行时间表
    测试过程的执行计划。这些测试过程包含在测试
    执行时间表中，执行时间表列出了执行任务间的
    关联和执行的顺序。
    test execution
    technique
    测试执行技术 用来执行实际测试的方法，包括手工的和自动的。
    test execution tool 测试执行工具
    使用自动化测试脚本执行其他软件（如捕捉/回
    放）的一种测试工具。[Fewster 和 Graham]
    test fail 测试失败 参见失败(fail)。
    test generator 测试产生器
    参见测试数据准备工具(test data preparation
    tool)。
    test harness 测试用具 包含执行测试需要的桩和驱动的测试环境。
    test incident 测试事件 参见事件(incident)。
    test incident report 测试事件报告 参见事件报告(incident report)
    test infrastructure 测试基础设施 执行测试所需的组成物件，包括测试环境、测试

    工具、办公环境和过程。
    test input 测试输入
    在测试执行过程中，测试对象从外部源接收到的
    数据。外部源可以是硬件、软件或人。
    test item 测试项
    需被测试的单个要素。通常是一个测试对象包含
    多个测试项。参见测试对象(test object)。
    test item transmittal
    report
    测试项移交报告 参见发布说明(release note)。
    test leader 测试组长 参见测试经理(test manager)。
    test level 测试级别
    统一组织和管理的一组测试活动。测试级别与项
    目的职责相关联。例如，测试级别有组件测试、
    集成测试、系统测试和验收测试。[TMap]
    test log 测试日志
    按时间顺序排列的有关测试执行所有相关细节的
    记录。
    test logging 测试记录 把测试执行信息写进日志的过程。
    test manager 测试经理
    负责测试和评估测试对象的人。他（她）指导、
    控制、管理测试计划及调整对测试对象的评估。
    test management 测试管理
    计划、估计、监控和控制测试活动，通常由测试
    经理来执行。
    test management tool 测试管理工具
    对测试过程中的测试管理和控制部分提供支持的
    工具。它通常有如下功能：测试件的管理、测试
    计划的制定、结果纪录、过程跟踪、事件管理和
    测试报告。
    Test Maturity Model
    (TMM)
    测试成熟度模型
    测试过程改进的五级阶段框架，它与能力成熟度
    模型(CMM)相关，后者描述了有效测试过程的关键
    要素。
    test monitoring 测试监控
    处理与定时检查测试项目状态等活动相关的测试
    管理工作。准备测试报告来比较实际结果和期望
    结果。参见测试管理(test management)。
    test object 测试对象
    需要测试的组件或系统。参见测试项(test
    item)。
    test objective 测试目标 设计和执行测试的原因或目的。
    test oracle 测试准则
    在测试时确定预期结果与实际结果进行比较的
    源。一个准则可能是现有的系统（用作基准），
    一份用户手册，或者是个人的专业知识，但不可
    以是代码。[Adrion]
    test outcome 测试结果 参见结果(result)。
    test pass 测试通过 参见通过(pass)。
    test performance
    indicator
    测试绩效指标
    一种高级别的度量，表明需要满足的某种程度的
    目标值或准则。通常与过程改进的目标相关。例
    如，缺陷探测率。
    test phase: 测试阶段
    组成项目的一个可管理阶段的一组独特的测试活
    动。例如，某测试级别的执行活动。[Gerrard]
    test plan 测试计划
    描述预期测试活动的范围、方法、资源和进度的
    文档。它标识了测试项、需测试的特性、测试任
    务、任务负责人、测试人员的独立程度、测试环
    境、测试设计技术、测试的进入和退出准则和选
    择的合理性、需要紧急预案的风险，是测试策划
    过程的一份记录。[IEEE 829]
    test planning 测试策划 制定或更新测试计划的活动。

    test policy 测试方针
    描述有关组织测试的原则、方法和主要目标的高
    级文档。
    Test Point Analysis
    (TPA)
    测试点分析（TPA）
    基于功能点分析的一种公式化测试估计方法。
    [TMap]
    test procedure 测试规程
    参见测试规程规范(test procedure
    specification)。
    test procedure
    specification
    测试规程规格说明
    规定了执行测试的一系列行为的文档。也称为测
    试脚本或手工测试脚本。[IEEE 829]
    test process 测试过程
    基本的测试过程包括计划、规约、执行、记录、
    检查完全性和测试结束活动。
    Test Process
    Improvement (TPI)
    测试过程改进
    （TPI）
    用于测试过程改进的一个连续框架，描述了有效
    测试过程的关键要素，特别针对于系统测试和验
    收测试。
    test record 测试记录 参见测试日志(test log)。
    test recording 书写测试记录 参见测试日志(test logging)。
    test repeatability 测试重复性
    一个测试的属性，表明每次执行一个测试时是否
    产生同样的结果。
    test report 测试报告 参见测试总结报告(test summary report)。
    test requirement 测试需求 参见测试条件(test condition)。
    test run 测试运行 对测试对象的特定版本执行测试。
    test run log 测试运行日志 参见测试日志(test log)。
    test result 测试结果 参见结果(result)。
    test scenario 测试场景
    参见测试规程规约(test procedure
    specification)。
    test scrīpt 测试脚本 通常指测试规程规约，尤其是自动化的。
    test set 测试集 参见测试套件(test suite)。
    test situation 测试状况 参见测试条件(test condition)。
    test specification 测试规约说明
    由测试设计规约、测试用例规约和/或测试规程规
    约组成的文档。
    test specification
    technique
    测试规约说明技术 参见测试设计技术(test design technique)。
    test stage 测试阶段 参见测试级别(test level)。
    test strategy 测试策略
    一个高级文档，该文档定义了需要对程序（一个
    或多个项目）执行的测试级别和需要进行的测试。
    test suite 测试套件
    用于被测组件/系统的一组测试用例。在这些测试
    用例中，一个测试的出口条件通常用作下个测试
    的入口条件。
    test summary report 测试总结报告
    总结测试活动和结果的文档。也包括对测试项是
    否符合退出准则进行的评估。
    test target 测试目标 参见退出准则(exit criteria)。
    test technique 测试技术 参见测试设计技术(test design technique)。
    test tool 测试工具
    支持一个或多个测试活动（例如，计划和控制、
    规格制定、建立初始文件和数据、测试执行和测
    试分析）的软件产品。[TMap] 参见 CAST.
    test type 测试类型
    旨在针对特定测试目标，测试组件/系统的一组测
    试活动。例如，功能测试、易用性测试、回归测
    试等。一个测试类型可能发生在一个或多个测试级别或测试阶段上。

    testability 可测试性
    软件产品修改后被测试的能力。[ISO 9126] 参见
    可维护性(maintainability)。
    testability review 可测试性评审
    详细检查测试依据，以判定测试依据在测试过程
    中作为输入文档是否达到质量要求。
    testable requirements 可测的需求
    对需求的一种程度说明，表示是可依据需求进行
    测试设计（以及后续的测试用例）和执行测试，
    以及判断是否满足需求。[IEEE 610]
    tester 测试员 参与测试组件/系统的专业技术人员。
    testing 测试
    包括了所有生命周期活动的过程，有静态的也有
    动态的。涉及到计划、准备和对软件及其相关工
    作产品的评估，以发现缺陷来判定软件或软件的
    工作产品是否满足特定需求，证明它们是否符合
    目标。
    testware 测试件
    在测试过程中产生的测试计划、测试设计和执行
    测试所需要的人工制品。例如，文档、 脚本、输
    入、预期结果、安装和清理步骤、文件、数据库、
    环境和任何在测试中使用的软件和工具。
    [Fewster 和 Graham]
    thread testing 线程测试
    组件集成测试的一个版本，其中，组件的渐进式
    集成遵循需求子集的实现，与按层次的组件集成
    相反。
    time behavīor 时间行为 参见性能(performance)。
    top-down testing
    自顶向下测试 集成测试的一种递增实现方式，首先测试最顶层
    的组件，其它组件使用桩来模拟，然后已被测试
    过的组件用于测试更低层的组件，直到最底层的
    组件被测试。参见集成测试(integration
    testing)。
    traceability
    可追溯性 识别文档和软件中相关联条目的能力。例如，需
    求与相关测试关联。参见水平可跟踪性
    (horizontal traceability)，垂直可跟踪性
    (vertical traceability)。
    U
    understandability 可理解性 软件产品对于用户是否易于理解、软件是否适用、
    怎样应用于特定任务和应用的条件的能力。
    unit 单元 参见组件(component)。
    unit testing 单元测试 参见组件测试(component testing)。
    unreachable code 不可达代码 不能够到达因而不可能被执行的代码。
    usability 可用性 软件能被理解、学习、使用和在特定应用条件下
    吸引用户的能力。[ISO 9126]
    usability testing 可用性测试 用来判定软件产品的可被理解、易学、易操作和
    在特定条件下吸引用户程度的测试。
    use case 用例 用户和系统进行对话过程中的一系列交互，能够
    产生实际的结果。
    use case testing 用例测试 一种黑盒测试设计技术，所设计的测试用例用于
    执行用户场景。
    user acceptance
    testing
    用户验收测试
    参见验收测试(acceptance testing)。
    user scenario testing
    用户场景测试
    参见用例测试(use case testing)。
    user test 用户测试 由真实用户参与的评估组件/系统可用性的测试。
    V
    V-model
    V-模型 描述从需求定义到维护的整个软件开发生命周期
    活动的框架。V-模型说明了测试活动如何集成于
    软件开发生命周期的每个阶段。
    validation 确认 通过检查和提供客观证据来证实特定目的功能或
    应用已经实现。[ISO 9000]
    variable 变量 计算机中的存储元素，软件程序通过其名称来引
    用。
    verification 验证 通过检查和提供客观证据来证实指定的需求是否
    已经满足。[ISO 9000]
    vertical traceability
    垂直可跟踪性
    贯穿开发文档到组件层次的需求跟踪。
    version control 版本控制 参见配置控制(configuration control)。
    volume testing 容量测试 使用大容量数据对系统进行的一种测试。参见资
    源利用测试(resource-utilization testing)。
    W
    walkthrough
    走查 由文档作者逐步陈述文档内容，以收集信息并对
    内容达成共识。[Freedman 和 Weinberg, IEEE
    1028]。参见同行评审(peer review)。
    white-box test design
    technique
    白盒测试设计技术 通过分析组件/系统的内部结构来产生和/或选择
    测试用例的规程。
    white-box testing 白盒测试 通过分析组件/系统的内部结构进行的测试。

    查看(2757) 评论(0) 收藏 分享 管理

  • 要用LoadRunner来确定问题所在，应该用哪些计数器？

    2008-01-14 17:42:12

    Web系统执行某些操作的时候速度很慢，要用LoadRunner来确定问题所在，应该用哪些计数器？

    通用指标（指Web应用服务器、数据库服务器必需测试项）:  
      *   ProcessorTime:   指服务器CPU占用率，一般   平均达到70%时，服务就接近饱和；  
      *   Memory   Available   Mbyte   :       可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；  
      *   Physicsdisk   Time     :   物理磁盘读写时间情况；  
        Web服务器指标：  
      *   Avg   Rps:   平均每秒钟响应次数＝   总请求时间   /   秒数；  
      *   Avg   time   to   last   byte   per   terstion   （mstes）:平均每秒业务角本的迭代次数   ,有人会把这两者混淆；  
      *   Successful   Rounds：成功的请求；  
      *   Failed     Rounds   ：失败的请求；  
      *   Successful     Hits   ：成功的点击次数；  
      *   Failed     Hits   ：失败的点击次数；  
      *   Hits   Per   Second   ：每秒点击次数；  
      *   Successful     Hits   Per   Second   ：每秒成功的点击次数；  
      *   Failed     Hits   Per   Second   ：每秒失败的点击次数；  
      *   Attempted     Connections   ：尝试链接数；  
      数据库服务器指标：  
      *   User   0     Connections   ：用户连接数，也就是数据库的连接数量；  
      *   Number   of   deadlocks：数据库死锁；  
      *   Butter   Cache   hit   ：数据库Cache的命中情况；

    查看(531) 评论(0) 收藏 分享 管理

  • 2008学习任务

    2008-01-14 17:35:42

    2008年已经过去了半个月了，我要开始指定我的学习任务。

    winrunner功能测试工具的学习

    qtp自动化测试工具的学习

    白盒测试的学习

    sql数据库的学习

    我的2008年加油......

    查看(258) 评论(0) 收藏 分享 管理

  • XML

    2008-01-09 16:52:33

    XML是一种标记语言。

    结构化的信息中包含了一些内容（例如文字，图片等）和一些指示出内容的重现手段的标记（例如，在一个章节头部的信息和其脚注处的信息是有不同含义的。）所有的文档都有不同的结构。一种标记语言，是定义文档结构的机制。XML规范定义了一个对文档进行标记的标准。
    什么是文档（Document）当前在XML基础上进行的开发或应用的总数，是非常令人吃惊的（XML开始应用也不过是一年左右的时间，注：该文写于1998年）。在我们的所描述的意图中，单词"Document" 并不单指传统的文档，同样也有"数据格式"的语意。他包括向量图，电子商务处理数据，数学方程式，对象附加数据，服务器APIs，以及数千种结构化信息。

    为什么XML与HTML如此相象？

    非也。在HTML中，标记符号的语意和标记设置是固定的。例如，标记总是处于最顶级的头部，标记根本就用不上。在W3C联盟中，一些浏览器的厂商和WWW网站社区都联合开发和制定了一些HTML的扩展标记，以使得最新的一些技术能够在Web页面上得到展现，并带来一些样式（Stylesheets）上的变化。但是无论如何，这种改变是相当困难的，因为所有的浏览器厂商都得考虑如何保持他们产品的向后兼容性问题。

    对于需要广泛发布信息的人来说，在页面中加入新的标记的就需要浏览者使用最新版本的Netscape或者Internet Explorer浏览器，这也是得不偿失的。

    XML既不固定标记符号的语意，也不固定标记的设置。实际上，在描述性的标记语言中，XML才是一种真正的向后兼容的语言（Meta-language）。另一方面，XML提供了定义标记和结构关联的灵活手段。当我们不需要预先定义标记设置时，也就不需要考虑其语意。一个XML文档的全部标记的语意来自于处理他的应用程序或者是样式表的定义。

    为什么XML与SGML如此相象？

    实际上，XML被定义为SGML的一个应用子集。SGML是ISO8879规定的通用标记语言标准。SGML从被确立为标准起，十几年来不断完善，但是由于过于复杂，在Web上却没有适合其标准的文档。既然XML被定义为SGML的一个子集，那么任何具有完整构造的SGML系统都能够阅读XML文档。反之，阅读一个XML文档倒不需要系统具有SGML的完整构造。XML也可以被看作一个有限的SGML集合。对于纯技术主义者来说，这是一个非常值得注意的重点，一个十分微妙的区别。

    为什么选择XML？

    为了正确的理解XML。理解他为什么被创造是十分重要的。XML被设计成一种结构丰富的文档，所以能够在Web上四处应用。在此之前，我们仅有两种选择，一种是HTML，一种是SGML。
    对于HTML，我们已经讨论过了，他的固定语意的标记不能够提供良好的文档结构。而SGML虽然能够提供良好的结构，但是相对于一个浏览器来说，未免显得过于过于复杂，实施起来也很麻烦。一个完整的SGML系统相当庞大，需要解决的各种复杂问题带来了很高的成本。处理在Web中传送的结构化文档需要一种小巧灵活的机制。
    当然这也并不意味着，XML一定能按照预期中那样全面的替代SGML。XML被设计为在Web上传递结构化的内容，对于一些其他方面的应用，SGML依然是最合适的解决方案，例如创建并长时间储存一些结构混杂的的文档。在许多组织机构中，筛选SGML来生成XML已经成为标准的Web传输方式。

    XML的开发目标

    XML规范展示了如下的目标：
    1． 在Internet上直接使用XML。用户能够象使用HTML文档那样快速而简单的打开和浏览XML文档。在实际应用中，只有当XML浏览器象HTML浏览器那样被大量广泛的使用时，才能达到这个目标。

    2． XML应该支持非常广泛的应用，XML能够在：著作，浏览，内容分析等等领域发挥巨大的作用。当初仅因为需要在Web上传送结构化文档而定义XML的想法到显得十分的狭隘了。

    3． 由于XML可以兼容SGML，所以很多人用他来处理那些来自于组织机构中十分庞大、烦琐，原本需要SGML来处理的信息。XML被设计的很实用，能够兼容已经存在的标准，并且能够解决在Web中传输结构化文档的新问题。

    4． 计算机程序能够很处理的处理XML文档。说得比较通俗一点，任何一个能力相当于计算机系毕业的学生的程序员，都只需要大概两个星期就能编制一个处理XML文档的程序。

    5． 在XML中，随意数值保持足够的小，理想上是0。随意特征不可避免的带来兼容性的问题，以至于用户在共享文档时会出现失败的情况。

    6． XML文档应该保持可读性和一定的清晰程度。如果你没有XML浏览器，或是你从什么地方接受到一个篇幅巨大的XML文档，你也能够通过常用的文字编辑器来阅读他，并且了解大致的意思。

    7． XML的设计应该很快就准备好。通常一个标准的产生需要很长的时间。XML需要能够尽快的被开发出来。

    8． XML的设计应该是结构合理而简洁的。可以用很多种办法实现上面的第4条所提到的目标，归根结底来说，XML应符合EBNF(Extended Backus-Naur Form)的表述规范，并遵从现代编译工具和方法来实现。 从很多点上可以说明SGML的语法是不符合EBNF的表述规范的，写一个合适的SGML解析器需要处理繁杂而少见的工作，而且难以解析语言的特性，XML不应该如此。

    9． XML文档应该是易于创建的。尽管最终需要使用专用的编辑器来创建和修改XML内容，但是那并不是很紧迫的。在中间过渡期，我们可以选择一些其他的方法来创建XML文档：例如直接用手写板生成，或者是使用简单的Shell和Perl脚本来生成，等等。

    10．XML标记的简练是其最大的价值所在。XML并不支持SGML中一些功能强大的特性，但这些特性也使得SGML解析器增加额外的负担。

    查看(860) 评论(0) 收藏 分享 管理

  • Javascrīpt

    2008-01-09 16:51:23

    Javascrīpt是一种基于对象(Object)和事件驱动(Event Driven)并具有安全性能的脚本语言。使用它的目的是与HTML超文本标记语言、Java 脚本语言（Java小程序）一起实现在一个Web页面中连接多个对象，与Web客户交互作用。从而可以开发客户端的应用程序 等。它是通过嵌入或调入到标准的HTML语言中实现的。它的出现弥补了HTML语言的缺陷，它是Java与HTML折衷的选择，具有以下几个基本特点：

    1、是一种脚本编写语言
    Javascrīpt是一种脚本语言，它采用小程序段的方式实现编程。像其它脚本语言一样,Javascrīpt同样已是一种解释性语言,它提供了一个易的开发过程。它的基本结构形式与C、C++、VB、Delphi十分类似。但它不像这些语言一样，需要先编译，而是在程序运行过程中被逐行地解释。它与HTML标识结合在一起，从而方便用户的使用操作。
    2、基于对象的语言。
    Javascrīpt是一种基于对象的语言，同时以可以看作一种面向对象的。这意味着它能运用自己已经创建的对象。因此，许多功能可以来自于脚本环境中对象的方法与脚本的相互作用。
    3、简单性
    Javascrīpt的简单性主要体现在：首先它是一种基于Java基本语句和控制流之上的简单而紧凑的设计, 从而对于学习Java是一种非常好的过渡。其次它的变量类型是采用弱类型，并未使用严格的数据类型。
    4、安全性
    Javascrīpt是一种安全性语言，它不允许访问本地的硬盘，并不能将数据存入到服务器上，不允许对网络文档进行修改和删除，只能通过浏览器实现信息浏览或动态交互。从而有效地防止数据的丢失。
    5、动态性的
    Javascrīpt是动态的，它可以直接对用户或客户输入做出响应，无须经过Web服务程序。它对用户的反映响应，是采用以事件驱动的方式进行的。所谓事件驱动，就是指在主页(Home Page)中执行了某种操作所产生的动作，就称为“事件”(Event)。比如按下鼠标、移动窗口、选择菜单等都可以视为事件。当事件发生后，可能会引起相应的事件响应。
    6、跨平台性
    Javascrīpt是依赖于浏览器本身，与操作环境无关，只要能运行浏览器的计算机，并支持Javascrīpt的浏览器就可正确执行。从而实现了“编写一次,走遍天下”的梦想。实际上Javascrīpt最杰出之处在于可以用很小的程序做大量的事。无须有高性能的电脑，软件仅需一个字处理软件及一浏览器，无须WEB服务器通道，通过自己的电脑即可完成所有的事情。

    综合所述Javascrīpt是一种新的描述语言，它可以被嵌入到HTML的文件之中。Javascrīpt语言可以做到回应使用者的需求事件(如：form的输入)，而不用任何的网路来回传输资料，所以当一位使用者输入一项资料时，它不用经过传给伺服端(server)处理，再传回来的过程，而直接可以被客户端 (client) 的应用程式所处理。

    查看(597) 评论(0) 收藏 分享 管理

  • 界面与功能测试

    2008-01-07 11:02:54

    • 对文本框进行测试

      　a,输入正常的字母或数字。
      　b,输入已存在的文件的名称；
      　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
      　d,输入默认值，空白，空格；
      　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
      　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
      　g,输入特殊字符集，例如，NUL及\n等；
      　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
      　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

    在测试过程中所用到的测试方法：

    　1,输入非法数据；
    　2,输入默认值；
    　3,输入特殊字符集；
    　4,输入使缓冲区溢出的数据；
    　5,输入相同的文件名；

    命令按钮控件的测试

    测试方法：

    　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
    　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
    　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

    单选按钮控件的测试

    测试方法：

    　a,一组单选按钮不能同时选中，只能选中一个。
    　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
    　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

    up－down控件文本框的测试

    测试方法：

    　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
    　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
    　c,直接输入超边界值，系统应该提示重新输入；
    　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
    　e,输入字符。此时系统应提示输入有误。

    组合列表框的测试

    测试方法：

    　a,条目内容正确，其详细条目内容可以根据需求说明确定；
    　b,逐一执行列表框中每个条目的功能；
    　c,检查能否向组合列表框输入数据；

    复选框的测试

    测试方法：

    　a,多个复选框可以被同时选中；
    　b,多个复选框可以被部分选中；
    　c,多个复选框可以都不被选中；
    　d,逐一执行每个复选框的功能；

    列表框控件的测试

    测试方法：

    　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
    　b,列表框的内容较多时要使用滚动条；
    　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

    滚动条控件的测试

    要注意一下几点：

    　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
    　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
    　c,单击滚动条；
    　d,用滚轮控制滚动条；
    　e,滚动条的上下按钮。

    各种控件在窗体中混和使用时的测试

    　a,控件间的相互作用；
    　b,tab键的顺序，一般是从上到下，从左到右；
    　c,热键的使用，逐一测试；
    　d,enter键和esc键的使用；

    在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

    ps:密码输入框测试时要特别注意进行字母大写输入的测试。

    查找替换操作
    　案例演示:打开word中的"替换"对话框
    　测试本功能有通过测试和失败测试两种情况
    　通过测试:

    　1,输入内容直接查找,或查找全部
    　2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

    失败测试:
    　1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试    ;
    　2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

    替换测试大体相同.
    　关于编辑操作窗口的功能测试的用例    :
    　1,关闭查找替换窗口.不执行任何操作,直接退出    ;
    　2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试    ;
    　3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色    .
    　4,热键, Tab键.回车键的使用.

    插入操作
    　1,插入文件
    　测试的情况
    　a,插入文件;
    　b,插入图像    ;
    　c,在文档中插入文档本身    ;
    　d,移除插入的源文件    ;
    　e,更换插入的源文件的内容;

    2,链接文件
    　测试方法:
    　a,插入链接文件    ;
    　b,在文档中链接文档本身    ;
    　c,移除插入的源文件    ;
    　d,更换插入的源文件的内容.

    3,插入对象
    　要测试的内容
    　a,插入程序允许的对象,如,在word中插入excel工作表;
    　b,修改所插入对象的内容.插入的对象仍能正确显示    ;
    　c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

    编辑操作
    　编辑操作包括剪切,复制,粘贴操作.

    测试剪切操作的方法
    　a,对文本,文本框,图文框进行剪切;
    　b,剪切图像
    　c,文本图像混合剪切
    　复制操作方法与剪切类似.

    测试时,主要是对粘贴操作的测试,方法是:
    　a,粘贴剪切的文本,文本框及图文框    ;
    　b,粘贴所剪切的图像    ;
    　c,剪切后,在不同的程序中粘贴
    　d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
    　e,利用粘贴操作强制输入程序所不允许输入的数据.

    界面测试用例的设计方法
    　1,窗体
    　测试窗体的方法:
    　a,窗体大小,大小要合适,控件布局合理    ;
    　b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确    ;
    　c,缩放窗体,窗体上的控件应随窗体的大小变化而变化    ;
    　d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常    ;
    　进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

    2,控件
    　测试方法:
    　a,窗体或控件的字体和大小要一致    ;
    　b,注意全角,半角混合
    　c,无中英文混合.

    菜单

    进行测试时要注意
    　a,选择菜单是否可以正常工作,并与实际执行内容一致;
    　b,是否有错别字    :
    　c,快捷键是否重复    ;
    　d,热键是否重复    ;
    　e,快捷键与热键操作是否有效
    　f,是否存在中英文混合
    　g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
    　h,鼠标右键快捷菜单

    特殊属性
    　1,安装界面应有公司介绍或产品介绍,有公司的图标
    　2,主界面及大多数界面最好有公司图标
    　3,选择"帮助"->"关于"命令,应看

     

    查看(504) 评论(0) 收藏 分享 管理

  • web 测试

    2008-01-07 10:48:31

    web test

    1页面部分
    （1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
    （2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
    （3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
    （4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
    （5） 页面特殊效果显示是否正确

    2     页面元素部分
    （1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
    （2）素是否显示（元素是否存在）
    （3）页面元素是否显示正确（主要针对文字、图形、签章）
    （4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
    （5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
    （6） 页面元素的容错性列表（如输入框、时间列表或日历）
    （7） 页面元素的容错性是否存在
    （8） 页面元素的容错性是否正确

    3     功能部分
    （1） 数据初始化是否执行
    （2） 数据初始化是否正确
    （3） 数据处理功能是否执行
    （4） 数据处理功能是否正确
    （5） 数据保存是否执行
    （6） 数据保存是否正确
    （7） 是否对其他功能有影响
    （8） 如果影响其他功能，系统能否作出正确的反应
    （9） 其他错误
    （10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
    如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
    单项功能测试（增加、修改、查询、删除）
    增加——>增加——>增加 （连续增加测试）
    增加——>删除
    增加——>删除——>增加 （新增加的内容与删除内容一致）
    增加——>修改——>删除
    修改——>修改——>修改 （连续修改测试）
    修改——>增加 （新增加的内容与修改前内容一致）
    修改——>删除
    修改——>删除——>增加 （新增加的内容与删除内容一致）
    删除——>删除——>删除 （连续删除测试）
    （11）查询功能分为两种情况，验证操作结果。
    一、打开页面时自动显示结果，则不特别强调；
    二、需要手工操作进行查询，则每次在其他功能完成后进行。
    4     提示信息
    （1） 成功、失败提示
    （2） 操作结果提示
    （3） 确认提示
    （4） 危险操作、重要操作提示
    （5） 返回页面 提示后显示的页面
    5     容错性
    注意以下几种情况
    （1） 为空、非空
    （2） 唯一性
    （3 ）字长、格式
    （4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
    （5） 日期、时间
    （6） 特殊字符 （对数据库）英文单、双引号，&符号
    6     权限部分
    功能权限： 指定用户可以使用那些功能，不能使用那些功能
    数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
    以合并到功能测试
    操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
    并到功能测试
    权限变化： 可以合并到功能测试

    （1） 功能权限是否存在
    （2 ）功能权限是否正确
    （3） 数据权限是否存在
    （4） 数据权限是否正确
    （5）操作权限是否存在
    （6） 操作权限是否正确
    （7） 引起权限变化的功能列表
    （8） 功能权限变化还是数据权限变化，或两者兼有
    （9） 权限变化是否正确

    7     键盘操作
    （1） Tab键的使用
    （2） 上下方向键的使用
    （3） Enter键的使用
    （4） 系统设定快捷键的使用（如果设置有快捷键）

    8     测试中还应注意的其他事项
    （6） 完整性：是否是一个整体，没有功能缺损
    （7） 易用性：使用是否方便
    （8） 一致性：类似的问题用类似的方法处理
    （9） 提示信息：提示信息是否完整、正确、详细
    （10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
    （11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
    （12） 可扩展性：是否由升级的余地，是否保留了接口
    （13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
    （14） 运行速度：运行的快慢，带宽占用情况

    有几点：
    1.    功能点测试：是否满足需求所要求的功能
    2.    字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
    3.    字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错    .
    4.    标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确    .
    5.    中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错    .
    6.    信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理    .
    7.    界面测试：界面的正确性、一致性、友好性、易用性。

    用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
    1.    易用性检查：确保软件易于理解，方便使用。
    2.    一致性检查：
    a.    注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
    b.    提示信息的表达方式是否一致。
    c.    按钮排列顺序是否一致。
    d.back, cancel    等按钮跳转页面处理是否一致。
    e.    各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
    3.    正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
    4.    友好性检查：
    a.    提示信息是否友好.
    b.    系统应该在用户执行错误的操作之前提出警告，提示信息    .
    c.    页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
    5.    合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
    6.    检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
    7.    页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理

    ·      

    查看(347) 评论(0) 收藏 分享 管理

  • 关于点击率吞吐量的曲线

    2008-01-07 10:46:40

     因为在客户端发request的时候，是不会管服务器的状态的。

            下面打个比方，具体数据，不可做任何参考，只是我临时编的。
            比如：服务器可以同时每秒处理100次点击，这时，需要调用服务器的一些资源来处理，像：JDBC连接、内存、开socket等等，其他的用户呢？应该都在排队状态，而服务器处理完了前面的用户后，需要一些时间来释放这些被占用的资源，假设为1秒，如果LR采样的时长为2秒，那么服务器处理的用户应该为50次点击／每秒，按这种理想状态，点击率的图应该是比较平稳的。
            但是，系统受的压力会随着点击的增加而增加，系统性能也就慢慢的下降，例如释放资源的速度开始变慢、换页开始频繁，那么，后面的点击造成的请求，很有可能需要等待的时间随机变长。但是采样的频率是不变的，所以后面的采样值应该慢慢的变小。
            也就是像有些图中所显示的那样：随着场景时间的持续，点击率，吞吐量等图的曲线慢慢的下降。

            而出现超时的现象也很好解释了，无非是有些请求，等待的时间太长了。

            有些图呢是比较稳定的，曲线平稳，这时可以认为，系统可以承受当前用户量的压力。

            而有些场景会出很多超时的错，这就有可能是系统承受不了这种的压力，或者配置上有些问题。

            需要综合分析了。

    查看(605) 评论(0) 收藏 分享 管理

  • 如何成为伟大的软件测试工程师

    2008-01-07 10:31:43

    Hallmarks of a Great Tester

    If you ask me, I'll tell you a great tester

    Is devious

    A great tester has a streak of deviousness.  Anyone can follow the lists of test cases that abundantly fill most books on testing.  A great tester can move beyond these lists and dream up an endless series of gnarly methods for attacking the program.  A great tester is described by developers as "sick" and "demented".

    Is curious

    A great tester is interested by everything.  A great tester wants to understand why everything works that way it does.  The best (or worst, depending on your point of view) bugs are a result of interaction between two pieces of software (applications, modules, components, whatever).  A great tester knows that understanding how something works leads directly to understanding how that something interacts with another something, which interaction leads directly to bugs.  A great tester manifests this curiosity in every aspect of life:  how does marketing work?  How are construction cranes built?  Why do they add rebar to concrete?  How are crayons made?  A great tester's curiosity knows no bounds.

    Is excited by bugs

    A great tester thinks bugs are cool.  A great tester shows up in a developer's office on a regular basis with a big grin eager to show off the latest nifty keen horridly awful bug that the tester found in the developer's code.  A great tester boasts about bugs to other testers and eagerly listens to other testers' exploits.

    Knows there are always more bugs

    A great tester knows that no application is ever bug free.  A great tester knows that an application that seems to be bug free is really full of bugs they haven't thought to look for.  A great tester is always on the lookout for new types of bugs.  A great tester views every bug found by a customer as a sign they missed an entire class of bugs.

    Stays on track

    A great tester knows that finding and isolating bugs to their root cause requires focus.  A great tester doesn't ignore bugs found along the way, but postpones investigating them until the current bug is nailed.  (And, of course, gleefully told to the corresponding developer.  And boasted about to other testers.)

    Scopes appropriately

    A great tester knows that they will not have sufficient time to run every test case they would like to run.  A great tester prioritizes and scopes their tests so that the tests most likely to find the bugs most likely to affect the customer are executed first.

    Investigates weird behavīor

    A great tester watches for odd occurrences.  Icons that display one position off from where they should and radio buttons that don't stay set may be a simple programming error, but a great tester knows that such oddities are just as likely to be but the tip of a nasty bug.  A great tester goes beyond "That's weird but that's life" to "A-ha!  That's what's going on!"

    Writes precise bugs

    A great tester takes the time to narrow a bug down to the minimum number of steps necessary to reproduce a bug.  A great tester tests around a bug to understand what the bug actually is.  A great tester writes bugs that state the bug exactly and clearly distinguish between what is proven fact and what is conjecture on the part of the tester.

    Has passion for the customer

    A great tester knows that they are the last defense against the customer receiving a product that doesn't serve the customer's needs.  A great tester understands every aspect of the customer.  A great tester understands what the customer needs to do and how the customer wants to use the product.  A great tester looks beyond the customer's needs to see how the product can revolutionize the customer's tasks.  A great tester promotes the customer's point of view throughout the product cycle, from the first nascent product vision through specifying and implementing features to cutting features and triaging bugs to product release and ongoing maintenance.  A great tester helps the rest of the product team understand the customer as well as they do.

    Is a specializing generalist

    A great tester is completely familiar with every detail of their feature.  A great tester also understands how their feature fits into and affects the entire product.  A great tester is willing to change or even cut their feature in order to make the product as a whole better.

    Picks their fights

    A great tester recognizes that fixing every bug is often not worth the resources that would be required.  A great tester balances each bug against each other bug and allows some bugs to be shipped so that other bugs can be fixed.

    Stands their ground

    A great tester knows that some bugs just have to be fixed.  A great tester is willing to be obstinate and obdurate and to ruffle feathers if necessary in order to ensure that a must fix bug is in fact fixed.  A great tester calmly shows why the bug must be fixed and convinces the rest of the team that it indeed can't be shipped.

    Can ask developers where the bathroom is

    Visitors to a foreign country are well advised to become familiar with the language and customs of the country, enough so that they can get a cab back to their hotel, ask for directions to the bathroom, and know whether shaking hands is the height of civility or completely gauche.  Likewise, a great tester is familiar with the language and customs of developers.  A great tester understands UML well enough to get the gist of UML diagrams and to draw a class or sequence diagram without making developers laugh too hard.  A great tester can write code at least as well as first year programming college students.  A great tester understands design concepts sufficiently to participate in design discussions and reviews without being asked to leave the room.

    Knows testability is just one of many concerns

    A great tester knows the only way to truly test an application is to build testability in to every aspect of the product.  A great tester analyzes the product's architecture, design, and features, and develops a plethora of ideas for ensuring the product can be tested.  A great tester, however, knows that testability is not the only factor affecting the architecture, design and features.  A great tester balances testability against the other factors and helps the team create the right mix.

    Knows when to ask for help

    A great tester takes pleasure in a challenge.  A great tester, then, enjoys banging up against a brick wall and slowly breaking through it.  Some walls are thicker than others, however, and sometimes the wall has a tester-size hole that the tester continually manages to miss.  A great tester realizes when it's time to ask for help and does so.  A great tester knows who to ask for help.  A great tester knows there isn't any shame in asking for help.

    Makes time for training

    A great tester knows that the only way to continue to be a great tester is to never stop learning.  A great tester doesn't limit this education to testing, either, but also researches programming, program management, marketing, and anything else that is remotely related to the process of creating software.

    Never stops testing

    A great tester goes beyond feature boundaries and tests throughout the product.  A great tester tests other products.  A great tester tests books, refrigerators, lights, doors...anything in any part of their life that makes them go "That's not right".


    *** Comments, questions, feedback?   Want a fun job on a great team?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need testers, and my team needs a data binding developer, program managers, and a product manager.  Great coding skills required for all positions.

    查看(819) 评论(2) 收藏 分享 管理

  • 测试工具大全(各类测试工具简介)转载

    2007-08-10 13:48:59

    企业级自动化测试工具WinRunner

     

    提名理由：Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

    工业标准级负载测试工具Loadrunner

     

    提名理由：LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

    全球测试管理系统testdirector

     

    提名理由：TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

    功能测试工具Rational Robot

     

    提名理由：IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

    单元测试工具xUnit系列

     

    提名理由：目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。

    功能测试工具SilkTest

     

    提名理由：Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。 

    性能测试工具WAS

     

    提名理由：Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

    自动化白盒测试工具Jtest

     

    提名理由：Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。

    功能和性能测试的工具JMeter

     

    提名理由：JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

    性能测试和分析工具WEBLODE

     

    提名理由：webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。

     测试工具大全

    Author: Vince

    工具类别 工具名称 生产厂商 相关网站
    通用功能自动化测试工具 Winrunner Mercury
    Quicktest pro Mercury
    Xrunner Mercury
    QARun Compuware
    TestPartner Compuware
    WebKing Parasoft http://www.parasoft.com
    Robot IBM Rational http://www.ibm.com/cn
    Visual Test IBM Rational http://www.ibm.com/cn
    Functional Tester IBM Rational http://www.ibm.com/cn
    SilkTest Segue
    SilkTest International Segue
    e-Tester Empirix
    WebFT Radview
    TestComplete AutomatedQA
    QA Wizard Seapine
    Software EggPlant RedStone
    Test Edition Microsoft Visual Studio
    PureTest Minq
    Autotester Autotester
    Testbench400 Original Software
    TestExpert VEReCOMM
    TestRunner Qronus
    TTCN suite Telelogic http://www.telelogic.com.cn
    QC/Replay Centerline
    Web AutoTester
    eValid Software Research
    WebART OCLC
    MaxQ 开源
    WebInject 开源
    Marathon 开源
    性能测试/监控工具  LoadRunner Mercury
    SiteScope Mercury
    Topaz Mercury
    QaLoad Compuware
    PerformaSure/benchmark Quest
    Silkperformer Segue
    Silkperformer Lite Segue
    SilkCentralTM Performance Manager Segue
    e-Load Empirix
    Robot IBM Rational http://www.ibm.com/cn
    Performance Tester IBM Rational http://www.ibm.com/cn
    WebLoad RadView
    Web applicaton stress tool  Microsoft
    Application center test Microsoft
    PureLoad Minq
    Athene APR Metron
    ForeCast Facilita
    Impact/Impact for CBT Cyrano
    Berkeley Laboratory sniffer Lawrence
    Jmeter 开源
    openSTA 开源
    Siege 开源
    StressMark 开源
    DBMonster 开源
    白盒测试/代码分析工具  VcTester ezTester http://www.eztester.com
    Jtest Parasoft http://www.parasoft.com
    C++test Parasoft http://www.parasoft.com
    SOA test Parasoft http://www.parasoft.com
    .test Parasoft http://www.parasoft.com
    Codewizard Parasoft http://www.parasoft.com
    Insure++ Parasoft http://www.parasoft.com
    DataRecon Parasoft http://www.parasoft.com
    Numega devpartner studio Compuware
    DevPartnerJavaEdition Compuware
    BoundsChecker Compuware
    SmartCheck Compuware
    DBPartner Compuware
    Bean-test Empirix
    Aqtime AutomatedQA
    QESatJava AutomatedQA
    Visual Unit Unitware
    PC-lint Gimpel Software
    Macabe Macabe
    Optimizeit Suite Borland
    JProbe Suite Quest Software
    Application assurance suite Quest Software
    Sql optimizer Quest Software
    Jprofiler ej-technologies
    workbench Cyrano
    Logiscope TeleLogic http://www.telelogic.com.cn
    rulecheck TeleLogic http://www.telelogic.com.cn
    SilkPerformer Component Test Edition Segue
    Purifyplus IBM rational http://www.ibm.com/cn
    Rational Test Realtime IBM rational http://www.ibm.com/cn
    junit 开源
    cactus 开源
    Hansel 开源
    TestNG 开源
    StrutsTestCase 开源
    JFCUnit 开源
    Httpunit 开源
    Dunit 开源
    cppunit 开源 http://sourceforge.net/projects/cppunit
    Nunit 开源
    Xunit 开源
    JTR 开源
    MallocDebug Linux平台工具
    Valgrind Linux平台工具
    Kcachegrind Linux平台工具
    dmalloc Linux平台工具
    ElectricFence Linux平台工具
    LeakTracer Linux平台工具
    memprof Linux平台工具
    ccmalloc Linux平台工具
    mprof Linux平台工具
    yamd Linux平台工具
    njamd Linux平台工具
    mpatrol Linux平台工具
    嵌入式测试工具 VcTester ezTester http://www.eztester.com
    codetest Metrowerks
    Cantata/cantana++ IPL
    IceMaster Reflex Technology
    System test Reflex Technology
    scorecast DDC-I
    Testquest Testquest
    UniText ATTOL
    vectorcast Vector software
    testrunner Qronus
    Logiscope Telelogic http://www.telelogic.com.cn
    测试管理工具 TestDirector(QualityCenter) Mercury
    QADirector Compuware
    certify Worksoft
    Product manager Aimware
    SilkCentral Test Manager Segue
    Doors Telelogic http://www.telelogic.com.cn
    e-manager Empirix
    testmanager IBM Rational http://www.ibm.com/cn
    TestView Manager RadView
    Professional T-Plan
    缺陷管理工具 TestDirector(QualityCenter) Mercury
    ClearQuest IBM Rational http://www.ibm.com/cn
    TrackRecord Compuware
    TestTrack pro Seapine
    TrueTrack McCabe
    Devtrack Techexcel
    Notes IBM Lotus
    SilkCentral Issue Manager Segue
    PVCS Tracker Merant
    AR System Remedy
    URTrack LealSoft
    Butterfly Hansky
    Bugzilla 开源
    Mantis 开源
    JIRA 开源
    BugFree 开源
    配置管理工具 ClearCase IBM Rational http://www.ibm.com/cn
    PVCS Version Manager Merant
    VCS Diamond
    StarTeam Borland
    Perforce Perforce
    TRUEchange McCabe
    SYNERGY CM  Telelogic http://www.telelogic.com.cn
    VSS Microsoft
    Firefly Hansky
    CVS Subversion
    SCCS RCS
    CCC/Harvest Computer Associates

    查看(351) 评论(1) 收藏 分享 管理

  • 黑盒测试 (转载)

    2007-08-10 13:45:36

    一、黑盒测试在快速应用开发（rad）环境中的重要作用

    　　软件测试方法一般分为两种：白盒测试与黑盒测试。其中，白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，着重于程序的内部结构及算法，通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，实际上是站在最终用户的立场上，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。

    　　随着rad环境的发展，软件工程面临新的挑战，其中包括：

    　　●应用系统的规模越来越庞大，结构越来越复杂；

    　　●开发团队人员越来越多，分工越来越细；

    　　●项目投资日益提高，导致投资风险增大。

    　　在这样一种背景下，软件质量面临着更大的危机，而解决问题的关键正是黑盒测试，可是由于传统的黑盒测试往往局限于手工测试，凭借工程人员的经验自发地进行，缺乏严格的测试管理机制，因而效果并不明显。

    　　在分发一个应用系统之前，若没有经过科学、周密的黑盒测试，就相当于将大量隐含的缺陷（defect）交付到最终用户手中，这对于开发团队自身、项目投资方及最终用户来说都是不负责任的表现，也将严重损害三方的利益。

    　　今天，软件的质量要求越来越受到重视，在对软件的质量监督中，黑盒测试起着重要的、不可替代的作用；而随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。

    　　二、黑盒测试的操作步骤

    　　在传统的软件开发生命周期当中，测试工作往往被搁置到整个开发过程的后期进行，也就是说，当应用程序的编码工作已经基本完成，才开始进行测试，这样做的缺点在于：

    　　a）由于应用程序庞大而复杂，测试工作千头万绪，测试人员难以组织科学、全面的测试用例，从而大幅度提高了测试成本，并严重影响测试的全面性和有效性；

    　　b）由于缺陷所涉及的模块从开发到测试之间的时间间隔较长，使得程序员的修改和维护工作要付出更大的代价；

    　　c）由于受到分发日期的限制，测试工作往往是在忙碌中结束的，而将大量的缺陷遗留给最终用户，也就是说，真正的测试工作实际上是由最终用户来完成的。

    　　因此，为了保证测试工作科学、精确、全面、有序地进行，应该采取一边开发一边测试的策略，使得开发工作与测试工作平行进行，这也就是俗话所说的“越早测试越好”的概念。

    　　一套完整的测试应该由五个阶段组成：

    　　1．测试计划

    　　首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

    　　2．测试设计

    　　将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

    　　3．测试开发

    　　建立可重复使用的自动测试过程。

    　　4．测试执行

    　　执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

    　　5．测试评估

    　　结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

    　　显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。

    　　三、手工测试与自动测试的比较

    　　手工测试无法保证黑盒测试的科学性与严密性，这是因为：

    　　●测试人员要负责大量文档、报表的制订和整理工作，会变得力不从心；

    　　●受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试；

    　　●如果修正缺陷所花费的时间相当长，回归测试将变得异常困难；

    　　●对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含混不清，没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率；

    　　●反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一，测试花费的时间越长，测试的严格性也就越低；

    　　●难以对不可视对象或对象的不可视属性进行测试。

    　　因此，自动测试成为最佳的解决方案。所谓自动测试，实际上是将大量的重复性工作交给计算机去完成，一个优秀的自动测试工具，不但可以满足科学测试的基本要求，而且可以节约大量的时间、成本、人员和资源，并且测试脚本可以被重复利用（包括被不同的项目所利用）。

    查看(221) 评论(0) 收藏 分享 管理

Open Toolbar