前端测试

#评论/v2ex

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