我知道很多公司都有他们的测试部门，我问这个问题是因为我无法明确一些概念。
1，单元测试是否应该由测试部门/第三方企业完成？
对于我自己的感觉，我认为这应该由开发者自己完成。但有一种说法是：
您将倾向于以编写代码的方式测试代码。所以我们做单元测试更好。并且您不是专业测试人员，因此您无法确保您的单元测试是最佳的。
如果这是错的，有没有官方说过程序员应该自己进行单元测试？
2，尽管进行了单元测试，但测试部门还做了哪些其他测试？
这是一个简单的问题。也许有一些随机测试，一些压力测试，但任何人都可以给我一个测试部门正常工作的清单吗？
答案 0 :(得分：4)
虽然开发人员应该测试自己的工作（而且他们都做了，有些人只是使用效率低下的“run-test-last-change-fix-run-again”方法），但是有一个心理问题试图找到自己的错误：
如果你知道自己犯了错误，你可能会试图避免它。事后看来，通常很明显/很容易看到错误，但是当它发生时，这不是真的。因此，这会造成一种“失败者”的情况，即当你真正努力的时候，每个人都认为你是愚蠢的。
每个开发人员都有自己的错误模式;这就是每个人都一遍又一遍地犯同样的错误。有各种各样的原因，最重要的是盲目或不愿意承认自己的缺陷。
当你匆忙时，你开始偷工减料。这不错，这是人。问题是你的记忆已经满了你工作所需的所有细节。现在你的记忆表现会因压力而降低。这意味着您将忽略重要细节，而不会注意到 - 您的大脑已经在极限运作。你不会注意到你错过了它们。并且你不会记得你注意到的那些，因为你的记忆处于恐慌模式 - ＆gt;只有真正重要的（如生命危险）信息才会得到处理。
自我监视根本不适用于人类。你总是需要一个外部控制器，否则就会有腐败。
因此让别人测试你的作品是有意义的：
他们不会使用相同的模式（点击的位置，点击按钮的顺序，键入的速度，......）可以快速发现您自己找不到的简单错误，仅仅因为他们不在你喜欢的电脑使用方式之外。
他们的任务是让你的生活变得悲惨（简而言之）。如果老板值得他的钱，他将创造一个竞争环境，开发人员将尝试尽可能少的漏洞进行测试，而测试将试图找到尽可能多的错误“显示他们”（其中“他们”是另一个团队）。这非常有效（人类群体喜欢竞争），但你需要意识到工作中的心理力量。如果管理得不好，就会产生很大的压力（ - >更多的错误），倦怠和相互仇恨。如果老板不善于管理人类，那么将适得其反。
他们有不同的假设。他们没有编写代码，所以他们不知道它应该如何工作。他们会像顾客一样看待你的工作，看看开发人员永远不会关心的事情（“看起来很丑陋”，“反应不够”）。他们可以找到使产品更容易销售的问题。开发人员通常只关注“工作得很好”（=当我按照正确的顺序单击右键时不会崩溃）。
现在你的问题：
单元测试是否应该由测试部门/第三方企业完成？
没有。单元测试是可以在代码上运行但仍具有一定含义的最小可能测试。测试部门永远不应该运行那些，这是自动CI服务器的工作。这是适合计算机的愚蠢，乏味和重复的工作。
但让测试部门定义新的单元测试是有意义的。或者，测试中的错误报告应转换为新的单元测试。
尽管进行了单元测试，测试部门还做了哪些其他测试？
一些例子：
答案 1 :(得分：1)
我觉得好像程序员应该自己做了很多测试，但大部分都归结为功能测试。它是否按预期工作？
测试/ QA人员倾向于更深入地进行测试。来自安全背景，他们将确保所有输入都经过验证，并且没有任何东西容易受到SQL注入和CSS的攻击。此外，在不同团队构建不同成品的大型项目中，测试部门将测试成品，以确保在集成过程中不会出现错误，包括负载测试，各种情况下的安装测试和测试，不同的操作系统等。测试部门需要知道在每种情况下会发生什么，以便其他团队可以确定这是一个值得修复的错误，并让客户群知道这是一个已知问题或设计。
让我们看一下视频游戏。在视频游戏中，您通常会在设计环境中移动精灵。测试人员确保精灵在碰到任何墙壁时停止并在所有可能的墙壁上进行测试，以确保精灵没有任何剪裁问题。开发人员通常会对引擎进行编程并制作地图和交互，但除非向他们报告，否则不会关注查找单个剪辑问题。
答案 2 :(得分：1)
单元测试由负责编写代码的开发人员编写。它们基本上是编码器的用途。我使用它们来确保我提供给QA的代码没有内部错误，如NPE会停止测试（以及让我们看起来很糟糕）。任何项目都有不同的组件需要协同工作，单元测试可以确保各个组件按预期工作，并且它们的交互都按预期运行。
其他小组的测试侧重于研究产品行为的不同方面：
功能测试检查是否符合业务要求
系统集成测试检查程序是否在类似于生产环境的上下文中工作
加载测试检查程序在投入大量工作时是否会按预期运行
用户体验测试检查普通用户是否可以浏览用户界面。
有一个乒乓TDD的概念，其中一对程序员交替编写测试和代码，因此您可以从第二个人的角度获益。这可能是进行测试和获得即时代码审查的最佳方式，但它让管理层想到两名员工在单一任务上工作，因此很少有机会。即使没有它，程序员也会试图通过测试来破解代码。在我写这篇文章的时候，我宁愿打破我的代码而不是别人以后做的。