很少有企业会在一架飞机的构件做完寿命测试之前去做试飞实验。然而如今的大多数软件开发企业仍然在软件单元测试通过之前将系统集成。假如你正负责用 Java 开发企业级的应用软件，那你如今是发现了一个更便利的方法，来解决这个问题。请核对一下以下的 10 条信号，你将发现开发者测试对你的必要，以致你从今天开始就着手企业开发者单元测试（ EDT ）。
第十条：你的开发人员因软件质量问题而花大量时间返工。
许多开发团队在修补软件和维护已发布的软件上要花去 50% 以上的时间。当系统变得庞大时，这些工作就变得更为复杂。尤其是在许多现存缺陷的系统部件被集成在一起后。 EDT 的最大优点就是使开发团队第一时间创造出高质量的软件从而减少返工的时间。
第九条：因为低质量的系统纳入了 QA 循环体系而延长了 QA 的周期。
我们经常遇到这样的事，因为被测试的软件无法启动运行而使得计划中的系统测试被取消。因为单元级的软件缺陷导致系统无法运作， QA 的资源是解决不了这类问题，这时开发的每一个参与者都蒙受损失。一旦当开发工程师运用 EDT 确保递交 QA 的代码是高质量的。那 QA 就可以更注重于检测软件功能的准确性以及在压力情况下的表现能力
第八条：你发现极难维护现有的代码基础。
许多公司不得不维护很久以前编写的软件或者通过企业购买得到的软件资产，这些软件的开发人员都已经不在了，在这种情形之下，对软件进行任何修改都变得风险较大。为了解决这类难题，软件需要被重新整理和进行单元测试使开发人员对软件代码有所了解并建立信心。 EDT 可以为这类过程提供全自动的，带管理功能的工具，使得这一流程变得更有效和经济。
第七条：你的 QA 部门需要有一个单元测试标准来度量被允许进入 QA 循环的代码。
一直以来，对于单元测试的程度成为很难去度量和评判。俗话说 “ 不可用标准来度量的事，则不可能被管理起来 ” 。 EDT 则可以对单元测试提供度量以及更为详细的信息，从而使得开发团队向 QA 移交代码变得简单易行。
第六条：你很难让你的开发团队在开发过程中引入单元测试。
假如企业希望单元测试成功，那就必须将单元测试集成到开发流程中去，然而开发团队经常为了赶进度而放弃单元测试，实际上导致更多开发进度的延误。 EDT 可将单元测试流程集成到现有的配置管理框架内，以便建立和监督测试目标，提供必要的度量和可观察力，将单元测试作为核心开发流程的一部分来管理。
第五条：你必须了解你的单元测试资产才能管理你的开发团队。
当软件被很好的设计（包括单元测试）后，任何根据业务要求的软件变更变得迅速。一旦开发人员了解并对自己的代码有信心，软件变更变得容易，从而使软件能更好地服务于业务。当然目前只有少数的公司能对其单元测试有深入的了解。 EDT 不仅可以为企业的单元测试提供全局观，可以提供详细的单元测试信息
第四条：你可以用 Junit 来做单元测试，但因其的低质量和低覆盖率导致对你的单元测试增值不大。
采纳单元测试流程是个很好的开端，但很多公司在短期内看到的则是相对单元测试之前较差的投资回报率。单元测试是一个综合的问题， EDT 可以帮助在开发中自动生成单元测试，并随代码的变化而更新。运用 EDT 开发者可以达到更高的测试覆盖率和质量，但又无需花太多的努力
第三条：你发现使用 Junit 做单元测试太费时费力。
开发人员必须不断地按业务功能要求增加，质量受限制。以及开发速度压力之下工作。如此压力下开发人员很难自我约束用 Junit 来作每个单元的测试。 EDT 可以帮助开发者将这些艰难的工作自动化，使开发人员可以更多关注开发中的其他重要工作。 EDT 使单元测试交易切实可行，并且更有意思。
第二条：你发布了你的软件，祈祷你的客户使用中不会遇到重大的运行错误。
传统的系统测试不能解决今天庞大又复杂的应用系统遇到的情形。最糟糕的软件缺陷往往存在于你从未考虑去测试的那些死角。然而你的客户往往会在这种问题上雪上加霜。 EDT 可以让你知道什么地方被测过，什么地方没有被测过，帮助你达到手工难以覆盖到的代码基本面。 EDT 让你更有信心地发布你的软件。
第一条：你夜晚无法安然入睡。
出处： www.dumasoftware.com 作者： 陈安明
90
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
