这是一个创建于 2112 天前的主题，其中的信息可能已经有所发展或是发生改变。
有什么心得吗大家。我想在团队推进，但是小团队没啥经验。
网上的资料都太简单了。
网上的资料都太简单了。
 | 1 linvaux 2020-01-03 14:34:55 +08:00 via Android 前端的自动化测试？ |
 | 2 component 2020-01-03 14:38:17 +08:00 你说的应该是单元测试吧，不管是 vue 还是 react 都有相关文档啊，单元测试就是那么简单，只是很繁琐而已，你模仿写一个就知道了。 |
 | 3 cylmsun 2020-01-03 14:42:02 +08:00 katalon |
 | 4 Austaras 2020-01-03 14:42:35 +08:00 看 angular 文档 说真的，前端不管啥东西没有，都可以去看看 angular 怎么做 |
 | 7 dinjufen 2020-01-03 15:05:03 +08:00 我也在给 vue 项目做单元测试来着，但是写了几个感觉真麻烦，我甚至怀疑前端项目有必要测试吗 |
 | 8 userdhf 2020-01-03 15:07:57 +08:00  1 无代码测试，全凭领导极限操作。。 |
 | 9 KuroNekoFan 2020-01-03 15:17:51 +08:00 via iPhone 1 别吧，成本太高了，没必要 |
 | 10 as80393313 2020-01-03 15:28:45 +08:00 如果是一套组件库的话可以，就是项目里面几个小组件没必要吧？业务代码写单元测试前端有吗？ |
 | 11 nianyu 2020-01-03 16:38:02 +08:00 前端别搞自动化测试 |
 | 12 luozic 2020-01-03 16:40:19 +08:00 e2e? 前端这部分做主要有两个难点， 第一个资源问题（实际就是投入产出比问题）： 如果前端有分层，公用组件和接口层，业务层还可以抽出来搞搞，没有，搞个锤子的 auto，维护脚本和场景过程能让人罢工。 第二个就是 stable 问题： 前端喜欢短平快，粗糙猛的那种做 auto 一点意义没有，还不如好好学习一下怎么搞前端工程化组件化。 |
 | 13 wszgrcy 2020-01-03 16:58:35 +08:00 via Android 前端的写测试时间，我感觉基本上和代码开发时间相同。。。坑爹的是，如果业务变更，你的测试用例还要重写(前端变更的速度，可比后端快多了。。。。)，所以除了自己写一些开源的组件，其它的装不知道吧。。。要写就是再给一倍时间 |
 | 14 hantsy 2020-01-03 16:59:34 +08:00 单元测试方法前后都通用。Java 几乎离不开 JUnit 生态圈，前端比较杂，套路差不多。 前后分离，自动化测试，涉及到用户功能，必须想办法 Mock Backend API。 目前我接触到的可用的测试框架有 Spring Cloud Contract，Pact 等，即实践 Consumer Driven Contract （ CDC ）测试。 1. 首先定义好 API 的 Client （ API Caller，Consumer ）和 Server （ API Producer/Provider ）之间的 API Contract，这个 Contract 一般有多种格式可以定义，在 Spring Cloud Contract，Groovy/Kotlin DSL 是最常见的（也有 JSON，YAML 等）。Spring Cloud Contract 除了能够定义 HTTP 之间的协议外，对 Message Broker （ AMQP，Spring Cloud Stream ）也是支持，也紧跟 RSocket 协议（应该新版本会支持），但前端支持不是很好，官方有例子。 . 根据 Contract 自动生成 Stub Server Codes，可以供前端调用测试，那么前端就可以通过调用一个真实的 Stub Server 来完成测试。 3. 后端本身可以通过测试，验证 Contract，从而保持 API 前后端的一致性。 Pact 也类似，比较通用，各种语言（ Java，Ruby，Python，JS，等）支持都很好，有专门的 Pact Server, 可以可视化 Contract，缺点是 Message 协议不如 Spring Cloud Contract。 |
 | 15 lihongjie0209 2020-01-03 17:05:58 +08:00 测试这东西怎么说呢, 在需求稳定的情况下做吧, 这样代码接口都提前定义好. 如果需求经常变, 或者是项目开发初期还是不要做了, 你写测试的速度还没有需求变化的速度快, 更别提接口稳定了. 而且, 作为前端你如果考虑浏览器测试, 那就更是坑, UI 改版测试全报废. |
| 16 hantsy 2020-01-03 17:06:02 +08:00 @wszgrcy 这种“写测试浪费时间”的想法都是自欺欺人的。不写测试代码，难道就不用测试吗？ 手动测试一个功能可以重复上百次都愿意干，而把这个过程用代码写下来（测试代码，就是让它后面可以自动运行来检测变更问题），却各种借口，只有一个理由可以解释：懒。 如果不写测试，项目自动化基本都是空谈，基本不可以实现。 |
 | 17 ctro15547 2020-01-03 17:07:02 +08:00 变化速度快的 ui 类型自动化测试都不建议弄，成本太高了。想通过前端来测试后台倒是可以写些小脚本挂着，按键精灵就成 |
 | 18 enjoyCoding 2020-01-03 17:08:30 +08:00 前端测试主要分两个: unit 和 e2e. 个人认为 unit 对于 MVVM 的功能超级简单且鸡肋,只是测试一些常用的函数,因为元素由数据产生,所以只要对比数据就可以了,又因为是单元测试,可能会把每个函数拆开进行测试,这基本没可能会错...如果是测试驱动开发,那在写测试的时候就要考虑代码的主要构成,复杂性太高.... e2e 的话觉得还是不错的,但是跟 CI 兼容性并不好.... 可能作为从业人员我并没有了解到测试的重要性及其精髓 |
 | 19 ah64zzpk 2020-01-03 17:46:20 +08:00 @hantsy pact CDC 我用过，我们是用在微服务的各个后端 service 之间的 api 依赖上的，前端的 e2e 是个啥啊？ e2e 在我眼里就是 Ui 上输入，ui 上验证输出，那数据库后台服务都得有才行吧？ |
 | 20 lavvrence 2020-01-03 17:46:50 +08:00 我们前端除了会写 ajax 和 css 其他都不会。更别提 nginx、docker、测试、部署了。 |
| 21 ah64zzpk 2020-01-03 17:51:43 +08:00 @enjoyCoding 问问你这里说的 e2e 是怎么痒的一种测试？ Selenium? |
 | 22 randyo 2020-01-03 17:54:19 +08:00 via Android 页面每次都改，测试啥，每次都改测试用例，这跟手动测试有区别吗 |
 | 23 wan8140870 2020-01-03 17:59:30 +08:00 可以看下 testcafe |
 | 24 yuang 2020-01-03 18:00:25 +08:00 via Android 小团队就算了吧，吃力不讨好 |
| 25 hantsy 2020-01-03 18:05:52 +08:00 @ah64zzpk jest 本身不是有录制功能 snapshots 吗？前端如果还是围绕 PageObject 套路，应该容易的，直接调用 pact server 的 Contract API，在 CI 服务器集成测试时，切换到真实的 API 上去试。 |
 | 27 wangyzj 2020-01-03 20:25:02 +08:00 Selenium? |
 | 28 tyrealgray 2020-01-03 20:27:24 +08:00 webdriver + cucumber |
 | 29 zhw2590582 2020-01-03 20:31:47 +08:00 单纯测试组件还好说，一旦和业务逻辑混在一起，还真是不写好过写，太花时间不值得 |
 | 30 puilu 2020-01-03 20:44:42 +08:00 没搞过 |
 | 31 g0thic 2020-01-03 20:46:33 +08:00 还没测完 需求设计稿又改了？ |
 | 32 ayase252 2020-01-03 20:46:56 +08:00 用过 testing-library 写过一些单元测试，问题在于一些框架（说的就是 antd ）不按套路来，很难套进去测试。 |
 | 33 hive 2020-01-03 20:47:32 +08:00 cypress 就是写测试用例比较麻烦 |
| 34 hantsy 2020-01-03 20:59:41 +08:00 @g0thic 这个的确是问题，属于公司层面的。 国外项目中，都可以花一两个月去写一个 POC，把技术上想到的 Barriers 扫清，实现自动化。再转移到项目上，按步就班的开发，每个迭代周期免不了改动，一般不会推倒重来。 设计，需求的基本上是不会影响开发这个阶段的。做产品实际也要花大量考虑各种可能性，各种演练。如果一两个月下来，公司做产品设计的人还推倒重来的改动，这种估计没有哪个公司容得下。 |
 | 35 murmur 2020-01-03 21:03:19 +08:00 业务怎么做自动化测试。。谁告诉我一下，全业务跑一套比开发代码还累，框架都是别人的 |
 | 36 HuHui 2020-01-03 21:14:33 +08:00 via Android 伪命题 |
 | 37 Chingim 2020-01-03 21:18:20 +08:00 via Android 别。测 gui 成本太高了。 而且业务代码变动频繁 |
 | 38 orzorzorzorz 2020-01-03 21:22:52 +08:00 做产品可以落，先从 benchmark 开始吧，得给人看数据才能说得出话。做一套通用模板，然后在这基础上做个性化开发，这类倒是不用测试了，会有测试组背锅的。 |
 | 39 gouflv 2020-01-03 23:30:30 +08:00 via iPhone unit test 其实项目用到的不多，e2e 可以试试 cypress |
 | 40 charlie21 2020-01-03 23:36:41 +08:00 via Android 从开发看测试是根本性错误，应该从需求看测试，新需求自然需要新测试。测试虽然测的是开发出的代码，but 测试是按照 “新需求” 来做。不是按照 “新代码” 来做。你有了新需求 老的单元测试当然会报废一部分、留下一部分。否则养测试人员吃白饭的？ 测试和开发无关，其实测试甚至可以先于开发写好，这叫 test driven development TDD 按照 TDD ... |
 | 41 McContax 2020-01-03 23:38:06 +08:00 Javascript 没有用任何框架该怎么落地，jQuery，或者 vue.js 都没有用，学生阶段还没有什么实际大项目，求老前辈指点指点 |
 | 42 zhigang1992 2020-01-04 00:36:46 +08:00 Jest + Puppeteer |
 | 43 onfuns 2020-01-04 00:56:34 +08:00 via Android 前端页面业务组件没必要写单元测试吧？需求都做不完还有时间写测试？ |
 | 44 weixiangzhe 2020-01-04 09:35:44 +08:00 via Android 大家的意见是 utils 和组件 开启单元测试吗，有没有基于 pupeteer 的 自动操作记录工具呢，我其实最烦就是想表单这种东西每次都要输入一遍 |
| 45 enjoyCoding 2020-01-04 10:47:18 +08:00 @ah64zzpk e2e 翻译过来就是端到端,开浏览器程序模拟用户的操作,具体属于什么测试我也不太清楚,应该算到功能测试,黑盒测试里面吧. |
 | 46 Lfinesse 2020-01-04 11:06:12 +08:00 UI 组件上 storybook 业务项目用 Cypress |
 | 47 zhuzhibin 2020-01-04 12:02:18 +08:00 via iPhone 小团队 使用过 cypress 维护业务验收 总结就是业务如果变化频繁没啥意义维护 而且真的需要精力 |
 | 48 adspe 2020-01-04 13:30:28 +08:00 落不了 |
 | 49 undermoodzyx 2020-01-05 23:55:32 +08:00 核心 util 和通用组件上单测，业务组件真心难搞，费时费力又不讨好，表单的输入问题有很多解决方案 |
| 50 ah64zzpk 2020-01-06 22:19:07 +08:00 via iPhone @enjoyCoding 哦哦，那这个就需要后台也得起起来了，DB 啊啥的，就是 Selenium 那一套了，挺重的 |
 | 51 coloz 2020-01-09 00:06:16 +08:00 1 也是小团队之前也有这样的疑问，前端全用 ng 开发，ng 自带 spec.ts 做测试，从来没用过，在两个 ng 群里问了下，大家居然都表示，早已默认关闭 spec.ts 生成。 现在总结出的测试办法： 1.自己准备个测试后台，或者假数据后台测试。（写个路由加返回数据就行，比用 mock 做轻松多了，还不污染项目） 2.用 puppeteer 写自动点击脚本，按正常流程操作一遍，然后页面上能点的都无脑点，无脑输入，然后记录报错。（详尽的单元测试很费时间，不如点击，前端嘛，草率点就好，点不出来的问题，都不是问题） |
Select Language