上节课我们梳理之后，本节课就要正式开发对url / header / body的三处替换，我仔细看了下之前我设计的规则，占位变量必须用 ##变量名## 来占位。
在我们之前的开发中，是直接从run_case.py中复制过来旧逻辑的替换代码：
仔细观察，虽然替换的逻辑没有发生变化，但是取值明显不对了。
原来我们是用临时缓存的变量来传递,即 repr(str(eval(i)))，也正是因为如此才造成了并发时候的bug。
而现在我们现在是要从tmp_data中直接拿即可。
这里我们需要注意，图中的四处取值，其中两处是需要进行repr的，也就是需要用到完整的表达式方法展示数值。
这是因为url 和 普通文本参数 都是纯字符串替换。而json请求体和header的值有可能是任何格式，所以需要用到repr后才能替换。
repr：
所以我们用字典的话，也需要考虑一下这里。
不过在此之前，让我们先简单的实现另外两处 str(eval(i))的变化吧：
然后再考虑这俩个repr。
注意，这里我们要实际的去考虑这些参数的值 是怎么提取出来的。
先来回顾这部分代码：
如果是路径法提取出来的，那就肯定是原始格式，整形就是整形，列表就是列表.... 而用正则法拿出来的一定是字符串。
但是等到替换的时候，只能以字符串格式进行替换。
那么为什么要用到repr？
我们来看这个例子：
如果我们按照上图这个例子中，直接进行替换。那么得到的结果，新的替换后的new_d 就是：
请问，abc是什么？ 应该是个字符串，但是双引号呢? 丢了吧？ 这样当做header传输肯定会报错了
我们的预期应该是 ： {"key":"abc" }
所以需要进行repr处理：
这样的结果就变成：
这就算是实现了。
当然，小伙伴在写的时候，可能还会遇到bug或者报错。
其中有个可能的原因就是用户在设置的时候 设置成：
占位符带了额外的引号。
那么结果就变成了：
显然，多了引号。
这里的问题就是一个哲学问题了。因为用户如果随心所欲的去设计。那么我们的系统永远不可能正确。
比如 例子中的 header， 用户设置成 {"key": ##a## }
此时，你猜用户是按照哪种规则呢？ 我们最终的a 是按照字符串放进来，还是原始类型呢？ 我们是给a 用repr加上引号还是不加使用原始忠实替换呢？
如果我们确定给加引号,那万一a是个整形123，结果就变成了"123"
如果我们不给加引号，那万一a是个字符串"abc" ，结果替换就变成了 abc
所以最好的办法就是 规定！
规定 用户设置的值，不要手动额外加任何引号括号等，保持原始变量放在那就行。
然后我们的代码用repr拿到原始值的string格式，替换即可保证最真实的数据格式了。
好了，本节课到此结束。下节课我们要去完善 实际的报告整合部分功能了，欢迎继续关注：测试开发干货
