可测试性（Testability）， 让我们做得更好

我不知道有没有公司吧可测试性真正当做一个事情来做。反正我经历过的公司和项目中，几乎没有产品在开发阶段或者测试阶段主动考虑过可测试性。

几乎每一次做自动化项目，对于产品的可测试性，我都有深深惋惜的感觉。因为写了大量的代码，花了大量的时间，仅仅是为了获得某个“没有命名的控件”，。如果这个控件具有ID，那么所有的代码可能仅仅是一行系统调用，简单不说，而且稳定性还远远胜过自己写的代码。

因为开发的投入如此至少，但它取得的效果如此之好。所以，我想当然的以为所有人都会立即赞同改善“测试性“的要求。但现实往往是“残酷”的。至少我经历过的公司在产品开发阶段几乎都没有考虑过可测试性的问题。对于可测试性的增强也仅仅限于QA与DEV的私人交流，而不是公司层面的一个正式活动。甚至，由于各种原因，开发部门会拒绝因为改善可测试性而修改代码。

也许你有遇到下面的情况。

QA：能否考虑一下可测试性？

DEV：为什么我需要考虑可测试性？

QA：可以调高测试效率。比如自动化测试程序可以更快的开发出来，而且稳定性更高。

DEV：这个难道不是你们QA的责任吗？

QA：。。。。。。

DEV：你叫我提高可测试性，那你总得告诉我怎么做吧

QA：我们这里有一个针对UI设计的guideline，有下面一些指导方针，第一条就是“给控件命名”。。。

DEV：那工作量太大了！我们有几十个个页面，每个页面有几十个控件，那就有成百上千的控件，而且代码分布在各个地方。。。。而且，有些控件不是由我们控制的，是第三方库生成的。所以你这一条是不能达到的。

QA：也不是全部都要有名字。

DEV：有些要命名，有些又不要命名，你这个规则太复杂了，缺少可操作性。

QA：。。。。。。

Manager：我们赞同提高可测试性可以测试效率，这对提高产品质量有好处，但是你能否给出一份详细报告，关于代码达到可测试性需要的额外成本，和开发测试脚本需要的额外成本的比较？

QA：。。。。。。

也许你也这样无语过。但后来我想，关于可测试性，虽然干活的人是Dev，但QA也不能把所有东西都踢给DEV，毕竟最终收货的是QA。这个事情是跨部门的一个活动，应该由QA主导，尽量较少由此带来的对DEV在设计和开发的额外工作。所以要考虑下面两点

1）   简单的规则

面面俱到，过于详细的规则只会让人或者畏而远之，或者消极的遵守。所以规则要简单，容易理解。我个人的总结是下面三条。这三条做好了，能解决90的问题。

1．   给元素命名

2．   给元素的父亲命名

3．   不要重复命名

2）   可执行性

因为DEV和QA工作的巨大差异，所以DEV可能并不理解QA的测试方式，自动化程序的工作机制等等，所以一个“错误-反馈-矫正”的机制是必须的。

一开始就要求DEV做到符合QA的要求是不可能的。但是没有关系，允许不足，允许错误，只要有一个正式的矫正机制就可以了。

总得来说，“改善可测试性“，它真的效果很大。QA一定要去做这个事情，但是不能丢一个几十页的文档过去给DEV，然后说”哥们，全看你的了“，而是要我们一起把这个事情做好。大家Happy。