关于 QA 和自动化测试

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

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

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

---

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

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

---

现在前端流行 React 框架。React 把渲染层分离了，使得“页面渲染在内存，而不是浏览器”成为了可能。从而 React UT 可以变得很轻巧。

@testing-library/react 是 React 官方推荐的 UT 框架。但我认为 @testing-library/react 不仅仅是 UT 的框架，它会发展成产品端到端自动化测试的解决方案。因为：

• 测试脚本是在 node 环境中运行的。这样调用其他脚本，如环境初始化等脚本非常方便。
• 测试脚本的编写的内容也是模拟用户操作。
  如下方代码示例，模拟初始化加载和用户点击刷新。

it("loading & refreshing", async () => {
  render(<App />);
  expect(
    await screen.findByText(/apolis/i)
  ).toBeInTheDocument();

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

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

• 还没有人评论，欢迎说说您的想法！