思考的是，测试方法根据测试的对象和测试目的而衍生的，有这个思路之后，我想就可以运用自己的思路选用测试方法，设计测试策略

这个主题很喜欢！

流程图画的挺好

微信和支付宝属于第三方服务，用 mock 处理，我理解是默认第三方服务是正常提供响应的，自动化主要测试的场景是贵司本身的服务。

不同的请求参数对应着不同的用例，那么可以配置多个 JSON 数据，但这种类似于 “写死” 的数据，不是特别灵活；那么，请求参数为什么会变化，了解变化规则，就可以动态生成参数，相对灵活一些。希望对你有所帮助。

不反对宣传自己的产品，但是还是期望有具体的内容，进行一些对比分析去阐述如何选择合适的自动化测试工具，以及你宣传的工具对比同类产品的具体优势是什么。

看起来不错的样子

通过实现一个目标，涉及了很多知识呀！学习到了！

功能测试其实是投入产出比比较高的测试手段，可以在合作的过程中，归纳总结分类常见问题，研究开发定位问题的手段等，夯实基础。对于自动化测试，或者性能测试等，如果公司业务不需要的话，是很难有实践机会的，可以通过课程学习，技术群交流等途径获取相关方面的知识，然后再去寻找合适的平台，希望能对你有所帮助。

质量堡垒的建设任重而道远，感谢大佬分享！

内容完整，对于自己写代码很有帮助。

公司规模不同，对于压测方案的设计也会不同。大一些的公司，会有自己的压测平台，专门组织压测的专职 QA，对于数据隔离、流量仿真、压测监控都比较完善，即可供支持的配套设施完备。但创业公司，初期流量访问并没有那么大，需要压测的场景简单，要求也不高，采用 Jmeter 或者第三方工具（比如阿里云）。建议，如果真的想专职做性能压测，推荐 https://time.geekbang.org/column/intro/100042501/ ，希望对你有帮助。

调研后，看看适不适合使用自动化，考虑投入产出比去节约成本，这样推行也有利于自动化的落地

沟通，很重要的作用是对齐信息吧，但是如果你遇到不成熟的同事，还没等说完事儿，直接就甩锅，人家就不跟你沟通，先发泄一通，怎么说呢，也很费耐心。

常用场景吧，每次都得手工重复的，是很多场景的前置条件，总结总结，提炼一下，做成工具后，能明显感觉到提效成果。

现实中，bug 描述 + 线下沟通，bug 准确的描述记录，体现工作量，后期的回顾归类等，但是当时还是在于与研发的沟通定位吧，但是，心里确实得知道怎么是好的 bug 描述，这样有效编写 bug 报告，这属于 QA 的基本功，要不断的温故知新。

最近也在回看设计测试用例的知识，设计的时候尽量从各个角度上考虑。产品 PRD 功能的覆盖、数据流转、新老接口等等吧，随着经验的增加形成自己的常用测试点列表。推荐看看《饿了么质量体系搭建实战》中的第二章，希望对你有帮助吧。

总让我想起来 robotframework 和 cucumber

区块链体现的是思维变化，测试使用的技术还是可以继续使用的，还有测试思维很重要。

首先，建议有时间去总结总结把过往学到的东西和项目经验，最好是落实到文档中。我也是工作快 3 年了，功能测试指定是占工作的一部分，自动化、压测等技能也是得根据公司具有业务的需要，毕竟每个公司也不一定需要自动化。
其次，大环境确实不好，以往的金 3 银 4，boss 直聘的消息都看不过来，现在每天都不多。
最后，关于留在此地，还是回老家，最好是想清楚，回老家可能没你想象的那么舒服。

说一下我个人的理解，你提到的研发对于自己开发的产品要求高，我觉得是好事，这样你就有更多的时间去做更加有趣的事情，比如说提效工具的制作，发现公司现有的研发流程是否存在缺陷，如何改进等等。
再说一下对于测试后期发展的事情吧，其实就我本人而言，工作年限大约 3 年吧，但经历过外企，大厂、小厂（创业公司），你会发现公司属性不同，对于测试岗位的要求并不同，大厂要求高，跟你合作的人能力很强，基本能很迅速的解决问题，但是自己可发挥的空间不是那么好争取到的，小厂的话，正是相反，但是需要你 cover 的东西很多。
出路这个事情吧，我说一下我个人的心态吧，仅供参考，时刻学习，随时准备被裁被淘汰（本人由于公司业务调整，已经被裁过两次了），其实大家说很多只是个人经验，重要在于你怎么看待这份工作，是想长干还是过几年转行，是想好好干，还是差不多就行了。

被对技术的热情感动，研究研究，再来讨论