可测试性设计，即所谓的DFT，今天又一次重重地感觉了一次它的重要性。
系统中有一个权限管理模块，同一个物理用户可以不同的逻辑角色登录系统，系统中以各个逻辑角色为最小管理单元进行权限管理。一般情况下，用户可选择的逻辑角色范围是极有限的，绝大多数用户应该有只一个逻辑角色，当然在测试情况下，情况刚好反过了，基本上每个物理用户会有几个逻辑角色，容易暴露出问题。主要集中在，角色拥有的权限不正常，比如看到了不该看的，看不到该看的，可以做不该做的，做不到该做的。
一直以来，对这块的调试/测试都是很困扰我的问题，主要就是DFT没做好。最开始，把所有业务逻辑和界面绑定在一起，差不多每一条规则都要在界面上点来点去，构造很多与真实环境类似的数据去测试，非常麻烦，不容易遍历到各种情况。
后来将这模块重构了，把业务逻辑和界面分离，用单元测试来保障逻辑的正确性。从DFT的角度讲，这种代码架构方式，就是一种改进，对DFT的改进。
有了单元测试，还不能保证程序能完全正确地运作，因为除了逻辑正确，还有可能其他地方出错，比如输入数据就有问题。在前些天他们测试的一个版本中，依然发现了一些权限相关的问题，让我觉得比较郁闷，因为我一直以为应该是万无一失了的。不过事实摆在眼前，也逃不掉，今天老老实实地在那里定位，不过开始的时候还是异常困难，因为测试场景的千奇百怪，我的开发环境下，有些场景很难模拟。
后来突然灵光一闪，我应该为了方便测试，多写一点代码，多加点功能，比如当前这个问题，我可以加一个特性，能在某种特定条件下，使我可以以任意角色登录系统。说干就干，果然很容易地定位到了测试发现的几个问题的原因。
今天的经历告诉我，在软件可测试性设计方面，有很多值得研究的东西的，天呐！
支付宝扫一扫
微信扫一扫