相空间（Phase Space） 的概念是由 "动态系统理论 "提出的。
"动态系统理论 "是一个数学领域，它描述了复杂系统的存在及其相互猜想和独立的行为。
相空间是一个系统存在所有可能状态的空间；而这些状态以独立的形式共存并相互对应。
举例：一个参数化的太阳系和存在于该系统中的相互猜想的物体，存在着依赖关系、重力的推力和拉力、一个物体对另一个物体的摆动效应对物体内部构成的影响，以及一个系统如何在其存在中将物体保持在边界内。
对于软件应用程序而言，相空间代表的是以有限时间循环（"实例、函数、数据和应用程序接口的启动和终止"）为边界的系统组件，其中包含可见和不可见的边界。
这些边界的存在取决于为软件组件编码的条件和限制，或者取决于系统与其用户和物理世界中其他实体的交互程度。
存在于相空间中的软件对象：
描述了相空间中相互之间具有引力结合的对象，有些对象作为质量影响因素保持在中心位置，而其他对象则反映出更多的不稳定性，在这种微妙的平衡中，我们可以看到一个由相互结合的对象组成的平衡生态系统。
1、运动：
作为一项普遍原则，每个受力约束的物体都会以一种混乱但可预测的方式运动。物体可能会改变路径、轨迹或速度，但会保持一种模式，这种模式可以被观察到，然后受到外力的影响。这与任何软件应用组件都是一样的。
2、力和吸引力的关系
驱动力与吸引力关系的神谕所依据的原理是，如果一个物体通过一定的力对另一个物体产生吸引力，那么就应该有一个相反的运动力来为吸引力创造这种运动。就软件应用而言，移动物体的最大吸引力是数据、用户组合及其行为。
3、摇摆效应
晃动的概念与对象实例之间的交互有关。这种交互可以通过内部应用程序接口、数据或用户的外部游览进行。
由于用户或应用程序接口已成为交互的媒介，不同领域与核心系统对象的交互也可能造成这种影响。
示例应用存在于相空间中，具有摆动、力、推力和来自其他物体和应用的拉力等物体通用特性。
测试人员的观念：
测试本身就是一项封装活动。如果我们把测试看作是一个三维形式，那么理想的情况是它形成一个球体，而这个球体的核心永远是规格和要求。
“上下文 "会对应用球体产生巨大的引力。需求在时间上的变化与上下文对应用程序的影响成正比。
这就改变了一切，因为一旦应用程序不属于开发人员的领域，而基本上处于开放状态（掌握在测试人员和用户手中），用户体验、业务规则、认知行为、测试结果、边界分析和技术的强烈刺激就会将应用程序作为结构化代码行的看法转变为某种边界摇摆不定、对人机交互极为敏感的物体。最终，错误就是这样产生的。
无论我们在有限的时间内编写多少测试用例，我们都无法确保达到所需的覆盖率。这种上下文膨胀的实际效果改变了游戏规则。
这里的关键是要从第一组需求中提取出坚固的东西。要有足够的灵活性，能够承受通货膨胀的压力。
例如，请考虑以下共享乘车应用程序的情景：
- 乘客希望预订乘车服务。
- 应用程序浏览可用的乘车服务列表。
- 乘客匆忙中点击了乘车服务，刚刚开始接载乘客，正在移动中。
- 乘车服务预订成功。
- 乘客收到一个预订号码，现在可以在应用程序上跟踪即将到来的车辆以及车辆和司机信息。
- 车辆驶近，但从未停车接载我们的乘客。
- 这里发生了什么？
- 司机应用程序的应用场景是，当司机发起乘车时，不会为车辆预订任何乘车服务。
- 通勤应用的应用场景从未打算停止或拒绝预订已启动的乘车服务。
- 人的状况触发了软件状况，导致用户不满和操作延迟[list=1]
客户的感知
- 人在使用软件应用程序时的行为会因花费在该应用程序上的时间而发生变化。
- 在上述示例中，乘客从出发到到达某个目的地，每天可能至少使用应用程序两次，因此考虑到 4 周的行程，每月的次数约为 32 次。
- 与现实世界中的用户和软件进行的这几次交互（如上所述）可能会触发无限多的上下文事件和行为决策，这些事件和决策既不会作为测试用例写入代码，也不会在 UAT 中提及，更不会在用户旅程交互和焦点小组会议中突出显示。
- 例如，就通勤应用而言，如果没有实际使用车辆、旅行、上机、结账和支付测试用例，就无法测试所有应用场景。
请慎重考虑，这类测试不可能在无限的时间范围内进行。情况恰恰相反。这些测试都是按照编写好的脚本进行的，有一定的时间限制，受众也最少。
这类活动的结果通常是由 "未声明的假设 "驱动的，即开发人员和测试人员认为问题 "太明显"，不可能发生，并将其视为小事(当局者迷、灯下黑)，或者说 "如果发生了，我们会处理的"。