软件测试中的过度设计(2)

　　其实我们用一个Matrix就足以把这一组TC说清楚了，根本不用分这么多目录结构，如下图：

　　商业工具给我们提供目录功能，是想帮助我们整理设计思路，不过如果我们设计过度，就会把自己搞晕，所以目录结构的设计，尽量扁平，多使用Matrix来描述TC。

　　对页面控件的静态校验TC要设计得很完整

　　我在参与一些项目的TC评审的时候，经常能看到大量的WEB控件静态校验TC，比如文本框的“不填任何字符”、“填数字”、“填汉字”、“填超过20个字符”，再比如Grid控件的“上一页”、“下一页”、“最后一页”等等。其实这些TC模样都差不多，不同的只是控件的名称，还有控件属性(例如最大字符数)。编写这些TC无疑要花费大量的人力，有的甚至为了写一个 “不填任何字符”这样的简单TC，要写出上百个汉字来。

　　对于这些非常成熟的WEB控件，一般每个开发团队都会有一套成熟的框架，出错的可能性不是很大。另一方面，成熟的测试团队也必然会沉淀出一些对控件进行静态测试的方法和规范。即使我们不写这些TC，只要我们搞清楚每个控件的属性，明确每个控件的标准测试方法，是完全可以很好的覆盖这些静态TC的，实在没有必要让“等价类”、“边界值”这些测试理论在静态校验上发挥的淋漓尽致。我们关注的重点应该是业务逻辑，还有程序的内部结构。

　　自动化覆盖率越高越好

　　关于自动化覆盖率的问题，争论一直没有停止。大家也都同意，自动化脚本多了不好，少了也不行，至于到底多少才是最好，谁也说不清。其实我也说不清，所以这里也不多罗嗦了，只想说一点，互联网软件的特点是创新多，变化快，因此相应文档(比如需求、TC、自动脚本)的寿命都是短暂的，测试团队如果花费大量的成本来维护这些文档，很容易造成“测试过度”，疲惫不堪。不同于传统软件行业，互联网软件的测试团队，更注重于灵活轻便，善于应对频繁的软件变化，对自己的产品有着透彻的了解，不管是业务需求还是程序结构，这一点非常重要。

原文转自：http://www.uml.org.cn/Test/201107072.asp