你的 id 是怎么找到的，uiautomatorviewer 截图发下？

全是 unable ，建议确认下会不会是 android sdk 版本太低？

对于每天发帖数，内部有讨论过是否需要限制，但最终没能达成一致，所以目前还是没有限制的。针对你提出的情况，我们按照具体情况，一般会屏蔽一部分避免引起刷屏。

后续也会推出举报功能，便于大家主动反馈给管理员，便于我们更及时处理。

不知道你用的是具体什么方法什么路径来读取和写入 excel ，不好判断你这样有没有问题。但有几个点可以肯定：

1、你本地运行的方式和 Jenkins 不完全一样，目测 Jenkins 运行并没有把 maven resources 文件一并拷贝到 target/classes 中，但你本地运行有。建议你本地和 Jenkins 用一模一样的命令来运行，再把结果作对比。
2、target 下面的文件都是构建产物，每次构建都有可能发生改变，不应该纳入 git/svn 进行版本管理。但你的截图里能看出它们都被纳入管理了（有绿色的勾）

不大清楚你是根据什么教程入门学习的，但建议你找一些比较专业全面的教程学习下，太速成的只追求能跑，不追求规范，容易遗漏这些小点，而这些点才是体现专业的地方，也是避免你踩各种坑的捷径。

你有这样的迷茫，我理解是你开始对工作上的重复感到无趣，但一扩展又发现东西太多，不知道从何下手好。

建议先全身心投入工作，把工作中不懂的都弄懂，然后你会发现有些重复其实没必要，有些地方自己没想到。这段时间你可以对你接触到的东西做比较深入的学习，也可以借此探索你的兴趣点。

等到自己觉得已经对现有的东西都很熟悉后，把你了解的整理一个思维导图，再通过咨询你的导师或者身边有一定经验的朋友了解更长远的路，再做打算。

1、数据库数据没有生成，是不是就没有执行项目？

不知道你的项目具体做了什么操作，建议可以加一些关于写入数据库这个操作的日志打印（前面学习直接 System.out.println 就好，后续正式项目记得换成专业的 logback ，否则会显得是个很业余的初学者），通过确认这些日志有没有出现来确认有没有执行。

2、构建以后工作区 Excel 文件打开显示乱码

excel 文件不是文本文件，有一些二进制的部分（可以理解为硬要当文本文件打开，就会显示为乱码的东西），所以不能通过直接查看工作区来看内容（Jenkins 默认没有微信那么强大，没有集成 excel 预览功能），需要下载下来再打开查看。如果下载了查看还是乱码，再另外处理。

博客系统 mysql 挂了，貌似系统有点问题。最近比较忙，过年的时候闲一些再修复。

建议你可以看看官方的文档，我这个文档有点年头了，和最新的已经有比较大差异了，不建议参考。

感谢指出。

按照您的操作步骤，我进入了我的收藏页，但没能复现您截图中的问题，可以看到页面标题是可以正常显示的（图中红色箭头所指部分），请问能否更详细地描述下您的步骤？

之前没出过问题，不代表没问题。
有人愿意承担责任，不代表他能承担的起。
尽量不要基于个人经验做出全局的判断。
存在不确定性的情况下，一定要在可控的情况下进行逐步验证。

这几句点赞！经验主义，有时候换个角度看就是侥幸心理。

自动化平台搭建这个，1 年内就完成，并且有这么多资源，很不错呀！

应该有吧，我们公司也有搭纯 kityminder 的。具体没研究过

统一回复: 平台后续会做一次分享，开源方面因为还有其它公司定制功能在里面，暂时无计划。

研发投入 2 人 3 个月左右。
我们走小迭代，前期核心功能 1 个月发版，后续迭代 1 周 1 个小版本

建议你另外开贴，记录下你的详细步骤和关键代码吧？只有一个日志不好确定是哪里有问题。

我一般只记住命令名字，用法直接 tldr 。不过写得还是挺全的。

PS：好像漏了 sudo 、su 这两个很常用的命令？

@Maya 能否在您的手机上手动重现下？之前没开 bugly 收集崩溃，现在刚打开，如果可以重现，可以尝试几次，后台应该可以收集到崩溃日志。

我们做这个统计倒不是信任问题，而是有的大项目测试周期比较长，参与人数、用例数也不少，统计这个可以方便作为每天进度参考，也方便负责人比较准确地确认进度有没有问题。

你们是怎么做的？

用户直接在平台的用例上手动登记（定义了几个特定标签用于通过、失败），暂时还没做进一步的关联。

你说的追踪具体是指？

截图来了：

目前主要会通过这个平台进行用例的编写、任务的指派、执行结果的登记及统计。目前内部推进开发自测也是通过平台来给用例和登记自测结果，便于统计和记录。

如果说边界值有没有意义，当然是有意义的。

至于意义有多大，相关问题是否需要修复，就要按照优先级来了。技术人员需要重点关注产品的核心功能，如果核心功能都没法保障，那边界值问题自然不会被重视。

另外，我理解任何系统对于一个输入值的大小一定是有限制的，比如 UI、接口（如 nginx 限制单个请求大小，http url 最大长度限制）、数据库（字段长度）。超出长度就会出现问题，可以看看这个机制的极限值是多大，是否能满足产品需要（建议重点看看数据库字段长度），超过极限值程序会如何处理（直接截取？报错？）。之前我们曾经出现过一次由于超出极限值系统直接截断而没有报错的问题，导致原始数据缺失，影响还是很大的。

如果不满足，那就明确提出和要求更改。

是的，主要是团队的小伙伴给力。

是的，你也来一个？

就是 TesterHome 的公众号呀