如果你是被面试者，你会如何回答这个问题呢

第一个是题目描述有歧义。。userName 和 userID 是不是两个字段，一会儿 userName 一会儿 userID 的，不了解的以为你打错了。。
就当你没打错，我理解的题目意思是发送一个 userName 返回一个 userID,而且这个 userID 不重复，那就说明 userName 可以重复喽，
首先空值可不可以传，最多传多少字符，支持汉字么，支持符号么，支持空格么，用同一个 usaerName 多线程循环请求看会不会出现并发问题。
让我设计这个 userID，sql 主键自增也行，时间戳加别的信息也行，UUID 不太清楚怎么生成的哈就不讲了。
自动化的化上面提到的分开写 case 就可以了。。
大概我是这么想的

userId 是唯一主键，userName 是唯一的外键。
你想说从数据库里搜一个存在的，再搜一个不存在的？
测试环境是可以这么玩。
注册入参是带 userName 的，如果返回有 userId，你们开发就是菜鸡，没有一丁点的安全意识。

1. 既然注册请求的 userName 不允许重复，那么重复值是肯定要测的，看后台怎么给返回值了；其他的测试就按照正常的测试流程了:长度 (0、规格长度、超长)、特殊字符、中文
2. 返回值的 userId，这个其实不太好预测，可能要看一下后台生成规则，可能是随机的，也可能是数据库自增产生的，根据生成规则判断一下 userId 返回数据的数据格式 (或者如果是自增产生的，是否可以查询一下当前的最大值，那么可以期待一下下一个值，当然这个不考虑并发的情况下)；目前我们这边不验证这个 userId，最多验证一下格式 (比如是否是八位？主要测试下是否符合后台生成规则)，或者有时候根本就判断一下这个 userId 是不是空就可以结束叻 (这是基于后台代码写的不错的情况下)，但是这个字段最好不要在响应中体现吧？
3. 并发注册测试一下，看这个 userId 会不会重复，代码能不能有效处理多线程

其他的，想不到了，嗯。。。，虽然也没有明白楼主主要想测试哪方面的能力。。

如果数据库层面都限定死了 测这个没有什么意义。只要做一个异常校验就行了

两个点，纯粹从楼主的要求考虑，
1.采用 hashset 方式生成制定数量的用户名，用户名不重复了
2.返回结果的 userId，根据服务端的 userid 生成规则。写对应的正则，但考虑到生成的 useid 重复，可以采用 list user 形式，查询条件 userName，判断 list 长度是否为 1，确保唯一性

从开发角度考虑，我直接看开发代码就好了，用例根本都不用设计，开发不会按规则改，我帮他改

1、首先需要确认一下你是否描述清楚了你的问题？
2、可以将问题以书面形式展示给面试者。
3、面试是双向的，那个 95% 的比例是不准确的，难道 30 个人仅两个回答与 jmeter 无关？不排除有培训机构推荐过来的菜鸟

我猜测楼主想要的是：

1. 先设计用例，不要一上来就讲工具。用例设计的时候除了常规正常异常，还需要关注下 userName 重复时 userId 不重复，以及 userId 返回值是否与数据库一致，高并发下是否会出现 userId 重复或由于线程间锁竞争引起的性能的问题。
2. 设计好用例后，再说用工具如何实现。

我也没看懂，一会儿 userName，一会儿 userId 的，什么鬼

题目都没说清楚~
还怎么面试别人？

楼上几位大佬已经把 case 各种情况考虑了，个人认为既然是注册的功能，返回的除了 userId，应该还需要一个字段 isHas，来表示这个 userName 是否被注册

题目描述很混乱，没有重点，能问出这种问题的，我只能说你一点都不懂接口自动化。

题目大约是这样：
现在有一个接口，接口的功能是注册一个用户。
接口请求参数就会有一个 userName，这个 userName 的要求是不能重复，请问怎么设计这个 userName。
接口的返回值中有数据为该用户注册后的 userId，请问怎么设置这个 userId 的期待值。

不重复就调整数据库字段长度，串上 UUID 即可
返回的 userId 想必是自增主键，除了 > 0，我真想不到有啥能够校验的办法，因为多线程在跑，线程数也在持续调整，不大可能去拿现有的 current + db_increment_offset * thread_count，我的答案就是 > 0~
工作 12 年了，求鄙视~

哥，给个接口文档呗

很好奇楼主的答案

好奇楼主的答案，除了 13 楼的大哥答案，我想不出别的

估计楼主隐藏了一些条件：
1、是不是分库分表？
2、userId 是不是可以预测？
3、有木有 sql 注入？
4、特殊字符是否支持？
5、字段是否截断（字段超长）？
6、unicode 是否支持？

工作 10 年，被鄙视了。不擅长接口测试。

说实话我没看懂题目，没有任何接口说明让别人测试都是耍流氓，至少参数限制数据类型得给吧

肯定是你的问题，工作中见过很多情商低的 it 人员

我觉得这个是数据层面的问题吧，需要看下 userID 是怎么生成的，如果是随机码，那去验重的必要性就比较小，如果是通过一些列算法计算得出，那还要考虑数据库是怎么设置的，如果 ID 是通过 name 固定算法生成，也就是说，我们在数据层面只需要验证 name 的重复性就好了吧。
不知道我这样理解对不对，说实话，有点没搞懂这个问题的关注点是哪里，可能是我没理解到位。

分库分表有点意思。不介意多交互一次的话，可以利用自增主键做一个唯一 userid 的生成器。或者每个分表有一个 offset，然后基于这个 offset 自增，当然这个数量上就有局限了。

麻烦先说清楚题目吧

请先学会如何把问题说清楚吧。

22 楼的不要局限与黑盒，可以向开发咨询分库分表的逻辑是怎样做的，然后根据开发代码设计用例。

题目描述的不清楚，我的理解跟 2 楼是一样的，调用注册接口时：
request 里有一个字段是 userName,传递的值是注册时，用户填写的用户名；
response 里有一个字段是 userId,用于标记用户的唯一性；
按现有需求，需要确保此接口注册的用户 userId 唯一，那么请问，如何设计此接口的测试用例？

不好意思，打字快了一点，打错了。
第二行的中的 userId 应该是 userName。

我心目中的答案是，userName 可以用函数去生成一个不会重复的用户名，
对于返回 userId，也可以做一个函数根据 userName 去数据库查询到 userId。

主要是看看面试者是否熟悉接口测试工具中函数的使用，和一些在 response 中一些变化的返回值去如何处理的。
这些场合其实在接口测试的时候还是挺常见的。
看到大家的反应，也许我要去思考一下如何出这种题目了。

楼主错过了（刷掉了）很多可以做自己师傅的人

另外 userName 生成函数我个人习惯用： autotest+ 时间戳 去生成， 我觉得这个相对来说不会最不会重复。
如果说要考虑到 username 的长度的话，可能会做点长度的处理。

了解一下前置条件和后置条件，为什么要去生成一个随机 username 呢？username 肯定是预期设定好的，各种组合，最后把这些组合删掉，下次继续用。工作七年，求鄙视。

生成用户名称/昵称的需求还是可以接触到的，例如使用手机号码、qq 账号注册微信账号时微信账号是自动生成的，允许修改一次。

好想说楼主，现在开价 15 算啥呢？我面试过的，就只会功能测试的，linux log 都不会看的，开价 20+，测试人员参差不齐，啥都有，那些人都是趁着年轻捞一把不干的。

你说的不错，去删除数据库的数据也是一种方法，不过这种方法有一定风险，要很了解新增用户的在数据中真实添加数据的位置，万一，删除数据不干净，会留下脏数据。
其实没有什么鄙视不鄙视的，真的要说测试这个用户名的方法是在太多了。
我的设计思路就是能不去数据库里做增加和删除的操作就不要去做，这样比较容易留下脏数据，情愿多创建点新数据，不到万不得已不去碰数据库，当然查询没有问题的。
比如前置条件中，可以先去查询设计的用户名是否在数据库中存在，如果存在就去删除，然后去执行接口测试。
但是这个也是涉及到一些脚本的问题，八仙过海，到了对岸就行。主要是看是否有设计思路，工具的使用现在大家都没有问题，真的做过接口测试，或者稍微深入点，就需要有自己的思考和解决问题的思路。这才是重要的。

我只是说删除数据，没有说直接去删除数据库。便捷的方法是用 sql 去删，也可以要求去用 api 的方式去删除，当然最终也是去操作数据库。其实有更好的方法，比如是做 docker 的数据镜像，但条件没有满足之前肯定需要有落地的方法，先落地再寻求更好的做法。

手动删数据库是一件非常不靠谱的事情，因为注册数据可能落在多个服务器的多个表里。
测试直接操作数据库，脏数据你是坑自己呢，还是坑开发呢。如果测试这么玩，测试的测试环境数据库操作权限会被收回。
很多接口异常是需要数据回滚的。
接口的回滚异常能有多少人考虑到并测试的？我个人持怀疑态度。。。

用 userName 去注册后返回 1 个不能重复的 userId 吗？
返回的 userid
前面加自选的业务标记位字符（标记是什么业务的）中间是后面序号时间戳后四位 +1。跨天在重置序号。

自己连个题目都说不出清楚

没看明白你题目的意思，你如果是想要不重复 uid 的话，要么就将当前时间加一个字符呗

楼上小伙伴们说的都在点上。
可题主，这哪里是在考 “如何做接口自动化测试”，分明成了 “如何实现批量用户注册” 😂

同 3 楼:
根据 username 就能期待出 userid?
开发设计注册的猿类可以去财务那结账了.

莫不是 username+ 时间戳或者 md5 什么的吧,
这种几十年前的敷衍设计,多骗几行代码?

注册这块的测试,4 楼讲的很清楚.

28 楼,真相```

楼主回：根据 username 去查询 userid，只不过是为了解面试的人是否能对动态返回的值进行设计处理。希望面试的人有自己的思路去解决类似这种问题。好像一个查询天气的结果，返回值中有今天是星期几，如果不会动态的去设计这个期待值的，怎么能做成自动化。
何必在业务逻辑上这样纠结？

楼主回：自动化的脚本就是需要可以不断的反复执行，虽然每执行一次脚本会多一个注册的用户。但这个概念绝对不是你说如何实现批量用户注册。

我是 3 楼，返回值是开发逻辑，不是测试逻辑。
可以通过设计不同的入参，返回不同的出参。
但这个是有逻辑的，不是随机的。。。
你举得例子都没有逻辑，为什么查询天气要返回星期几？难道不是查询的时候入参带日期、时间，返回为毛要有星期？
我觉得楼主需要多想想，接口为什么这样设计，冗余参数的危害性。。。

楼主回：
因为这个本来就是一个面试时候的一个问题而已，没有必要带那么多逻辑上去。
至于为什么查询天气要返回星期几，可以参考这个接口（这个接口是我做测试用的）
https://www.sojson.com/open/api/weather/json.shtml?city=%E4%B8%8A%E6%B5%B7
如果工作中有这样的接口，的确和你说的一样要去思考这类问题。但是这是这个面试题，希望得到的只是设计思路。

楼主回：
如果我们两现在在面试，你提出这类问题，作为面试官的我肯定会给你加分的，至少你思考了这个问题，也说明在工作中或多或少的经历过。有的面试者，应为没有经历过这种问题，随便写了接口自动化测试，或者说做的太浅，很多问题没有自己思考过，那就不能给出解决方案，跟不要说和面试官 题问题了。

3 楼，既然楼主这么客气，我说点我觉得可能是实话的话，可能不太容易让人接受，楼主可以慢慢思考，不接受也没问题。~
我个人是开发，为了避免有人针对我，我就不实名了。。。
我以前做通讯测试的时候接口也就做做全流程测试，很多细节也不清楚。
我想说的是逻辑思维是程序的基础，逻辑思维强的，沟通做事的成本都会很低，至于经验，接口测试门槛也不高。
如果你有机会面更大的公司，你会发现考察的基础能力和实际经历，实际经历最好明确化，逻辑细节都非常重要。你问问题的方式，我个人觉得有待提高。你这么问问题，你自己以后面试可能也会有问题。
不要鄙视经验稍微欠缺的人，有些人有可能只是缺个环境。只要努力基础好，做自动化测试绝对不会有问题，当然你要做好人家学会了跑路的思想准备~
很多做测试的同事，包括我自己都有个很不好的习惯，第一时刻总觉得自己是对的，不对的话，我怎么和开发撕啊，怎么区分责任，久而久之，就算自己觉得不对，也会潜意识第一时间圆自己是对的，没问题的。我最近也在思考这个问题，拿出来跟楼主分享一下。

看了半天都搞不清楚楼主想表达的是些什么，而且你还我最怕的那类同事类型，就是说话没什么逻辑的那种（对于这句话，其实我想匿名，但是初来乍到，一时没有找到匿名回复的开关在哪。。。BUG）。。。

这种感觉通常发生在开发需求串讲的时候，一两句话带过。。。实际工作中，我会从系统整体涉及（分布式还是单点等等）、数据库结构设计（向上面说的，分表、字段结构、是否冗余等等）、参数校验、结果检验、操作权限、各种上限限制等等方面去理清规格。。。规格不讲清楚，就让其他人去测试，完全是耍流氓

当然，面试官就是真理。。。

楼主回：其实我在回答中也说一个在我心目中一个我觉得现在对于我比较满意的解决方案。我一直觉得最有效的方案和最能在实际工作中解决问题的方案才是最好的。这少在这个帖子中，有几位还是愿意给出解决方案的，也的确是切实可行的。比如，在面试的时候也有人给出先去数据库查询是否存在某个 username，然后去删除，在跑脚本，这也也是种可以解决问题的办法，对于这位在这个题目上我觉得他有自己的设计，是很不错的。
的确是我把题目写的简单了，以后我考虑面试的时候尽量把细节和逻辑写的太清楚点，在面试的时候，我还会引导一下，这里就不说了。
至于你提到别人学到手了会跑这个观点，我本人就支持学到了就跑这种观点，如果你的能力提高了，公司不能给到你相对于的薪资，那就换家公司。现在的公司又不是以前的大锅饭，一吃一辈子的事情。员工和公司都是互相选择的，缘分尽了就散了呗。我比较喜欢有上进心的，尤其是那种在完成工作任务的时候，会主动来进行学习的。
另外说一句，我们来 testerhome，不就是大家来分享自己的经验，让别人少走弯路。

存储 user 的表中，利用代码执行 LAST_INSERT_ID() 函数，获取最新的 userId。然后和接口返回值比较，您看这样回答合适嘛

楼主回：只要答案中有提到用函数和在数据库中查找，其实就可以了。至于函数怎么写，那都是可以优化的或者根据实际情况写法也会不同。有了思路一切都容易解决。
至少你的答案和我的想法差不多一致 。

大致看了下没很明白，一般自动化接口测试，不都是要考虑数据初始化，然后查表比较返回么（比较这边加上特有的业务逻辑），然后再来个数据清理么。。。；楼主是要考察这点么？纯探讨，说错见谅

首先这种问题我是不是集成到自动化项目里的，没人会经常改 userid 的生成规则的吧，然后就是接口测试了，把需求，开发的相关代码搞来，具体问题具体分析，设计测试方案，然后写脚本测试就行了。

好复杂 name 自定义？返回 userid?
redis 自增加规则就好了。然后先把信息放到 redis 异步同步数据库 15k 并发 眼睛都不眨 并发再多就奇读偶写交替 优化序列化方式 速度起飞

我连谁在提问都没搞明白，"anonymous" 这个人怎么说了这么多

其实最讨厌这种自以为是的笔试题，有些题目写的可能连作者自己都不知道答案，也不知道想要测试应聘者哪方面的能力，反正就是搞一个虎头蛇尾的题目摆在那。...

说白了，我还没看懂这个问题

我还没看懂楼主问的问题，相信面试者多少跟我一样吧