先补充一下昨天没有看完的前面一节的内容吧
开一扇测试窗口
书上在这一部分讲了我们应该如何support产品。产品环境和测试环境不同，我们一般不会直接通过调试器debug产品的运行情况，包括功能非常强大的arthas我们也不会在产品上直接使用。对此书上建议可以在特定的地方加入log，这里需要注意日志的格式一定要同一，不然会给后面的support添加难度。此外还可以暴露一些"魔术URL"，访问这个URL可以暴露诊断窗口。
此外我们的系统还使用了ART工具，自己定义了切面，对controller的方法记录了操作人以及入参信息，方便后面的support。
对于日志，我们现在的做法稍有一点被动。我们在完成一个新的需求的时候一般不会在里面加入log，除了一些预感到后面会有很难的support case的时候。然后等到产品上产生了异常，有一部分根据Exception还无法查明原因，只能再往代码里加入log，等下一个版本才会有日志信息。我们的系统对于日志还有一个优化点，如果我们想新加一个日志，就要在每个环境的配置文件中加上日志文件的配置，每次都需要修改十几个文件，对于这个配置我觉得可以优化一下。
测试文化
测试可能有三种：
- 测试先行
- 边做边测
- 永不测试
我觉得第一个太难，最后的不可取，可以考虑第二个。我就有一个不好的习惯，我一般只在整个Story做完了才会测试，通常就是改了十几个文件，最后直接跑整个流程，跑通了就提交代码了。
使用基于特性的测试
举个例子，我们测试一个排序函数。那么输出结果的特性就是：结果的元素个数和输入的元素个数相同；结果集里面每一个元素都比后面一个元素小。对此我们就可以编写测试了。
基于特性的测试作者在书中举的例子是一个Python的库，它可以随机的生成测试数据，而我们的单元测试一般都是指定了输入集。所以这就是基于特性测试的一大弊端，如果测试没有通过，则需要再另外编写单元测试排查问题。
网友评论