β测试

β测试是一种通过将产品发布到真实世界并收集反馈，从而确定为产品正式发布做好准备的过程。听起来b测试好像很简单，但b测试实际上是一个非常复杂的过程。当b测试执行失败时，基本无法获取有价值的数据。反之，当实行β测试成功时，将会获取大量有价值的信息。执行一次成功的b测试过程与执行其他过程非常类似，你必须搜集可以找到的所有实践经验，并将其用于实际的测试过程，在测试时还必须保持一种勤奋的态度。

β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档，客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。

软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试）。编码和单元测试属于软件生命周期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周期的另一个独立阶段，即测试阶段。

软件测试的目的：

1、测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行；

2、好的测试用例在于发现至今未发现的错误；

3、成功的测试是发现了至今未发现的错误的测试；

4、好的测试工程师应该做到不仅发现问题，还能够帮助开发人员分析问题。

测试的原则：

1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。可以采用Junit和Jtest来辅助进行单元测试。

2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。

3、应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）

4、测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件。

5、充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。

6、严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。

7、应当对每一个测试结果做全面的检查。　

8、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

软件测试的对象：软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试（评审）的对象。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。

BetaTesting－－Beta测试
在客户场地，由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。

AcceptanceTesting－－可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

actualoutcome－－实际结果
被测对象在特定的条件下实际产生的结果。

AdHocTesting－－随机测试
测试人员通过随机的尝试系统的功能，试图使系统中断。

algorithm－－算法
（1）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（2）执行一个特定任务的任何操作序列。

algorithmanalysis－－算法分析
一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间方面的要求。

AlphaTesting－－Alpha测试
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

analysis－－分析
（1）分解到一些原子部分或基本原则，以便确定整体的特性；（2）一个推理的过程，显示一个特定的结果是假设前提的结果；（3）一个问题的方法研究，并且问题被分解为一些小的相关单元作进一步详细研究。

anomaly－－异常
在文档或软件操作中观察到的任何与期望违背的结果。

applicationsoftware－－应用软件
满足特定需要的软件。

architecture－－构架
一个系统或组件的组织结构。

ASQ－－自动化软件质量（AutomatedSoftwareQuality）
使用软件工具来提高软件的质量。

assertion－－断言
指定一个程序必须已经存在的状态的一个逻辑表达式，或者一组程序变量在程序执行期间的某个点上必须满足的条件。

assertionchecking－－断言检查
用户在程序中嵌入的断言的检查。

audit－－审计
一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。

audittrail－－审计跟踪
系统审计活动的一个时间记录。

AutomatedTesting－－自动化测试
使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多
Backus-NaurForm－－BNF范式
一种分析语言，用于形式化描述语言的语法

baseline－－基线
一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更。

BasicBlock－－基本块
一个或多个顺序的可执行语句块，不包含任何分支语句。

basistestset－－基本测试集
根据代码逻辑引出来的一个测试用例集合，它保证能获得100%的分支覆盖。

behaviour－－行为
对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。

benchmark－－标杆/指标/基准
一个标准，根据该标准可以进行度量或比较。

big-bangtesting－－大锤测试/一次性集成测试
非渐增式集成测试的一种策略，测试的时候把所有系统的组件一次性组合成系统进行测试。

BlackBoxTesting－－黑盒测试
根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

bottom-uptesting－－由低向上测试
渐增式集成测试的一种，其策略是先测试底层的组件，然后逐步加入较高层次的组件进行测试，直到系统所有组件都加入到系统。

TestDirector，（以下简称TD）它是MercuryInteractive公司推出的基于WEB浏览器环境下的测试管理工具。通过TD的流程控制可以规范软件企业的测试流程、改善测试质量、减轻测试人员的负担、提高工作效率。

项目移植：这里说的项目移植是指将已经建立的TD项目整体文件在保证数据安全和完整的前提下移植到其他服务器的过程，这个过程包括以下几个方面（1）数据库的移植（2）项目文件的移植（3）项目配置文件的移植。经过移植后的TD项目可以实现双机备份的功能。

集成工作环境：我们把TD服务程序和TD使用的数据库存放在同一台计算机上的这种工作环境称为集成工作环境。这种工作环境节省成本，维护较复杂，不利于数据的安全性。

分布式工作环境：把TD服务器程序和TD后台使用的数据库存放在不同机器上，也就是使用单独的一台计算机作为TD项目的数据库服务器，TD服务程序通过网络访问数据库服务器，这种工作环境称为分步式工作环境。这种环境的成本较高，但是利用维护，数据的安全性较高。对一些专业性的企业尤其是需要将TD开放到Internet上，我们建议使用这种工作环境。

基于IISWEB服务下的TD服务程序支持的数据库有ACCESS、SQLSERVER、SYBASE、ORACLE。由于ACCESS数据库的迁移比较容易本文就不介绍，本文主要讨论SQLSERVER数据库的移植。掌握SQLSERVER数据库类型的TD项目移植，对ORACLE、SYBASE类型数据库的项目移植工作也能做到触类旁通。

1、http://www.enet.com.cn/article/2006/1030/A20061030277495.shtml
2、http://www.testage.net/html/77/n-156477.html