这个我之前回答过我们前端测试同学的疑问，笔记如下：
我司的前端测试职责
- 测试用例编写：根据业务场景和特性需求，编写测试用例，一般用 excel 描述清楚特性、场景、分级、预期结果等关键信息，并通过开发或架构师的 review 评审。
- 测试框架的单元测试 code：懂一些前端的测试，可能会需要负责[[mocha]]、[[jest]]等测试框架里面的单元测试的编写。一般基础的框架需要这种测试粒度，而快速迭代的业务，可能没这个成本写单元测试。
- 自动化 E2E 用例编写和执行：一些基线用例，门槛用例，用[[Selenium]]、[[Playwright]]进行端到端自动化测试。快速迭代的页面一般归类为高级别低频率测试用例，需要具体分析，要进行自动化用例的成本和收益的评估。
- 手工用例：自动化不能满足的某些场景；经评估，手工测试成本更低的一些复杂用例。
- 压力测试：前端的测试，一般就是造大量假数据，对 js 代码本身进行渲染性能测试，比如首屏加载速度，1 万行的表格的加载速度等等，一般能顺带测试到一些 api 是不是可靠，性能够不够。还有一些混沌测试之类的，有能力的可以搞一搞。
- 用户体验测试：有能力和话语权的前端测试，可以提出用户体验等方面的独特见解。
- 对类生产环境负责：保证类生产环境和生产环境的一致性，避免类生产的问题流到现网。大特性的版本，需要测试负责人出具测试报告（更多的是综合的，包括前端功能和各项特性，还是看上线的特性是什么）后，才能上线现网。相当于给 SRE 之前，在加一把可靠锁。bugfix 版本，也需要前端测试简单测一测，多一个保障。

总体而言，前端测试一般都是手工用例居多，所以技术含量偏低，一般都请外包员工来做以降低成本。有上进心的前端测试，一般不会满足于机械地页面重复点击，会在自动化测试、压力测试、环境管理等方面走出一条自己的路，给自己定义成综合测试，而不是局限于前端测试。