关键字：软件测试知识帖
第1帖【2004－5－10】：软件测试的理想模式是什么？ Brian Marick：我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效，而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组，他们不可能有时间把所有测试都做好。所以，最佳的方式是让开发人员承担一定量的测试，独立测试组给予他们支持。独立测试组主要承担整个系统的测试，去寻找开发人员还没有发现的缺陷，如子系统间的交互、运行条件、内存使用等。
如何更有效地开展系统测试呢？让测试人员在项目初期就参与进踪去，让他们看到第一版的系统需求、用户手册和系统原型，在系统实现前就对需求进行捕获和跟。在该过程中，他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行，并且在该过程中会发现一些缺陷。大家都知道，这个阶段，问题发现是非常“便宜”的。
这样，系统测试工程师在项目早期就介入，产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计，因为书写完整测试的条件还不成熟，但这却是构建完整测试的基础。
注：Brian Marick是Reliability Software公司的专职测试技术顾问。
第2帖【2004－5－11】：测试经理角色定位
Johanna Rothman：测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。
对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于“测什么和何时测”测试经理的一个重要职责。
高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。
第3贴【2004－5－12】：测试的基本原则
（美）Roger S. Pressman
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3、Pareto原则应用于软件测试。简单地讲，Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4、测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6、为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。
第4贴【2004－5－13】：什么是“好”的测试？
什么是“好”的测试？ Kaner，Falk & Nguyen
1、一个好的测试发现错误的可能性很高
为了达到这个目标，测试者必需理解软件、并尝试设想软件如何才能失败，例如：在GUI（图形用户界面）中有一种潜在的错误，即错误识别鼠标位置，那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
2、一个好的测试并不冗余
测试的时间和资源是有限的，没有必要构造一个与其他测试用例完全相同的测试，每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如，软件SafeHome中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码（4个数字），然而，每一个有效/无效密码将只检测一种不同错误模式，例如一个将8080作为有效密码的系统将不会接受非法密码1234，如果接受1234，将产生错误，另一个测试输入1235，与1234的测试意图相同，因此是冗余的，然而，非法输入8081或8180就有些细微的差异，即对与有效密码相近但并不相同的密码应该进行测试。
3、一个好的测试应该是“最佳品种”
在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。
4、一个好的测试既不会太简单，也不会太复杂
虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常每一个测试应该独立执行。
第5贴【2004－5－14】：软件可测试性
Roger S. Pressman
理想情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得测试工程师能够更容易地设计有效的测试用例。
什么是“可测试性”？软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。James Bach这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。
以下是一个常见的软件可测试性检查表：
·可操作性－“运行地越好，被测试的效率越高。”
·可观察性－“所看见的，就是所测试的。”
·可控制性－“对软件的控制越好，测试越能够被自动执行与优化。”
·可分解性－“通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。”
·简单性－“需要测试的内容越少，测试的速度越快。”
·稳定性－“改变越少，对测试的破坏越小。”
·易理解性－“得到的信息越多，进行的测试越灵巧。”
第6贴【2004－5－15】：实时系统测试
Roger S. Pressman
很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。
另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤：
1、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。
2、行为测试。利用CASE工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。
3、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。
4、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件/硬件接口间的错误。
第7贴【2004－5－16】：单元测试、集成测试、系统测试、验收测试、回归测试
Software Research
单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。
系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
第8贴【2004－5－17】：软件测试策略
Roger S. Pressman
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。
人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
·测试开始于模块层，然后“延伸”到整个基于计算机的系统集合中。
·不同的测试技术适用于不同的时间点。
·测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
·测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。
软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。
第9贴【2004－5－18】：白盒测试
Rex Black
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1）保证一个模块中的所有独立路径至少被使用一次；
2）对所有逻辑值均需测试true和false；
3）在上下边界及可操作范围内运行所有循环；
4）检查内部数据结构以确保其有效性。
“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷：
1、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
2、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。
正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。
白盒测试是一种逻辑覆盖方法，主要包括：
语句覆盖
判定覆盖
条件覆盖
判定-条件覆盖
条件组合覆盖
路径覆盖
第10贴【2004－5－19】：黑盒测试
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
1）如何测试功能的有效性？
2）何种类型的输入会产生好的测试用例？
3）系统是否对特定的输入值尤其敏感？
4）如何分隔数据类的边界？
5）系统能够承受何种数据率和数据量？
6）特定类型的数据组合会对系统产生何种影响？
运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
第11贴【2004－5－20】：软件测试充分性准则
（1）空测试对任何软件都是不充分的。
（2）对任何软件都存在有限的充分测试集合。
（3）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。
（4）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
（5）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
（6）软件测试的充分性应该与软件的需求和软件的实现都相关。
（7）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。
（8）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。
第12贴【2004－5－21】：静态测试
在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的，也与项目管理过程相一致。每当一个文档通过了静态测试，就标志着一项开发工作的总结，标志着项目取得了一定的进展，进入了一个新的阶段。
静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上，人们总结出了一些行之有效的静态测试技术和方法，如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进行监视、控制，从而保障软件质量。
第13贴【2004－5－22】：什么是测试需求？
Brian Marick
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。
在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。
测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1）插入一个新的条目
2）插入失败－条目已经存在
3）插入失败－表已满
4）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。
这应该只是对测试需求的一个方面的理解
测试需求应该包含两个方面的内容：
1、确定测什么，就是上面这位仁兄所说。
2、测试对产品的需求，解决需要产品为测试提供什么特性，可以更好的去测试的问题，就是我们常说的可测试性需求。
第14贴【2004－5－30】：GUI测试
Roger S. Pressman
图形用户界面（GUI）对软件测试提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时，GUI的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在GUI设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见GUI测试的指南：
窗口：
·窗口是否基于相关的输入和菜单命令适当地打开？
·窗口能否改变大小、移动和滚动？
·窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
·当被覆盖并重新调用后，窗口能否正确地再生？
·需要时能否使用所有窗口相关的功能？
·所有窗口相关的功能是可操作的吗？
·是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
·显示多个窗口时，窗口的名称是否被适当地表示？
·活动窗口是否被适当地加亮？
·如果使用多任务，是否所有的窗口被实时更新？
·多次或不正确按鼠标是否会导致无法预料的副作用？
·窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
·窗口是否正确地被关闭？
下拉式菜单和鼠标操作：
·菜单条是否显示在合适的语境中？
·应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
·下拉式操作能正确工作吗？
·菜单、调色板和工具条是否工作正确？
·是否适当地列出了所有的菜单功能和下拉式子功能？
·是否可以通过鼠标访问所有的菜单功能？
·文本字体、大小和格式是否正确？
·是否能够用其他的文本命令激活每个菜单功能？
·菜单功能是否随当前的窗口操作加亮或变灰？
·菜单功能是否正确执行？
·菜单功能的名字是否具有自解释性？
·菜单项是否有帮助，是否语境相关？
·在整个交互式语境中，是否可以识别鼠标操作？
·如果要求多次点击鼠标，是否能够在语境中正确识别？
·光标、处理指示器和识别指针是否随操作恰当地改变？
数据项：
·字母数字数据项是否能够正确回显，并输入到系统中？
·图形模式的数据项（如滚动条）是否正常工作？
·是否能够识别非法数据？
·数据输入消息是否可理解？
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
