确实有这种情况，自上而下推行，纳入考核最好，实在不行测试也可以深度介入。

我是这么认为的，人工智能足够成熟之前，工具不会知道业务需求该如何实现才是正确的。

内推吗

已添加代码示例，code review 和静态分析、扫描还是有区别的，后者不能发现关于需求实现是否和预期一致的业务逻辑的问题，而前者可以发现，这点工具目前是无法替代的。

希望对你有帮助

如果大多是规范类的问题，说明你们的研发团队个人能力很强啊，规范类问题是锦上添花的事，需强制推行的流程规范去约束

文章写的挺好，18 年越来越好

设计阶段要考虑测试实施的便利性。例如：可配置性（白名单）、测试后门、关键环节打日志、页面元素分配 id 等

我知道你创建这个社区的初衷是好的，同时也希望你能静下心来仔细想想，哪些人是真心为测试行业在肺腑之言（无论你认同的还是你不认同的），哪些人是盲目的在跟从，哪些人是出于个人目的在无底限的迎合你，苦口良药利于病，忠言逆耳利于行。还是那句话，静下心来，仔细想想棋。

我的理解，做自动化或项目前应该要考虑落地效果：对效率的帮助、对流程帮助、对质量的帮助、可扩展性、易用性，然后再用技术 付诸实施。反对为了技术而技术，为了自动化而自动化，做啥事总要有目的，不是吗？我也是做技术的，实在看不出这段话有啥问题？

思想和技术的关系很好理解，你要用技术去做解决方案，总要设计规划吧，这就是思想，技术离不开思想，动了脑子思考问题，这就是思想，技术是为了实现思想。盲目自动化是指思想 level 太低了

有机会，哪天不想干了，你收下我吧

教授

多线程处理

我做的那个就串起来了

人工查有点繁琐，能不能把线索串起来更直观的展现给用户呢

能体会到你写这篇文章时的心情，基本能从一个人的文章中看出其人，我相信你是有情怀的人。社区需要不同的声音，难听的话不一定是坏话，好听的话不一定是好话。如果有几个老鸟都发声，你是否能冷静下来细细品味。还是那句话，文章里能折射出一个人的正能量，也能暴露出其阴暗面，时间是最好的裁判，拭目以待

1.做接口测试前需拿到接口设计文档或相关资料，里面会定义接口的请求方式、编码、content-type、请求参数、返回报文结构等定义，没有这个就失去了接口测试的衡量标准。
2.ajax 只是支持异步返回结果，它也支持同步返回，和异步接口是两个概念，异步接口一般会有相应的回调接口。
3.有些开发对接口的理解也有误区，跨系统调用接口获得最原始的数据，一般都会在业务层包装后由控制层暴露，这一层的接口才负责和前端页面或客户端交互。当然，复杂系统可能包三层的都有。

测试数据参数化管理

说的不错，一旦看懂开发写的代码，熟悉业务，针对性的开展测试工作，能极大提高测试效率和质量。以后的发展趋势就是懂开发的测试和懂测试的开发

挺好的，谢谢分享

一切技术都为解决实际问题服务，我更感兴趣的是关于多重跟踪这块，希望有更多的图文描述，以供借鉴。

感谢作者用心的扫盲，朴实的技术分享。
补充一点我的理解：
Socket 就是客户端与服务器之间通信用的套接字。
主流编程语言都为网络编程提供了 Socket API，基于此可以进行协议开发。

嗯，确实说明了些问题，行业土壤的问题。不过我对这个行业却是真的热爱，唯一能做的就是做好自己，帮助到周边的同事，虽然鄙人 coding 能力不一定比你们任何人差，知识面不一定比你们任何人少，但我觉得品质和思想比 coding 更重要。这个社区的初衷还是不错的，方向好坏在于舵手的高度

他们以为你是我小号，一针见血的点评他们是听不进的，好心当驴肝肺，兄台洗洗睡吧