软件测试系列培训之单元测试+幻灯片1.ppt

* * 测试工具的使用者必须对测试工具非常了解，在这方面，有效的培训是必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，对于测试工具使用者的积极性是很大的打击。 * * * * 　　在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。 　　在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。 　　使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。 * * * * * * * * * * * * 一般大家都会认为单元测试会浪费时间，这是一个误区。一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。 　　在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。 　　在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。 发现软件错误的情况有很多： 　 1、由首次编写代码的开发人员发现。 　　2、由尝试运行代码的开发人员发现。 　　3、由组中的其他开发人员或测试人员发现。 　　4、作为产品大规模测试的一部分。 　　5、由最终用户发现。 　　如果在第一种情况下发现软件错误，则修复错误比较容易，成本也很低。情况越靠后，修复软件错误的成本就越高；修复一个由最终用户发现的软件错误可能要耗费 100 或 1000 倍的成本。更不用说用户通常因为软件错误导致工作无法继续，而一直等到下一个版本才能解决问题。 　　如果开发人员能够在编写代码期间发现所有的软件错误，那就再好不过了。为此，您必须编写能在编写代码时运行的测试。有一种很不错的方法，它恰好可以做到这一点。 经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。 在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。 * 一般大家都会认为单元测试会浪费时间，这是一个误区。一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。