大多数情况下，卓越的测试从两个问题开始：谁是我们的客户？他想知道什么？

　　然而，如果我们的客户并不了解测试、开发，以及会影响产品工作的其他领域，有可能，他不清楚自己想知道什么。那么，我们从哪儿开始呢？我们可能会尝试看看系统的“地图”，并且询问相关的问题。

　　假设，我给你一张地铁系统的地图，并且要求你覆盖地铁系统，你会怎么做？

　　你可能会先选择某一条线路的终点站，乘车到另一个终点。然后，对其他所有线路重复这个操作。当你覆盖完所有线路时，你完成对地图的100%覆盖了吗？

　　也许没有。大多数地铁线路是双向的，为了覆盖系统，你必须在每一个方向乘坐一次。所以你这样做了。那么现在已经100%覆盖了吗？

　　也许还没有。在主线路外还有辅线，列车可以绕回，或者跳过某一站。当你乘坐所有的辅线后，你达到100%覆盖了吗？

　　也许还没有，地铁线并不是孤立的，在不同线路之间还有换乘站。为了覆盖地图，你需要覆盖每一个方向上线路之间的换乘站。现在，已经完整了吗？也许你还需要在每一站都下车，确认无误？

　　目前为止，我们用一种抽象的、结构化的方式在思考覆盖地图，还没有仔细思考使用系统实际上会发生什么。

　　我们没有讨论所有类型的列车——客车、维修车、等等；我们也没有讨论基础工程——铁轨、信号系统、电力供应——这些地铁系统运作所必需的支持。

　　我们还需要看看与其他系统的互连——人行道、巴士、电车、火车以及机场，等等；我们可能还要讨论不同类型的乘客——常客、学生、流浪艺人、障碍人士，等等。

　　我们也许还需要考虑他们为什么使用系统——在高峰时期上班、上学，在周末去看电影和购物，还是在酒吧打烊后回家。

　　我们还可以审视地铁的辅助系统——标识、垃圾回收、警卫、报摊以及广告。

　　我们还应该考虑系统和时间之间的关系——运行时刻表、实际到达时间、上车时间，等等。

　　我们还没有考虑我们如何观察不同时段——高峰时期、午间、系统关闭前的午夜。

　　最后，我们还要考虑一些环境的组合，可能导致非线性的影响——在高峰时期，列车拥挤，上车需要花费更长时间，不能像正常情况一样快速驶离，导致系统变慢，这种反馈又导致列车更加拥挤。

　　我们还没有讨论这些事情，也许是因为我们，或者客户还没有完全认识到测试的动机：为什么测试？然而，地图快速地激发了我们的思考，唤起更多的覆盖可能性。

　　事实上，对于系统的任何描述都是一张地图——流程图、结构图、UML模型、以及思维导图，等等。通常，我们询问地图上的某一个标记，例如UML模型中的某个动作，来设计测试用例。然而，当我们疑惑：哪些是最重要的？我们同样可以从地图开始，询问问题，可以使用启发式来寻找风险——最简化（Simplest），最普遍（Popular），最严酷（Critical），最复杂（Complex），最病态（Pathological），最挑战（Challenging），错误应对（Error Handling），间歇期（Periodic）。

　　- 从这里到那里，最简单的线路是什么？

　　- 标准路线是哪个？

　　- 哪些是基本路线？