确实有这种情况,自上而下推行,纳入考核最好,实在不行测试也可以深度介入。
我是这么认为的,人工智能足够成熟之前,工具不会知道业务需求该如何实现才是正确的。
内推吗
已添加代码示例,code review 和静态分析、扫描还是有区别的,后者不能发现关于需求实现是否和预期一致的业务逻辑的问题,而前者可以发现,这点工具目前是无法替代的。
希望对你有帮助
如果大多是规范类的问题,说明你们的研发团队个人能力很强啊,规范类问题是锦上添花的事,需强制推行的流程规范去约束
文章写的挺好,18 年越来越好
设计阶段要考虑测试实施的便利性。例如:可配置性(白名单)、测试后门、关键环节打日志、页面元素分配 id 等
我知道你创建这个社区的初衷是好的,同时也希望你能静下心来仔细想想,哪些人是真心为测试行业在肺腑之言(无论你认同的还是你不认同的),哪些人是盲目的在跟从,哪些人是出于个人目的在无底限的迎合你,苦口良药利于病,忠言逆耳利于行。还是那句话,静下心来,仔细想想棋。
我的理解,做自动化或项目前应该要考虑落地效果:对效率的帮助、对流程帮助、对质量的帮助、可扩展性、易用性,然后再用技术 付诸实施。反对为了技术而技术,为了自动化而自动化,做啥事总要有目的,不是吗?我也是做技术的,实在看不出这段话有啥问题?
思想和技术的关系很好理解,你要用技术去做解决方案,总要设计规划吧,这就是思想,技术离不开思想,动了脑子思考问题,这就是思想,技术是为了实现思想。盲目自动化是指思想 level 太低了
有机会,哪天不想干了,你收下我吧
教授
多线程处理
我做的那个就串起来了
人工查有点繁琐,能不能把线索串起来更直观的展现给用户呢
能体会到你写这篇文章时的心情,基本能从一个人的文章中看出其人,我相信你是有情怀的人。社区需要不同的声音,难听的话不一定是坏话,好听的话不一定是好话。如果有几个老鸟都发声,你是否能冷静下来细细品味。还是那句话,文章里能折射出一个人的正能量,也能暴露出其阴暗面,时间是最好的裁判,拭目以待
1.做接口测试前需拿到接口设计文档或相关资料,里面会定义接口的请求方式、编码、content-type、请求参数、返回报文结构等定义,没有这个就失去了接口测试的衡量标准。
2.ajax 只是支持异步返回结果,它也支持同步返回,和异步接口是两个概念,异步接口一般会有相应的回调接口。
3.有些开发对接口的理解也有误区,跨系统调用接口获得最原始的数据,一般都会在业务层包装后由控制层暴露,这一层的接口才负责和前端页面或客户端交互。当然,复杂系统可能包三层的都有。
测试数据参数化管理
说的不错,一旦看懂开发写的代码,熟悉业务,针对性的开展测试工作,能极大提高测试效率和质量。以后的发展趋势就是懂开发的测试和懂测试的开发
挺好的,谢谢分享
一切技术都为解决实际问题服务,我更感兴趣的是关于多重跟踪这块,希望有更多的图文描述,以供借鉴。
感谢作者用心的扫盲,朴实的技术分享。
补充一点我的理解:
Socket 就是客户端与服务器之间通信用的套接字。
主流编程语言都为网络编程提供了 Socket API,基于此可以进行协议开发。
嗯,确实说明了些问题,行业土壤的问题。不过我对这个行业却是真的热爱,唯一能做的就是做好自己,帮助到周边的同事,虽然鄙人 coding 能力不一定比你们任何人差,知识面不一定比你们任何人少,但我觉得品质和思想比 coding 更重要。这个社区的初衷还是不错的,方向好坏在于舵手的高度
他们以为你是我小号,一针见血的点评他们是听不进的,好心当驴肝肺,兄台洗洗睡吧