也是差不多，我们主要关注召回率、可用率和对用例编写效率的提升情况。

哈哈，我第一次也是在这本书看到的。后面看《开窍》和别的书，里面也有类似的观点，所以记忆就越来越深刻了。

《穷爸爸富爸爸》是本好书。只是我自己实在控制不住自己，做不到尽量只花收益的钱，少动本金。

测试用例生成，这块还挺多公司在探索的。

从 tps 的图看，3 分钟后已经停止发起请求了，但直到 7 分钟结束，持续有 http fail 出现，说明是一直在等待 http 请求返回，直到全部返回都收到/都达到超时上限自动结束。

你把响应时间的图加上，应该就很清晰了。

嗯嗯，确实是可以换。我想表达的是，不具备投资的赚取收益属性，因为卖的时机取决于自己的刚需，而不是涨了就可以卖。而且自住的，也没法通过收租之类的方式持续获得被动收入，只是在不断地付房贷。

学习算不上，主要看一些理财书里看到的。

想先了解下，你这里的 产品质量 ，定义包括哪些？

比如一些需求内容不够明确，不满足实际业务需要，没达到预期的业务目标，在你这个范畴中不？

1、编程语言里的数据类型要转换为 json，有一个叫 序列化 的过程。这个过程会把变成语言里的数据类型，按照一定规则转为 json 里的数据类型。python 里一般用自带的 json 库进行序列化（具体要看你们研发的代码）。

这个库的 python 转 json 的转换规则如下：https://docs.python.org/3/library/json.html

2、按照上面规则，turple 应该转为了 json 的 array，而你的接口规定的参数类型是 string，自然对不上

3、覆盖的时候，覆盖 json 支持的格式就好。甚至有些场景下，没太大必要做这个测试，因为各个语言的反序列化其实是有一定的兼容性的，比如 json 传了 string 类型的"3"，语言中对应的类型是 int，会尽量转为 int。这部分转换是各个库自动完成的，开发压根不用写代码，风险也低。所以在做参数覆盖的时候，相比单纯从技术层面去设计，更建议从业务层面去设计。业务层面的才是研发要写代码实现的，也是风险更高的。

如果不打算做任何和代码沾边的事情（如自动化、提效脚本编写等），也不想和开发交流时让对方觉得你懂行，确实没啥用。

自住非投资的，就别看房价涨跌了。涨了你又不会卖，跌了你也不会买，何必为此影响心情？

另外，自住的房子，属于负债，不属于资产，和自用的车没啥区别（不具备涨了后随时出售赚取收益的属性）。好好享受下房子带来的便利和安定感就好了。