谢谢回复。
拿到的是设备，没有提供我们接口，只能找真人来测试

写的挺好。
感觉就是测试左移的思想。但是 QA 除了对自己的交付物测试用例和测试报告可以把控外，对于需求文档、设计文档、代码质量有多大的影响力呢？ QA 提出的 bug 有全生命周期的记录和管理，但是对于需求文档和设计文档的改进意见是没有这样的途径和权力

写的真好。
“人是要赋能的，仅仅是管没有用的，你要让他自己觉得有成长，觉得在这个团队有自己的价值，这样才能留住人，做好事”，这个观点特别认同，但是工作中没有碰到特别符合这个要求的领导
关于如何提升自己，有时也想过，“在工作时间挤出一点时间学习和提升自己，哪怕牺牲一点产品质量（因为时间是有限的，很难一直在工作时间外挤出时间学习）”，可能这个观点老板们会非常反对。

感谢回答。思路非常清晰，也具有可操作性。
只是我觉得第一点说着比较简单，但是实际上工作量会比较大。要和产品对需求，要和开发了解业务模块和接口，这块要求产品和开发提前有高质量的输出物（需求文档、开发文档）才可以。

也非常感谢推荐的书籍，另外一位同学也推荐了一本书，都是非常知名的书。但是全部都是脱离了业务单纯的讲测试，我并不喜欢这类书（可能是我理解的不够吧），我觉得都是在讲理论，太脱离实际了。没有看到一本书是教测试人员如何更好的去了解业务的，去熟悉开发用到的技术。假如我拿到一个测试购物商城的需求，与其看那些方法论，我还不如找一个竞品，去淘宝，京东上面看看人家是怎么做的，我觉得这样更有助于发现问题，提升质量。不是说方法论不好，是觉得大家都在说方法论，有点脱离现实了。

根本原因是我觉得写测试用例没有意义，最多是让自己熟悉需求，提醒自己不要有遗漏点，但是现在都敏捷开发了，周一分配了任务，周二就有任务需要测试了，写用例的时间也压缩了。

真的是经验之谈啊，和业务结合做自动化才能真的提高效率。

感谢回复，非常有收获。

好观点

如果有真正的设备就用真设备来测试，如果没有真实设备可以通过代码模拟设备来发送消息。如果测试的应用层的功能，消息内容也可以直接插入到数据库里面。