设计场景 也就是用例，其实需要很多测试基础理论支持。 正常走一遍流程只是开发思维而已。

您可以从以下概念着手：

单元测试 - 集成测试 - 系统测试

功能/非功能/接口

功能：可见不可见，输入，处理，输出。
非功能：iso9126
接口：用户接口/软件接口/硬件接口

对于具体用例设计，可以参考黑盒 11 种测试方法：
比如：等价类 - 有效/无效，边界值，
判定表，正交，流程图，场景法，状态迁移，输入/出域覆盖，错误猜测法，异常分析法，因果图法

其中每种方法都博大精深，内含多个技术概念。

然后额外再学习下：
单元测试的五种逻辑覆盖法，集成测试的 自顶向下，自下而上，大突击，三明治，阿尔法贝特验收测试等方法。

等全都学完了，估计你就明白怎么设计这种场景了

不知道楼上有没有审题

我感觉楼上的回复大体是对的。要看你实现自动化的目的是什么，只做冒烟回归，那就设计基础场景的用例覆盖就好了把。如果你要实现全覆盖的场景，那就参考手工的测试用例，哪些可以实现自动化就尽量实现。看楼主的意思，写的手工用例只覆盖了正常流程的处理场景，说明用例覆盖不全

自动化场景怎么设计？那你写自动化是为了回归，究竟是回归什么尼，是想所有 ui/case 都去回归吗，还是单纯为了 kpi？不要为了自动化而自动化。。。

比较好奇，自动化的场景一般是从原有的回归用例里提取的，场景设计应该在整理回归用例的时候就做完了。如果回归用例的场景设计没做好，那就补充回归用例的场景好了，和自动化没太大关系。

如果你说的是不知道哪些回归用例该自动化，可以考虑从优先级高到低排序，先做优先级高的。优先级定义就是如果线上出现用例对应场景不通过的情况，会造成多严重的故障。故障越严重，用例优先级越高。一般情况下，正常场景优先级是最高的，所以你现在这么做也没啥不对的。