没有自动化测试的应用应该如何测试？

敏捷推荐围绕应用建立足够的单元测试和验收测试，以构建足够强壮的测试套件。然而，实际情况是：不是所有的应用都有配套的测试套件。敏捷测试讨论组中有一个有趣的讨论，提到如何为没有任何自动化测试的应用进行测试，成员们提出了多种方法。

Asad Safari发起了这个讨论，他说他的一个应用没有任何测试，团队中的开发人员不熟悉单元测试，距离截止日期也只有3个星期的时间供团队测试。他希望得到一些建议，指导如何在这样的约束条件下测试。

Phlip回应道：他曾多次处于类似环境，并推荐以下建议：

• 加入一个可选模块，能够通过任意或是指定的输入来驱动应用；
• 向程序中加入日志，把错误信息和断言存入日志文件中；
• 编写一个大单元测试，调用你所有的程序，提供前面提到的输入，然后梳理日志；
• 编写一个大的断言，在其中指出日志应该没有任何错误；
• 现在开始一个一个排错。每次去掉一个错误，去掉对它的异常处理。

Phlip指明：在这个大测试保护伞之下，如果时间允许，团队可以开始编写小规模的、目的更明确的测试。他还指出：虽然团队可以在接下来的三个星期等待上面的做法产生效果，编写和运行更小的单元测试应该马上开始。

Adam Sroka同意Phlip的建议，并补充道：

没错，很多团队碰到质量低劣的代码时，会放慢速度，产出的价值也会减少，而这对于质量没有任何好处。我们需要更实用的解决方案……如果没有从一开始就加入测试，那么就很难完全把测试做好，这是没问题的。但是就此认为测试没有价值，这是错误的看法。测试虽然不完美，但仍有其价值所在。

Brian Spears却没有被他们说服，他认为敏捷不是魔法，在三周时间内恐怕没法产生什么好解决方案。他说：

敏捷不是魔法，对这种紧急情况的解决方案，如果有的话，就是要投入很多很多时间，这明显不是敏捷的做法。

Adam反对这个看法，指出有很多团队如果进入类似境况，都采用了敏捷。这是团队变得有实效的机会，也是让软件变得更好的启动之旅。

Annette认为：这种情况最应该做的就是用很多很多时间做手工测试，因为到了这个阶段，自动化测试就太费时间了。推荐从重要的和与收入相关的功能开始测试。Annette也推荐了Lisa Crispin和Janet Gregory合著的Agile Testing一书。

Charles Bradley提出了类似的建议，不过他指出还要获得一个有条件的承诺。他说：

你的时间很有限，所以从业务角度来看，将ROI最大化是最佳选择。就使出吃奶的劲头做手工测试吧！但是要从你的老板那里得到承诺：他们无论如何也不会再让你的团队这么做了……他们应该先规划好时间和金钱完成自动化测试……着手下一个发布工作时就应该马上开始，甚至更早，比如开始修复当前版本的bug时。

因此，编写完整的测试套件，也许不是最适合当前情形的做法，团队最好开始手工测试。而这并不能削弱在一有机会时就编写适当的测试套件的做法。正如Jonathan Rasmusson指出的：

你所能做的就是修复bug，然后在上线之前尽一切可能完成手工测试。这就是你到这个时候还能做的事情。更大、更重要的问题，是你在三周截止日期到达之后要做什么。