不考虑数据重复，用 yes 命令，创建 10G 文件 10 来秒，考虑数据复杂度，可以用 tpcds 来造数据

前置的需求分析与测试设计，后置的性能分析与性能调优都是不可或缺的关键。

认同，测试只是种手段，如何分析需求，分析架构链路，设计性能测试场景，将业务模型转为脚本模型才是比较重要的，不然做出来的结果也没意义，指标数据只是执行后的死数字罢了。

并发只是提高 TPS 或 QPS 的一种手段，实际操作中线程数=并发数，但是不等于处理并发能力

秒级 1000 并发需求可以有两种理解：

1. 场景可以支持 1000QPS 或 TPS，不论是高并发还是低并发，能达到就可以（达不到加资源），同时观察响应时间和错误率在合理范围内，给出达到预期的最小并发，另外如果资源冗余再看下资源能支撑的最高并发以及可达到的最高 TPS 或 QPS，评估是否符合预期（适用于流量高峰持续场景）
2. 当前资源下、1000 并发场景下的服务能力在合理范围（响应时间、错误率、资源指标），直接起 1000 并发，看资源情况（适用于秒杀活动那种场景）

这种都要结合实际的性能测试需求，看是哪一种再决定怎么做，不用纠结于字眼。以登陆接口为例的话，我理解更多的是 1000QPS 的概念，而不是 1000 个并发。

是的，测试用例评审就是拉齐产品与开发，开发与测试，测试与产品对项目需求的认知，防止出现返工扯皮

开发不想听的用例评审：点这个按钮，输入这个东西，......（🥱，好无聊）
开发想听的用例评审：这个场景下。。。这个逻辑下。。。（卧槽，这个逻辑好像没考虑到）

评审时注意引导讨论，简单 case 快速过，涉及到场景逻辑的要一条条认真对，不确认的 case 要提前标注与 RD、PM 讨论
测试经验比较少的经常写一堆前端 case，不考虑前端操作带来的后端逻辑，写了几百条看不到重点，异常逻辑分支重后端，前端操作几条就够了

我经历过的 case 评审都是在与开发对场景逻辑中度过，要么测试帮开发补充逻辑场景，要么开发帮测试补充逻辑场景，这样才是测试用例评审的意义，测试用例不是宣讲，是对齐。

测试可以做很多事情来提升自我价值，这些价值也可以被上下游认可，但问题是大部分的测试缺少这样创造价值的土壤
让做
你能做
做完落地
落地能推广
推广产生业务价值

很多做的事情死在其中的步骤中。开发从无到有可以依赖业务方、产品提供原型创造符合业务需要的软硬件产品，测试很难创造落地东西，因为没有明确的需求方。现在各种平台层出不穷，我觉得开发这些平台给自身带来的技术享受、技术提升应该是要大于平台本身对质量、效率、团队带来的价值成就的。

其实不用否认，不用证明，测试在研发测试流程中是必不可少的，但是测试人员是很容易被替代的，幸运的是我们很卷，开发卷，产品也卷，需要快速迭代，需要开发不停的写业务而不是写单测，这样给了测试生存空间，就像上面说的存在即是价值，不用怀疑自己价值，不用拔高自己价值，不要一昧追求技术广度，单一领域内的技术深耕、业务深耕可能对混口饭吃更有帮助

不能，你后面的如果反而是全链路压测更应该考虑的问题或者是关键问题。。。。压测形式、接口等等只不过是做压测必要参与条件，怎么做好反而需要考虑数据污染、流量来源、业务场景、流量比例等等这些东西

质量内建：内部没事找事
研发赋能：外部没事找事
敏捷驱动：快速做完业务然后没事找事

玩笑一下，无意排斥或怎样

质量内建：从 QA 角度出发，找到 QA 可以主导的测试质量提高的建设的事情，例如测试准入准出流程规范建设、代码提交环境部署的流水线建设，各种自动化测试提效等等。
研发赋能：从 QA 角度出发，找到可以对上下游产生影响的测试建设的事情，例如测试左移的一些事情，环境维护、单测、代码覆盖率检查，亦或者是质量内建中沉淀的测试工具、平台等放开给到研发，提高研发自测效率质量等等，或者是右移的一些事情，例如一些质量监控的东西反馈到研发、产品等等，提前暴露解决一些问题等等。
敏捷驱动：就是快速迭代，通过自动化的手段，当然不光是测试自动化包括提测上线等等，快速对齐，快速开发，快速回归测试，快速上线，线上即时反馈，再快速循环等等，但是实际真正能把敏捷用好的寥寥，这要求整个团队能在各个层面对齐，认知、技术、能力等等。

多学习多干活对个人成长提高是好事情，技术虽好，莫要贪杯内卷哦

web: console 报错给前端，接口报错给后端，都没报错给前后端
app: 接口 200 给前端，非 200 给后端
【手动狗头】

节点 1 后再增加并发，qps 仍然增加，说明节点 1 的瓶颈不是服务端瓶颈，可能是并发太少或者发压机瓶颈导致 qps 上不去
节点 2 后再增加并发，qps 不增加或者反而降低说明有可能是服务端瓶颈，还要结合响应时间、资源情况、服务 log 去排查原因

qps 上不去的原因是多种多样的，要结合压测服务的链路配置等去调整，并没有特定的规律，压测过程中流量 qps 只是其中一个指标，要结合服务器资源、数据库资源、网关等链路的每个点去看对应的指标情况，这样你才能分析出 qps 为什么会出现这样的曲线

单接口的话就没有太多场景可以设置了吧，主要考虑接口的查询逻辑和要关注的性能点，服务器压力、数据库压力等等，然后接口是否有缓存，存储层查询是否有缓存等等，中间件层等等，接口参数化等等（例如单一接口是动态参数，考虑业务场景下的不同参数）等等等等

使用队列参数化，每个参数是个 json，报文、设备号啥的放里面

https://www.jianshu.com/p/7d8cd61843ad看下这个

xctest 可以直接切换 app，appium 不知道能不能。。

XCUIApplication.init(bundleIdentifier: "xxxxxxxx")

运行时长就是 fastmonkey 里的运行次数
monkey.monkeyAround(iterations: 1000)

额，待测试 app 完全没启动，还是启动了又拉回到这个 demo app，完全没启动的话可能还是 bundleID 的问题吧，具体没看到代码也不清楚。。。还有一种方法是你可以找到 10.1 的 xctest framework 替换到 11 的 Xcode 下 也可以使用原来的那个 monkey

可以二次开发 swiftmonkey，把不支持 10.1 以上的 XCEventGenerator 换成 xctest 的 API
这是我之前二次开发的记录https://www.cnblogs.com/dreamyu/p/11280030.html
这是我之前改造的https://github.com/lcyfly/sjk_swiftmonkey
只是修改了下 tap 点击事件，如果是其它手势操作可以根据 xctest 的 API 自己修改下，修改后点击频率会降低到大约每秒 3-4 个 action，但是已经超过了用户正常操作频率了

先确认你测试是在应用层还是数据库层，如果是应用层只需要关注应用层对数据的逻辑处理，如果是 etl 数仓测试的话，可能要对每一层数据的处理进行校验，包括但不限于数据表结构，字段类型边界等校验，数据一致性校验，数据完整性校验，数据正确性校验，数据转换逻辑校验。

需要注意的地方，如果前期可能更加关注的是数据完整性和正确性，简单来说就是数据量是否正确，是否缺失数据，正确性的话就是数据抽样检查每个字段是否正确。这也是最容易出问题的，例如数据量有问题，数据字段缺失，数据转换逻辑有问题，因此在测试的时候需要更加关注，让开发提供完整的表映射文档，表结构文档，自测 sql 等辅助文档进行测试

我现在也有同感，现在有一些帖子对于一些人的引导是有问题的。

测试平台应该是基于团队，基于项目流程等需求的产物，不是每个公司的必需品。
以接口测试平台为例，在做之前是否有对其他工具框架有深入的认识，是否能通过使用工具框架来快速解决问题，是否可以通过二次开发框架来解决问题，如果能解决问题为什么还要做平台。

我之前就受到这方面影响了，好多框架平台上来就分析其他工具框架的缺点，例如 postman，不好用啊，不适合团队协作用啊，然后推广自己的轮子，但其实深入调研学习后发现大多数框架平台的实现就是 postman 的缩影，甚至还没 postman 做的好。比如：

1. 测试环境的配置，postman 支持全局变量配置
2. 测试 setup 配置，postman 支持 pre-script 脚本
3. 测试断言，postman 支持 test，如果你不会写代码，postman 提供了好多 test 模版点一下就能用，修改下参数，如果这点东西都不想学就别做接口测试了。
4. 测试执行，postman 支持 collection 集合执行，还可以设置执行次数，执行时间
5. 调试的话，postman 有 postman console
6. 团队协作的话，postman 支持 teamwork，可以使用 team workspace，还支持 collection 分享，即使免费的一个月可以分享 2000 次，还可以导出
7. 持续集成可以用 Newman Jenkins 啥的
8. postman 还支持 mock 数据

当然，学习实践一些新技术是每个人的自由，毕竟现在还多也有测试平台啊各种这样的需求，只是不希望一些刚刚接触测试或者接口测试的同学上来就被引导为做接口测试做个平台才行或怎样怎样，而不去深入学习了解本质以及一些开源工具框架的优点。

单独调试一条，用 postman 就解决了，何必执着于框架，本来数据驱动就是针对数据量比较大的情况好做统一的处理，即使做了是否运行的标记，运行的时候还是要一条条判断筛选，效率太低了。

可以参考 httprunner 的思路，将测试数据，接口数据抽离出来，相同业务流程的在一个 testcase 中，动态创建多个 test 方法来执行接口

个人感觉在面试场景下如果没有特殊说明, 能实现就好了,从测试角度来说能写出来就好了,大部分公司算法只是加分项不是必需项, 那些要求很高的会要求你实现并写出单元测试,那就可以写的更健壮一点, 当然如果纯站在讨论解题上,还是需要考虑很多情况的

def searchNum(array):
    length = len(array)
    left_first = 0
    right_first = 0
    left_last = length - 1
    right_last = length - 1
    left = None
    right = None
    while(1):
        # left
        left_mid = (left_last + left_first)//2
        if array[left_mid]<0 and array[left_mid+1] == 0:
            left = array[left_mid]
        if array[left_mid] >= 0:
            left_last = left_mid
        if array[left_mid] < 0:
            left_first = left_mid

        # right
        right_mid = (right_last + right_first)//2
        if array[right_mid] > 0 and array[right_mid-1] == 0:
            right = array[right_mid]
        if array[right_mid] <=0:
            right_first = right_mid
        if array[right_mid] > 0:
            right_last = right_mid

        if left and right:
            return left, right

现在动不动的框架就是一门开发语言 + 相关单元测试框架 +excel+ 报告输出 + 关键字驱动数据驱动, 简直了