用户测试
用户测试是由用户进行的，不是由伪装成用户的测试人员进行的，不是由秘书或者执行者伪装成测试人员、用户进行的。用户是使用最终产品的人。
用户测试是由用户或测试人员或其他人(有时甚至是顾客软件合同中接受测试的律师)设计的。用户测试的集合可能包括边界值测试、压力测试或任何其他类型的测试。
设计的有的用户测试是只由用户执行他们并报告程序是否通过这些测试的细节。如果你的目的是提供一个周密的、没有任何显示错误事件机会的系统脚本示例，那么这是设计测试的一个好方法。
如果你的目的是发现用户在系统实际使用中会遇到的问题，那么你的工作就比较难了。 软件测试
Beta测试通常是简单的、有效的用户测试，但是实际上它们是非常难管理的，并且不会产生大量的信息。关于beta测试的一些建议，请参见Kaner,Falk & Nguyen(1993).
一个好的用户测试，在给用户提供足够的结构来报告结果的有效性时，必须给用户的认知活动有足够的余地(在某种程度上有助于读者理解和解决问题)。
用户测试中发现的故障一般是可靠的和有目的的。少数用户会执行特别有力度的测试。但有些用户会把程序放到复杂的情形下运行。
场景测试
一个场景就是描述了一个假设情况的故事。在测试上，检查程序如何在这种假设环境下复现。
理想的场景测试是可靠的、有目的的、易于评估的、复杂的。
实际上，许多场景在这些特性中的至少一个上是微弱无力的，但人们依然称之为场景。这种模式的关键信息是当你设计一个场景测试并试图完成它时，你需要紧记这4个特性。
场景测试的一个重要变异是粗糙测试。故事中经常会有一个仅由普通用户使用的序列或数据值。然而，他们会出现在用户错误之外，或异常但似是而非的情形下，或敌对的用户行为下。Hans Buwalda(2000a,2000b)称之为“肥皂杀手”以区别于称之为“肥皂剧”的正常情形。类似的情形在安全测试或其他形式的压力测试下是普遍存在的。
在RUP(Rational Unified Process)中，场景出自使用用例。(Jacobson,Booch, & Rumbaugh,1999)。场景制定了参与者、角色、事务处理、参与者的目标、以及在试图达到目的的过程中发生的事件。场景是使用用例的一个实例化。一个简单的场景追溯了一个独立使用用例的全过程，指定了数据值以及用例中的路径。一个比较复杂的使用用例会首尾串联若干个使用用例，来追踪给定的任务。(参见Bittner & Spence,2003; Cockburn,2000; Collard,1999; Constantine & Lockwood,1999; Wiegers,1999.)警告性注意，请参见Berger(2001).
无论如何他们是继承来的，好的场景测试在第一次运行时具有很大的力度。
不同团队多久执行一个给定的场景测试。
有些团队创建一个类似回归测试的场景测试池。
其他团队(像我)一次或在很短时间内执行一个场景测试，然后设计另外一个场景而不是坚持使用一个以前用过的。
通常，测试人员生成的场景能洞察到产品内部。这在测试初期以及稍后的再一次测试中是非常真实的(当产品已经稳定，测试人员试图了解产品进一步的用途时。)
文章来源于领测软件测试网 https://www.ltesting.net/
