机遇和困难并存，当你觉得有问题很多，无从下手的时候，也是你实际解决问题落地项目，提升自己的时候。
聊下个人建议：
1、自动化提高测试效率是肯定要做的，可以从接口自动化开始（UI 自动化这类项目就先算了吧）。越没时间搞，越要抽时间去做，自动化用来做回归测试，这样才是良性循环。
2、测试流程规范，这个牵涉太多，其实应该由 QA/PMO 牵头，测试、研发、产品、运维一起推进。在没有资源的情况下，多和各个 leader 聊下相关问题和困境，询问他们应该怎么做，自己也要给出合理的建议，逐个击破问题。
3、花钱招人吧，不管是业务专家还是技术专家，多一个牛人多一份力量，有些事情不是 1、2 个人力能解决的。

坚持、规划、落地

我感觉分层不是难事，难的是端到端啊

因为算是实名留言，所以改了一下，等可以匿名之后再放出其他的
其实我的问题主要是，我不知道从哪开始开展，没有一个较好的方向

谢谢，确实是要着手去做，但是开始不易，流程规范的话，这边我也只能通过我们两个人的测试来做规范，尽量覆盖或者是冒烟节省时间去检查开发的严重问题。一次周期做下来，两个人，真的太累了，一个月反反复复在做一样的事，对我个人来说真的觉得这一个月过的实在重复且没有意义；
有一次我拉着 App 开发修改 bug，因为打包等了很久，而且因为各种小问题但是必须得改的问题更换好几次版本，最后他抱怨，这一天他不知道他自己在做什么；我只能回复，我这一个月我不知道我在做什么；

是啊，三端之间的通信，云端到 App 端的其实还好，但是跟设备的话就很难确定，加上设备还增加了安全化的内容

建议是先看看是否可以做接口类的，然后做持续集成，只有吧持续集成做起来了，才有精力做其他的。不然你每天就光跑脚本了。做了持续集成开发其实也解放了，他可以开发一部分功能或者修改一些 bug，提交代码之后自动编译，自动部署。这中间他就可以并行做其他的事情了，你也不用说是盯着他编译浪费时间了。部署完成之后来个通知，你直接去验证就完事了。

其实现在无论怎么样，都建议吧持续集成做了，这个带来的收益太大了。可能你现在投入精力，花个几个月时间，搞出来之后节约的时间远远不止。我们以前没做持续集成，开发都是基本改完所有 bug 再提测的，这花费的时间就 1-2 天了，测试这段时间基本就是写用例，现在基本 2-3 小时开发就改完，然后缺陷基本都验证完了。

而且做了持续集成之后，接口类的都是全自动校验，后台只要提交代码就自动校验所有以前的接口，避免以前的接口出现问题。我觉得这个挺关键的，也确实遇到过好几次开发无意间改了之前的接口的问题。UI 层面的我们公司是暂时不做的，因为涉及到的人力和物力有点多，这方面不划算，所以我们没做。这方面我是没啥经验的

我觉得当务之急是复盘，找出过程中遇到的问题，最消耗时间和精力的点，然后逐个击破。
1、比如构建发布时间较长，可以优化 CI 流程。
2、老功能受影响，可以实现接口自动化进行回归测试。
3、新功能问题多多，可以反馈开发或者项目负责人，从上向下推动。
4、bug 扯皮，可以定期评审，让产品或者项目负责人说了算。
5、业务理解有限，测试推进困难，将测试思路或者要点用 xmind 记录，请产品评审下，查漏补缺。
6、测试技术覆盖不全，可以寻求新的测试资源（请开发帮忙、招聘新的伙伴等）。

要合理利用测试的权力，测试不止是一个质检的角色，更重要的是卡口子，是保障上线质量的最后一道关卡。可以制定各项标准，经各 leader 同意，不符合标准的不予测试、上线，要说 NO。

1. 先解决现有的问题。比如快速给开发反馈，规范测试准入准出。
2. 再考虑构建体系

一定跟设备端约定好可测性，从业务角度，梳理出来需要的模块或组件，让开发提供调用接口。后期才方便进行验证，自动化也好开展。

我们这边前期测试没有跟开发评估可测性，现在全黑盒，如果想要做点自动化，要同步跟开发的技术栈，现在是 RN，比较蛋疼

按照我之前在智能硬件项目的经验来看，如果要做效率化的事情，其实按四端来区分着做（可能不大准确，毕竟硬件类型也非常繁多）：

• A 端（APP）
• B 端（官网，网页配置页）
• S 端（Server 端）
• D 端（设备端）

其中，A 端和 D 端可能存在直接通信，比如蓝牙协议等等，也可能是 A -> S -> D 这样的路径，所以可以考虑的自动化层考虑应用层 API 协议或者其他协议的自动化测试。
对于 A 端本身有比较复杂的交互，可以建立 UI 自动化测试做功能验证
对于 S 端，就是常规的服务端测试自动化，社区里面实践也比较多，难的是 S -> D 的交互，状态上报，指令下发什么的，这块是专项来验证，S <-> A 的交互就是常规的自动化测试了；
至于 D 端的自动化测试，这块比较复杂，涉及到的层面很多，网络层面、协议层面，驱动层面，硬件本身的系统固件等等，这个比较复杂，需要专项去研究了。

持续集成这部分设备端是有做起来的，但是 App 端这边尝试持续集成，但是暂时只能拿自己的电脑做服务器，接口类自动验证的话这个我倒是可以尝试一下，是需要写 pipeline 么？Jenkins 方面的还是有点模糊，我可以再看一下相关的内容，感谢

1. CI 流程我觉得可以做部分优化，但是这个可能也是需要开发合作
2. 接口自动化也是有考虑过，但是确实迟迟未给测试接口，并把测试限制很多，弊端很多，受开发的限制太多，特别时测试 leader 本身不是技术出身可能相对有点麻烦，很多开发都不愿意相信我们有能力去做，只觉得我们麻烦，测试的 leader 也是给我们分配各种手动验证的工作，真的想做点什么，等手工测试结束之后，已经晚上十一点了，实在是不明白，既然如此为什么要招两个懂开发的去做手工测试，而且面试的时候跟我确定是有自动化测试的架构跟代码，只是几个脚本。。
3. 新功能问题，很多情况都没有跟我们同步，直至要验证版本才知道有这方面的新功能，还是一句，很被动
4. 扯皮没办法，周会也不会听的，反馈了多次了，我只能每一处都验证确定好，再去跟开发对峙
5. 这个其实还好
6. 开发人也少，也不会配合我们去增加他自己的工作量的（毕竟我说我可以学，但是回复我的是他没有写文档的时间，没有这样的工作安排，好的吧，人微言轻）

很感谢你的回帖，我会参考好好做自己的准备，也会跟相关的 leader 去沟通，看看如何优化跟进这类型的问题，尝试去理解他们的通信协议，至少不让他们觉得” 说了你又不懂 “，这种情况还是很伤的

确实，已经就目前这个项目周期的测试做参考，规范了一下测试的流程，增加快速冒烟去检查开发的问题，规范测试的准入准入准出这个我不太清楚应该怎么进行；
构建体系是需要进行的，只能一步步积累，尽量不让自己陷入冗杂重复的测试任务（几乎前 3/4 个月都是这个状态）

所以说我们公司缺少一个有经验的测试开发带队，而我自己又经验不足，很多情况下都是想做但是没有权限没有话语权

嗯嗯嗯，所以现在想先把 A-S 端的自动化先确定好，虽然公司研发的老大老想让我一个人做 UI 自动化，黑盒自动化我真的不太想做，工作量大而且维护成本高，可使用的场景也不多

可能在我公司有点困难，相对，有点，专制，只看结果，不管过程；所以，害怕挨骂；测试的权力真的很少，而且每次觉得版本有问题，直接打回，然后让他再给我版本，再给的版本如果出现其他问题，开发会问上个版本有这个问题吗？有的话就会责怪我们为什么没测出来，然后因为各种小问题反反复复打版本；所以测试的时间一直被压榨

总结
接下来近期内（这一两个月）会继续尝试做的事：

1. 构建 App 端的持续集成，尝试将接口自动化接入集成中
2. 跟云端拿接口，尝试去实现接口自动化
3. 将稳定功能的 UI 自动化完成增加入每日测试的记录
4. 与相关的负责人讨论这方面的问题
5. 最重点的还是自己的学习积累，量变才能质变

十月有十天假期，感觉可能还是会有项目来打扰，加上老姐结婚，可能也没几天完整的；
十天假期希望能看完一门课，完成一个案例，读完一本相关技术书籍

可能是尽量不去想项目内的构建或是优化，更多是去看其它方面的，积累，或许不死盯着这一块可能看到的更广

我之前基于串口指令做了不少开关功能的验证，这个比较快速有效。UI 自动化不是不能做，还是放到最后去做吧

接口校验这个你可以参考下社区的一些帖子，基本是自己写程序校验的。校验这个事情可以放到 pipeline 里面，pipeline 是流水线步骤，本身是没有校验功能的，pipeline 是帮你运行你写好的程序。

A 端和 D 端怎么实现自动化呢。蓝牙协议的

UI 自动化的工作量和维护成本你们做过评估了吗？评估后或许你们会觉得可以接受呢！
可使用场景有多少你们做估算或统计了吗？如果真的不太多，那确实光点点点就可以了。

感觉我和楼主很像！我本身学的 web，现在是在公司物联网部门，职位是自动化测试，就我一个人，感觉很迷茫，不知道自己现在需要做什么。我本身是不参与软件测试的，看着其他测试每天忙的焦头烂额，我也很想参与，但是 leader 招我来的目的是做一些自动化工具和提升组内自动化。但是入职到现在就只做了一些工具。因为物联网的产品好杂，不知道从何下手提升组内自动化。之前在手机公司做过，产品和系统比较单一，流程很完善，有负责功能测试的，有测开、有接口测试、有 ui 测试。但是现在产品多且杂乱，流程也不是很完善，系统也很多（嵌入式、安卓、实时），自己接触的 自动化基本都是关于安卓相关的，好迷惘不知道如何下手，不知道自己下一步需要做什么了。

能留个联系方式吗，我也是物联网的测试，也迷茫，根本没有接口啊，都是单机片，552096884，楼主也加我个，交流交流