21、编写测试的策略

编写测试的策略

1. 测试工具使用与PASFIT的发展

在测试工作中，即便拥有世界上最好的工具，如果不能明智地使用，也无法发挥其作用。测试工具虽能让测试的指定变得容易，但在合适的时间指定正确的测试，仍取决于使用者。曾有团队发现，过早提供过多细节会让整体情况变得模糊，导致程序员不清楚该编写什么代码。不过，并非所有团队都会如此，只是在某些时候确实需要细节，最晚应在程序员拿起编码任务卡并开始处理某个故事时提供。

PASFIT的发展就经历了这样的过程。最初，基于单元格颜色生成Java代码来创建PAS中的数据，维护起来十分困难，部分原因是应用程序在图形用户界面（GUI）和数据库层面都处于频繁变动中。在之前的尝试后，PASFIT近一年都没有进一步发展。直到拥有了更稳定的数据库视图和GUI，才创建了一个引擎，该引擎使用简单的命令式语言（即脚本）对GUI执行带参数的操作，例如“转到平衡页面”“平衡电池：油、水”。这个脚本逐渐演变成遵循生产会计的思维过程，成为一种特定领域语言。引擎使用Ruby和Watir编写，脚本中的指令基本上是动态调用的Ruby方法，便于更新。脚本运行后，框架会加载测试希望比较的视图快照，并逐行、逐单元格地比较断言内容和实际发生的情况。最终，在电子表格中使用数据透视表进行了增强，使用户能够专注于他们希望为测试断言的结果。总体而言，这相当成功，尽管应用程序的要求意味着运行300个测试大约需要12小时，耗时较长。

让业务人员更多地参与回归测试的维护也很困难，但一旦实现，效果会很好。目前，业务用户和开发人员会进行15分钟的站立会议，处理当天失败的场景测试。这种方式很有效，因为人们在参加会议时往往知道前一天可能破坏了哪些内容。未来的改进可能包括针对实际用户报告而不是视图进行断言，以及每