背景
年前我负责的工作基本完成或者暂停了，于是临时协助另一个同事，当时这个项目已经在测试阶段，是需要根据用户提交的信息提取属性值（如年龄、性别、籍贯、地址、公司、职业等，我们称为变量）。
需求
将用户输入的详细地址中的省、市、区、街道取出来并分别给这四个字段赋值。
问题
产品没有对处理规则和特殊情况做详细说明。
通过Code Review发现实现方式是简单粗暴的直接对地址做切割，开发同学估计没有考虑这么多情况，所以决定先通过简单冒烟确认一下大致问题。
进入测试
1 输入【广州市天河区珠江东路18号】（部分地址不全）
结果：省市区街道四个字段都为空
2 输入【广东省-广州市-天河区-珠江东路18号】（带其他符号）
结果：省市区街道后面都带上了-
跟开发大致描述了问题，修复和提交后进行第二次测试：
1 输入【北京市北京市朝阳区人民东路16号】（对直辖市来说会有两个市的情况）
结果：省份为空
2 输入【广西壮族自治区/南宁市/马山县/人民东路16】（省份的结尾不一定为省）
结果：省份广西，城市南宁市，区为壮族自治区马山县
3 输入【珠江东路16号/天河区/广州市/广东省】（顺序错乱）
结果：城市为空
这时候我已经不想一个个场景测出问题后再让开发改了，因为产品没有明确提出想要的效果，而且开发没有想到可能会出现的情况，每次修改都可能需要重构那部分代码，这样的效率和质量都很低。我想到一个方式，我们可以把验收用例整理给开发，开发直接根据我们提供的场景和预期情况设计实现方式。于是我和另一个同事一起给出了一些场景和预期结果，比如带符号的、地址位置错乱的、地区有缺省的、直辖市的地址、自治区的地址等。开发同学结合会出现的情况设计了较合理的实现方式，结果当然是高效高质量地完成这部分工作。
当然，这种情况的正确处理应该是产品给出明确的提取规则，但是这种需求比较特殊，产品只提出需要什么数据，具体的处理逻辑可能并没有考虑，这时候我们需要推动产品给出明确规则。在测试中发现有出入的逻辑问题时，需要产品、开发、测试坐在一起讨论出结论，最好不是由开发或者测试定下规则。但是验收用例驱动开发给我们提供了一种思路：当开发明确知道验收用例的时候，他能在编码时将需要处理的情况补充上，这时候代码质量是比较高的，相比后期测试时再进行调整，成本也较低。一份完整、准确的验收用例甚至可以代替需求文档。
网友评论