粗略扫了一眼，性能应考虑手机耗电量的测试.楼主大部分考虑的都是纯软件的，但是关乎手机日常生活的，应该从硬件设施方面也多做考虑.

加个 Location Based Services 测试吧，这块也不可避。

楼主的公司和我马上要离开的公司很像，设计完全不管，就靠测试和开发来保证软件质量，我保证个屁，测试最重要的是在设计阶段保证软件的合理性，不要在开发出来后来回改设计，当软件开始开发时，测试就应该根据设计文档制定出测试大纲或者文档，等开发完成后按照大纲和文档进行测试即可，最应该动脑筋的地方应该是设计阶段，如果在测试阶段要改设计，浪费的就是三个部门的时间

不写用例的也遇到过：忽然一个没见过的项目产品过来找你，这个测试一下，后天上线. 你:黑人问号.jpg 这时候要去看这个产品需求，说明，复杂一点的还要请求开发，然后还要测试，输出报告。是肯定没有时间写测试用例的.
其实，一直觉得敏捷的含义就是：灵活变通. 毕竟产品为主.

@chenhengjie123 可否讲讲你的测试开发之路，是怎么走的？最近有点迷茫。

楼上建议单独开贴问，在匿名贴里面匿名发布评论的人你是 @ 不到的，他不会收到任何通知。

#1 楼 @anonymous 有个问题想请问下，最近一直在研究自动化测试，UI 层的，appium 或 selenium，可是发现基本发现不了什么 bug，而且断言方面很难做到严谨话，原因是基于 UI 层元素的获取，元素的动作，所以断言很难如意。想了解下你们自动化是怎么设计断言的？发现的 bug 有人工测试的百分之一吗

同意 22 楼的看法。在解决问题的大局观下，应当从这两点思考问题。
题外话：其实我也理解楼主 --- 人跟人的确有差别，楼主如果觉得周围的人真的很 low，继续努力提升自己，当有合适的机会到来时，调到心仪的地方即可。

个人觉得可以分两方面去看：

• 一方面是测试人员不懂 logcat，不懂定位 crash 的话，面试能进来也说明进来的门槛比较低。楼主作为中坚力量（或者测试开发），更应该在团队中主动起到推动作用来缓解和解决这个现象。
• 另外一方面，是否因为之前出现过系统误报问题，导致用户（测试人员）对你的平台系统的可靠度产生了质疑？毕竟你面向的用户就是你身边的测试人员，他们吐槽你，你不能觉得用户是 SB 就喷一下对吧，问题还是需要解决。

题外话，测开在内部推广自己的工具的时候，会遇到很多尴尬的问题，其实推一件事本身就是一个难题，建议多站在对立面思考。

一个人测试肯定有测不出的地方，关键看态度。

#11 楼 @anonymous 我就是 9# 这个，非楼主，感觉楼主还是经历太少，经历多了就不过再说了

#5 楼 @hu_qingen 两条一模一样的回复 客户端有 bug 吧

那是因为楼主经历过的不够多！当你经历多了，你会发现林子大了，什么鸟都有！

PS：和楼上一样，我也觉得楼主的排版很乱，或者说没有排版意识 ：）

为什么要去和你觉得 low 的人去比较呢，往上看就好。

需要吃点教训

有啥好纠结的让他 low 去。最后末位淘汰就好了。

回复功能是不是出现 bug 了？？？为什么我回复你，楼主，回复人变成你，楼主自己了？我的头像呢？我的 id 呢？？？

#9 楼 @anonymous 我觉得你说的 都非常有道理。如果不是一个测试管理人员，且公司产品好坏跟你没关系的话，你管人家呢。觉得拉低测试行业水准，那可以选择提高自己。毕竟别人好坏跟你也没有必然关系。楼主吐槽，就当听听，以示警戒。单纯的吐槽，而不结合外界因素，比如 money，比如心情，比如自我发展，比如性格，比如......那这样吐槽也没有意义。毕竟这不是你自己。都是人，谁离得开各种因素的制约和影响呢~~~~做好自己就好，除非自己开了公司，除非他是你的员工

测试工具要能解决功能测试人员的"痛点",那么他自己会依赖、会乐意去使用

我觉得有几个原因，1.个人能力及业务水平，确实测试入门低，但坑很大，想成为一名合格的测试还是很困难的。2.市场原因，让别人看 crash 日志，让别人看数据报文，漏洞分析，都可以，但是你得给相应的待遇啊，事实上大部分公司，测试的待遇都比开发差很多，这个就决定了很难招到高级的人才。是不

我觉得或许可以换个角度来看，可能有些测试确实很 LOW，不愿意学习。工具还是为人服务的，如果能再多花点心思做到直接能拿给开发看，无视掉手工测试的是不是也是一个办法？（当然如果你前期没有跟开发交流过，开发一般是不会睬你的，哎，就是个悲剧）

你们的功能测试人员可以换人了，测试人员只有嫌 Bug 少的，不会嫌 Bug 多的，开发才会嫌 Bug 多。。。
尽可能全面的发现问题才能更好的保证品质，我们这的测试人员一般都是努力在证明开发认为不是 Bug 的 BUG。

作为一名测试，描述问题时得条理清晰，有逻辑性吧。瞧你这密密麻麻，碎碎念的。。。

我们测试大部分都是水军，谁让这东西入行简单呢。其实我本身也挺水的自动化做起来了但是也总有遗落的点。自己一个人测试总还是有想不到的地方。

1. 有没有带来效益我觉得应该从团队层面考虑，不能说功能测试觉得不是 bug 那就不是 bug 。如果最终这些 bug 开发认同并修复了，那就是带来效益了，发现了功能测试没有覆盖到的问题。
2. 你提到的功能测试如果确实如你所说，不愿意，甚至不屑于学习查看日志，那么他很快会被淘汰。态度上他就被淘汰了。