[微软测试技术心得整理，转载请注明出处]
【要点】
在测试的实施过程中，可能会由于软件设计本身存在的可测性太差的问题，导致测试的难度相当大，甚至出现无法测试的情形。这种情形往往是由于极差的软件架构设计和极为不规范的软件开发工作导致的。当然，设计成如此不堪入目的软件本身是不值得测试的，往往这样的软件团队也没有包含测试人员。软件的可测性往往就意味着，软件代码的质量低，软件的可维护性低，软件的质量低下也是不言而喻的，那就没有测试的必要了。
所以其实高质量的软件才需要测试，成熟的软件开发队伍才会对测试工作的需要急切而渴望。
【心得】
如果设计不当，测试可能会是软件开发过程中代价最高的一个环节。
好的软件设计/架构和可测性是关联在一起的。
1）紧耦合。紧耦合的特点是：“不把大半个系统实例化就无法测试”。
2）弱内聚。弱内聚的特点是：“这个类实现了太多功能，导致测试非常复杂”。
3）冗余。冗余的特点是：“同一个方法在多处使用，每一个地方都得测试”。
提高软件的可测性并不会给软件开发工程师和软件架构师带来太多额外的考虑，并不需要付出太多额外的代价。就是说，一个经过良好设计的、可自诊断、可管理、可维护的高质量软件本身的可测性就很高。如果说有代价，也就是开发工程师自身软件设计和开发水平提高时所必须付出的投入。
提高软件可测性的同时其实也提高了软件的可维护、可管理性。
