这是一个创建于 1238 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如测试数据生成和管理、自动化测试框架和语言绑定等这些大方面的困难。
 |
1
js8510 2021-07-02 10:27:25 +08:00
你这个问题大的可以写本书。个人经验，遇到的最重要的困难是：
获得并维持开发者对测试的信任和信心 具体的技术问题都会有答案，就这个是一个负责大型项目自动化测试的 tech leader 最重要的任务 |
 |
2
lzz120 2021-07-02 10:38:02 +08:00
理解 PO 的真实意图
|
 |
3
Vegetable 2021-07-02 10:40:04 +08:00  4
最大的困难是 deadline
|
 |
4
Jooooooooo 2021-07-02 10:55:34 +08:00 1
最困难的是随着业务迭代, 谁去不停的维护里面的用例
自动化测试一般都是覆盖业务全流程的, 这得专门有人定时跟踪正在变更迭代的需求 有大的架构变更用例有可能得重写, 这个成本怎么考虑? |
 |
5
balabalaguguji 2021-07-02 10:58:23 +08:00
我有录制过一个视频讲解自动化测试，可以看看有没帮助 https://www.bilibili.com/video/BV1nh411974p?p=8
|
 |
6
ctro15547 2021-07-02 11:14:59 +08:00
困难在于项目没在稳定期， 时间人力耗费成本很大，单独分几个人去写又划不来；一般会写写接口测试，app 性能测试，保证基础功能（不容易改动）的可用性；大部分 UI 自动化，我是用来辅助功能测试的，成熟的项目上也会用 ui 自动化来代替部分基本功能检查
|
 |
7
paradoxs 2021-07-02 11:16:49 +08:00
最大的困难在于：
老板：我们花了那么大的成本组建自动化测试团队，现在软件还是有 BUG ？你要怎么解释？ |
 |
8
wangkun025 2021-07-02 11:18:15 +08:00
你这么一说，造原子弹也没什么困难啊
|
 |
9
Mark24 2021-07-02 11:41:24 +08:00 1
困难来自于变化吧。
连描述的业务代码都在天天变。 想在变化的东西上测试，你也得变。变来变去。还不如不测。能用就行。这是困难。 |
 |
10
7gugu 2021-07-02 13:26:44 +08:00 via iPhone
懒得写测试用例就是最大的困难吧🤷♂️
|
 |
11
jorneyr 2021-07-02 13:27:58 +08:00
超级耗时间。
|
 |
12
ayase252 2021-07-02 13:35:27 +08:00 via iPhone
😅偏见吧
|
 |
13
dilu 2021-07-02 13:47:00 +08:00
钱
|
 |
14
dayeye2006199 2021-07-02 15:08:37 +08:00
我在公司看到过的几个神奇的自动化测试管理工具
一个工具会侦测下游被你代码影响到的部分，交 pull request 的时候除了你自己写的测试，还会把那部分测试也跑一遍 一个工具会侦测哪些测试已经失效，会自动暂停这部分有问题的测试 感觉这些工具都不是标准工具，但是对管理大量自动测试非常的重要 |
 |
15
DD0a48YwCzYUCQ8y 2021-07-02 20:38:20 +08:00
插个眼，等大佬进
|
 |
16
linvaux 2021-07-03 11:46:10 +08:00
- 普通测试：自动化测试好啊，学完一波跑路，美滋滋
- 测试开发：自动化测试好啊，写完一个框架 /平台跑路，美滋滋 - 高级测试：自动化测试好啊，让普通测试写用例，我点一下就能跑，美滋滋 - 测试 leader：自动化测试好啊，今年 pbc 知道怎么写了 - 老板：都有自动化测试了，为啥产品还是有 bug ？ |
 |
17
iEverX 2021-07-03 18:21:57 +08:00
@dayeye2006199 #14 怎么判断的呢，粗想一下感觉很难
|
 |
18
hugo54 2021-07-03 23:11:42 +08:00
@dayeye2006199 这是加了静态调用分析了
|
|
19
hugo54 2021-07-04 00:22:43 +08:00 1
* 开发不能保证接口文档交付时间和质量，测试整体工时被压缩
* 写自动化 case 成本比手工测试成本高很多，受限于 deadline 不愿意写（哪怕自动化测试基础设施已经很完善） * Case 管理和维护成本大 |
|
20
dayeye2006199 2021-07-06 13:06:14 +08:00
@iEverX 具体的原理我也不太清楚，但是公司有几个比较特别的代码管理方法，导致了做这类工具的可行性，应该不是每个企业都适用：
1. 采用了 monorepo 管理代码，所有代码全在一个 repo 里。 2. 采用了 bazel/buck 这样的模块化编译工具。所以代码之间的依赖关系可以通过解析 bazel 的文件得到。 |
Select Language