1、检查产品说明书
1、开始测试
1、黑盒测试和白盒测试
黑盒测试，又称功能性测试或行为测试。测试员只需知道软件要做什么--而无法看到盒子里的软件是如何运行的。只需要进行一些输入，就能得到某种输出结果。他不知道如何运行，为什么会这样，只知道程序做了什么。
白盒测试，又称透明盒测试。测试员可以访问程序员的代码，并通过检查代码的线索来协助测试--可以看到盒子里面。测试员根据代码检查结果判断或多或少可能出错的数目，并据此定制测试。
注意：进行白盒测试要冒一些风险。因为要以适应代码操作来定制测试，所以很容易形成偏见而无法进行客观测试。
2、静态测试和动态测试
静态测试：指测试不运行的部分--只是检查和审核；动态测试：指通常意义上的测试--使用和运行软件。
比如：检查二手汽车的过程。静态测试技术有：踢一下轮胎、看看车漆、打开引擎盖检查等。动态测试技术有：发动汽车、听听发动机声音、上路行驶等。
3、测试产品说明书（静态黑盒测试）
测试产品说明书属于静态黑盒测试。产品说明书是书面文档，而不是可执行程序，因此是静态的。
无论产品说明书的格式如何，都可以利用静态黑盒测试技术测试。通过询问软件的设计者或编制者甚至可以测试没有写出来的产品说明书。
2、对产品说明书进行高级审查
测试产品说明书的第一步不是马上钻进去找缺陷。而是站在一个高度上进行审查。审查产品说明书是为了找出根本性的问题、疏漏或遗漏之处。
1、假设自己是客户
把自己当作客户，研究一下客户会是什么人；和市场人员或销售人员聊一下，了解他们对最终用户的认识。请记住，质量的定义是’满足客户要求‘，测试员必须了解测试软件是否符合那些要求。
在假设自己是客户是不要忘记了软件的安全性。客户也许会假设软件使安全的，但测试员不能假定程序员会正确处理安全问题。
2、研究现有的标准和规范
标准和规范的差别在于程度不同，标准比规范更加严格。如果小组认为很重，则标准应该严格遵守；规范是可选的，但应该遵守。小组将标准作为规范也不罕见，前提是只要每个人都清楚就行。
下面可以考虑作为标准和规范的一些例子：
- 公司惯用语和约定。软件若是位某公司定制的，就应该采用该公司职员常用的术语和约定。
- 行业要求。医药、工业和金融行业的应用软件尤其必须严格遵守的标准。
- 政府标准。政府--特别是军队系统有严格的标准。
- 图形用户界面（GUI）。如果软件在windows或apple操作系统下，关于软件外观和用户的感受具有公开的标准。
- 安全标准。软件及其界面和协议可能需要满足一定的安全标准或级别。也许还需要进行独立的认证，以确保其满足必要的标准。
定义软件要符合何种标准和规范，是项目经理或编写产品说明书的人的任务。测试员要做的是观察，’检查‘采用的标准是否正确、有无遗漏。在对软件进行确认和验收时，还要注意是否与标准和规范相抵触，把标准和规范视为产品说明书的一部分。
3、审查和测试类似软件
了解最终结果的最佳方法是研究类似软件。类似软件有助于设计测试条件和测试方法，还可能暴露意想不到的潜在的问题。在审查竞争产品时需要注意的问题：
- 规模。软件的功能强大还是单一？代码多还是少？这些差别与测试有关吗？
- 复杂性。软件简单还是复杂？这会影响测试吗？
- 测试性。是否有足够的资源、时间和经验来测试软件？
- 质量和可靠性。软件是否完全满足质量要求？可靠性高还是低？
- 安全性。竞争对手软件的安全性（不管是宣称还是实际的）和自身的比较起来如何？
动手实践是无可替代的，因此拿到类似软件就要尽量试，使用它、疯狂实验、追根问低，这些都是为仔细审查产品说明书积累大量的经验。
注意：要阅读关于竞争对手软件的评价方面的联机或印刷的文章。这对安全方面的问题特别有帮助，因为测试员偶然使用软件不一定能发现安全方面的缺陷。然而在出版物中，这些问题会特别引起关注。
3、产品说明书的低层次测试技术
1、产品说明书属性检查清单
经过深思熟虑，可称为’一字不漏‘的优秀产品说明书应具有8个重要的属性：
- 完整。是否有遗漏和丢失？完全吗？单独使用时是否包含所有内容？
- 准确。既定解决方案正确吗？目标定义明确吗？有没有错误？
- 精确、不含糊、清晰。描述是否一清二楚？是否有单独的解释？容易看懂和理解吗？
- 一致。产品功能描述是否自相矛盾，与其他功能有无冲突？
- 贴切。描述功能的陈述是否必要？有没有多余信息？功能是否符合原来的客户要求？
- 合理。在规定的预算和进度下，以现有人力、工具和资源能否实现？
- 代码无关。产品说明书是否坚持定义产品，而不是定义其软件设计、架构和代码？
- 可测试性。功能能否测试？给测试员提供的建立验证操作的信息是否足够？
在测试产品说明书、阅读文字、检查图标时，要仔细对照上诉清单，看看他们是否具有这些属性。如果不具备，那就是发现了需要指出的缺陷。
2、产品说明书术语检查清单
问题用语通常表明功能没有仔细考虑--可能归结于前文所述的某一属性。从产品说明书中找出这样的用语，仔细审查它们在上下文中是怎样使用的。产品说明书后面可能会阐明或掩饰，也可能含糊其辞--无论是哪一种情况，都可视为软件缺陷。
- 总是、每一种、所有、没有、从不。测试员需要考虑违反这些情况的用例。
- 当然、因此、明显、显然、必然。这些意图说服你接受假定情况，不要中了圈套。
- 某些、有时、常常、通常、大多、几乎。这些话太模糊，‘有时’发生作用的功能无法测试。
- 等等、诸如此类、历次类推、例如。以这样的词结束的功能清单无法测试，功能清单要绝对或解释明确，以免让人对功能清单内容产生迷惑。
- 良好、速度、廉价、高效、小、稳定。这些是无法量化的术语，它们无法测试。如果说明书中出现这些用语，必须进一步准确定义其含义。
- 处理、进行、拒绝、跳过、排除。这些用于可能影藏大量需要说明的功能。
- 如果...那么...（没有否则）。若没有’否则‘，想一想’如果‘没有发生会怎样。
4、测验
1、软件测试员可以根据产品说明书进行白盒测试吗？
是的，白盒测试就是使用如何设计影响如何测试的概念进行的。测试员可以参加焦点人却、易用性研究和市场会议，了解用于定义功能特性和整个产品的过程。但这存在一定的风险，因为这些信息诱使测试员倾向于假定说明书是正确的。
2、试举一些Mac或Windows标准规范的例子。
在Mac机上，删除的文件放在废纸箱；在Windows中，删除的文件放在回收站。
在Windows中，按F1总是显示软件的帮助，在Mac机上则是Command-？
在Windows中，File菜单总是最左边的菜单选项。
在Windows中，选择Help菜单中About显示软件的版权、许可证和版本信息。
在Mac机上，Command-X执行剪切操作，Command-C执行复制操作、Command-V执行粘贴操作。
还有很多例子。
3、指出下述产品说明中的错误：当用户选择Compact Memory选项时，程序将使用Huffman解析矩阵方法尽可能压缩邮件列表数据。
错误在于使用了’尽可能‘的说法，这一点无法测试，因为该说法没有量化、不精确。说明书应该说明压缩究竟达到何种程度才行。
4、解释测试员应该担心下述产品说明的哪些内容：尽管通常连接不超过一百万个，但是该软件允许多达一亿个并发的连接。
可测试性。典型应用只有一百万个到无关紧要。如果产品说明书声明由一亿种可能性，那么，一亿个连接都要测试。测试员需要设法测试这么多可能性，或者让说明书作者把最大可能性降低到接近典型应用的数目。
2、带上眼罩测试软件
1、动态黑盒测试：带上眼罩测试软件
1、动态黑盒测试：不深入代码细节测试软件的方法。又被称为行为测试，因为测试的是软件在使用过程中的实际行为。（动态：程序在运行，测试员像用户一样使用它；黑盒：测试时不知道程序如何工作，带上了眼罩）
有效的动态测试需要关于软件行为的一些定义，也即需求文档或产品说明书。不必了解软件‘盒子’内发生的事情，只需清楚软件的输入和输出。好的产品说明书会提供这些细节信息。
接下来开始定义测试用例。测试用例指进行测试时使用的特定输入，以及测试软件的过程步骤。注意：选择测试用例时测试员最重要的一项任务，不正确的选择可能导致测试量过大或过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围时成功的诀窍。
2、在没有产品说明书时使用探索测试：
软件开发过程如果采用大爆炸模式或者边写边改模式，可能没有产品说明书，这对于软件测试员不是理想的状况，但此时可采取称为探索测试的解决方案--了解软件、设计测试、执行测试同时执行。
这需要把软件当作产品说明书来对待。系统地逐项了解软件的功能、记录软件执行情况、详细描述功能，运用‘检查产品说明书’中所讲的静态黑盒技术，把软件当成说明书来分析，然后运用本章的动态黑盒技术来测试。
在这种情况下，无法像有产品说明书那样完整测试软件。如无法断定是否遗漏功能，但可以系统地测试软件，找到软件缺陷几乎是肯定的。
2、通过性测试和失效性测试
测试软件有两种基本方法：通过性测试和失效性测试。在进行通过性测试时，实际上是确认软件至少能做什么，而不会考验其能力。纯粹为了破坏软件而设计和执行的测试用例称为失效性测试或错误强制测试。
在设计和执行测试用例是，总是首先进行通过性测试。在破坏性测试之前看看软件基本功能是否能实现是很重要的，测试员可能会吃惊地发现仅仅正常使用软件就会发现那么多软件缺陷。
确信软件在普通情况下都能正确运行之后，就可以采取各种手段搞垮软件来找出软件缺陷。本章后面将会讲到失效性测试通常不会突然出现。虽然看起来于通过性测试差不多，但它是蓄意攻击软件的薄弱环节。
错误提示信息：是通过性测试还是失效性测试。
测试用例中常见的一种就是设法迫使软件出现错误提示信息。如在软驱中还没有插入磁盘时向软盘中保存文件。这些用例实际上搅乱了通过性测试和失效性测试之间的界限。产品说明书可能会特别说明某些输入条件将产生错误提示信息。这似乎显然是通过性测试，但由于迫使软件出错，因此可视为失效性测试。实际上，可能两者都是。
不必费力去区分它们。重要的是设法迫使指定的错误信息出现，或者设计测试用例迫使未考虑到的错误暴露出来。最终可能在通过性测试和失效性测试中都找出软件缺陷。
3、等价类划分
选择测试用例是测试员最重要的任务。选择测试用例的方法是等价类划分，又称为等价分类。等价类划分是指分步骤地把海量（无限）的测试用例集减到很小，但过程同样有效。
一个等价类或者等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。
在寻找等价划分时，考虑把软件具有相似输入、相似输出、相似操作的分在一组。这些组就是等价划分。
等价类划分的目标是把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。因为选择了不完全测试，就要冒一定的风险，所以选择分类时必须仔细。
等价类划分可能主观。测试同一个复杂程序的两个测试员，可能会得出两组不同的等价类划分间。只要审查等价划分的人认为它们足以覆盖测试对象就行。
4、数据测试
对软件最简单的认识就是将其划分成两部分：数据和程序。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。程序是指可执行的流程、转换、逻辑和运算。软件测试常用的一个方法时把测试工作按同样的形式划分。
对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。如：电子表格中输入的数字，太空游戏中余下的射击次数，存放在软盘中的备份文件。
即使最简单的程序要处理的数据量也可能极大。使所有这些数据得以测试的技巧：根据一些关键的原则（边界条件、次边界条件、空值、无效数据）进行等价类划分，以合理减少测试用例。
1、边界条件
边界条件是特殊情况，因为编程从根本上说在边界上容易产生问题。程序员往往在处理大量中间数值时是对的，但可能在边界处出现错误。
边界条件的数据类型：数值、速度、字符、位置、地点、位置、尺寸、数量。这些类型的特征：第一个/最后一个、最大值/最小值、开始/完成、超过/在内、空/满、最短/最长、相邻/最远。
测试边界：提出边界条件是，一定要测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试刚刚超过边界的无效数据。缓冲区溢出是由边界条件缺陷引起的，它是造成软件安全问题的头号原因。
2、次边界条件
有些边界条件在软件内部，最终用户几乎看不到，但测试员仍有必要进行检查。这种称为次边界条件或内部边界条件。
寻找这样的边界不要求测试员成为程序员或具有阅读代码的能力，但确实要求大体了解软件的工作方式。如：2的幂和ASCII表。软件可能有许多其他次边界条件，所以测试员应和程序员交流，看看他们能否对其他的应该测试的次边界条件提供建议。
- 2的幂。
计算机和软件的基础是二进制数。如：用 位(bit) 表示0和1；字节(byte) 由8位组成， 0-255；字(word，32位系统)由4个字节组成；kilo，1024；mega，1048576等。
通信软件可以体现2的幂的示例。带宽或传输信息的能力总是受限制的，人们总是需要尽可能快地收发信息。因此工程师要尽一切努力在通信字符串中压缩更多的数据。其中一个方法：把信息压缩到尽可能小的单元中，发送这些小单元中最常用的信息，在必要时扩展为大一些的单元。
假设某通信协议支持256条命令，软件将发送编码为一个4位数据最常用的15条命令。要用到第16-256条之间的命令，软件就转而发送编码为更长的字节的命令。
软件用户只知道可以执行256条命令，不知道软件根据4位/字节的边界执行了专门的计算和不同的操作。
在建立等价划分时，要考虑等价划分中是否需要包含2的幂的边界条件。如输入1-1000范围内的数字，为了覆盖任何可能的2的幂的次边界，还要包含临近4位边界的14、15、15，以及临近字节边界的254、255、256。
- ASCII表
@、A-Z、[、'、a-z、{，的ASCII值是64到123。这些情况都代表次边界条件。如果测试进行文本输入或文本转换的软件，在定义数据划分包含哪些值时，参考一下ASCII表是相当明智的。如：测试的文本框只接受字符A-Z和a-z，就应该在非法划分中包含ASCII表中这些字符前后的值@、[、'、{。
尽管ASCII仍然是软件表示字符数据非常流行的方式，但它正被Unicode(统一编码)的新标准取代。Unicode是为解决ASCII码无法表示所有书面语言字符的问题而开发的。
ASCII只用8位，能表示256中不同的字符。Unicode使用16位，可以表示65535种字符。目前已为39000多种字符指定了数值，其中21000多种用于表示中国象形文字。
3、默认、空白、空值、零值和无
一定要考虑建立处理默认值、空白、空值、零值或者无输入等条件的等价划分。因为这些值在软件中通常进行不同的处理，软件可能会执行不同的路径，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价划分。
4、非法、错误、不正确和垃圾数据
数据测试的最后一种类型是垃圾数据。这是失效性测试的对象。经过边界测试、次边界测试和默认值测试等通过性测试证实软件能否工作之后，就该进行垃圾数据测试了。
非法、错误、不正确和垃圾数据测试是很有意思的。如果软件要求输入数字，就输入字母。如果软件只接受整数，就输入负数。如果软件对日期敏感，就看它在公元3000年石佛还能正常工作。假装有肥胖的手指，同时按下多个键。
5、状态测试
目前为止，我们测试的是数据-数字、文字、软件输入和输出。软件测试的另一方面是通过不同的状态，验证程序的逻辑流程。软件状态指软件当前所处的条件或者模式。
测试员必须测试程序的状态及其转换。
1、测试软件的逻辑流程
除了及其简单的程序外，基本上不可能走遍所有分支，达到所有状态。对于软件测试，解决方法是运用等价划分技术选择状态和分支。
- 建立状态转换图
这样的图可能作为产品说明的一部分被提供出来，那就可以采用 ‘检查产品说明书’ 中的技术进行静态测试。否则就需要创建一个状态图。状态转换图应该表示出一下项目：
1.软件可能进入的每一种独立状态。如果不能断定是否为独立状态，它就可能是。以后发现它不是，随时可以将其剔除。
2.从一种状态转入另一种状态所需的输入和条件。可能是按键、菜单选择、传感器信息或者电话振铃等。状态不可能无缘无故地存在，其原因就是在这里要寻找的。
3.进入或者退出某种状态时的设置条件及输出结果。包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等。这些是状态转换时发生的部分或全部现象。
因为正在进行黑盒测试，所以不必了解代码中设置的底层变量。从软件用户角度建立状态图即可。
- 减少要测试的状态及转换的数量
测试软件逻辑流程，基本上不可能走遍所有分支（每一种线路组合、翻来覆去、循环反复），达到所有状态。将大量的可能性减少到可以操作的测试用例集合，有以下5种实现方法：
1.每种状态至少访问一次。如何到达的没有关系，但每一种状态都必须测试。
2.测试看起来最常见和最普遍的状态转换。尽管听起来很主观，但其根据是进行说明书的静态黑盒分析时收集到的信息。某些用户情况可能比其他更常见。希望这样能管用。
3.测试状态之间最不常用的分支。这些分支时最容易被产品设计者和程序员忽视的。测试员可能是第一个测试它们的人。
4.测试所有错误状态及其返回值。错误没有得到正确处理，错误提示信息不正确、修复错误时未正确恢复软件等情况常有发生。
5.测试随机状态转换。打印状态图，在上面任意做各种标记。如果有时间，可以参考‘自动测试和和测试工具’关于如何自动执行状态随机转换测试。
- 怎样进行具体测试
确定要测试的状态及其转换之后，就可以定义测试用例了。测试状态及其转换包括检查所有的状态变量：进入和退出状态相关的静态条件、信息、值、功能等。
2、失败状态测试
以上探讨的状态测试都属于通过性测试，测试包括审查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常。和数据测试一样，相反的做法是找到使测试软件失败的案例。此类案例的例子使竞争条件、重复、压迫和重负。
- 竞争条件和时序错乱
多任务是指操作系统设计用来同时执行多个独立的进程。设计多任务操作系统并不繁琐，设计充分利用多任务的软件才是艰巨的任务。在真正的多任务环境种，软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统种同时运行，并且共享内存、磁盘、通信以及其他硬件资源。
竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以及找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何？
以下使可能会面临竞争条件的例子情形：
1.两个不同的程序同时保存和打开同一个文档。
2.共享同一台打印机、通信端口或者其他外围设备。
3.同时关闭或者启动软件的多个示例。
4.同时使用不同的程序访问一个共同的数据库。
- 重复、压迫和重负
重复、压迫和重负这三个失效性状态测试的目标：是那些处理程序员没有考虑到，但在极端恶劣条件下可能发生问题的状态。
1.重复测试：不断执行同样的操作。最简单的使不停地启动、关闭程序。
进行这种测试的主要原因是检查是否存在内存泄漏。计算机内存被分配进行某些操作，但操作完成时没有完全释放，结果是最后程序耗尽了它赖以工作的内存空间。如果某程序在开始启动时工作状态良好，但最后越来越慢，或者经过一段时间就表现不稳定，原因可能就是内存泄漏缺陷。重复测试就能暴露这些问题。
2.压迫测试：使软件在不够理想的条件下运行，内存小、磁盘空间少、CPU速度慢、调制解调器速率低等。观察软件对外部资源的要求和依赖的程度。压迫测试就是将支持降到最低限度，目的在于尽可能地限制软件的必要条件。
3.重负测试：与压迫测试相反。它尽量提供条件任其发挥。让软件处理能可能大的数据文件。如：对通信端口之类的外设进行操作，把能连的都连上；如果服务器可以处理几千个并发连接，就按它说的做。
时间也是一种重负测试。对于大多数软件，长期稳定地工作是很重要的。某些软件应该能永远运行下去，而不用重新启动。
重复、压迫和重负测试应联合使用，同时进行，这是找出以其他方式难以发现的严重缺陷的一个可靠的方法。
6、其他黑盒测试技术
余下的黑盒测试技术是找出缺陷中的漏网之鱼的技术。他们不想数据测试和状态测试那样独立，而是他们的变形。
1、像笨拙的用户（无经验或新的用户）那样做
不熟悉软件的人，会输入程序员无从想象的数据，会中途退回去执行其他操作，会单击不应该单击的东西。他们会发现开发小组完全遗漏的软件缺陷。
2、在已经找到缺陷的地方再找找
原因有：某模块功能找到的缺陷越多，就说明那里的缺陷越多；程序员倾向于只修复报告出来的缺陷。
3、像黑客一样考虑问题
想想软件里面有哪些有价值的东西，为什么有人要想获得其访问权限，黑客进入的方法有哪些。
4、凭借经验、直觉和预感
学习测试不同类型和规模的产品，就会得到各种提示和技巧以便更有效地找出令人棘手的缺陷。记录哪些技术有效，哪些不行。尝试不同的途径。有可疑之处，要深入研究。
7、测验
1、判断：在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。
对。该技术称为探索测试，基本上把软件用作产品说明书。这不是理想的过程，但是急了也能用。最大的风险是不知道特性是否被遗漏。
2、如果测试程序向打印机输送打印内容，应该选用哪些通用的失效性测试用例？
可以尝试打印时不加纸，或者使其卡纸。
可以脱机打印，拔掉电源，断开打印机电缆。
可以尝试在墨粉不足的条件下打印，甚至不加墨盒。
为了明确所有的可能性，可以查看打印机的操作手册，找出支持的错误处理，设法建立使用的错误情况。
3、启动windows写字板程序，并从File菜单选取print命令，打开如下图的对话框。左下角显示的print range（打印区域）特性存在什么样的边界条件？
如果选择page选项，From和To文本域就变为可用状态。明显的边界条件是0到99999，即文本域的最小值和最大值。增加测试254，255，256，1023，1024和1025等内部边界是明智的做法。此外，还有其他的内部边界。试着从只有6页的文档打印第1-8页。这是一个不同的内部边界。看看是否还能想出别的。
4、假设有一个文本框要求输入10个字符的邮政编码，如下图。对于该文本框应该进行怎样的等价划分？
至少应该有以下等价划分，但还可以想出更多：
- 合法的5位数字邮政编码。合法是指所有字符都是数值，不是指投入使用的现有邮政编码--但这可以构成另一个区间。
- 合法的9位数字（带连线的9位数字）邮政编码。
- 5位以下数字。如只有4位数字。
- 9位以下数字。如只有8位数字。
- 5位以上数字。如不带连线的8位数字。这是否与9位以下数字区间相同吗？
- 9位以上数字。尽管不可能输入9位以上带连线的数字。但测试员应该尝试一下。
- 10位数字，无连线。与9位以上数字区间稍有差别。
- 连线位置不对。
- 连线不只一条。
- 无数字和无连线。
5、判断：访问程序的所有状态也确保了遍历各种状态之间的转换。
错。想想浏览遍布美国的50个不同城市。可以制定到达每个城市的旅游计划，但是不可能走遍所有城市之间的道路--这将是走遍美国的所有道路。
6、绘制状态转换图有多种不同的方法，但是它们都具有相同的三个要素是什么？
- 软件可能处理的每一个状态。
- 从一个状态转移到另一个状态所需的输入和条件。
- 当进入和退出状态时产生的条件、变量和输出。
7、windows计数器程序的初始状态变量有哪些？
初始显示值和内部中间值置为0。存储寄存器（MC,MR,MS和M+按钮）置为0。剪切板内容（暂存剪切、复制和粘贴数据）保存不变。
另一个初始状态变量是计算机启动时出现在屏幕上的位置。打开计算器程序的多个副本，注意其位置不一定相同（至少在windows95/98中如此）。作为探索测试的一个练习，看能否找出计算器打开时出现位置的规则。
8、当设法显露竞争条件软件缺陷时，要对软件进行何种操作？
尝试同时做几件事。它们可以是相关的，如从一个应用程序同时向两台打印机输出打印；也可以是无关的，如在计算机计算时按各种键。所作的目的是迫使软件执行某一功能时出现与自己竞争的状况。
9、判断：在进行压迫测试的同时进行重负测试是不合理的。
错。任何测试都是合理的。软件测试员的任务是发现软件缺陷。但是，由于软件测试的实质，在这种情况下发现的任何缺陷可能都不会修复。