图片都挂了，点击跳转都是 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 语言，用自己顺手的语言对应框架更趁手。

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

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

个人建议，你就直接持续跑着 5 个左右的 appium 服务，脚本只需要选择用哪个服务就好，这样也可以并发，而且技术上更简单。当然，要记得脚本里面确保每次执行完毕都结束 session 。

如果要搞用到时启动，你需要了解 python subprocess ，需要知道如何从命令行启动 appium ，需要能监控 appium 服务是否真的启动成功。从你目前的回答看，你对这些方面的知识了解其实并不是很多，所以直接持续开着 appium 服务，脚本只管选择，这个方案可能更适合你。

当然，有一个绕不过的点，那就是你还得知道如何从命令行，而非 appium desktop 启动 appium 服务，否则做不到多开。这方面的知识一楼已经有说过了，建议可以结合社区搜索一下知识理解一下。如果实在还是不理解，可以再发帖说你找到了哪些文章，个人理解是如何和卡在哪里，便于大家协助你。

自动化测试中，验证码的最佳解决方案是万能验证码或者直接可跳过。

不能做到独立无人工介入的，都只是半自动化，不大适合用 jenkins 自动触发执行。

往年 MTSC 大会都有小程序测试的相关议题，甚至有邀请到微信的同学来分享。建议可以先看看？

交流是要相互的，建议你先提出你自己的观点和看法，别人才能回应交流。只是抛问题只能称为咨询。
而且任何具体工具使用都是依附于当前业务需要的，你也没介绍你的业务情况、痛点难点，大家也不知道给啥建议你好。

信息太少了，而且除了薪资，你也没提到你所在城市或者公司这两个职位之间你的感受对比，无法给出建议。

从大的行业来说，前端开发对业务的贡献会比自动化测试大，门槛也高一些，所以应该前景更好。但到了具体公司，这并不一定，如果质量是公司瓶颈，测试开发也会很吃香。

我不是活动主办方，控制不了这些 ppt 。

建议你可以在那个公众号下留言给他们。

各个地区、各家公司要求不一样，这个问题建议你查招聘网站 jd 以及去自己直接面试下，得到的答案才准确。

PS：自学不管做到什么程度，从公司角度你的实际项目经验还是近乎于 0，需要不少时间才能上手实际项目。深圳竞争还是比较激烈的，非应届且没多少测试方面的经验，不知道好不好找。建议空杯心态，多去试试吧。

看漏了个 Manager ，原来是平台呀。

可以和作者沟通下，提个 pr 或者直接 fork 到你账号另外维护呀。

谢谢反馈~我们看下是否设置有误。