20090916(怎么做到可测性)

全天主要就测试的多个方面进行了开放式的讨论总结。
先就题目进行分两组总结，然后由顾问提出ThoughtWorks的一些思考。两厢对比。
所有内容本身不涉及具体的实践，只将这个领域的问题通过讨论引起大家的思考和关注。

关于测试的成本，TW认为有如下因素
a)无效性引入的成本：包括用例的无效、工具的无效。
b)团队沟通引入的成本：比如部门壁垒引起的，异地配合产生的，不同部门的进度规划不一致造成的。
c)设计依赖引入的成本：这个设计包含的层面较为立体，大粒度小粒度都有设计，都可能存在不合理的依赖
导致产生耦合，进而演变为不可测或测试成本高企。应该是目前的测试成本的主要组成。
那么我们更关心降低测试成本可以采取的措施，TW总结了几条
1)选择合适的工具：不同的工具效率差异是倍数关系。
2)做更多的低成本测试：所谓低成本测试其实就是单元测试。
3)更好的设计：包括产品自身的设计(更多的考虑可测试性，在设计阶段降低测试的成本),和测试用例的设计。
用例本身的管理也需要设计、重用、面向对象、抽象等设计手段，而不是流水账式的铺陈。
4)招聘合适的人：由于测试在敏捷中的工作变得更为复杂，自动化要求更高，开发的内容比例变的更多，
对人员的要求门槛提高了。因此原有的招聘要求需要重新考虑是否合适。
5)投入充裕的设备：自动化测试毫无疑问需要用大量的设备代替人工，虽然经费增加了，但是坚持做下去，
效率的提高肯定大于经费的支出。控制严格捉襟见肘的设备只能让提高效率的追求打个折扣。
6)提高自动化测试的比例：没啥说的，实话啊。

接着谈了下关于测试工具的选型的话题，总结下来就一句话，一定要选在某一点上做的最好的工具，不要选大而全的工具。
工具可以多点，这是现实情况。什么都能做往往是什么都做不好。

测试用例的职责：发现缺陷、功能验证、指导设计、自动运行。

怎么做可测性设计，能够让系统在各个层面具备可测试性？

设计阶段：在功能性需求设计的同时增加可测性需求，需要SE、TSE共同在设计阶段完成
编码阶段：长期持久的在组织层面提高人员的软件能力，在个人层面主动学习业界先进思想，生产无限趋近满足优秀
代码标准的产品。高内聚、低耦合，具备支撑可测试性的可能。
运行阶段：丰富运行轨迹记录，能够在出现问题时自我提供解决问题的运行信息。
这些都是思路，而不是具体的方法。