强烈同意，面对甲方真的很痛苦，因为好的产品经理，在甲方提出原始需求的阶段就要学会拒绝和引导，如果同时做产品和测试，结果可能就是接了一堆垃圾需求，然后测试时间还不够。

缺点是，没有什么特别突出的优点，自认是个普通人。 感觉这个回答是比较万金油的

我们以前也用量化，后来觉得会造成对立就不用了。由于公司会定期评 CMMI5 资质，所以在使用敏捷开发的模式下，有公式会去计算成果，要结合 sprint 内的故事点、用例数来看，想了解的可以自己去查相关资料。
不过实际工作中，我们最终还是把加班时长占绩效的 40% 来评，剩余的 60% 则是产品业绩 + 团队领导对你能力的主观意见。

我个人工作感受，自动化没有覆盖全部场景（包括深度，脚本健壮性的完善）的情况下，它最大的意义就是给领导做汇报用的。
能通过自动化发现的 bug，基本上不会是什么复杂的问题；复杂的问题，基本上都是靠人工测试的逻辑去发现的。
自动化的场景对象，最好是那种重要程度不高的，但又属于主流程业务的，这样即使出现问题，其实后果不会很严重。

我是 4 楼，补充一下吧，如果不知道变量名实际输出叫什么，要用到调试取样器 Debug Sampler，如图所示添加

注意这个取样器要放到请求的后面，请求执行后，它会读取到前面所有请求中输出的各类变量值。

例：下图中，我在 JDBC request 中定义的输出变量其实叫 rantenantid，但实际产生的叫 rantenantid_1，那么后续引用时就需要用 ${rantenantid_1}来引入这个值：

直接在 JDBC requst 中获取需要的字段，你要求是随机取的话，可以直接用 order by rand() limit 2，比如：
select 字段 1,字段 2,字段 3 from 表 A where 条件 order by rand() limit 2;
然后在 JDBC requst 里把字段 1、2、3 分别提取成变量，后续的接口引用它们就行。

1、①如果有规范的接口文档，可以尝试测试接口，一定程度上能够去理解开发的设计思路，这样避免纯粹的黑盒测试。
②自我提升：了解各类测试的常用工具（接口、安全、性能），顺便就可以学习一些简单的代码编写，以后深入使用工具基本都需要一定的代码能力。
③测试规范制定：现在虽然只有你一个人，但是可以考虑以后团队会不会招新测试，规范制定挺重要的，测试用例（日常、回归、个性化）怎么维护，BUG 怎么提，测试报告怎么写等等。
2、适合
3、不知道你们是用瀑布式还是敏捷式的，比如我司是走敏捷冲刺的，我们会提供冲刺测试报告，内容比较简单直观，就是统计一下 bug，分析根因，这些是需要跟团队成员一起开会过的内容（敏捷阶段的最后会有个冲刺回顾会议）。