无论是留下还是跳槽，现在都是一个考验你计划制定和时间分配的好时机；
跳槽的话就要找出自己的闪光点和能力范围

自顶！！！
请教各位大佬 TPS/响应时间在设计用例时的相互关系

英雄所见略同啊，质量的控制与提高是测试永远离不开的中心点，但是除此之外我还有一些想法，亮有一言，请诸位静听。测试岗位的引入首先带来的除了硬性的产品质量提高，还有一种思想上矛盾面的出现，即使是一个应届生测试人也会给项目内其他人员带来一种警戒与自我怀疑，这也在另一方面提高了产品质量。

如何问一个问题呢：1.说清楚自己观察到的现象，无论是直接还是间接的 2.说清楚问题出现前的操作，给出自己认为的可能性关联点 3.如有相关日志或其他相关信息，一同给出完整题 4.如有初步的定位结果或定位进度一并给出 5.说清楚自己的问题中心点，无论是否与实际问题中心一致 6.保证回答者的权威，如果你很确定自己的正确性，求同存异给与其应有的尊重

总结下就是持续集成这事只能在公司流程完善，产品成熟，计划安排合理的情况下去做

input

你的意思是同一串信息，不同的来源（解密/抓包），然后抓包的就可以直接使用登录吗？

一个关注的是接口本身，一个关注的是接口间的流转情况，可以在保证接口无问题的情况下进行完整流程的接口间调用测试。其实这个就和单元测试后集群测试的性质差不多，个体与集体的关系

测试 - 技能图谱！干饭人！

不明觉厉，时代的洪流滚滚而过，不进取的结果只有被取代！

对流计算的具体流程有了概念，但是具体测试手段还是有些不清晰，主要疑问点是 checkPoint 的间隔时间点内去多次注入故障，以求出现数据重复类的问题，可是大数据量的情况下，怎么去验证数据重复的问题出现呢？现在项目也在用
sql-》kafka-》flink》sql 的流程，是不是可以直接通过两端此时间段内的数据量差别来进行确定呢？

简单来说，左移：把自己当成产品人员来对待需求，提高需求质量，优化需求方案；右移：把自己当成现场/实施人员来看待产品，发现可能在实验室中无法发现的线上环境导致的问题

测试负责的情况其实就一种：从测试手上出去的产品出的问题。
当然有几个前提：1.代码在测试结束后未变 2.出现的问题已在测试阶段提出 3.测试结果为质量较差，不建议上线，然后强行带风险发版 4.出现的问题与需求不符

base

一台电脑都有哪些组件，怎样的电脑算好电脑，怎么组装一台不黑屏且可以热菜的电脑

真香啊，我要去上海!!!

嗯，我只是给个建议

看了半天。。不知道咋回你，建议问问题拿一个线程组的结果来问，这看起来太费劲了，一堆都是 tps 的图。如果想直接找下性能瓶颈可以参考下https://testerhome.com/articles/20773

算平薪啊，那就没必要去试外包的坑啊

非大佬：在我毕业后当了两年外包后，就此立誓：再也不进外包！除非给的很多
你这个问题，我认为你说出现在的薪资或者你换工作的目标薪资和经验来，这样能给你看下跳槽的性价比
最后，外包行业最不可信的几点（至少我认为）：1.可转正 2.可涨薪 3.和正式工一样 4.可靠

大家的反应有点大哈，已经表明了经验 1-3 年。。只是兼职来整下内推，合适的来，不合适的也不强求

就测试报告而言肯定是发版前发，因为是否发版是要参考最终的测试报告内的测试结果来进行评估的，如果直接发版了还测了干啥。

我看着这个 10/2 陷入了沉思

全篇都在诠释一个道理：困难创造目标，坚持塑造成功。向大佬学习

当我刚毕业的时候就已经在思考这个年龄的问题了，至今两年了，没有改变