目前就是卡在，linux 服务器里安装安卓系统，linux 中 adb 连接安卓设备，然后执行 python 脚本，运行 app 自动化，后续结合 Jenkins 集成

额，我语文不大好，你意思是说这么多地方卡住？可以分享下你自己通过什么方式找，找到了什么文章，然后你现在有什么问题是这些文章都解答不了的？

• linux 服务器里安装安卓系统

这个只能弄虚拟机吧，毕竟两个都是完整的操作系统。不过 x86 平台上高性能的 android 系统基本都是 x86 指令集的，用 arm 指令集的因为要额外转译性能都一般，而且目前手机上的系统都有各种自家的二次开发，和原版的有一定差异，所以这么跑出来的结果可信度有限，比较少人这么做。

看起来是个技术优化需求，从需求看应该是 redis 和数据库数据结构不变的情况下，优化中间的定时任务性能。所以还是最好去看下代码确认下逻辑是否一致，纯黑盒难保会有遗漏。

如果是我测，我会这么做：
1、先了解清楚原来老的定时任务，具体做了什么转换。这个了解相比问开发，更需要自己也去看看相关代码，代码里才有最充分的细节
2、然后 review 新的定时任务，转换逻辑和老代码是否一致
3、逻辑 review OK 后，找一些 redis 数据，分别交给新老定时任务去处理， diff 对比下输出值有没有差异，同时可以看看性能是否有提升
4、最后结合整个业务去过一下代驾功能里和这个定时任务有关的用例，确认整体功能正常
5、最后确认下预计的上线切换方案（最稳的是新的任务先不要写到正式表，先写到一个临时表，然后观察一段时间确认写入的内容和老任务一样，再关掉老任务，新任务切换到正式表），做一下演练。

除了找 bug，测试团队是不是能给公司的业务带来更多贡献？比如帮助整个团队的品质得到进一步的提升：“品质 “要比” 缺陷 “的范围大很多。

这点很认可，要扩大上级对测试价值的认知，如果总是觉得测试只是手工活点点点，那后面会处处受限。

这个是什么时候的文章？好像现在很少说测试基建要花大精力去弄浏览器兼容性了。

挺有意思的用法，想了解下有实际落地的效果情况吗，可以分享下不？

看楼主的示例，一个重置密码的流程画起来好像还是有点复杂度的，而且这只是一个实际业务中来说比较简单的逻辑了，复杂逻辑会不会画出来的成本更高？

下载地址 是个纯文字而不是链接，是复制的时候故意去掉的不？

另外，你这个访问地址我试了下公网无法访问，应该是只有你们内网可访问的，建议可以去掉，只分享下思路什么的。

PS：建议楼主前端可以应用下一些样式组件，比如 bootstrap ，更进一步建议了解下 vue + element ui 。现在除了用例管理用 agileTC 颜值还不错外，其他界面颜值有点一言难尽，会严重影响第一印象分。

没用过 locust ，只说明下我的理解，供参考：

一般压测工具只要没有 fail 或者报错，都是请求成功。看你第二个请求的 response 里面有 num_requests 表示发出请求数， num_failures 表示请求失败数，看这个就可以看出来了。

每个请求都记录详细的 response 信息，会很消耗性能，导致压测工具压力上不去，所以一般压测工具默认是直接通过 http status 判断成功（2xx/3xx）/失败（4xx/5xx/请求超时等异常），有别的需要的话得额外写断言。

有些业务的开发人员都不需要测试人员的介入 ... 好多业务不需要测试介入，测试人员对业务就不能进行深入的了解。测试人员的出路在哪呢？或者说测试人员要做些什么呢？

没太看懂，到底是少量开发人员不需要介入，还是大部分？

另外，由于开发同学需要深入很多细节，所以在整体系统的全局视角上一般不如测试，比较明显的就是除了自己负责的模块，其他模块基本只了解皮毛，所以导致开发在做整体系统的集成测试方面不如测试考虑全面（如果测试连这个都比不过开发，那真得好好反思下了）。测试可以从整体系统集成这个方面去看，整体系统质量如何。还可以进一步看哪些地方质量风险大，怎么去做 “预防”，而不仅仅是设计用例和执行测试做 “验证” 。

从楼主的设计初衷看，应该是主要针对相对复杂度不那么高的项目快速建立自动化用例用。从这个角度来看，建议楼主可以针对这个方向进一步优化，比如加上一些自动生成用例或者说录制生成基础用例的手段？

低代码平台一般初衷是相对代码经验弱一些的同学，或者通过高度的封装极大降低代码量。看楼主的思路，应该属于前者。对于代码经验弱的同学来说，自动生成/录制生成会比在界面拖拉拽写用例吸引力更大。如果不写代码但还得要求有编程思想，容易不上不下，写代码的人不喜欢用，不怎么写代码的人也觉得写起来不如自己直接执行方便。

额，为啥要遍历多个页面呢？你能先说明下，你到底要测试的是前端的什么性能不？

这几个方向的目的是有一定差异的

资源加载速度（lighthouse）：基本目标是尽可能有效整合资源/懒加载非立即需要的资源，在网速不变的情况下，减少加载网页所需的总网络请求数（浏览器内部并行网络请求是有限制的，资源太多会导致要等前面加载完才有机会开始加载，减慢加载速度）。常用举措有资源整合和资源拆分（弄懒加载用）

不同地理位置的网络加载速度（各种测速类网站）：基本目标就是加快网速，常用举措是增加 CDN 节点。

开始加载后白屏时间：这个实际是用户体验优化了。在前两者已经没有可优化的点的时候，尽量降低白屏时间。常用举措有骨架屏、懒加载等。

运行时 FPS 等性能数据：这个更多是一个界面流畅度问题的 profile 工具，即通过采集和性能及运行内容有关的数据，辅助定位性能问题。常见使用场景是界面卡顿时定位卡顿原因用。

请问，有找到合适的 android 10 以上监控 app 单独流量的方案了吗？

google 查了下，有个说的比较全的文章，但里面对应 android 10 以上的方案要不得 root ，要不得用 android 应用通过 android api 获取，没有直接通过 adb 获取的方式：https://android.stackexchange.com/questions/203868/how-to-view-network-traffic-requested-by-a-specific-app/204022#204022

你这里的安全问题应该是暴露了敏感的内部错误信息吧。解决方法应该是线上环境通过配置 AOP ，在最后返回内容前换用统一的错误信息（比如常见的 Internal Error ）避免直接返回原始 exception 信息。

接口入参类型不一致只是引起这个问题的其中一种原因，如果下一次这个入参不是来自于接口，而是来自于数据库数据或者别的输入，你光限制接口参数长度就没法防范了，所以这个问题不应该通过限制接口参数长度来解决，成本高且无法彻底解决问题。

前端性能有好几个细分领域，常见的有资源加载速度（lighthouse）、不同地理位置的网络加载速度（各种测速类网站）、开始加载后白屏时间（除了录屏外不大了解还有什么工具）、运行时 FPS 等性能数据（chrome 浏览器的 Performance 选项卡里就有）。

从楼主描述的意思看，应该是最后一个？

前端开发也是比较新的同事，里面很多堆叠的逻辑也不太清楚；

这种情况下做重构，要非常小心。不清楚逻辑就做重构，是重构容易出问题的原因之一。现在你们处于测试没法把场景列得足够全，开发也没有对原有逻辑梳理得十分清晰的就动手重构的状态，重构的两个大坑都踩到了。。。

建议：
1、看这次重构是不是非常必要，如果不是，那就先 hold 一下，或者重新梳理逻辑后再重构吧。
2、如果代码已经上线甚至基于它已经做了一部分功能，不好回滚，那就找熟悉这块逻辑的同事（不限于测试，包括产品等都可以拉过来）一起过来补充更多的场景，以及做好线上用户反馈问题后及时响应的机制。

1、单元测试的测试对象一般是某个组件或者某个函数，目标是保障这个组件/函数满足要求没问题。由于单测一般会把输入都通过类似 mock 的手段进行控制，所以是可以模拟出几乎全部你能想得到的输入（当然前提是你能想到）。不过如果说只是要用到 mock 手段方便你模拟线上数据的多样性，那你只需要一个接口 mock 服务就可以了，不需要特意去弄单元测试。

2、不知道你在测这个重构项目时，对重构的技术方案、改动范围有多少了解？有没有对现有缺陷做缺陷分析，看主要出现的原因是什么？每项测试都有自己擅长的点和不足的点，建议先找到你现在问题的原因，再考虑用什么解决方案。你说的线上数据多样线下难以覆盖，只是一个直接原因。为啥重构前线上同样多样的数据不会出问题，重构后会出问题呢？是不是重构的时候有些地方本身就没考虑完善导致逻辑遗漏，或者重构的人对以前代码逻辑不够熟悉，想当然去写写出了不正确的逻辑？这些才是根本原因。

个人经验，要控制好重构类项目的风险，必须从技术方案开始入手，把重构拆碎成多次，控制每次重构的边界（可以理解为改动范围），每重构完成一部分就测试并上线一部分，就算出问题也可以在这次有限的改动范围内快速找到原因并修复。否则一次大重构非常容易变成重写，影响范围大到几乎整个系统重测，开发测试都得加班加点，且风险难以控制。

这个看具体是什么样的异常吧。

如果是本身业务逻辑中可能存在的异常（比如查询结果查不到结果之类的），那肯定应该有合适的处理。至于 NPE 这类错误，可以提议让开发同学学一下阿里代码规范，里面就有一条 防止NPE，是程序员的基本修养 。

至于是否暴露具体提示信息这个，线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户，确认下有没有配置就好了，测试环境暴露倒问题不大甚至有助于排查。

不过一个对 NPE 都不在意的开发团队，你要求接口做得很完善，很难。如果不是专门测服务端的话，建议接口保障好各个可能存在的业务场景都能处理好就差不多了，至于那些尽善尽美的东西，不建议一上来就以规范、缺陷的形式来走，容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析，让开发逐步知道这块没做好会有什么危害，对质量逐步有更高要求，再推进到规范，会比较好。

建议优先学习你工作上用得到的相关工具吧，selenium 跑个 demo ，做个笔记记录下来，便于后续工作上用到可以快速捡起来就可以了。

工作上用不到，很多东西你比较难接触到，虚拟项目和实际项目还是有很大差异的。比如之前社区有挺多同学提问那些基于 vue 或者 react 写的控件，selenium api 直接操作没有效果，这类不在实际项目里面用，不一定会遇到。

hmm，不确定这个问题提问时，面试官想了解的是全貌，还是单纯被测项目的信息？

如果是全貌，这里用类似 STAR 法则去分点说明，挺全面的，逻辑也很清晰。成果描述稍微优化下，尽量写比较实在的东西，而不是那么虚的东西，会好一些。

如果是单纯想被测项目信息，考察对项目的熟悉程度，可能还是稍微有所欠缺。上面对项目的介绍有点简单，听起来像是纯搬运产品介绍文案的内容，没能看出从你作为测试人员角度，对这个项目的一些思考理解（比如这个项目最具价值的功能是什么，它的价值是什么，为什么是最，你用到了什么手段保障这个价值可以交付给客户而不受质量问题拖累）。

PS：主观题自动批改，客观题教师在线阅卷的功能 ，这里是写反了？客观题不是更容易做自动批改么？

所以，哪里可以实践使用 Selenium 的项目吖?

日常你测试的 web 站点相关用例，有改为用 selenium 来帮助你完成它吗？如果没有，可以从这里实践起来。很多所谓的高级技巧，其实就是当项目复杂到一定程度时演进出来的技巧。项目复杂度没上来，学这些其实不大容易理解和代入。

其实我是基于安全方面进行考虑的，当时我在写接口用例，然后我就想如果前端/后端都按数据库设计来进行的话是不是很大一个程度提高了系统的安全性（如：SQL 注入，只要对每个传参类型和长度进行校验，就能很大的把 SQL 注入难度提升一个级别。）所以我当时的理解就是所有的接口都必须做长度和类型的校验，最好和数据库设计的字段保持一致。

你说的这个想法，是有具体实例佐证么？有的话，可以分享下？

以我对 sql 注入的了解，通过这种方式去防范有点 隔靴搔痒 的味道。sql 注入防范的核心是在数据解析 sql 的位置，防范用户原始输入值带有 sql 关键字引发 sql 查询实际作用和设计目的产生很大的差异，进而泄漏一些不应该出现的数据。比如很常见的 sql 注入参数输入值：1 or 1 = 1，长度一点都不算长，类型也只是一个很普通的字符串，但里面带有 sql 关键字 or 、= ，会引发 sql 语义变化，所以需要进行防范。而且这类防范，mybatis、jpa 等常见的数据库连接框架，写法规范的情况下已经自动进行防范了，从接口规范层面通过字符类型 + 长度去防范，个人觉得实在没有必要，也不一定能起到实质性的防范效果。

建议先别定规范，定一下协作机制就好。

人少的话，其实沟通成本也不高，有些事情同步到位就可以了。规范很多时候是人多了，某些重要事项做事方式不统一，引起的额外沟通成本比较高，才需要以规范形式定下来的。

接口传参长度和数据类型应该与数据库设计的对应字段保持一致

楼主可以分享下你要测的接口参数是什么，对应设计的测试用例大概是什么，哪些用例执行失败引发这个帖子的思考么？

如果从上面这个文字意思上看，这个接口和数据库长度、类型保持一致的限制有点死，一旦长度要变化（比如需求有改动），服务端代码 + 数据库 DML 都得改，略麻烦。一般来说，数据库字段长度限制会设置得比实际业务规定长一些，避免后面改大还得改 DML 走审批流程那么麻烦。而且常用的 varchar 变长字段类型是按实际内容占用存储空间的，这个长度设大一点，不会引起什么副作用。有时候偷懒会直接不设置接口的校验，直接交给数据库来限制（大于字段定义长度，数据库会直接无法入库，返回失败，但一般这种情况不好给明确指示用户是超出长度，只能后台查日志看出，所以说是偷懒）

另外，不知道你们后端使用什么语言框架做开发，如果用的 spring ，类型和长度这类比较死的限制，复杂度不高，甚至在写接口定义代码的时候就可以完成了。

数据类型：数据类型这个 spring 是自动根据服务端设定的参数数据类型转换的。比如类型是字符串，那接口不管传字符串的 0 和数字的 0，框架都会自动转为字符串的 0。但如果类型是数字，传了个转不了数字的字符串（比如 a ），框架会自动报错拦截。

长度限制：接入 JSR 303 框架，给要限制的参数加上 @Size(min, max) 注解就可以了（可以参考 https://www.jianshu.com/p/d2ddd856cce2 ）

要写全挺多的，上面也列了不少。

从楼主上面信息看，测试团队应该还比较新甚至只有 1 个人，那要规范的应该主要不是测试（才 1 个人用的规范性价比不高），而是测试的合作方。推荐可以优先写比如项目流程规范、提测规范、缺陷等级规范这类涉及合作团队的部分，减少不规范的合作形式引起的额外成本。

完整看完了，很有收获。对于 35+ 的问题视角，也很有参考意义。

这个问题没太看懂，保障测试质量指的是保障测试团队的工作质量，还是指项目中的质量保障？不知道当时面试的上下文，所以没太理解这个问题到底想问什么。

另外，可以也分享下你一般给出的回答是什么？