我相信认真看过社区内帖子和回帖的测试行家心里知道，目前还存在很多同行，对业务测试也好，自动化测试也好，都可能存在一些认知上的误区，而且这种误区会像病毒一样传播，我觉得作为一名热爱测试的人，有责任站出来普及一些常识性误区。

关于 QA 和 QC 的区别

现实情况有很多人会把 QC 也理解成 QA，我人微言轻就直接引用网上的定义：Quality Assurance vs. Quality Control。可能接触过 CMMI 的同行对两者的区别有更深的体会。我的理解是：QA 是整个软件生产过程的执法者，对整个过程的质量体系负责，偏管理但又必须懂技术；QC 是为检验产品而实施的具体的产品测试活动，包括业务测试、自动化测试等。
为了更容易理解，举个例子：一家生产精密仪器的制造商，制定了一套确保生产质量的流程规范，各个生产、装配环节必须严格遵守，确保这个流程规范按既定执行的角色就是 QA。还是以这个例子为例，流水线最后精密仪器制造出来了，要有人去检验其是否能按设计标准正常工作，这个角色就是 QC。

自动化的目的是什么

我看到一些回帖在解答提问者疑惑时竟然多次提到 “自动化测试的目的不是为了发现 Bug”，他们可能也是受到了一些加精文章的影响。其实，仔细想想，这个概念是不值得推敲的，自动化测试是执行测试的一种手段，那测试的目的是什么？也许我的理解还不够到位，但至少包括以下几点：

• 把测试从枯燥的重复劳动中解放出来，例如：回归测试等；
• 协助手工测试完成很难模拟或无法模拟的的工作，例如：篡改服务返回的数据验证前端对各种数据场景的处理，弱网模拟、特殊协议数据包解析验证等；
• 尽早发现 Bug，例如：数据层的存储过程、Package 批量调用验证、接口自动化等偏底层的问题；
• 协助定位问题，现在的自动化提出了更高的要求，例如：接口层发现问题了，可以通过添加的 traceID 定位到日志错误或错误代码行，app 运行中异常可捕获错误日志等；
• 线上监控报警，现在的自动化不仅限于线下，线上的也已覆盖，测试和运维的工作可能存在交集，我们不能把质量问题寄托于他人，一旦发现问题，让损失到最小。
• 提高工作效率，这个面有点广，例如，测试环境的自动化编译、打包、部署、持续集成甚至持续交付等

关于测试用例的理解

我在一篇文章中看到，把测试用例设计定为初级阶段，这绝对是技术至上的一种偏见和对测试用例的一种无知。敏捷可能对测试用例有弱化，但这和测试用例设计属于何种阶段是两码事，在传统企业，测试用例的设计好坏会直接关系到产品质量。即便是敏捷也会有简化的测试用例，其设计好坏也直接影响到测试盲区。所以说，测试用例设计的质量好坏，直接能反映出设计者的测试功底、技术功底、测试经验。