还未发布过话题
  • 而且你的业务应该没有接触到复杂的场景,如果遇到其他协议要用到第三方模块,工具玩的再转也没什么卵用
    (比如我之前公司做远程课堂的(类似视频会议),要用到 sipp 工具来注册和发视频流和音频流(sip 协议),中间还要和和三四个服务器各种交互)我不知道工具怎么搞定

  • 1、用手去点一堆按钮然后编辑一堆配置文件,我不觉得这是简单的方法(明明几行代码能搞定的)
    2、性能测试的话,python 用协程去并发也不差的,至于测试报表和上面的统计项自己实现也不难,而且这个不像工具上面有时会造成一个假的压力值
    3、好多测试工具编写的年代比较早,那个时候的普遍认知是测试不需要编码能力,导致工具都是面向 “点点点和配置文件”

  • 感觉现在行业缺的就是【说点别的】😂

  • 面试又失败了 at 2020年11月27日

    没事,多面面就好了,类似这种面试很多,都是实现功能后,单元测试里的用例划分好写全;尤其是用例设计是主要考察点,当然前提是得实现;

  • MTSC 参会感受 at 2020年11月23日

    第一点是趋势,是行业的发展和社会发展的选择;
    第二点不是很赞同;
    第三点用不着去辩论了,已经是事实了

  • 我技能和你差不多,画板子、嵌入式(stm32)、各种仪器使用(第一家公司呆了两年;偏硬件测试)

    性能测试调优、运维(k8s 玩的还可以)、前端(vue)、 后端(python tornado 微服务的主框架然后各种中间件(redis、mq 之类的))、售前、技术支持、产品原型图,基本一个项目从需求到交付都参与了。。。(小公司呆了两年,唯一和测试沾边的就是性能测试和调优。。。)

    感觉自己就是那种临时工具箱,现在准备全力转后端

  • [但是因为考虑计算复杂及实时性,比较占用服务端性能,所以放到前端]---这个应该不复杂也不占性能。。。【应该是后端怕麻烦为了省事把这些烦人的业务甩了出去】
    我比较赞同 5L 的观点,整套系统的架构确实有问题,至于避免这类问题的发生,要么加人,或者单元测试写详细点,而且单元测试你得参与(用例设计和编码)