现在流行叫 QA，而不是测试。这是因为大家意识到：保证软件质量，仅仅靠编码完成后的测试是不够的，从需求分析、设计阶段开始就要严格把关。QA 的职责从之前的“编码完成后测试”延伸到软件开发的全过程。

参与了全过程的 QA，不仅对测试工作更有把握，还能提出产品方面的建议、制定有效的项目计划、找出开发设计存在的问题。例如：

• 功能是不是过度设计了？用户只要 XX 就够了。
• 在什么时间点合代码？
• 这样的表结构，功能满配的情况下，数据量是多少？这样规模的数据，用这样的算法操作，是否影响系统性能？

---

现在流行敏捷开发，为了保证质量和速度，测试的工作需要向自动化发展。因此 QA 又多了一项任务：编写端到端自动化测试脚本。

这种端到端自动化测试脚本，编写、调试体验很差。打开一个浏览器，模拟用户在网页操作，速度很慢，盯着看让人心急。但编写、调试阶段你还不得不盯着看。其实前端开发更了解元素定位，更清楚用什么定位方式更可靠，但因为编写效率低，影响开发进度，这个工作一般都是 QA 来做。

---

现在前端流行 React 框架。React 把渲染层分离了，使得页面不渲染在浏览器，而渲染在内存中成为了可能。这样 React 的端到端测试可以变得更轻巧。

@testing-library/react 是 React 官方推荐的 UT 框架。但我认为 @testing-library/react 不仅仅是 UT 的框架，它会发展成未来产品端到端自动化测试的解决方案，因为它的编写方式也是模拟用户操作。

test("loading&refreshing", async () => {
  hsfetch.mock([{ name: "apolis" }]);
  render(<App />);
  expect(
    await screen.findByText(/apolis/i)
  ).toBeInTheDocument();

  hsfetch.mock([{ name: "kzhang" }]);
  user.click(
    screen.getByRole("button", {
      name: /refresh/i,
    })
  );
  expect(
    await screen.findByText(/kzhang/i)
  ).toBeInTheDocument();
});

我理想的样子是：QA 和前端开发共同实现产品的端到端自动化测试。QA 设计测试用例、搭建测试环境、提供用于测试环境数据初始化的脚本；前端按照 QA 设计的测试用例编写自动化测试脚本，自动化测试脚本中会调用 QA 的数据初始化的脚本。