临时测试是开发人员和软件公司在检查软件的当前迭代时实施的一种软件测试。 这种形式的测试能更深入地了解程序，找到传统测试可能无法突出的问题。
最重要的是，测试团队对临时测试过程有一个完整的了解，这样他们就知道如何规避其挑战，并确保团队能够成功地实施这种技术。
确切地知道临时测试是如何工作的，以及哪些工具可以促进其实施，可以使企业不断增强其自身的质量保证程序。 正式的测试过程遵循非常具体的规则，这可能导致团队遗漏某些bug–临时检查可以规避这些盲点，快速测试每一个软件功能。
在这篇文章中，我们仔细研究了临时测试以及在开发软件产品时如何利用它的优势。
特设测试的含义：什么是专案测试？
临时测试是一个避免正式规则和文件的质量保证过程–帮助测试人员发现常规方法无法识别的应用程序中的错误。 这通常需要在测试开始前对软件有全面的了解–包括对程序内部运作的了解。 这些临时检查的目的是以反映用户输入的方式打破应用程序，说明各种潜在的情况，以便开发人员能够修补任何现有的问题。
缺少文档是这种技术的核心，它不包括检查表或测试案例来指导测试人员完成应用程序的功能。 临时测试完全是指以一个团队在那个特定时刻决定的有效方式来测试软件。 这可能会考虑到预先存在的正式测试，但也可能只是在分配给这种技术的（可能是有限的）时间内进行尽可能多的测试。
1.在软件测试中，什么时候以及为什么需要进行临时测试？
公司进行临时测试的主要原因是它能够发现传统方法无法发现的错误。 这可能是由于任何数量的原因，例如传统的测试案例遵循一个特别标准化的过程，无法考虑到应用程序的特异性。
每种测试类型都可以为质量保证提供新的视角和有趣的方法–这也显示了通常测试策略的问题。 例如，如果临时测试可以确定团队的测试用例没有解决的问题，这表明他们可以从重新校准他们的测试方法中受益。
测试人员可以在测试过程中的任何时候进行临时性检查。 这通常作为传统（和更正式的）质量保证的补充，考虑到这一点，测试人员可以在他们的同事进行更正式的检查时进行临时检查。 然而，他们可能反而更喜欢把临时检查留到正式测试过程之后，作为专门针对潜在盲点的后续行动。
当由于缺乏文件而时间特别有限时，临时测试也可能是有用的–正确的时间取决于公司和它的首选方法。
2.当你不需要做临时测试时
如果没有足够的时间同时进行临时测试和正式测试，重要的是团队要优先考虑后者，因为这可以确保大量的测试覆盖率–即使仍然存在一些差距。
如果团队的正式测试发现了需要修复的错误，一般来说，最好等到开发人员完成必要的修改后再进行临时检查。 否则，他们提供的结果可能很快就会过时，特别是当测试与已经出现错误的组件有关时。
除此以外，临时测试必须在测试阶段之前进行。
3.谁参与了临时测试？
在Ad-Hoc测试过程中，有几个关键角色参与其中，包括：
– 软件测试人员是进行临时检查的主要团队成员。 如果进行伙伴或配对测试，那么这些测试人员中的几个人将在相同的组件上一起工作。
– 开发人员可以在正式的质量保证阶段之前独立使用这些检查来快速检查他们自己的软件，尽管这比专门的临时测试的深度要低。
– 团队或部门领导授权整体测试策略–帮助测试人员确定何时开始临时测试以及如何在不影响其他检查的情况下进行测试。
临时测试的好处
软件测试中临时测试的优势包括：
1.快速决议
由于这些测试在检查前、检查中和检查后都不需要频繁的记录，所以团队有可能更快发现问题。 这种简单性为测试人员提供了巨大的自由。
例如，如果他们测试了一个组件，但不能识别任何错误，团队可能只是继续进行下一个测试，而没有在文件中指出这一点。
2.对其他测试类型的补充
没有任何测试策略是完美的，100%的覆盖率通常是不可能实现的–即使有一个全面的计划。 传统的测试总会有差距，所以公司整合多种方法很重要。
临时测试的具体目标是找到正式测试无法覆盖的问题–保证更广泛的整体测试覆盖。
3.灵活执行
临时测试可以发生在测试前质量保证过程的任何时候，让公司和团队决定何时是执行这些检查的最佳时机。 他们可能会选择在进行常规测试的同时进行临时测试，或者可以等到事后再进行–无论如何，团队都会从他们所掌握的选择中受益。
4.加强合作
与许多其他形式的测试相比，开发人员更多地参与这一过程–特别是如果公司使用好友和配对测试。
因此，开发人员可以更好地了解他们自己的应用程序，并可能能够以更高的标准解决错误。 这有助于进一步提高软件的整体质量。
5.多样化的视角
临时测试可以从新的角度展示应用程序，帮助测试人员以新的方式参与这些功能。 在整个测试过程中，额外的视角是至关重要的，因为正式的检查往往至少有微小的差距。
如果临时测试人员在使用软件时有破解它的特定意图，他们就能更容易地确定程序的限制。
临时测试的挑战
临时测试过程也有一些挑战，如：：
1.报告方面的困难
缺少文档使得临时测试变得更快，但也会使重大问题以外的报告变得困难。
例如，以前进行的一项检查可能在以后变得更加相关，尽管最初没有导致重要的结果。 如果没有全面的文件，团队可能无法解释这些测试。
2.可重复性较差
沿着类似的思路，测试人员可能并不完全了解导致他们观察到的反应所需的确切条件。 例如，一个返回错误的临时检查可能没有足够的信息让团队采取行动。 他们可能不知道如何重复这个测试并得到相同的结果。
3.需要软件经验
由于速度是整个临时测试的关键，而且它通常涉及到试图破坏应用程序，所以这些测试人员对这个程序有一个深入的了解是很重要的。
知道了它的工作原理，测试人员就可以用更多的方式来破解和操纵软件，但这可能会大大增加对临时测试的技能要求。
4.有限的问责制
缺少文档可能会导致更多的问题，而不仅仅是糟糕的报告；它还可能无意中延长了测试过程，影响了快速的个人临时测试的效用。
如果在每个阶段都没有足够的文件记录，测试人员可能很难跟踪他们的进展。 这甚至可能导致他们重复其他测试人员已经完成的检查。
5.可能无法反映用户体验
几乎每一种测试类型的目的都是为了说明以某种方式影响终端用户的错误。 临时测试主要依赖于一个有经验的测试人员试图模仿一个没有经验的用户，这应该在每次检查中保持一致，包括他们试图破坏应用程序。
特异性测试的特点
成功的临时测试的主要特点包括：
1.调查性
临时测试的主要优先事项是使用常规检查没有考虑的技术来识别应用程序的错误。 临时检查的目的是为了找到团队测试程序中的漏洞，包括他们的测试用例的覆盖率。
2.非结构化
临时检查通常没有固定的计划，只是在正式质量保证的典型范围之外进行尽可能多的测试。 为方便起见，测试人员通常会将检查按组件分组，但即使这样也没有必要–他们甚至可能在执行检查时设计出检查。
3.经验驱动
临时测试人员利用他们已有的软件经验来评估哪些测试会带来最大的好处，并解决正式测试中常见的盲点。
虽然测试过程仍然是完全非结构化的，但测试人员在决定他们的策略时，会应用他们以前的临时检查等知识。
4.范围广泛
对于团队在临时测试期间应该进行哪些检查没有确切的指导，但它们通常涵盖了一系列的组件–可能会更多地关注应用程序的更敏感方面。 这有助于测试人员保证他们的考试能够充分补充正式测试。
我们在临时测试中测试什么？
质量保证团队通常在临时测试中测试以下内容：
1.软件质量
这些检查旨在识别常规测试无法发现的应用程序中的错误；这意味着该过程主要测试应用程序的一般健康状况。
临时测试能找到的错误越多，开发人员就能在截止日期前实现更多的改进。
2.测试案例
临时测试一般不实施测试用例–而这是专门为了让团队调查他们在提供充分覆盖方面的有效性。 如果临时检查能发现常规测试过程不能发现的错误，测试用例很可能是不充分的。
3.测试人员
目标也可以是检查测试团队的技能和知识，即使测试用例是充分的。 例如，他们实施案例的方法可能是不充分的，临时测试可能对解决由此产生的测试覆盖面的差距至关重要。
4.软件限制
临时测试还试图了解应用程序的极限–例如它对意外输入或高系统负载的反应。 测试人员可以专门调查程序的错误信息，以及这个应用程序在面临重大压力时的表现如何。
澄清了一些混淆之处：
临时测试和探索性测试
有些人认为临时性测试和探索性测试是同义词，尽管事实比这更复杂。
1.什么是探索性测试？
探索性测试是指从整体角度调查软件的质量保证程序，特别是将发现和测试过程结合到一个单一的方法。 这通常是完全结构化测试和完全自由的临时检查之间的一个中间地带。
探索性测试在特定的情况下效果最好，例如，当需要快速反馈或团队必须解决边缘案例时。 这种类型的测试通常在团队使用脚本测试的同时达到其全部潜力。
2.探索性测试之间的区别
和临时测试
临时测试和探索性测试的最大区别是前者使用文档来记录和促进其检查，而临时测试完全避免了这一点。 探索性测试更加强调测试的自由度，但从未达到与完全非结构化的临时性方法相同的水平。
探索性测试还包括在这些检查过程中了解应用程序及其内部运作情况–临时测试人员反而经常在开始之前对软件的功能有全面的了解。
临时测试的类型
在软件测试中，有三种主要的临时测试形式，包括：
1.猴子测试
也许是最流行的临时测试类型，猴子测试是那些涉及一个团队随机查看不同组件的测试。
这通常发生在单元测试过程中，在没有任何测试用例的情况下颁布一系列的检查。 测试人员以完全非结构化的方式独立调查数据，让他们检查更广泛的系统及其抵御用户输入的强烈压力的能力。
观察这些非脚本技术的输出有助于测试团队识别其他单元测试由于传统测试方法的缺陷而错过的错误。
2.伙伴测试
在临时背景下，伙伴测试至少使用两名工作人员–通常是一名测试员和一名开发人员–并且主要在单元测试阶段之后进行。 这些 “伙伴 “在同一个模块上一起工作，以确定错误。 他们多样化的技能和全面的经验使他们成为一个更有效的团队，这有助于缓解许多因缺乏文件而产生的问题。
开发者甚至可以自己建议一些测试，让他们确定可能需要更多关注的组件。
3.成对测试
结对测试类似于涉及两个工作人员，但这通常是两个独立的测试人员，其中一个执行实际测试，另一个做记录。
即使没有正式的文件，记笔记也可以让团队非正式地跟踪个人的临时检查。 测试员和记录员的角色可以根据测试的情况进行转换，或者在整个过程中保持他们所分配的角色。
拥有更多经验的测试人员通常是进行实际检查的人–尽管他们总是互相分担工作。
手动或自动的临时测试？
自动测试可以帮助团队在整个质量保证阶段节省更多的时间；这让测试人员在他们的日程安排中安排更多的检查。 即使没有明确的结构，测试人员也必须努力使覆盖面最大化，自动化鼓励对该软件进行更深入的检查。
自动临时检查通常比手动测试更准确，因为它们能够避免在死记硬背的任务中出现人为错误–这在不同的迭代中颁布相同的测试时特别有帮助。 这一程序的成功通常取决于团队所选择的自动化测试工具及其功能。
然而，自动化测试确实有一定的局限性。 例如，临时测试的主要优势是它能够模拟用户的输入，并在测试人员想出时颁布随机检查。 如果组织的测试程序在复杂的检查中挣扎，这些测试可能会失去其随机性。
将这些高度具体的任务自动化所需的时间也可能限制了这个过程的典型的时间节约。 重要的是，团队要彻底调查可用的自动化工具，以找到符合他们公司项目的工具。
你需要什么来开始临时测试？
以下是临时测试的主要先决条件：
1.合格的工作人员
由于临时测试是对软件内部工作的快速、随机的检查，通常有助于拥有对该软件有经验的测试人员。 他们还应该对关键的测试原则有一定的了解–这可以让他们轻松地确定最有效的检查。
2.一个非结构化的方法
测试人员必须愿意放弃他们通常的临时测试策略；这种心态与质量检查本身一样关键。 这种方法只有在没有结构或文件的情况下才能成功，测试人员在每个阶段都记住这一点至关重要。
3.自动化软件
虽然临时测试更依赖于测试随机输入和条件，但在任何情况下，自动化仍然是一种非常有效的技术。
出于这个原因，临时检查仍应尽可能实施自动测试工具，因为正确的应用程序可以大大简化这一过程。
4.其他形式的测试
临时测试与其他采取更正式方法的检查一起使用效果最好–帮助团队保证整个软件的实质性覆盖。 测试人员混合各种技术是至关重要的，尽管这可能是在他们完成临时性测试之前、期间或之后。
临时测试过程
测试人员在软件测试中进行临时测试时应遵循的通常步骤是：
1.定义临时测试目标
由于缺乏文件和结构，这个阶段是有限的，但最重要的还是团队有一个明确的重点。 测试人员可能会开始分享关于哪些即将进行的测试和优先考虑的组件的模糊想法。
2.选择临时测试小组
当团队集思广益提出一些潜在的临时检查时，他们也想出了哪些测试人员最适合这种类型的测试。 他们通常选择密切了解应用程序的测试人员，也可能将他们与开发人员配对。
3.执行临时性的测试
在决定哪些测试人员适合这个阶段后，这些团队成员在测试的一个商定的点上开始检查。 他们的目的是执行尽可能多的临时检查–测试人员可能直到这个阶段才设计出这些检查。
4.评估测试结果
在完成测试后（甚至在个别检查之间），测试人员将对结果进行评估，但不将其正式记录在测试案例中。 如果他们发现申请中的任何问题，他们会非正式地记录下来，并讨论团队的下一步行动。
5.报告任何发现的错误
一旦他们评估了结果，测试人员必须告知开发人员软件中存在的错误，这样他们就有充足的时间在发布前修复它们。
测试团队还利用这些信息来确定如何改进他们的正式测试流程。
6.必要时进行重新测试
测试团队可能会对应用程序的新迭代重复这个临时过程，以检查它处理更新的情况。 由于测试人员在测试案例中已经修复了许多以前发现的漏洞，未来的临时检查可能需要不同的方法。
临时测试的最佳做法
在临时测试期间，测试团队应该实施某些做法，包括：
1.瞄准潜在的测试差距
虽然临时测试涉及的计划比其他类型少得多，但该团队仍然旨在解决质量保证方面的缺陷。 如果临时测试人员怀疑团队的测试用例存在任何具体问题，他们应该在进行检查时优先考虑这个问题。
2.考虑自动化软件
自动化策略，如超自动化，可以为想要进行临时测试的公司提供许多好处。
这方面的成功取决于几个关键因素，包括企业选择的工具，以及他们临时测试的一般复杂程度。
3.做全面的笔记
在临时测试中缺乏文件，主要是为了进一步简化这个过程–团队在进行过程中做非正式的记录，可以从中受益。 这给测试人员提供了这些检查及其结果的清晰记录，提高了他们的整体可重复性。
4.不断完善测试
临时测试人员不断完善他们的方法，以考虑到团队测试策略的变化。 例如，在查看公司软件的较新版本时，他们可能会根据较新的、更具包容性的正式测试案例来调整这些检查。
执行中的7个错误和陷阱
临时测试
与任何测试过程一样，有很多潜在的错误，团队应该努力避免，例如：
1.没有经验的测试人员
为了保持临时测试的预期速度，团队领导必须根据测试人员所具备的知识和技能来分配他们。 虽然许多形式的测试可以容纳入门级的质量保证人员，但临时检查需要充分了解软件的团队成员；最好有运行这些测试的经验。
2.没有重点的检查
临时测试由于其速度较快，可以显著提高测试覆盖率–团队不需要在每次检查前后填写大量文件。
然而，临时测试人员仍然必须保持强烈的关注；例如，他们可能决定优先考虑某些有更大失败风险的组件。
3.没有规划
避免任何计划可能会限制临时测试的有效性。 尽管这种方法是非结构化的，但重要的是，团队在开始之前对要运行的测试有一个粗略的想法。
在这个过程中，时间是有限的，知道如何进行可以带来很多好处。
4.结构性过强
在光谱的另一端，这种方法通常依赖于缺乏规划，因为这有助于测试人员主动颠覆测试用例并发现隐藏的错误。
临时测试也被称为随机测试，将一个结构强加给它可能会阻止这些检查定位错误。
5.没有长期变化
临时测试的目的是找出团队测试用例中的任何弱点；这就像检查软件本身一样，检查他们的整体策略。
然而，这意味着只有当团队使用这些信息来逐渐完善他们的正式检查时，临时测试通常才会有效。
6.不兼容的数据集
几乎每一种形式的测试都需要某种形式的模拟数据来评估应用程序的反应；一些工具让测试人员自动填充模拟数据的程序。
然而，这可能并不反映用户如何与软件打交道–临时检查需要软件可能遇到的数据集。
7.信息孤岛
测试人员和开发人员之间必须不断沟通，即使后者不属于临时测试过程。
这有助于每个人了解哪些测试已经进行了–显示出接下来要采取的行动，同时也防止测试人员不必要地重复某些检查。
专案测试的输出类型
专项检查产生几个不同的输出，包括：
1.测试结果
各项测试产生不同的结果，具体到所涉及的确切成分和方法–这可能有多种形式。
通常是由测试人员负责确定结果是否构成错误，尽管由于缺乏文件，很难将其与他们的预期进行比较。 如果发现任何问题，团队会将这些结果传递给开发者。
2.测试日志
该软件本身使用一个复杂的内部日志系统来监控用户的输入，并突出可能出现的一些文件或数据库问题。
这可能指向一个内部错误，包括导致该问题的软件的具体部分。 有了这些信息，专门的测试人员和开发人员可以更容易地解决他们发现的问题。
3.错误信息
许多临时检查的具体目的是打破软件并暴露其极限，这意味着应用程序的错误信息是这些测试最常见的输出之一。
通过故意造成错误信息，团队可以展示普通终端用户在他们采取的意外行动对程序的运行产生不利影响时看到的情况。
临时测试实例
这里有三个临时的测试场景，显示了一个团队如何为不同的应用实施它：
1.电子商务网络应用
如果一个公司希望测试一个基于电子商务的网络应用，他们可以使用临时测试–特别是猴子测试–来观察平台处理意外的用户互动的情况。
测试者可能旨在将每个功能推向极限，例如以不切实际的数量将物品添加到他们的购物篮中，或试图购买缺货的产品。 他们不受团队测试案例的限制，他们可以进行的检查几乎没有限制；测试人员甚至可能尝试使用过时的URL完成购买。
2.桌面应用程序
临时测试人员也可以对桌面应用程序实施这些技术，可能的重点是不同的机器以及它们各自适应程序的程度。
团队成员可能会反复进行这些检查，以了解改变硬件或软件设置如何影响一个应用程序的整体性能。 例如，一个特定的显卡可能会在渲染界面时遇到困难。
另外，这些测试人员可以简单地给他们的程序提供不可能的输入，看看它是如何反应的，例如它是否能够正确地显示错误信息，向最终用户充分解释问题。
3.移动应用
临时测试人员检查移动应用程序的一种方式是测试其安全协议–例如，他们可以尝试直接访问该应用程序的开发工具。
团队可以尝试通过寻找常见的漏洞和利用方式，看看是否能够进行未经授权的操作；他们可以专门请在应用程序安全方面有经验的工作人员来促进这一工作。
这也可能涉及到与开发人员的配对测试，因为他们对应用程序的设计有深入的了解，让测试人员打破软件，准确显示其安全性的不足之处。
检测到的错误和bug的类型
通过临时测试
临时检查可以发现一个程序的许多问题，如：：
1.功能性错误
使用临时测试来检查一个应用程序的基本功能，可能会发现严重的错误，从而影响终端用户如何与之接触。
例如，猴子测试一个电子商务网站的支付选项将说明阻碍交易的条件。
2.性能问题
测试人员可能专门致力于在程序中制造性能问题–例如通过在数据库中填充各种垃圾邮件的输入。
这可能表现为明显的滞后时间，甚至是一般的软件不稳定，这将可能导致（可能是全系统）崩溃。
3.可用性问题
这些检查也可以突出界面和一般用户体验方面的问题。例如，一个移动应用程序的用户界面可能在另一个操作系统或屏幕分辨率上呈现出不同的效果。 糟糕的界面可能会导致用户在操作该应用程序时遇到困难。
4.安全缺陷
临时测试的随机性使其能够涵盖一系列常见和罕见的安全问题；测试人员可能会使用这些检查来发现一个程序的管理后门。
或者，他们的检查可能显示该软件没有数据加密。
常见的临时测试指标
专案测试使用各种指标来促进其结果，包括：
1.缺陷检测效率
这个指标考察的是测试过程在每一种测试形式中发现缺陷的有效性，包括临时性测试。 缺陷检测效率是指发现的缺陷的百分比除以问题总数–显示测试的有效性。
2.测试覆盖率
临时测试的一个辅助功能是通过检查组件的方式来增加覆盖率，而测试用例并没有考虑到这一点。 这意味着测试人员也将尽可能地从根本上提高每个检查的测试覆盖率。
3.总测试时间
临时测试比其他质量保证过程要快得多 – 测试人员必须努力保持这一优势。 测试持续时间指标向团队成员展示了他们如何能够节省时间，并进一步复合临时策略的优势。
4.撞车率
这些测试通常旨在破坏软件并导致崩溃或严重错误–让他们超越典型的测试策略并发现意想不到的问题。 为此，了解软件崩溃的频率和导致这些问题的原因会有所帮助。
5个最好的临时测试工具
在软件测试中，有许多免费和付费的测试工具可用于临时测试，最好的五个工具如下：
1.ZAPTEST免费和企业版
ZAPTEST是一个全面的软件测试程序，在其免费和企业版本中都提供了强大的测试+RPA功能。
这个全栈软件自动化+RPA套件允许在不同的桌面和移动平台上进行全面测试；该软件的1SCRIPT技术还可以让用户轻松地重复执行相同的检查。 在此基础上，该工具利用最先进的计算机视觉，使ZAPTEST有可能从人类的角度运行临时测试。
2.浏览器栈
BrowserStack是一个云平台，可以方便地在3000多台不同的机器上进行测试，还有一个特点是可以实现Selenium脚本的自动化。 虽然它为软件项目提供了强大的覆盖面，但它在浏览器和移动应用程序方面的效果最好。
BrowserStack测试解决方案还包括100分钟自动测试的免费试用–尽管这可能用途有限。
虽然基于云的方法可能是有帮助的，但它也对平台的响应时间产生了负面影响。
3.LambdaTest
LambdaTest同样使用基于云的技术，并且非常强调浏览器测试，这可能会限制其对其他应用程序的有效性–尽管它仍然与iOS和Android程序很好地衔接。 当可扩展性是一个问题时，这是一个有用的平台，并与许多其他测试托管服务整合。
然而，一些用户对该应用程序的各种非试用选项的定价反应不一，有可能限制了小型组织的使用。
4.测试轨道
TestRail由于完全在浏览器中运行，一般来说适应性很强，尽管非常注重高效的测试案例，但也拥有直接的临时性功能。 它在每次测试后提供的分析结果也可以帮助那些积极避免制作自己的独立文档的团队，同时仍然让他们验证自己的测试过程。
然而，较大的套件可能会在其基于浏览器的格式中挣扎，这可能会大大限制临时测试的时间节约。
5.Zephyr
Zephyr是SmartBear的一个测试管理平台，帮助质量保证团队提高他们的测试可见性，同时也与其他错误跟踪软件很好地整合。
然而，这一功能仅限于某些应用程序，Confluence和Jira是最受益于Zephyr的应用程序–这些可能不是每个企业最有效的解决方案。 Zephyr品牌下有几个可扩展的项目，价格各不相同。
临时测试清单、技巧和窍门
以下是团队在进行临时测试时需要考虑的其他提示：
1.优先考虑敏感部件
一些功能或组件自然比其他的更容易出错，特别是如果它们对程序的整体功能很重要。
每一种测试方法都应该确定应用程序中可能从更彻底的关注中受益的部分。 当测试的总体时间有限时，这尤其有帮助。
2.调查不同的测试工具
一个组织为促进其测试而实施的工具可能会影响这些检查的覆盖面和可靠性。
通过临时测试，值得关注尽可能多的程序，以找到适合其用户中心的程序。 使用计算机视觉技术的软件，如ZAPTEST，可以使用类似人类的策略来接近临时测试。
3.采取临时性的思维方式
临时测试在整个质量保证阶段提供了巨大的自由，但团队必须致力于此，以获得该策略的关键好处。
例如，专门的测试人员应该摒弃除基本笔记以外的所有常用文件，他们需要从一个全新的角度来检查软件。
4.相信测试的本能
临时测试或一般软件检查的经验可以帮助突出常见的故障点，这有助于测试人员确定如何发现所有类型的错误。
至关重要的是，测试人员要相信自己的直觉，并始终利用这些知识来发挥自己的优势–他们可以凭直觉判断哪些临时检查是最有用的。
5.全面记录发现的错误
虽然临时测试没有正式的文件，大多依靠非正式的笔记，但团队能够识别和沟通软件错误的原因仍然是至关重要的。
他们必须记录测试提供的任何与开发人员有关的信息，例如这些问题的任何潜在原因。
6.始终对用户负责
每种形式的测试都打算在一定程度上适应用户的整体体验 – 临时测试也不例外。 虽然它通常更深入地研究应用程序的内部工作，甚至其内部代码，但临时测试人员应尝试以用户理论上可以做到的方式来破解这个软件。
7.持续改进流程
测试团队应该在同一软件的多个迭代之间以及从一个项目到下一个项目之间完善其临时测试的方法。
他们可以从开发人员那里收集反馈，看看他们的临时测试对质量保证阶段有多大帮助，以及他们是否能够显著提高测试覆盖率。
结论
临时测试可以帮助各类组织认证他们的软件测试策略，但他们实施这种技术的方式可能是影响其有效性的一个重要因素。
平衡不同的测试类型是从临时检查中获得最大利益的关键–特别是这种形式的测试打算通过填补战略空白来补充其他的测试。
有了像ZAPTEST这样的应用程序，团队就有可能以更大的信心或灵活性进行临时测试，特别是如果他们实施自动化。 无论团队的具体方法如何，他们对临时测试的承诺可能会彻底改变整个计划或项目。
