软件测试应该注意的几大误解 软件测试
最近看了网络上所谓专家写的文章，发现了一些对TDD与QA部门的误解。本文将解释部分误区，并集中讨论QA团队要在敏捷的世界里获得成功所必须解决的一些问题。
对测试的误解
1. "你只需要做单元测试——TDD测试已经足够"
对于大部分商业开发来说，根本就没有这回事。即使是敏捷开发的强力拥护者也承认他们需要一系列的测试技术。
TDD程序设计人员需要这些测试来验证代码的正确性。如果需求(测试用例)解释错误，那么你构建的代码也将无法达到目标要求。
大多敏捷项目都会使用探索性测试方法(黑盒)来支持白盒测试，而不会认为这两种技术只能选一。优秀的探索性测试可以在开发地过于深入之前发现开发人员所忽略的问题。
2. "你可以重用单元测试来创建回归测试集"
有些TDD拥护者认为常规的下游测试(downstream testing)是多余的，因为每一行应用代码都有对应的测试用例;他们认为重用单元测试就可以做到用户验收测试和回归测试所能做到的一切。
这听起来挺有道理，但由于某些原因，这是不现实的：TDD中的白盒单元测试的粒度与目标与下游黑盒测试的目的是不同的。
虽然单元测试的整体目标是保证代码能够实现所需的功能，但是回归测试的目标是保证被改动的应用代码不会产生意料外的效果。这两个目标是不同的--比如，检查一项属性是否具有合法的日期格式，与检查输入域中是否存在所需的日期是不同的。
3. "开发人员可以用开源工具写测试，因此我们不需要测试人员或者自动测试工具了"
职业测试人员实现的是与其开发同僚不同但同样有效的作用。
人们普遍认识到传统的自动测试工具并不像供应商们炒作的那么有效。原始软件的源码和供应商的产品一样可以改善数据库测试环境下的效率。这是因为没有合适的工具可以提供用户界面测试，所以我们才把方案扩展到了这一领域;我们的传统是有效地实施测试而不是屏幕抓取自动测试。我们开发了测试驱动，是因为在过去的二十年里传统的供应商错过了这个机会。
通常，TDD项目的测试代码至少与应用代码一样多，因此其本身就是应用软件。这种测试代码是需要在目标应用的生命周期中进行维护的。
4. "有了单元测试就不需要手动测试了"
手动测试是一项重复性很强的工作;成本昂贵、枯燥并且容易出错。虽然TDD可以减少功能测试所需的手动劳动，但是它不能消除对黑盒测试(手动和自动)的需求。
通过自动抓取测试人员的过程并记录其键盘和鼠标动作，测试人员能够腾出更多的时间来进行更有意义、更有价值的活动，比如测试难以(甚至无法)自动化的复杂场景。虽然手动测试很费时间(因此也很昂贵)，但是如果因为不进行手动测试而漏掉一些错误，则通常意味着将来可能要付出更大的代价。
文章来源于领测软件测试网 https://www.ltesting.net/
