潜意识需求是用户可能没有明确意识到或表达出来的需求，但这些需求在很大程度上影响着他们对产品或服务的满意度和体验。这类需求往往需要通过深入的用户研究、行为分析或是用户体验设计的洞察来发现和满足。
对于测试人员来说，这些需求是很容易被忽视的，由于它不会在需求文档里体现，因此很可能不会被测试覆盖到。随着时间的推移，非功能需求往往会成为潜意识需求。IT解决方案的日益复杂增加了潜意识需求的发生。它们确实需要测试，因为忽视它们会导致昂贵的产品返工。由于缺乏规范，测试只能依赖专家经验。
作为测试人员，我们偶尔都有同样的经历：新版本上线几天后，用户发现了一个严重缺陷。通常这不是核心功能，因为核心功能一切正常，但更有可能是一个非功能性问题，比如可用性、安全性或性能。这可能看起来不那么严重，但实际上，这些问题却相当棘手，解决起来既困难又费力。然后，项目经理来到你面前，问：“为什么你在测试中没有发现这个缺陷？你在测试上花费了超过x个小时，但测试的产品仍然有缺陷！”如果你是测试新手，你会面红耳赤，试图躲到桌子下面，考虑另谋职业。如果你是一位经验丰富的测试人员，你会保持冷静，直视项目经理的眼睛，说道：“没有人告诉我这个需求，那么我怎么知道它需要测试呢？去找BA，问为什么一开始没有说明这一点。”所以，项目经理走了，但你仍然对这种情况感到不舒服。虽然你不知道这个需求，但你仍然认为系统中有缺陷就是你的责任，尽管你从“软件测试的七条原则”中了解到，软件永远不会100%没有缺陷。实际上，你被一个潜意识的需求打倒了：每个人至少在用户方面都知道的需求，但这个需求被认为是如此不言而喻，以至于没有人关心并告诉你。
本文我们将研究这些潜意识需求的一些理论，看看我们是否能找到解决它的方法。
什么是潜意识需求？
潜意识需求的概念源于小日子Noriaki Kano的研究成果。20世纪80年代初，Kano教授为建立新的客户满意度模型奠定了基础，并开发了一个客户满意度模型（被称为Kano模型），该模型区分了与客户质量概念相关的基本属性和区分属性。虽然起源于营销研究，但Kano模型已成为IT业务分析和需求工程的基础之一。Kano模型区分了与客户满意度相关的三个类别的因素：
•性能因素：性能因素与客户明确需求的功能有关。它们与客户满意度之间存在线性关系：这些因素在产品或服务中出现得越多，客户满意度就越高。Kano将此称为“一维质量”，在需求工程中，它们通常被称为“满足者”或“有意识的需求”。
•基本因素：这些因素是客户隐含地期望在产品或服务中存在的因素。这就是需求工程所称的“潜意识需求”，因为客户认为这些功能是不言而喻的，甚至不知道这些功能。它们也被称为“不满者”：当这些功能存在时，没有人会注意到它们，因此它们不会提高客户满意度。然而，当它们缺失时，客户会认为产品或服务无法使用，并会非常不满意。Kano使用了“必须具备的品质”这一术语。
•WOW因素：第三类涉及功能，客户不认为这些功能是可能的，因此他们永远不会需求它们。因此，它们被称为“潜意识需求”。如果它们在产品或服务中缺失，客户将不注意它，所以它不影响满意度。另一方面，当它们出现时，客户会惊喜地发现：“delighters”，或者用Kano的术语来说，“有吸引力的质量”。Kano的一个有趣观察是，需求往往会随着时间的推移而改变。新的功能开始出现，几乎可以肯定的是，它们是潜意识需求。随着客户发现、体验和喜欢一个新功能，它成为一个明确的需求。渐渐地，当所有类似和竞争的系统都实现同样的功能时，客户会忘记系统最初没有这样的功能，并开始认为这是理所当然的，把它变成一个潜意识的需求。这就是为什么许多系统包含用户认为不可或缺的功能，而他们不知道为什么，因此也没有明确需求它们。一个很好的例子是手机上的相机功能，这个过程不到20年。第一次将摄像头作为手机的一部分，大多数客户都感到困惑：没有人需求这个潜意识功能。但作为惊喜，他们喜欢它，所有品牌都开始在手机上实现它，把它变成一个有意识的需求。如今，在购买新手机，每个人都认为它应该有一个摄像头，所以它已经成为一种潜意识的需求。对于分析师和测试人员
来说，有意识需求是最容易处理的，这些需求是由产品明确提出的，所以它们将明确地出现在需求文档中。潜意识需求如果没有经过测试，后面在生产中发现缺陷，用户也不会抱怨，因为他们一开始就没有要求这个功能（但请注意，这种缺陷如果涉及额外的风险，实际上确实需要测试）。在实践中，潜意识需求通常不涉及系统的主要功能，潜意识需求与一些“琐碎”的功能细节有关，与用户相关的质量标准（如可用性、安全或性能）有关，或与隐含的技术、基础设施、组织和法律限制有关。当然，根据产品和设计人员的领域知识，所有潜意识需求中的一定部分仍然会出现在系统的需求文档中。但可以肯定地说，相当大一部分是需求文档中缺失的。如果某个需求在需求文档中缺失，那么它在系统中实现的可能性极小。
如何处理潜意识需求？
对于测试人员来说，问题在于被测试系统的需求文档中缺少（大部分是潜意识）这类需求。在这种情况下，通常的黑盒测试技术不能使用，因为它们依赖于测试基础中的需求文档的分析。依赖于系统文档结构的白盒测试技术同样也不适用，因为系统的结构通常是从需求文档中推导出来的。
唯一剩下的就是基于专家经验：缺陷猜测、探索性测试。在基于经验的测试中，测试是从测试者自己的知识和经验组成的测试基础中推导出来的。因此，最大的问题是：测试者如何获得必要的相关知识和经验？那么，测试如何提升这方面的测试能力？
观察
•旨在不干扰用户的情况下，观察用户在通常的环境中工作。测试人员可能会注意到某些意外或未描述的行为、活动中的奇怪顺序或手动回避，这些都是潜意识需求的范畴。
•学徒制比观察更进一步。在这里，测试人员在系统部署的环境中进行简短的动手培训。当实际参与要完成的工作时，潜意识需求将很容易浮出水面。
•上下文查询是一种迭代的、现场数据收集技术，研究少数精心挑选的用户，以更全面地了解整个用户群的工作实践。
系统考古
系统考古学是一种从遗留系统的文档、用户界面或代码中收集有关新系统的信息的技术。当然，通过这种方法发现的大多数需求都将出现在测试系统的规格说明中。其余的需求要么与此特定情况无关，要么是潜意识的。
基于视角review
在这种技术中，测试人员使用特定的视角——在这种情况下寻找不熟悉的需求——从与系统领域相关的文档中检索信息，例如过程描述、公司规定。
这些技术有一个主要缺点：它们通常非常耗时。然而，为了获得识别潜意识需求和设计测试以减轻相关风险所需的全面领域知识，这种时间投资是不可避免的。一种完全不同的发现和测试潜意识需求的方法是通过示例进行规范。当整个开发团队在整个开发过程中应用时，这种方法效果最好，因为它促进了团队内的共享理解和信任。但即使是对测试本身，它也可以非常有用。
在这种方法中，测试用例不是从规格说明中推导出来的，而是从系统打算支持的工作过程中输入和输出的现实生活示例中迭代生成的。通过示例进行规格说明将为所有需求产生测试，无论是有意识的、潜意识还是潜意识的，从长远来看，这可能会比前面提到的技术更节省时间。通过示例进行规格说明和类似的方法（如行为驱动开发）的另一个好处是，由此生成的示例/测试用例最终会形成一个完整和最新的系统及其行为的摘要，即所谓的“活文档”。这里值得一提的另一种方法是设计思维。设计思维有多种变体，但它们都侧重于通过引入以人为中心的技术，如Persona和Empathy Mapping，来理解用户的真正需求。特别是对不同用户群体“痛苦”和“收获”的探索可以帮助测试人员识别以前未发现的潜意识需求。大多数设计思维变体中的一种常见技术是原型设计。原型设计为未来的用户提供了一个机会，让他们可以与新系统的早期版本进行实际操作，并对其行为提供反馈，从而轻松地揭示了潜意识需求。特别是所谓的低保真原型，如UI草图、故事板和客户旅程，在这方面非常有用。与通过示例规范一样，设计思维实际上是一个全队的努力，涉及分析师、设计师、开发人员和测试人员。
未来会怎样？
人们可能希望，随着IT分析和设计的专业化和成熟度的提高，测试人员对潜意识需求的担忧会逐渐消失，因为现在大多数产品所有者、业务分析师和需求工程师都学会了如何提取和沟通这些需求。然而，IT工作的趋势却恰恰相反。为了说明这些趋势，Cynefin框架非常有用。Cynefin框架是一个概念框架，作为“感知设备”用于辅助决策。它由戴夫·斯诺登在1999年为IBM工作时创建。Cynefin借鉴了系统理论、复杂性理论、网络理论和学习理论的研究，提供了五个决策背景或“领域”：
虽然最初用于决策，但它也可以用来根据IT项目必须处理的不确定性水平对IT项目进行分类：
•需求明确的项目。为明确的业务流程（如订单处理）提供支持。与此开发有关的一切都是预先知道的（“已知的已知”），因此，即使是潜意识的需求也会在规格说明中得到记录。在这些项目中，开发人员和测试人员可以轻松地依赖最佳实践。
•复杂的项目。它们通常涉及不同业务流程的集成，例如，ERP系统的开发。在那里，开发人员和测试人员可能会面临规格说明中没有出现的意外和潜意识的需求。然而，需求本身的类型是已知的（“已知的未知”），因此，通过选择现有的最佳实践，测试人员将能够处理它们。复杂项目是开发创新IT系统的项目，其中著名的例子有Spotify和Uber。在这里，开发人员和测试人员面临“未知的未知数”。因果关系只能在事后推断，而且没有正确的答案。开发团队将不得不制定自己的应急措施来处理固有的不确定性。设计思维提供了线索，以找到不可避免地缺失的潜意识需求。
•混乱的项目。不是项目管理的混乱，而是开发模块的混乱（“未知”）。团队完全探索了IT的新领域，如物联网、人工智能或机器学习。在这些项目中，不仅确切的功能，甚至未来的用户都是不确定的。但无论如何，这些系统将与用户互动，因此实现后遇到潜意识需求的机会是100%。唯一能帮助你的可能是一句史蒂夫·乔布斯的话：“follow your heart。”作为测试人员，你将不得不检视自己的潜意识需求，并在测试用例中使其具像化。
在IT的早期几十年里，大多数项目都处于明显的象限，自动化单个、严格划分的业务流程的“岛屿”。从20世纪90年代开始，我们开始尝试整合这些岛屿，项目变得复杂起来。随着互联网和移动应用程序的突破，我们看到复杂项目的出现，这些项目创建并触发了全新的业务流程。随着IT将其范围扩展到计算机的原始领域之外，蔓延到汽车、冰箱、灯泡或武器等产品，混乱项目正在迅速增长。因此，作为一名测试人员，准备好应对未知的事物；你会发现越来越多的潜意识需求。
往期系列文章
