这是一个创建于 731 天前的主题，其中的信息可能已经有所发展或是发生改变。
比较好奇，后端不管是单元测试还是集成测试这都比较好理解，查看输入对应的结果就是了，但是前端显示的是 gui 页面，这东西又该怎么量化呢？难道要测特定情况下页面显示的图像跟期望是否符合？
 |
1
Pichai 2022-04-25 21:24:37 +08:00
GUI 一般都是产品验收的工作吧！
前端获取后端的数据，解析数据显示其返回的内容，内容返回错误，给出响应的提示。 表单长度来说，前端做校验，如果不符合要求，就不会向服务端发送请求，减少了服务端的压力。 |
 |
2
zcf0508 2022-04-25 21:29:12 +08:00 via Android
端到端测试
|
 |
3
cdd2zju 2022-04-25 21:50:56 +08:00  4
这个我之前回答过我们前端测试同学的疑问，笔记如下：
我司的前端测试职责 - 测试用例编写：根据业务场景和特性需求，编写测试用例，一般用 excel 描述清楚特性、场景、分级、预期结果等关键信息，并通过开发或架构师的 review 评审。 - 测试框架的单元测试 code：懂一些前端的测试，可能会需要负责[[mocha]]、[[jest]]等测试框架里面的单元测试的编写。一般基础的框架需要这种测试粒度，而快速迭代的业务，可能没这个成本写单元测试。 - 自动化 E2E 用例编写和执行：一些基线用例，门槛用例，用[[Selenium]]、[[Playwright]]进行端到端自动化测试。快速迭代的页面一般归类为高级别低频率测试用例，需要具体分析，要进行自动化用例的成本和收益的评估。 - 手工用例：自动化不能满足的某些场景；经评估，手工测试成本更低的一些复杂用例。 - 压力测试：前端的测试，一般就是造大量假数据，对 js 代码本身进行渲染性能测试，比如首屏加载速度，1 万行的表格的加载速度等等，一般能顺带测试到一些 api 是不是可靠，性能够不够。还有一些混沌测试之类的，有能力的可以搞一搞。 - 用户体验测试：有能力和话语权的前端测试，可以提出用户体验等方面的独特见解。 - 对类生产环境负责：保证类生产环境和生产环境的一致性，避免类生产的问题流到现网。大特性的版本，需要测试负责人出具测试报告（更多的是综合的，包括前端功能和各项特性，还是看上线的特性是什么）后，才能上线现网。相当于给 SRE 之前，在加一把可靠锁。bugfix 版本，也需要前端测试简单测一测，多一个保障。 总体而言，前端测试一般都是手工用例居多，所以技术含量偏低，一般都请外包员工来做以降低成本。有上进心的前端测试，一般不会满足于机械地页面重复点击，会在自动化测试、压力测试、环境管理等方面走出一条自己的路，给自己定义成综合测试，而不是局限于前端测试。 |
 |
4
chairuosen 2022-04-25 21:59:19 +08:00
测试不了最终显示效果，但可以测试一个绝对可靠的中间产物，比如浏览器环境的 dom ，客户端的 view ，或者框架的 virtual dom
|
 |
5
rioshikelong121 2022-04-25 22:47:18 +08:00
|
 |
6
ChefIsAwesome 2022-04-25 23:39:35 +08:00 via Android
你写框架，写工具库，反正各种跟界面没关系的东西，可以用代码测。真正到界面的部分，也就是大部分人每天工作的内容，只能人工测。
道理很简单： 1.输入难模拟。你只能用浏览器机器人录操作。录的结果本质上就是 HTML 结构和事件。界面一变，这录的操作就得变。 2.输出难判断。通过代码只能判断 HTML 对不对。截图只能看到瞬间的效果。动画效果对不对，会不会有不想要的滚动条出现，正在输入的输入框会不会失去焦点，拖拽操作会不会卡住，各种各样只能人去判断的问题。 |
 |
7
a62527776a 2022-04-26 11:16:16 +08:00
非界面的输入输出测就行
|
 |
8
renhou 2022-04-26 11:25:35 +08:00
看一下 jest.js （单元）和 cypress.js （ e2e ）这两个测试框架就知道是测啥了
另外在加一些压力，兼容性，多设备的测试 |
Select Language