软件开发过程中的测试管理[2]

 比喻来说，这就好像是修建一条铁道线，得先把铁路轨道的标准定了、轨道先铺上，然后再在铁路上运行与轨道宽度标准相符合、专门为它而造的火车。铁路轨道的宽度标准决定了所用的火车必须遵循的宽度。所以可以说，轨道宽度标准是一个制约了火车合格标准的框架。先有了这个框架可以很容易地证实造出来的火车是否符合要求。当然，你也许可以不顾宽度标准先造个火车再说，但这样造出来的火车不见得能在轨道上跑：要是轮距宽度不符合轨道标准，你就得返工重做。TDD的管理模式就是这个先造检测标准的理念在软件开发上的运用，就好像是你先定好轨道的宽度，然后说：按照这个标准造火车，不能在这个轨道上跑的火车就自动不合格；TDD的管理模式使开发人员建立同样的思路：按照这个测试标准去开发程序，通不过这些测试的软件就自动不合格。
        　　
        这样的开发方法有很多好处，最明显的好处是“强迫”开发人员在设计程序的同时，并列进行必须进行的单元测试设计，催促你去思考如何验证你的程序单元的逻辑正确性和单元的完整性。更重要的是，这样的开发模式有助于推动进行自动化测试的工具程序的开发、提高测试的效率，因为那些事先设计好的的单元测试程序，在单元的功能程序编写过程中，可以被随时使用，来验证所开发的功能程序部分是否符合要求。

        这样的开发项目管理模式和理念，很明显地是将软件测试的作用和重要性提高到一个开发战略的层面。 测试不再是简单的开发完毕后再考虑使用的质量管理的辅助手段而已，而是衡量软件在开发过程中每个单元组件是否能够通过，可以说是掌握了项目进度的“生杀大权”。

        这个开发管理模式相对来说是一个比较新颖的方法，它对传统的开发流程的项目管理造成了不可避免的冲击，因此并不是很容易被开发团队接受，特别在绝大多数的在开发人员说了算的企业文化里，这样的开发方法的使用和推广很容易受到开发团队的阻力，因为它不仅用开发流程的改革来承认测试的重要性，并且由于开发人员被要求进行单元测试的开发和执行的额外工作 ，开发人员的工作量和习惯也都需要作一定的改变。

        但是毫无疑问，这个项目管理模式所能够带来的巨大好处是有目共睹的。这也是为什么这几年来在业界中像敏捷模式、TDD模式等新型管理方法在软件开发的项目管理上被越来越广泛地利用。就拿微软本身来说，我们目前也正在进行一场内部的改革项目管理的“革命”：两年前，总部产品开发部门有少数一些项目经理们自愿组成一个推广敏捷模式的兴趣社团，在少数几个开发团队开始推动敏捷模式和TDD等。他们有点像个“地下组织”，因为绝大多数的产品开发团队还是在使用传统的方法，公司也没有人正式倡导敏捷模式等。但是近两年来，采用TDD等模式来充分发挥测试对质量管理起到的好处，很快就得到很多团队的共识，因为那些采用了这些模式的团队在软件质量的增进上有明确的数据可以证实，这种尊重测试的方法为提高软件质量、降低Bug Count（缺陷数）、最终帮助开发项目的成功所能带来的巨大好处。在好几次公司的经验交流会上，一些采用了敏捷模式和TDD等方法的团队公布详细的质量管理的数据比较，来证明这些新方法的优越性。微软快速适应变化的特性使得公司很快地也学会支持对新型模式的采用，现在全公司对技术员工进行开发工程教育的部门也开辟相关的课程，帮助一起来推广对敏捷模式和TDD等管理改革的采用，颇有“星星之火快要燎原”的气势。有的团队甚至采用配对的两人坐在一起开发的工作模式：一个人开发进行单元测试的程序，另一个人接着开发功能程序、并马上进行测试。两个人来回使用同一台计算机来完成对某个组件的开发。

        完善的测试依赖全面的测试计划

        前面讲述了测试对软件开发的重要性。那么在开发项目管理的运作中，究竟如何执行具体的测试呢？答案是：每个软件都有它的功能设计，通过它们为用户解决某些问题或提供某些服务。测试的目的有两个：第一是要确证这些为用户解决某些问题的功能设计被正确无误地开发出来了，也就是说，如果用户按照所设计的使用方法和过程（我们称为User Scenario，即使用方案），的确能够利用这些功能所提供的服务和解决问题；第二是保证软件在被使用的情况下，如果使用者并不按照所设计的使用方案在使用软件，它不应该由于任意的使用、或其它外部影响造成任何问题，包括出现差错，比如数据遗失、数据错误、 甚至造成系统崩溃等等。

        为了达到这两个不同的测试目的，在执行具体的测试时就要采用不同的测试方法。为达到第一个目的、也是最主要的目的，最佳的方法是根据所设计的每个功能和使用方案，设计一个相对应的测试执行过程，去验证这个功能或使用方案是能够从头到尾完成的。这个测试执行过程的定义和描述我们称它为测试方案或测试案例（Test Case）。要能够确证所有功能的确是准确地被开发出来了，唯一的办法就是为每一个使用方案都设计出大量的、一套完整的测试案例（在微软的产品开发中往往都是几百甚至上千的测试案例在测试中被使用），然后通过对这些测试案例的按部就班的执行来证明软件的确可以完成所设计的功能。测试案例的全面性和完整性最终决定了为达到第一个目的测试的质量。

        要能够做到制定完整的测试案例，就需要有一个可以作为依据的纲领性指南，帮助测试人员设计这些案例。这样的纲领性指南是由一份叫做测试计划的文件来总结的。测试计划在软件的设计规范书的基础上进行总结和撰写，根据具体的软件和使用要求，制定出整个软件产品的总体测试构思和设想、测试总体范围、对测试方法和测试自动化工具的要求和定义等等。在测试计划的基础之上，测试工程师们根据它再进一步制定详细的具体测试方案。至于测试计划该怎样写，该包括什么内容，我在《软件开发项目管理》一书的第十一章里有详细的测试计划文件的模版你可以参照使用，这里我就不再重复了。

原文转自：http://www.ltesting.net