用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址,几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
一个在某个国家读起来非常自然的地址,如果按照另一个国家的惯例来组织,可能看起来完全颠倒,或者干脆就是错的。门牌号、街道名称、地点、地区和邮政编码出现的顺序,是国家性甚至地区性的惯例,而不是固定的通用模板。假定您本国的顺序就是自然或默认的顺序,是在构建任何处理国际地址的系统时较为常见且完全可以避免的错误之一。
有些惯例把门牌号放在街道名称之前,有些则放在之后。有些把邮政编码放在同一行的城市名称之前,有些放在之后,还有些则把它单独放在另一行。城市、地区和国家的相对顺序也各不相同,少数国家按照行政层级自上而下地组织地址,与从具体建筑物开始自下而上构建的惯例相比,读起来几乎是颠倒的。
这对系统中两个截然不同的部分都很重要。输入处理,尤其是自由文本地址字段,需要真正容忍格式上的差异,而不是期待一个僵硬的模板,因为真实用户在输入本国地址时,自然会按照本国的惯用顺序书写,而不是按照您的表单设计时所依据的顺序。输出格式,也就是将返回的地址展示给用户时,最好遵循目的地国家自己的惯例,而不是无论地址实际位于何处,总是以一种固定的门牌号在前或邮政编码在前的布局来呈现每个地址,因为按当地格式书写的地址读起来很自然,而按外国格式书写的地址读起来明显别扭,即使每个底层组成部分都是正确的。
地理编码本身对组成部分顺序的容忍度通常比简单的解析器更高,尤其是当它将输入视为一个整体字符串,与已知的参考数据进行匹配,而不是期待组成部分按照严格的预定顺序出现时。尽管如此,专门使用来自多个国家、格式正确的示例来测试您的地址处理逻辑,而不仅仅是您本国格式的重新排列版本,可以在国际用户直接遇到问题之前,及早发现您自己的验证和显示逻辑中的漏洞。
如果您正在为国际受众构建地址输入或显示功能,值得刻意针对几个与您本国惯例差异明显的国家进行测试,而不是假定单一模板可以通用。我们的正向地理编码端点在设计上能够容忍输入本身的这些差异,但您自己外围的表单验证和地址显示逻辑,也值得针对同样多样的情况单独检查。