用例越好
手工越纯净
态度越认真
可以排查掉绝大部分的问题，这是实践过的

现在岗位属于人头外包，在甲方，都不知哪些人是自己外包公司的，跟之前项目外包（自己公司坐在一起）的办公氛围很不同。。

很正常，特别这两年对安全要求越来越严格

纯净的手工，多适合研究技术。
全是逻辑类，没有技术视角是写不出来的。
不妨去去研究业务实现的技术，将业务逻辑和实现逻辑对比写用例？

uat 测试就是业务验收测试，肯定是最大程度模拟用户真实使用场景，用户是不会去抓包看数据库的

我们很早就要求测试用例按照业务逻辑进行编写了，一是 UI 输入输出类的写的太多浪费时间也发现不了很多问题。二是发现的问题在业务流程相关的点呈线性聚合，分析问题发现大部分是业务逻辑在测试用例体现上不足，业务流程覆盖度不全。核心还是测试人员对测试的系统、专业的业务不够了解。三是现在的 UI 自动化结合 AI 技术，基本可以做到非业务流程的全覆盖，不需要去人工走查，这个也是后面想做的实现非业务流程 UI 自动化。

对，他们把用例挖得很深，需求没写的，他们全挖出来了。。所以刚入职，看他们的测试用例好累，很多需求没写，很多看不懂

很多场景需求文档没有，这个是需求文档在软件研发全生命周期内维护不过关，在外包项目这个是通病，找负责人沟通太难，经常因为层层沟通造成项目进度停滞或者重复工作。作为合格的乙方外包方，只能从自身进行改进，恰恰从业务流程出发进行面向经验的测试设计和测试执行能规避很多问题。

这是好事，不是坏事。

内部逻辑才是业务根本，基本的工具都是一用就会其实没所谓，思想掌握就好。

这种需求要是能分享出来学习下就好了

我也是 uat 测试，接口不用测，数据库也没有权限看，只是测试页面功能和逻辑，需要很细致，要看着 prd 文档一点点对，是否漏侧了，还要主导业务验收，有时候出的 uat 用例业务根本就不用，他们自己用他们流程验收，领导不是测试的是业务出身的正编，我是外包但是也要写绩效目标管理，每个季度都要过，学的都是业务的经验，已经干了 1 年多了

你不会抗拒手工测试吧？ 。。。。

没数据库权限，找数据造数据好难，好麻烦。。头疼。。。因为大家都是接项目的形式，所以有些需求不知道，估计也没权限看（因为连谁负责，对应的项目名估计也不知道）。。

B 端吧，注重功能点和场景

对以后发展可能一半一半吧～ 很难说 跳槽的话 真的能用到目前已有的业务逻辑

其实在大厂数据库权限一样很严格，测试也没有数据库权限（线上线下的都没有，想要往往得走好几层 leader 的审批，得跟一堆人解释）。

这时得提前和研发沟通好，要不让研发支持帮忙看数据库数据，要不换其他的验证方式检查数据

其实了解业务逻辑不等价于绑死在某个具体业务上。

了解的过程是业务和技术一起发展的，在理解具体业务场景后，往往对应的技术实现就水到渠成理解了，当看这种东西多了，脑海里就开始构建【什么类型的业务场景 => 什么样的技术构成】这种关系，我管这种叫 “经验”，越是高阶的人脑海里这种关系索引越丰富越具象。

而这些知识，都是可以在不同的业务间迁移的，如业务需要登录、支付、查询、写入等很多共性场景，就都能做知识迁移了。

很好

逻辑类的用例是怎样的，场景、流程类的用例？

对，纯业务逻辑。因为 uat，所以只看业务结果对不对。

是的，我要培养这种思维，以前就是一个月 2 个版本，需求做完就发版，没有去思考，有时甚至测完就忘记。现在测一个需求，他们前期准备用例，评审用例，需求变更就持续差不多 2 个月，准备测试用一个月。。感觉应该想记不住都好难。。。

挺羡慕的，有时间有规范去沉淀，这样不做好质量都难吧

想到面试官当时问了一个问题，我说 “业务部在群里提问题，马上解决。有时候大问题，才写报告分析原因。” 然后面试官说 “看来，你没经过什么困难。”（后面得知，需要给客户（甲方）汇报分析问题，那怕那天是非工作日），好可怕。。

业务跟钱挂钩时，就知道什么叫事教人了

用例写的详细没毛病，但不用自动化去覆盖是很大的问题。因为一方面测试的人可能不会执行得这么详细；另一方面人的精力是有限的，难免失误，有这时间去一条条反复执行不如全部用自动化覆盖

研发直接去给甲方解释吗，我有一个朋友有类似情况，不过人家是做芯片交付工程师的，大头兵的研发我也没见过需要这样的

然，这么严格的测试，薪资待遇如何呢？

看数据库，用抓包工具，也属于手工测试吧，不让我用数据库我得疯了，因为有些测试数据确实得需要改数据库，我举个例子，我们有些业务场景会生成任务执行时间，那如果不能改数据库，只能等到执行时间去执行，那就太难受了