在维护阶段

　　有一点认识越来越为大多数人所认可：应用系统的维护费用与初始的开发费用基本相等，而在维护过程中，在对应用结构、逻辑、运行的理解上花费的时间，要用去50%的时间。

　　由于系统维护人员很可能不是开发人员本人，再加上人员的流动、团队内部的交流的不足，都需要对应用系统的理解。

　　理解应用系统

　　将应用系统的设计，以文件形式(部件文件间的关系)和调用图的形式(函数和过程间的关系)可视化。

　　函数的逻辑结构以控制流图的形式显示，在控制流图上选定一个节点，即可得到相对应的代码。

　　应用系统可以在不同的抽象层上进行分析，不同层次间的导航关联，促进对整体的理解。

　　对应用按其资源的使用进行检测，由此促进对函数之间(参数传递)的信息流、数据间的关系，以及其它资源的理解。

　　安全地修改软件

　　维护软件意味着修改软件，修改后的程序确认需要大量的工作。因为，看起来很小的修改，都可能会滚雪球似的导致数十处甚至上百处的修改。这种后继的修改需求，越早发现越好，最好是在编译前就发现并做出修改，最坏的情况是在调试和非回归测试期间发现。

　　二、黑盒测试的实施方案

　　传统系统的编程语言和逻辑全是过程式的。这种逻辑顺序只有当数据中的值引起不同的循环或控制顺序改变时才会发生变化。

　　客户机/服务器和图形用户界面系统不是过程式的。它们是事件驱动的。这意味着计算机针对发生的事件执行相应的程序。这里的事件是指用户采取的行为，象键盘活动，鼠标移动，鼠标击键动作和按键的动作，都是事件的例子。因为事件发生的顺序不能预先知道，事件驱动系统相对来说更难测试。开发人员不可能知道用户下一次要选中哪个按钮或菜单项。实际上，应用程序必须在任何时候对所有发生和可能发生的事件作好正确处理的准备。

　　另外，随着RAD(快速应用开发方式)的引入，导致应用的实现速度很快，但这种方式也有它的不足。一个重要的缺点是项目规划经常漏掉重要的测试阶段。测试象在传统开发项目中一样，经常被忽视，并且给予很不现实的少量时间和资源。对于这一点，测试RAD方式下提交的应用并保证软件质量是测试团队的首要工作。

　　黑盒测试在实施时又分为客户端的测试和服务器端的性能测试。客户端的测试主要关注应用的业务逻辑，用户界面，功能测试等;服务器端的测试主要关注服务器的性能，衡量系统的响应时间、事务处理速度和其他时间敏感的需求。在应用系统最终被交付之前保证这两方面的测试没有缺陷。

　　由于测试并不是进行一次就可以完成的个过程，而是需要根据产品版本的变化生成不同的测试过程，如果这一过程仅通过手工方式完成是很难达到的。需要通过工具的帮助，从而简化测试的复杂程度，降低在测试成本上的开销，缩短投放市场的时间。还有一个突出的特点就是应用程序的回归测试，这是手工方式完成不了的过程，只有通过工具才能实施。而回归测试在测试阶段是很重要的过程，通过回归测试可以发现很多隐含的缺陷和错误。

　　在服务器端的测试主要以模拟合法用户活动给系统的负载，负载测试的统计结果被用来预测用户将体验到的性能和响应时间。这都需要在客户机/服务器系统发行之前都要进行的。