欣赏软件功能测试之美

　　欣赏软件功能测试之美  软件测试

　　自动化测试功能测试之乐:

　　功能测试定义了产品的业务需求，通过它业务人员可以了解系统是否能在各个业务场景下正常工作。功能测试通常使用某种自动化测试框架编写，这样开发者可以从自动化的功能测试中获得快速反馈，为下阶段新功能的开发或软件内部实现的重构提供帮助。另一方面，它大大减少了手动环节可能引入的错误，而将枯燥的回归测试交给机器完成，在加快测试速度的同时，将质量保证人员解放出来，从而使他们可以更多地关注于创造性的探索测试。通过从用户角度进行的功能测试，团队对系统在真实条件下的可用性充满信心，而自动化的功能测试也大大提高了工作效率。这样一来，产品能以更高的质量，更快的速度进入市场。

　　功能测试之苦:

　　* 保持验收条件及其技术实现的同步

　　在任何开展自动化功能测试的敏捷开发团队中通常会存在两套系统、 一套是BA(业务分析师)\QA(质量保证人员)所编写、维护的验收条件，可能以纸卡、Wiki等形式记录下来。另一套是验收条件的技术实现。以源代码的形式记录，由开发者维护。两套系统的并行发展，带来了同步的问题。如何快速将验收条件转变为技术实现?当验收条件变化时如何使源代码部分同步变化?可不可以将验收条件与测试关联起来，利用Rspec的思路消除这个并行的系统?

　　* 无法系统化的划分测试

　　速度是阻碍频繁运行功能测试的主要原因。进行功能测试的团队常常花费数十分钟甚至数小时来运行完整的功能测试套件，加快测试几乎总以失败而告终，从用户角度进行业务场景的测试决定了功能测试的速度天生就是缓慢的。随着软件功能的日益完善，更多的测试被添加到套件中，庞大的套件也使得测试运行的时间越来越长。无法快速得到反馈使团队没有安全感，同时大大减缓开发的脚步，烦躁的开发者甚至开始逃避运行测试，将不安全的代码集成到产品中。

　　只运行相关的测试，听起来这似乎是一个解决方案。当开发者修改了登录模块的实现后，为什么他们非得花费1个小时等待其他模块的测试结果呢?如果可以仅仅运行登录模块相关的测试，将其余的测试留给持续集成工具运行，开发的效率将大大提高。但遗憾的是在XUnit的世界中，系统化的划分测试并不是件容易的事情。不论是利用文件名和目录来区分，还是手工维护测试套件，最终总会变成难以维护的大泥球。

　　* 阅读测试花费的大量时间

　　大量测试代码总是难以阅读。随着项目的进行， 各种不同习惯的缩写出现在代码中、测试代码中出现的大量的方法、设置数据越来越复杂等都给阅读测试带来了极大的麻烦。面对失败的测试，试图修复它的开发者总是需要在复杂的代码中挣扎着找出测试的意图，过滤掉准备数据的过程，抽丝剥茧地找到这个测试所覆盖的业务流程，分析究竟是哪个产品模块出了问题。出现这样问题的根源是没有对测试的目的 (业务价值)和技术实现做出合理的抽象。

　　能否有这样一个视图，过滤掉所有让人分散注意力的方法(私有方法，准备数据、清理数据的方法等)让开发者可以清楚地看到测试的目的和步骤，甚至让测试以一种自然语言的形式展现出来，让非技术人员也可以轻易地阅读修改测试呢?

　　* 启动功能测试的花费

　　在任何一个团队开始功能测试的第一步，总是耗时和痛苦的。下载各种依赖的库文件，在脚本中进行配置， 保证功能测试可以在命令行执行， 同时还要对IDE进行配置，让开发者可以从IDE中方便地运行单个测试。

　　能不能缩短这个过程，减轻开发者的痛苦?

原文转自：http://www.ltesting.net