问谁是测试人员？

EN

“测试人员”一词适用于所有从事略有不同工作的各种职业。测试人员的共同点是他们

• 试着破解你刚刚写好的漂亮代码。
• 查找边缘情况和需求之间的意外交互
• 提供自己的、独立的、不受影响的需求解释。
• 注意系统的意外和/或不舒服的反应。

一些测试人员是：

• 测试自动化工程师是测试人员之下的“程序员”。他们通常用各种语言编写脚本，以便在系统上执行自动化测试。通常，系统作为一个整体被测试为一个黑匣子，但是有时测试脚本更多的是在一个集成或单元测试级别上与一个白盒系统。
• 测试工程师编写的“测试脚本”意味着手工执行，或者由自己或者手动测试人员执行。这些脚本应该基于以前报告的需求和/或问题。
• 手动测试人员主要执行(手动)测试脚本，并作为一种强大的用户在系统中进行操作。

传统上，测试人员不需要编程知识，任何需要它的测试(例如单元测试或集成测试)都属于程序员的范围，只有当您不需要编程工具与被测试的系统交互时，测试人员才会出现。

有了测试自动化，测试人员可能会深入到代码中，但他们不太可能开始与程序员一起工作，因为这会过多地损害他们对需求的独立看法。这种独立的观点是重要的，因为它将带来毫无根据的假设和不明确或不明确的要求更早地被揭露。

我真的看不出这有什么用。我希望我能告诉他们我编码了什么，他们只会写测试。

那可不是你所生活的世界。此外，并不是所有的事情都可以在自动化测试中完成。此外，“手动测试人员”通常比开发人员拥有更好的领域知识。听他们的话，你可能会学到一些关于为什么你的系统有你要实现的需求的东西。

我还见过一些优秀的软件开发人员是科技公司(谷歌、微软等)的测试人员。为什么这些开发人员想成为测试人员？他们的开发人员技能真的被使用了吗？如果是的话，怎么做？

他们通常有“软件工程师在测试”或类似的职称。是的，他们的开发人员技能被用于编写测试，就像您在编写应用程序时一样。为大规模系统建立测试基础结构本身就会导致复杂的测试系统。

我认为这里的问题是，您混淆了特定的测试子集“单元测试”和被普遍接受为“测试”的大得多的测试集。

单元测试通常由编程团队自己完成。它可以是手动的，但通常使用自动化测试框架(如Junit )。

一般来说，测试团队并不关心单元测试，唯一的工作就是测试系统是否符合规范。他们不需要知道它是如何构建的，哪些语言框架是使用etc.etc的。以确定它是否有效。

除了单元测试之外，测试分为几类：

• 烟雾测试--启动系统，看看它是否能持续运行一天。
• 功能测试--程序是否按照规范的要求执行。
• 集成测试--程序在更大的环境中与其他组件一起运行良好吗？
• 非功能需求--程序是否满足规范中的任何NFR(响应时间、吞吐量、硬件要求、内存足迹等)
• 用户接受测试--让真正的用户使用它，确认系统是可用的，并做业务发起人真正想做的事情。

几乎不可能在不引入bug的情况下编写代码。更糟糕的是，正确指定模块几乎是不可能的。

所以，除非你的名字是“比尔喜悦”，否则你将在编码时引入bug。即使您的代码精确地用于规范完成的模块，也可能是错误的。

我所认识的所有优秀程序员都相信程序中充满了未被发现的bug，并知道在那些心里知道他们有多小心，他们就会做错事。边缘情况可能是正确编码的噩梦(如果循环执行n次或n-1次)。接口规范可以是完整的和模棱两可的；您可以读取文档，但是您真的不知道调用API时会发生什么。

测试是软件开发过程的基础，如果50%的项目时间没有用于各种类型的测试，那么代码在部署后很快就会失败。失败可能是微不足道的，可能是令人尴尬的，也可能是灾难性的。

所以要学会爱你的测试员！当他们发现窃听器时要高兴，他们刚刚救了你的命！