这里 100 个车，总得通过时间不应该是最后一排车通过的时间，即 5 秒吗？那么 TPS 不应该是 100/5=20 吗？

响应时间应该是获得服务器响应的时间。前 20 个车的响应时间是 1s，后面的响应时间肯定会加长。

个人觉得，把冒烟测试自动化，已经满足了大部分公司大部分团队的基础需求了。
其他的，从效率，从成本来看，还是以功能为主。

表示第一次用小黄车就是这样的，莫名被扣了一块钱。而且当时急着赶路，也没去联系客服什么的

做测试啊 想转产品 可是还没遇到合适的机会

25 未婚 看的也想转行了
但是转哪行呢

总觉得在哪看过类似的描述。楼主把原链接贴出来把

去年我和楼主情况差不多，在苏州的小公司，测试不受重视，很多东西自学了想在团队里推，结果人不够只能勉强进行功能测试。
年前下好决心跳槽，到上海这边投了几个简历收到几个 offer 以后，权衡一下去了一家银行全资子公司。结果发现那边的流程还不如原先小公司规范，果断离开了。
现在在一家互联网公司，流程也不是很规范，之前想锻炼的能力目前也还是没有机会锻炼，只能说先做着把。
外面的世界很精彩，外面的世界也很无奈，要做好心里准备，楼主加油

之前买过京东质量管控体系的那本，感觉这类的书需要至少三五年的经验和认知才能理解得了，目前我的状态只能消耗其中很少的一部分。
路漫漫啊。。

Jmeter 还没接触，虫师的两本倒是都接触过了。
selenium 那本还是蛮不错的，但是 web 接口那本用的 django 框架，目前公司不用这个，所以没进行下去。。。

我去参考参考哈。
逛了会当当，一个不小心从工具类转到了小说那边去了

是的。
不过换个角度想，以前要是不浪费一些时间，现在可能也没意识到学习很重要

真相了
就是不想走亲戚，所以要做一些学习计划，不然太太太无聊了

书的话背来背去有点重
不过我个人也是觉得看纸质书比看电子版好很多，京东看看吧

北京。。。开放直播吗

是否需要英文简历啊

工作地点在哪？

目前我们也是这样的模式：
1、产品和开发过需求的会议，是让开发评估需求的可行性，其中还包括实体和数据流转的细节。
2、可行性会议通过后，产品需要按会议结果修改然后发布需求。
3、在需求发布出来后，测试需要看需求&理解需求。这时候分为 2 种情况：
a、需求文档足够详细，测试可以直接按现有需求文档写用例；
b、需求文档存在细节的疏漏，测试需要汇总然后发布给产品/开会讨论，让产品完善需求。
产品修改的需求都需要邮件通知给开发。
c、需求存在设计疏漏（毕竟测试是最了解现有系统的人），这个时候产品、开发、测试都需要开会讨论了。
在会上定下来最新的需求。

（1）年龄：25
（2）测试从业时间：2 年
（3）目前的瓶颈：公司现状无法支撑自动化 + 自己私下弄力不从心
（4）职业规划：如上，对技术没那么热衷，在考虑要不要转行/换方向。具体未定
（5）所属公司类型：小型互联网
（6）对小编的批评：
对小编文中的比例来源很感兴趣，如果能说明一下来源可能会更好
（7）畅所欲言：
个人感觉，对于做产品的公司，产品终归是要人去测试的。未来即使 AI 运用于测试行业，功能测试还是免不了的。
当然，有极大可能性是产品团队做功能测试，测试团队根据算法、工具等测试代替人工的功能测试。

坏处就是，某段时间跟需求人员的关系很紧张，会议室里面经常会撕起来。。。

日常还有一个策略：
交付的需求存在大量不清晰的时候，测试评审的时候就会自己列出一个表格，统计所有不清晰的点。
然后发给需求人员，抄送给全项目组的人。
必要时，要进行会议讨论的。

这种模式下，需求评审占了很多时间

目前产品迭代到第三期了，没楼主问题那么久远，但是也有很多问题。
目前我采取的策略就是：从需求评审到测试结束，过程中就是不断不断不断不断给需求提 bug，不懂的全给他们提，提到他们不耐烦把需求补清楚为止

厉害了
三条回复的每一条都要再仔细消化消化

据说发布会他们自己试了一次都解锁失败了