期待你的分享

直接前置操作字符串 replace 可不可以

比去年好，面了几家，没一个过的，感觉公司做的项目太简单，还是自己的问题吧！

哥，你的排版真的是一言难尽

请问还在招聘吗

最简单的往往是最容易被忽视的，每次设计用例的时候就可能没有按照这个思维去做；导致设计的时候很混乱，每次我都是拿到需求先分析有哪些测试功能，然后再针对分析出来的功能画流程图 (相对复杂的)，根据流程图逐一运用黑盒测试的方法去设计每一个节点的测试用例。这些环节个人认为没有问题；到后边需要设计测试用例的时候，就会遗忘运用这些规则，而是凭着自己在这些节点中想到可能发生的场景去设计，这样感觉其实没有按照方法去设计高效；或者说有的时候有的逻辑可能套用不上等价类和边界值这样的方法；这也是我的一个小小的困扰之一。

这个考哪个比较合适，听说系统集成比较好过

很详细，感谢分享

这个实用的

个人觉得自动化维护成本真的不低

这个很正常的现象吧 我们的也是只不过我们测试不使用 python 使用的 jmeter 让开发把他加解密的方法打个包过来 引用进来 用它的方法在 beanshell 中调用实现加解密 整体过程就是这个思路 你用 python 应该更容易啊

很中肯了 还是觉得自己什么都半途而废 确实挺垃圾的

受教了 感谢指点！

赞同 硬学没有实践等于白学

1. 将要测程序打包成 jar 包 (这个网上有教程，很多)
2. 然后 jmeter 引入，放到 lib 目录等有多种引入方式
3. jmeter 使用 beanshell 写测试程序，调用引入 jar 包中的方法
4. 配合前置和后置使用 (根据业务需要)

赞同你的说法，个人努力固然重要。但是，也要看时运。有厉害的人带和一个人摸黑往前区别太大了。一个人奋斗能爬起来，真的是打心眼里佩服。之前读曾国藩的故事，很佩服他，换位思考了下，如果我在他那样的处境下，我绝对爬不起来，但是，他却越挫越勇，佩服这种精神；在以前什么都没有的情况下，那机会也固然大；而现在早已不同往日；但是，还是得摸黑向前。

看完这篇文章深有感触，首先声明一下本人情况，本人 97 年出生并没有大佬这么多的阅历，但是，您的发言我都一字不落的看完了，真的值得学习

1. 如果故事的开头因为自己太差，没有进入到好的公司，也没能遇到如同大佬这样的人，那后期的坑我觉得很难爬出来；为什么这么说，我举个例子。比如，进入一家公司，但是，这家公司测试体系不是很完善；在我看来，这是一个机会，如果像开头说的那样，像大佬这样带有优秀背景的；那就可以带这家公司的测试团队一路高歌猛进，最后起来，那最后的功劳最大的指定是您；其实，核心就是，如果自己开头太差，逆风开局，那这局游戏该怎么玩，也真心求教！

讲的很有道理，我们现在的测试团队我也不知道在一个什么层级，感觉好多东西没有真正测到点上，还只是表面的测试

最近也是在搞自动化，看到博主实现的方式好像和我这边的差不多，不过我的对异常处理和断言方面还不知道怎么做才是最好的，希望和你探讨一下，能否加个 wx 交流一下

是和我本地环境配置的有关系，本地环境配置也不会影响到 appium 的运行吧，如果是环境有关系，那应该是 node.js，你本地 node 的环境是哪个

我换了 1.15 的 appium 可以打开

也在时刻关注老家的行情，如果有好的机会，可能就要离开了

倒也是个方案

对，我也是这么想的，但是我可能更注重薪资方面，但是在这儿以我目前的实力来看未来应该在北京买不起房，难道真的要一直租房吗