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

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

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

个人的想法：
让测试更高效地测试
指导开发更便捷地测试
让质量相关的数据指标，更直观地展现

有些时候，并不一定要区分得这么明确，很多时候产生测试开发的原因仅仅是业务太繁忙，如果不特别设立这个位置就无法快速推进一些测试方面的提升。

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

你们是怎么做的？

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

你说的追踪具体是指？

截图来了：

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

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

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

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

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

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