简单的想法

这个问题太难了，感觉出题的人也不会知道这个水深水浅.
下面是自己的一些想法.

1. 单个 Server Cache 场景 - 最基本 cache 的功能

• cache 的读取
• cache 如果不在内容里面从数据库取，然后再放入 cache
• cache 过期，过期策略验证
• cache 的不同类型验证
• cache 超过内容容量 cache 策略

2. 分布式看 - 太难了，感觉问问题的人也不一定很懂

首先不知道这个地方的实现，总体可能有两种情况：

1. 都是直接访问 server 的 cache，remote cache 做同步分发，协调用
2. 先过 remote cache，server 的 cache 做类似二级缓存

但是不管怎么样如果是数据一致性，高可用的话有些事情一样都很难实现和验证,比如：

1. 数据一致性，这个缓存数据的要和实际最新数据一致，而且一个 server 端的 cache 更新了需要广播更新所有的 cache,还要保证时序性保证，先到 remote cache 的不代表他真的是先发生，网络，处理能力都可能有问题的，系统最后更新的表示最新的值，这个难呀
2. 可用性，如果一个 server 重启了，那么如果复制 cache 到这个 server，性能问题 如果 remote cache 挂了，怎么让 remote cache 的数据恢复正确，和实际情况一样
3. 如果不同 server 的时间都不一致，怎么保证数据一致性
4. 如果对 key 加锁的化，性能如何？如果没有 key 的话，怎么加锁？ 没有 key 是完全可能的，就是不在缓存里面，但是是去拿同一个东西，没法控制了？
5. 如果 server cache 的内存大小都不一致，怎么保证 cache 内容是一样的？

最后说这种功能,测试还是不要碰了，谁想的方案谁验证吧

问题是给多少钱？这个要求可不是不高，而是相当高

貌似 winzard.pinan.com.cn 这个链接报错了：@jacksonchina

antd pro 的味道

主要没找到 python 长期维护的 jsonpath 的包

赞一个，全能呀

坦白讲我觉得还是 else 里面要处理什么响应的验证也是在 doothertask 这个方法里面做 本质应该我觉得是 doothertask 这个业务校验不严格 以后如果其他地方调用可能会出现一样的问题

那也是 doothertask 的问题吧 和 if 没什么关系吧

直接在本机运行的,没有打包。maven 的项目的话，直接 mvn test 就可以了,或者在打包的时候不忽律 test，就会在打包时运行.

确实非常没意思，不知道为什么 35 岁的年龄限制，谁没年轻过，谁不会老;一直觉得应该有个中年人相关的互联网公司，互联网只关注 90 后，00 后要么就是老年人，但是 35 岁以上的其实也就是 80 后，70 后为什么就没有人关注这些群体？做这种互联网公司的应该更多需要 35 岁以后的， 突然发了点奇想。

不太清楚问得是什么问题 jmeter 录制的时候 js csshtml 都是单独的 http 请求 可以区分出来的

首先要有深度 没有深度连机会都没有 个人想法

首先我觉得是接口测试是有意义的，可以覆盖 App 前端可能不能覆盖的内容，几点理由：

1. 有代码的地方就有可能出错，APP 前端验证之后，接口部分的代码实际上可能并没有全部验证到， 原因为，App 前端的代码已经对接口的请求参数做了一部分验证，所以有些接口的用例可能没有办法覆盖 如果从覆盖率的角度看，就是纯粹通过 App 前端，有些代码永远的走不到 (不是只是异常处理的逻辑)
2. 接口并不只有 App 端访问，直接调用，或者其他客户端调用都有可能，甚至说可能被拦截后 直接修改参数再访问也有可能，从这点来说接口测试需要更加严格的校验，所以测试用例需要更多， 或者说需要去仿造通过 App 端无法测试的情况。 举个例子来说，如果用于用户名必须要要少于 5 个字符，这个限制只有在 App 端做了，没有在接口层做， 那么 App 端测试时候超过 5 个字符的用户名是不能注册，但是如果通过接口注册了超过 5 个字符的用户， 这个时候我想 App 端登录超过 5 个字符的用户名说不定永远不能成功了，这个其实就是接口测试的一些意义

确实 App 的前端校验和接口测试从业务的角度，用例确实有部分重合，不过从测试的意义来说，App 端的测试
有一部分的意义实际上验证和后端的交互是不是符合产品定义，这部分代码不是接口，
而是如何前端校验，如何交互，如何转换数据；举个极端点例子来说，如果登录的时候，App 同时发了两个请求，一个给了登录接口，
一个给了开发小哥自己的网站 (纯粹举例子)，从功能的角度看，整个登录流程是没有问题的，但是它是一个 bug，
而且很严重，而这些是接口测试无法覆盖的；

楼主其实问的是个好问题，其中确实有重复的部分，而且很多团队确实就是用 App 测试代替了接口测试，
在人员短缺，这个也是一个办法，合起来一起测试也不是一个完全没有道理，质疑重复测试也有道理，
把两者合起来看，看两者的差异点，相同的是什么，不同的是什么，可能就会更高效率了.

我有点啰嗦 .......

外企的测试工资比开发高多了？ 这个我觉得有点说的过头了，不觉得是个整体现象，个别可能有，但是如果整体不太现实。

初步估计需要在 pom.xml 文件里面加入 maven compile 插件，jdk 版本设置到 1.8

<build>

   <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>3.7.0</version>
       <configuration>
         <source>1.8</source>
         <target>1.8</target>
       </configuration>
     </plugin>
   </plugins>

 </build>

厉害厉害，想问一下楼主做这个大概花了多少人力呀？

单实例 jmeter 不能造成大于服务器处理能力的压力，这就是他的局限性， 这句貌似不太准确吧。 我觉得方法可以是：

• 可以不限制固定 QPS
• 增加线程数，甚至可以设定集合时间点，假设服务器极限 TPS 到 100，你 JMETER 线程数 200 个，同时设置集合点 200 个线程同时发

这样同时发，不就是超过你服务器极限 TPS 了吗，但是服务器 TPS 就这么多呀，TPS 就是这么多了，但是客户端的响应时间肯定很难看。 服务器不一定会挂（说明服务器的保护不错呀），有很多等待的队列，客户端反应就是超时越来越多，错误比例越来越高。

同样如果有监控系统看的，可以从服务端的角度看系统处理时间，在这种情况下，客户端响应时间和服务端的监控的响应时间数据我觉得会有不一样

其实 python3 自带虚拟环境的，python -m venv 就可以创建虚拟环境了，其他操作和 virtualenv 一样用，virtualenv 和性能测试关系也不大。

from collections import Counter

source = [1, 3, 8, 9, 15, 12, 15, 3, 3, 9]


# 不使用 python 标准库
def get_2dup(candidates):
    if candidates is None:
        return []
    if len(candidates) <= 1:
        return []
    count_result = {}
    for candidate in candidates:
        count_result[candidate] = count_result.get(candidate, 0) + 1
    return [k for k, v in count_result.items() if v == 2]


# 使用Counter
def get_2dup_counter(candidates):
    if candidates is None:
        return []
    if len(candidates) <= 1:
        return []
    count_result = Counter(candidates)
    return [k for k, v in count_result.items() if v == 2]


if __name__ == '__main__':
    print(get_2dup(source))
    print(get_2dup([1]))
    print(get_2dup([]))
    print(get_2dup(None))
    print(get_2dup_counter(source))
    print(get_2dup_counter(None))
    print(get_2dup_counter([]))
    print(get_2dup_counter([9]))

全职估计没人要

首先明确的是线程是压力生成器，实际上是客户端，TPS 是指服务器每秒处理能力。
分情况来看：

1. 如果压力生成是 2000 个线程，那么客户端每秒产生的请求应该会超过 2000 个，而服务器 TPS 只有 300，那么多出来的请求只能等待，这个时候客户端请求越积越多，从客户端的角度看响应时间就越来越长，因为排队等待处理的时间也计算在响应时间内；这个情况可能说明不了什么问题，可能系统就是这个设计的，可能就是个限流的设计，等待请求如果超过一定时间直接多超时返回，甚至说到了一定响应时间，如果这个响应时间大于客户端请求的超时时间，响应时间可能就不增加了
2. 如果并发线程数和 TPS300 比较接近甚至更少时，那么响应时间的增加应该不会很陡峭，如果增加很厉害或者波动很大时，那么需要仔细查看其他的指标了，比如 SQL，内存使用的情况，GC 频率是不是很高，是不是有报异常等等了

感觉没有什么好办法，最好让开发设置一个可以直接登陆的方式，要不然是自己给自己找麻烦。

如果一个公司本来就没有什么流程，你问人家流程是怎么样的？为什么流程是这样的，你让人家怎么回答你？如果回答没有流程，就显得公司 low，如果回答有流程，那就说谎了。在假设，如果回答没有流程，说不定楼主会问，那你问什么不会去推动呀云云，可是推动一个流程没那么容易吧，然后如果胡乱说了一下，或者网上的流程出一下，后者牛逼公司的流程说一下，似乎也可以有个交代，但是我想说的是，这和没说或者说不出有多大的区别；关于选型为什么 JAVA，或者 python，总体上生态圈的问题，他要是说基本没有区别（语法当然有区别，当也不至于要人分析语法吧）你要如何回答他呢？

我倒是想听听楼主如果对于自己提出的两个问题，你自己的答案是什么呢？

心态是双方的，谁都会老，不是吗？谁没有年轻过，太阳底下没有新鲜事，或许讨论一个人是否适合岗位的要求更合适，所谓讨论岗位就是讨论性格，能力和要求的薪资是否和岗位匹配。

关于匠人例子的一说，我很有怀疑，或许那个工厂一直都是用一种发动机，或许他们很多东西从来都没有变过；但是很明显互联网，或者 IT 这个行业不是这样的；

可以参考这个：https://testerhome.com/topics/3483
PageFactory 的 initElements 是生成的是 WebElement Proxy 的实例，这个你可以调试的时候看看，只有在真正去进行元素操作的时候，locationElementHandler 里面的 invoke 方法会先调用 findElement() 方法后，再执行你的如 click. 也就是 PageFactory 生成的元素实际是通过 locationElementHandler 里面的 invoke 方法去调用的，这也是 proxy 的原理.

@justcby SOAPUI 我也用过一段时间，他还是不错的。我也用过他做自动化的接口测试，我一个人负责功能和自动化，基本上也有 300+ 多个 case 的，20-30 多个接口，每个迭代两周，测试环境，集成环境都要测一遍，回归，新功能都要覆盖，基本上一个人也能搞定了，所以说效果还是不错的。我说说他的好处：

• SOAPUI 如果用来做自动化测试的话，基本功能基本都可以完成，包括文件上传，上下文参数传递，环境配置，数据库验证，json 返回结果认证等等，甚至可以去出数据库的值来作为参数，而这些甚至不需要编程，不过你需要学习 SOAPUI 自己的一系列表达式的规则
• SOAPUI 可以和 MAVEN 这些结合，但是我没有去研究如何做

不好的地方：

• SOAPUI 的表达式学习你是要花点时间的
• 复杂的数据初始化和验证的时候有点力不从心了

以上只是我个人的体会，其实用 SOAPUI 还是比较方便的,不过你至少要把他的官方文档中和你需要测试的东西的说明看一遍.

我自己觉得我为什么自己写代码的目的 (个人想法，如果有不同意见请跳过我说的) 是：

• 做自动化测试目标不是让人不写代码，而是写代码，了解代码，去更深入的理解一些基础性的，原理性的东西
• 自己工具更灵活一点，可以更方便的实现一些自己想要的东西，同时又比 SOAPUI 更轻量,SOAPUI 可以测一堆东西，不过我只要测 RESTFUL 类型的 API