这是一个创建于 1785 天前的主题，其中的信息可能已经有所发展或是发生改变。
有什么心得吗大家。我想在团队推进，但是小团队没啥经验。
网上的资料都太简单了。
网上的资料都太简单了。
 |
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 协议（应该新版本会支持），但前端支持不是很好，官方有例子。 2. 根据 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
jaylee4869 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
lbyo 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