单元测试 – 何时进行单元测试vs手动测试
|
虽然单元测试对于需要工业强度的大型项目(例如.Net框架API的开发等)似乎有效，但对于小型项目似乎可能有些过度。
什么时候自动化TDD方法是最好的方法，什么时候更好只是使用手动测试技术，记录错误，分类，修复等。 另一个问题 – 当我是微软的测试员时，我们强调，开发人员和测试人员有不同的价值，这两个小组之间的紧张关系可以帮助创建一个伟大的产品。 TDD可以打破这个想法，并创造一种情况，开发人员可能不是正确的人，严格找到自己的错误？它可以是自动的，但是似乎有很多方法来写测试，并且一个给定的测试集合是否“证明”质量是可接受的是有问题的。
TDD的有效性与项目规模无关。我将练习
the three laws of TDD即使在最小的编程练习。测试不需要太多时间来写，并节省了大量的调试时间。他们还允许我重构代码，而不必担心破坏任何东西。
TDD是一种类似于会计师实行的双重记账纪律的学科。它防止在小的错误。会计师将每次交易输入两次，一次作为信用，一次作为借记。如果没有发生简单错误，那么资产负债表将总和为零。这个零是一个简单的点检，阻止高管去监狱。同样的，程序员在它们的代码之前编写单元测试作为简单的点检。实际上，它们将每个位的代码写两次;一次作为测试，一次作为生产代码。如果测试通过，两位代码是一致的。这两种做法都不能防止更大和更复杂的错误，但这两种做法都是有价值的。 TDD的实践不是真正的测试技术，它是一种开发实践。 TDD中的“测试”一词或多或少是巧合。因此，TDD不是良好测试实践的替代品，而是良好的QA测试人员。事实上，有经验的测试人员独立编写QA测试计划(通常在编写代码的程序员(及其单元测试)之前)是一个非常好的主意。 这是我的偏好(实际上我的激情)，这些独立的QA测试也使用工具，如FitNesse，Selenium或Watir自动化。测试应该容易阅读商务人士，容易执行，完全明确。你应该能够立即运行它们，通常每天多次。 每个系统还需要手动测试。但是，手动测试不应该死机。可以脚本化的测试应该是自动的。你只想在需要人类判断时将人置于循环中。因此，人类应该做exploratory testing，而不是盲目地遵循测试计划。 因此，对单元测试与手动测试的问题的简短回答是没有“对比”。你应该为你编写的绝大多数代码编写自动化的单元测试。您应该有由测试人员编写的自动化质量检查验收测试。你还应该练习战略性探索性手动测试。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |