初学者有这样的问题也是正常的，不一定就是很 low 。
每个人都是从初学者一路踩坑过来的，大家还是多点换位思考把。

试下看是不是开启了系统的缩放？这个缩放有可能引起字体比控件大导致部分被截掉。

图里显示的内容不全，无法判定你用的是什么命令和报什么错，不好说根本原因是什么。把你图里面的文字都复制粘贴上来吧。

permission denied 只是表象，表明没权权限，但很可能核心是其它原因（如使用姿势不对）。建议贴图里面内容的时候，加个注释说明下你跑这段命令是想要达成什么目的，便于确认你的命令使用有没有错。

有没有 appium 的日志，能不能以代码块形式贴上来？

当项目内容/业务流/功能点很多时，效果和效率是如何权衡的

核心点和自动化回归一样，这个事情不管谁做，是不是你在上线前必须做的。如果是，那做这个事情本身就不会降低效率，最多持平。而效果肯定比不做要好。

但要留意做好宣贯，让整个团队都认为这个事情是必需要做的，工作量纳入时间排期和提测标准。很多时候开发不做自测很大的原因也是给排期时没有考虑这块的时间，所以没时间做。

另外，如果项目自测的内容确实非常多，光测试执行可能就要超过 1 天，那真的得好好想想是不是需求划分出了问题，一个需求太过庞大了。

个人意见：业务测试发展不一定要往测开或者测试架构，也可以走管理路线甚至转型产品等。

但从当前行业整体情况看，业务测试也需要有一定的技术能力。一些重复性的工作可以通过使用工具平台甚至自己写脚本提效，了解开发写的代码代表的是怎样的逻辑并有自己的判别能力，避免被开发的 “影响范围” 说得不准导致遗漏或多测。这些能业务测试测得更快更准，符合大部分公司对测试的期望，所以如果不具备就会被具备的人淘汰。

这部分能力和测开的技能部分重合，但不是说就得做测开。

就我司的实践，分享下个人经验见解：

1. 开发做更多什么类型的测试？
   ——正向的基本功能流程，或者说相当于冒烟测试类型的测试

2. 测试如何帮忙开发自测，测试需要提供什么等？
   ——冒烟测试，或者说开发自测的用例（内容写明确一点，别只是要点，免得认知有偏差后面撕逼）；造数据的脚本或者平台（特别是对于后端比较复杂的，前端不懂造数据会导致自测效率很低）；走通整体流程的一些手把手教程或培训（有时候开发只知道自己负责的一小块子模块，不知道整体流程怎么回事，我们既然很熟悉这个，可以分享下）。严格说不是帮忙自测，而是让开发更方便、更高效地去做自测，这样他们才更愿意做。毕竟开发最能产生价值的还是写代码完成功能，都想在写代码之外的事情尽可能不要花太多时间。

3. 如何去校验开发自测与否，以及自测的质量如何？
   ——用例精简到顺利的话半小时内可以全部完成，然后提测前让开发组织做一次半小时到一小时的演示（我们内部称为 showcase ），开发自己亲自执行这些自测用例，测试和产品一起看。一个是确认功能确实已经可用，测试自己也不用再花时间重复执行一遍；另一个是产品确认实现效果和他期望一致（有时候产品需求会有些没提及的模糊地带，开发可能不沟通直接自己脑补做功能，和产品期望不一样）。如果老是走不通，开发自己也会不好意思的，所以能借此促进他们自己先做好自测再演示，免得出溴。

   很多时候开发自己对质量没要求，是因为自己开发的东西自己都不用，所以对里面的问题都没感觉，磕磕碰碰能过一次就交差了。让他们自己实际用起来，自然就会发现自己开发的东西有啥问题或者哪里不好用，产生改进的自驱力。用流行点的话说就是 eat your own dog food ，各个大公司内部最新版本要求研发全员自己日常就得使用也是这个道理。

4. 第三个问题也引申一个问题，提测的标准可以有哪些？
   ——核心还是要能证明自己的代码能用，至少能走通正向核心功能，所以最低要求是上一步说的演示必须进行并且测试、产品都认为可以通过。更严格的提测标准可以在这个基础加上一些代码质量要求（如 sonar 标准、单测标准等）

不知道你这个具体是啥场景，能说下不？

很少见有这样的需要，既然都用 adb 了，基本都是在做专业调试了，没啥必要还要走公网。

图片都挂了，点击跳转都是 403 ，估计是防盗链了。建议修正下？

黑盒：总结经验，积累公共用例模板便于套用，让每次测试用例基于模板扩展，执行时根据时间和风险选择性精简，而非遗漏。
灰盒：知道代码改了啥，影响的功能有没有都测试到。结合覆盖率使用效果更佳。

说白了还是要持续积累经验和总结改进，只要不重复踩坑，慢慢就不会那么多遗漏了。

有个疑问，你给的那段 python 代码看起来是直接遍历 excel 内容的，我理解你要增加用例，应该只需要修改 excel 内容，不需要改代码的。

所以不大理解你的 “自动生成用例” 定义是什么？

我对这个 “自动生成用例” 的理解，会有两种类型：
1、自动生成代码。根据明确的 request、response 报文相关信息，生成对应的单个用例执行代码，例如 java 的 mybatis generator 那样根据数据库表结构定义，自动生成各个数据库表的增删改查方法。
2、自动生成用例。根据接口文档提供的信息，自动生成不同场景的单接口测试用例。比如接口文档定义了 request 中一个字段是可选值，那就自动生成带有这个字段和不带有这个字段的两个 request body ，作为两个独立的用例供后面程序执行。

不知道你是属于那种类型？

希望自己的框架可以支持通过读取 excel 数据自动生成测试用例

这句话隐含的信息量太多了，如果没有更具体的信息不好给出意见建议。

建议补充下：
1、why。目前工作效率的瓶颈是什么，为何期望要通过 希望自己的框架可以支持通过读取 excel 数据自动生成测试用例 这个方式去突破？说不定这个其实并不是最佳的方法。
2、what。这个自动生成用例，需要做到什么程度、什么效果，才能解决这个瓶颈？类似需求，先得来个原型让大家知道大概要做成啥样子，再聊技术方案。
3、how。excel 数据是什么样的数据，给个具体例子（不要是虚构的，直接用实际的就好）？生成的测试用例大概需要是什么样子的，也给个例子（同样是真实的）？目前对于这个实现有没有什么初步的想法？直接伸手不是个好习惯。

不明白你想大家分享什么经验，是实际工作中遇到难题怎么处理的经验，还是手把手的入门教程？

前者是很好的交流点，后者估计没多少人手上刚好有符合你需要的教程，更建议你去通过买书或者看官方文档自我学习。

PS：pycharm 只是一个软件，为了便于写 python 代码集成了很多写代码需要的功能（包括一键运行及调试 python 程序）。和 jmeter 、postman 不同，不是专门为执行接口自动化设计的，所以软件也没有内置和接口自动化相关的功能，所以你这么问大家都会觉得很奇怪。类比起来，这个问题类似于怎么用电脑去进行机器学习。

个人理解你要问的应该是如何结合 python 进行接口自动化测试？

说的很在理，特别是综合实力这个。任何培训只能教给你技术技能，但应用层面的软实力，最终还是要靠个人的修为。

能自我反思是一个非常好的开端，定期总结能让人更好地明确自己的不足和努力的目标，加油！

可以详细说说你的整体情况（比如是基于什么具体应用场景需要做自动生成用例代码，手上有什么数据可以作为自动生成的数据依据等），然后说说你的初步想法，我们再共同探讨？

目前不知道你的完整情况，不好提出意见建议。

把 241 上打的可用的和不可用的 jar 包解压出来，用文件 diff 工具对比下有哪些地方有差异？

不知道你的打包脚本具体是啥，会不会和打包目录有关，仅凭这个错误日志没法判定是什么问题。

不好意思，因为近期忙于准备深圳大会，开源项目的定期审核频率降低了，没有及时看到您的项目。

刚才已经确认过，您的项目已经审核通过开放给所有人查看了。其它近 3 个月的项目也全部审核了一遍。

感谢提醒，大会后我们会抽空增加相关的审核人员提醒功能，便于审核人员及时知道有新项目待审核，及时审核。

robotframework、精准测试之路、web 测试囧事、TMQ 出的几本书都挺不错。

不过测试技术的书真的不多，如果你真的期望往技术方向深入，建议先看一本开发语言相关的书，像读大学那样从头啃到位，那测试技术对你来说就只是稍微转个弯就能学会的东西了，上手会快很多。

上午一个主会场，下午 5 个分会场并行，不同分会场之间步行距离 2 分钟内。

是的。下午会有多个分会场并行分享。

成体系的知识，个人建议直接买书查看。

博客大多是按照个人历程记录分类的，很难做到成体系，毕竟没有多少人的经历刚好是和体系完全契合的。

+1，啥时候会大把的干等时间？表示没遇到过这么幸福的时间。

具体如何做，我想大家都有自己的思路，但是不能够总结出来，表达出来，这是我们大部分测试的通病——知其然而不知其所以然。

很认同这一点。不过这个并不只是测试的通病，开发、产品等其他角色也很多时候有这类问题，很多人都不怎么做总结，自然不善于总结。

第四个问题：有个登录项目，需要进行全面测试，你会测试哪些内容？

一上来就直接说怎么测的，个人觉得都不大对，因为都没了解清楚情况就开始想要开干了。以前看过一篇文章，说有个活动让大家讨论有个登录功能要测试，然后就开始各种密码错误、长度超限、密码错误得怎么提示更安全、密码存储是否加密之类的场景。结果大家都说完后，主持人再补充说明，这其实是个绑定微信账号完成登录的功能，不需要输入密码的。。。

你是从哪里看到 mockjs 可以进行接口正确性验证的？不知道你的上下文，不好回答。

硬要说的话，对于那些透传或者依赖下游服务的接口，通过 mockjs 可以把下游服务模拟掉，便于上游测试接口，也算是一种接口正确性验证的辅助手段。但我了解的 mockjs 大部分用途是前端开发在联调前辅助自己自测用的，前面这种场景用得会比较少，毕竟后端大部分都不是那么熟悉 js 语言，用自己顺手的语言对应框架更趁手。

别迷信这类练手项目，和实际公司项目差的太多了，基本这个项目的经验在面试官眼里面等价于没啥经验。去外包或者创业公司练一练都比这个强。

因为你不会经历产品需求不清晰需要不断沟通澄清、开发实现影响范围写得模糊需要沟通确认甚至看代码倒推、测试时间很紧张只能从风险角度挑着测、上线后要会看监控确认无故障这类真实项目家常便饭的场景，所以你对这类情况的处理解决能力也无法得知。