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

mvjh13

原帖由 lisuy 于 2009-4-28 15:57 发表



灰盒测试是怎么回事啊？我只知道白盒与黑盒。

灰盒是界与白盒与黑盒之间

mvjh13

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

mvjh13

单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
          它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
          一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。
          单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

mvjh13

集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
          它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，
          以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

mvjh13

验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
          所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

mvjh13

回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
          这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；
          二是不影响软件的其他功能的正确性。

mvjh13

测试要有重点
尽管我们的测试是需要按照一定的级别进行，但资源和时间是有限的，实际上我们不可能无休止的进行测试，因此在有限的时间和资源下如何有重点的进行测试是测试管理者需要充分考虑的事情。例如，在单元测试的时候，对于哪些函数我们需要重点测试，哪些函数可以粗略测试，哪些函数可以不测试；而对于系统测试，则要考虑首先应当保证哪些功能的测试，其次应当保证哪些功能的测试等等。测试的重点选择需要根据多个方面考虑，包括测试对象的关键程度，可能的风险，质量要求等等。这些考虑与经验有关，随着实践经验的增长，你的判断也会更有效。

mvjh13

对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。
对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。
但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，
并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，
要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，
就可以通过测试去验证产品在多大程度上满足了客户需求。
对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。
由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ”
测试经理的一个重要职责。
高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。
我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。
在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量

mvjh13

什么是 “ 可测试性 ” ？软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。

以下是一个常见的软件可测试性检查表：
· 可操作性－ “ 运行地越好，被测试的效率越高。 ”
· 可观察性－ “ 所看见的，就是所测试的。 ”
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化。 ”
· 可分解性－ “ 通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。 ”
· 简单性－ “ 需要测试的内容越少，测试的速度越快。 ”
· 稳定性－ “ 改变越少，对测试的破坏越小。 ”

mvjh13

测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－
我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合
用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件
完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。

mvjh13

白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生
的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
2 ）对所有逻辑值均需测试 true 和 false ；
3 ）在上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性。

“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？ ” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始
出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ” 的处理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着
我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，
其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

mvjh13

软件测试充分性准则

（ 1 ）空测试对任何软件都是不充分的。
（ 2 ）对任何软件都存在有限的充分测试集合。
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
（ 5 ）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
（ 6 ）软件测试的充分性应该与软件的需求和软件的实现都相关。
（ 7 ）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。
（ 8 ）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

mvjh13

图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。
同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，
所以也就产生了一系列的测试标准。

mvjh13

客户 / 服务器软件的测试发生在三个不同的层次：
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。

mvjh13

对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。
对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。
但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，
并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，
要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，
就可以通过测试去验证产品在多大程度上满足了客户需求。
对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。
由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ”
测试经理的一个重要职责。
高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。
我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。
在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。

mvjh13

恢复测试是通过各种手段，让软件强制性地发生故障，然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的），重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的，那么要估算修复的平均时间是否在可以接受的范围之内。

mvjh13

在安全测试过程中，测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码，可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统 “ 制服 ” ，使得别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙；等等。

mvjh13

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

mvjh13

同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（ Peer Review ），尤其是正规检视（ Inspection ）。正规检视是由 Michael Fagan 在 I B M 制定出来的一种非常严格的评审过程。
    需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。