Merge pull request #132 from cncolder/patch-1

Fix typo

Author: goldbergyoni

readme-zh-CN.md

@@ -1340,7 +1340,7 @@ test('When no products exist, show the appropriate message', () => {
 
 ## ⚪ ️ 3.7 写几个跨越整个系统的端到端测试
 
-:white_check_mark: **建议:** 虽然 E2E (端到端) 通常表示在真实浏览器中进行 UI 测试(见 3.6)，但某些情况下，它们表示覆盖整个系统的测试，包括真正的后端。后一种测试非常有价值，因为它们涵盖了前端和后端之间的集成 bug，这些 bug 可能是由于沟通 schema 时产生误会导致的。它们也是一种有效的方法来发现 backend-to-backend 集成问题 (例如微服务 A 将错误的信息发送给微服务 B) 甚至检测部署失败，目前后端没有像 [Cypress](https://www.cypress.io/) 和 [Pupeteer](https://github.com/GoogleChrome/puppeteer) 友好的 UI 框架一样友好且成熟的 E2E 框架。这种测试的缺点是，配置一个包含如此多组件的环境的成本很高，而且大多数组件都很脆弱——假设有 50 个微服务，即使其中一个失败，整个 E2E 也会失败。出于这个原因，我们应该少用这种技术，大概1-10个就够了。也就是说，即使是少量的 E2E 测试也很有可能捕获它们所针对的问题——部署和集成故障。建议在与生产环境相似的预发运行它们。
+:white_check_mark: **建议:** 虽然 E2E (端到端) 通常表示在真实浏览器中进行 UI 测试(见 3.6)，但某些情况下，它们表示覆盖整个系统的测试，包括真正的后端。后一种测试非常有价值，因为它们涵盖了前端和后端之间的集成 bug，这些 bug 可能是由于沟通 schema 时产生误会导致的。它们也是一种有效的方法来发现 backend-to-backend 集成问题 (例如微服务 A 将错误的信息发送给微服务 B) 甚至检测部署失败，目前后端没有像 [Cypress](https://www.cypress.io/) 和 [Puppeteer](https://github.com/GoogleChrome/puppeteer) 友好的 UI 框架一样友好且成熟的 E2E 框架。这种测试的缺点是，配置一个包含如此多组件的环境的成本很高，而且大多数组件都很脆弱——假设有 50 个微服务，即使其中一个失败，整个 E2E 也会失败。出于这个原因，我们应该少用这种技术，大概1-10个就够了。也就是说，即使是少量的 E2E 测试也很有可能捕获它们所针对的问题——部署和集成故障。建议在与生产环境相似的预发运行它们。
 
 <br/>