何时进行单元测试与手动测试

虽然单元测试似乎对API需要具有工业实力的大型项目(例如.Net框架API的开发等)有效,但似乎可能对小型项目有点过分.

什么时候自动TDD方法是最好的方式,什么时候可以更好地使用手动测试技术,记录错误,分类,修复它们等.

另一个问题 - 当我在微软的测试人员时,向我们强调,让开发人员和测试人员成为不同的人是有价值的,并且这两个群体之间的紧张关系有助于最终创造出一个伟大的产品.TDD可以打破这个想法并创造一种情况,开发人员可能不是严格找到自己错误的合适人选吗？它可能是自动化的,但似乎有很多方法可以编写测试,并且一组给定的测试是否"证明"质量是否可接受是值得怀疑的.

TDD的有效性与项目规模无关.即使是最小的编程练习,我也会练习TDD的三个定律.测试不需要花费太多时间来编写,并且它们节省了大量的调试时间.它们还允许我重构代码而不用担心破坏任何东西.

TDD是一门类似于会计师实行的双重记账规则的学科.它可以防止小错误.会计师将每次交易两次; 曾经作为信用卡,一次作为借记卡.如果没有做出简单的错误,那么资产负债表将总和为零.零是一个简单的抽查,以防止高管入狱.

同样,程序员在代码之前编写单元测试作为简单的抽查.实际上,他们将每一位代码写入两次; 一次作为测试,一次作为生产代码.如果测试通过,那么两位代码是一致的.这两种做法都不能防止更大和更复杂的错误,但这两种做法都是有价值的.

TDD的实践并不是一种真正的测试技术,而是一种开发实践.TDD中的"测试"一词或多或少是巧合.因此,TDD不能替代良好的测试实践和良好的QA测试人员.实际上,让经验丰富的测试人员独立地(并且通常在编程代码)编写代码(以及他们的单元测试)之前编写QA测试计划是一个非常好的主意.

这是我的偏好(实际上是我的热情),这些独立的QA测试也是使用FitNesse,Selenium或Watir等工具自动完成的.测试应该易于商务人士阅读,易于执行,并且完全明确.您应该能够立刻运行它们,通常每天多次.

每个系统也需要手动测试.但是,手动测试永远不应该死记硬背.可以自动编写可以编写脚本的测试.你只想在需要人类判断时把人放在循环中.因此,人类应该进行探索性测试,而不是盲目地遵循测试计划.

因此,对于何时进行单元测试与手动测试的问题的简短答案是没有"对比".您应该首先为您编写的绝大多数代码编写自动单元测试.您应该具有由测试人员编写的自动化QA验收测试.您还应该进行战略性探索性手动测试.

单元测试不是要替换功能/组件测试.单元测试非常集中,因此它们不会影响数据库,外部服务等.集成测试可以做到这一点,但是你可以让它们真正集中精力.最重要的是,在具体问题上,答案是他们不会取代那些手动测试.现在,自动化功能测试+自动化组件测试肯定可以取代手动测试.这将取决于很多项目及其实际做法的方法.

更新1:请注意,如果开发人员正在创建自动功能测试,您仍然希望检查那些具有适当覆盖范围的内容,并根据需要对其进行补充.一些开发人员使用他们的"单元"测试框架创建自动功能测试,因为无论单元测试如何,他们仍然必须进行冒烟测试,这真的有助于自动化:)

更新2:对于小型项目,单元测试不是过度杀伤,也不是自动化烟雾测试或使用TDD.什么是矫枉过正是让团队第一次在这个小项目上做任何这样的事情.做任何这些都有相关的学习曲线(特别是单元测试或TDD),并不总是一开始就完成.你也希望有人在一段时间内参与其中,帮助避免陷阱并克服一些编码挑战,这些挑战在开始时并不明显.问题是团队拥有这些技能并不常见.