确实，无论是开发还是测试还是交互，都是为了实现产品的要求而已，产品不行，那肯定产品也不行

但是问题那么多，怎么做到问题都能做比对呢，还是说只关注业务的重点场景就可以，比如日常生活的问题就已经无穷尽了

这个字正确率是拿预期结果去比对的吗

用记事本连数据库，这个记事本有这么强吗

同为安全类，年底才裁了一波 20%

这种新闻总结可能不需要测试介入，运营直接和法务评估了应该就能直接上了

行吧行吧

嗯

放下这些运气这类自己把握不了的客观因素，其实主要还是看人脉，人脉广人缘好，这种所谓的运气也更容易找到你

没有，至少懂一点吧

本来入职的时候是基本不会嵌入式，结果挪部门是嵌入式的，强行学 ，不过有同事带，但是主要还是靠自己

公司如果是中小公司的话，环境搭建、环境管理、环境维护基本也是测试干，要搭环境如果你们公司有自己的虚拟机那还比较好搞，如果只有实体机那你肯定也要会的，退一万步可能你也要搭实体的虚拟机设备

你们没有冒烟这种概念吗

确实少了百分之三十还问你开不开心，我都觉得有点缺心眼

太对了哥

挺好的，现在就是公司要求你往运营、售前、售后方向扩展

其实就是恒温老哥说的，要不产品知道和开发说了没和测试说，要不就是技术实现上开发知道测试、产品都不知道。

那些 tog 的需求不好多都是这样

肯定是需要持续维护的

我也想知道是怎么统计节省人力的，但是在平常项目中确实能够因为其实有大量的基准案例自动化了，所以手工测试的部分只有全新需求的案例和部分难以自动化或者自动化不了的案例，相对来说确实比之前轻松了不少，大版本发布（大版本要求全部案例执行一遍保证功能）时除了全新需求的测试用例，老需求的案例也因此能够快速验证（大概 5000 个自动化案例）

这个我在刚刚踏入测试行业的时候就见识到了，记得有一次需求测试，测试案例都已经写完了，测试方案那些都弄完了，执行案例的时候突然发现可能有个比较大的逻辑实现漏洞，然后立马去问开发是不是那个实现方式会不会有这样的漏洞，开发听到我和他说了之后，和我说的一句话就是你不和我说我怎么知道你不知道（需求是小需求，之前没有开发设计文档那些）

第七点这个感觉还是要评估，不过重点应该是开发评估改动影响面，测试根据影响面进行基本的功能测试和发散测试，这个 要结合实际去看

第九点好像挺多公司都这样

厉害确实