从业5年，一直开发Windows平台上的程序，客户端为主，间或网络、驱动。对于测试总结出一些经验，自认为有助于提高开发生产效率，目前的感觉在30%左右。具体数据随着这些方法的使用逐渐清晰。也请参考这些方法的兄弟们参与讨论，指正或提出更好的办法，共同让程序员（当然也包括测试、客户）的生活变得轻松些。

每段先提出问题，再说下针对的测试方法。

第一，一个看似简单的模块往往需要超过预期的时间。我们来分析一下为什么，开发人员写代码时是正向思维，考虑的是如何实现功能，走通正常流程。自测不能考虑特殊情况，比如边界、用户习惯性、涉及网络时的延时、断网等。相信带过项目的人都有过类似经验，开发人员提交结果时，经常说我完成了，自测通过。实际上还是漏洞百出，只能作为原型。必须测试跟进，迭代几次之后才整体完工。有时是因为测试工作周期与开发不配套，导致开发等待测试（这里是时间浪费），等测试反馈结果后，开发重新熟悉整个流程（因为多数开发人员——无论公司规模大小——身兼数职，这时早把几天前的项目忘到脑后了）。结果造成基本模块开发时间过长。模块之于整个项目，就像细胞之于身体，每个细胞都有问题，身体怎么能轻松愉快呢？

再深入看一下时间到底花在什么地方。其实开发测试的迭代过程中，小问题，或者说很容易观察到、并且也很好改的问题居多，且占用了大量迭代时间，比如输入框字符数过多，突然断网崩溃等等。真正需要开发人员花精力和大块时间解决的问题，往往只占小部分。

至此，我们可以说，如果吃掉小问题占用的时间，完成一个模块的时间将缩短1/3（在测试周期与开发周期错位不太多的情况下）。那么怎么吃掉这段时间？我的方案是开发人员的test case。举个例子吧。

实现自动更新功能。看到自动更新，会想到什么？Web服务器上放版本文件，自动发现新版本，下载新文件，覆盖本地文件。差不多是这样了，哦，也许还要加上覆盖之前关闭占用文件的进程，不然会导致覆盖不了。这下功能齐全了，开工。3天以后，完成了。现在来看看测试同志发现了什么问题。

1.

可借用TDD，即Test Drive Develop（测试驱动开发）。结合实际，目前多数程序员还不太能接受这种做法。有时候TDD也不太容易操作，软件的大功能提前知道，但细微功能，比如操作，流程要等开发到一定程度才知道。

待整理。