可是楼上说这样是自我麻痹啊

不说语言，不说框架，这个肯定是后端的 bug，随随便便什么参数都可以传，传了还不报错

说那么多没用，直接重新打开缺陷就好了，不改可以，好好说，理由充分，邮件抄领导发过来，没问题。否则刚到底。

你给 spring 提 bug 吧,springMVC 就是这样

老铁,当心被前端勒脖子

你这个 BUG 应该提给后端，为什么接收 bcd 参数不报错？后端改了之后，那就是前端的 bug 了，不改也得改

纠正下 好非常客气 -> 要非常客气, 考虑面试 -> 考虑面子

遇到这种问题,楼主可以提 bug 平台但是要备注是待优化的点并不是 bug 并且好非常客气的和前端沟通,你如果直接和前端说是 bug,前端或许考虑面试不会去怼你,但是心里肯定会鄙视你骂你是个煞笔.

楼主这类只是一个需求变动，开发不肯改可以拉上产品、开发、测试三方协调。

咱们平时提 bug 平台上有的问题根本就是完善的点,不算是 bug,提平台只是为了标识下防止忘记,你说这是 bug 是不太合适的

它只能说是一个待完善的点罢了,你直接给人家前端提 bug,前端会怎么想?你考虑过吗?

我觉得这是个 bug，但没必要立刻就改，因为优先级不太高，不影响使用及啥安全性。如果开发真忙，可以先不去改的。但是从代码逻辑严谨上来说，后面闲下来了，肯定要把这个改掉啊。

开发是不是傻子我不知道，我认为这就是个 Bug，你可以不修，我就是要提。

@ 胖虎 这算 bug?来你说说影响用户什么了?暴露什么信息了?要你这么说之前 4 个参数的时候接口就是不安全的了?隐私信息肯定是会加密传输的,你当开发是傻子吗?要你这么说,所有接口都一个字段然后拼接起来再加密,多安全!

你们公司的前端可能之前传过类似的接口,所以上述思想已经形成了.另外这个又不响应用户使用,为啥非要提 bug?楼主让我想起了某宁的测试,详情请点击

这不算 bug 吧?在有的公司里可能一个接口完成多个功能,根据前端传的参数不同来进行区别,前端会有冗余的字段,只要后端不接受就不算 bug.

除非是涉及到流量或者安全的问题，否则冗余三个字段问题也不大。

我觉得测试的核心技能不是自动化，也不是点点点。而是要知道为什么要去点这个按钮，为什么不用去点那个下拉框。

知道为什么点这个按钮的背后可能需要你做很多功课，比如对业务的深耕，或者是对行业、竞品的了解，又或者是对产品架构、设计的熟悉，研发随便改了什么地方，你掐指一算就知道该去点哪儿。

所以懂编程能自动化也只是你的工具。测试的定位我觉得是比产品更懂技术，比研发更懂产品。说白了测试又不是一个盈利的角色，而是更加偏向提升效能和节约成本的角色。

是的，但是我也感觉，python 一般是测试用来写脚本的，包括自动化，压力测试啥的。好像也不需要太清楚源码啥的。基本知道会用差不多了。不比 java，java 学的深是很有必要的，

好像回复不能修改 touch-tough

楼主几个问题：
公司的规模，技术部规模，测试组规模，专职测试技术方向的几个人？

我的背景，民企，外企，创业，现在在 bat，关于自动化的几个思考：
1、项目属性基本决定测试玩法，纯业务还是中后台产品
2、团队规模或者说用户数决定了测试的深度
3、是否有支撑整个产品研发流程的 CI/CD 体系，如果有的话，自动化是非有不可，不仅仅是自动化测试而是全流程自动化
4、回到个人做自动化的目的？证明自己的 coding 能力，还是想帮助到项目，不管是发现 bug 还是提升效率
5、如果我是你的话，我会怎么做？

• 不求大而全的自动化，针对效率低的点让机器去完成，比如生成测试数据
• 如果在业务团队，全力发现业务的 bug，深究 bug 出现的原因定位到具体的出错点，然后再告诉开发你这样写错了，应该怎么写，说的时候委婉点，没有必要每个 bug 都看
• 建立自己的技术品牌，请开发配合你，一起来完善质量体系
• 这是个 touch 的过程，意味着你要了解技术架构，技术实现细节，调优策略
• 不抱怨，有阳谋，加油！

祝你以后能遇到能遇到更好的 leader 吧。我打算留下来死磕了。

哪家公司也有这样的人！

楼主怀孕了所以干到明年回家了，工作没有心情重要

所以不跳了回家