【IT168 分析评论】

    软件实现的质量在某种程度上可以决定项目成败。决定实现质量的因素有两个：

    ? 缺陷（或称为Bug）的数量

    ? 增加新功能的难易程度

    无论开发者如何小心，随着开发的不断进行，系统中缺陷的数量都在不断积累。在传统软件开发方法中，测试往往被推迟到实现之后进行，因而不断积累的Bug不能被及时的发现和修复。这将带来如下后果：

    ? 随着Bug产生和发现之间的时间被延长，发现Bug原因的难度就更大

    ? Bug数量众多，相互间的关系变得更为复杂，修复的成本就更高

    ? Bug修复的效果难以确认，往往修改一个地方，就有可能破坏其他功能点，导致整个系统的BUG率长时间不收敛

    ? Bug数量长时间不收敛，开发团队逐渐失去信心，不敢再随便修改，从而导致实现新需求的难度更大

    ? 迫于进度压力，技术部门不愿进行更改，与业务部门的关系紧张

    为了保证实现质量，采用传统开发方法的团队也做了很多努力，例如明文规定单元测试覆盖率、定时进行代码复审等。但效果未必理想，一种情况是：由于实现和测试在实现时间上分离，测试运行不及时、不频繁，在进度压力下，这些制度往往不能真正落实；另一种情况是：很多测试只是追求覆盖率，没有真正起到充分测试的作用，甚至出现假测试。代码复审会议也流于形式，对于改进代码质量的帮助不大。于是我们看到一个现象：一边是公司不断强调质量管理，另一边软件还是Bug重重，代码修改难度很大。由此可见，要保证软件质量，只有制度还是不够的。

    大型企业级应用系统往往是由多个模块或者子系统组成的，因此除了基本的开发活动，与系统质量、成败密切相关的另一个问题是集成。

    传统开发方法通常在开发结束之后才进行系统集成和验收测试，这就导致这个阶段成了一个问题高发阶段。系统经常在集成阶段集成不起来，大量以前没有预料到的BUG突然出现，团队需要花费很多时间来解决这些问题，给项目造成了很大的风险。有些项目，在开发实现阶段感觉已经接近结束了，但一到集成阶段就问题重重，使得“上线”成了一件令人恐惧的辛苦工作，需要在客户现场加班加点才能成功上线。再加上验收测试突然提出大量修改意见，愈发增加了这一阶段的工作量和难度。

    传统实现方法困境分析

    造成上述困境的主要原因是：

    ? 测试人员介入产品测试较晚，一方面导致，随着系统的不断增大，很多缺陷被埋藏的很深，很难发现；另一方面，在接近发布的时点发现很多问题，留给开发人员修复的非常少，导致只能带着缺陷发布

    ? 需求通过文档传递，开发人员和测试人员理解常常有偏差。如果需求文档更新不及时，还会导致很多无效的工作

    ? 没有自动化的测试和持续集成环境的情况，集成和测试的成本很高，所以无法频繁的进行这种有效的质量保证活动

    ? 在开发过程中，开发人员更多考虑功能实现，而忽视了代码质量、设计的优化和可测试性，导致后期修改代码成本很高

    随着人们对软件开发认识的加深，可测试性（testability）逐渐被提升到了开发活动中第一要素的位置。而传统软件开发方法陷入困境的原因恰恰在于对可测试性的忽视。除了基本的验证功能的正确性，可测试还具有更深层次的含义：

    ? 可测试性是架构设计的试金石。不可测试的系统往往模块间依赖关系混乱，功能划分不清晰，理解困难，导致出现Bug后难以发现原因，新需求也难以加入

    ? 从敏捷开发的角度看，测试还具有如下功能和目标：

    1. 最准确、可运行的系统设计文档

    2. 测试驱动系统设计

    3. 自动化测试更好的支持重构，从而使架构演进成为可能

    在传统开发方法中，代替自动化测试的往往是大量的手工测试，这样测试除了成本高、耗时长外，还存在难以保证测试一致性和质量，从而无法担当起保证软件质量的重任，更对架构设计毫无贡献。