解释为什么测试优先开发能帮助程序员获得对系统需求的更好的理解。测试优先的开发有什么潜在的困难。

测试优先开发帮助我们更好地理解需求，因为你要写一个测试程序，就需要分析需求，探究详细意图。

有时候，在需求不全的情况下,你会发现写一个测试是不可能的。测试优先开发的问题就在于是一些测试很难写，因为在任何一个测试之前都要一个就绪的系统底层结构.

给出四个理由说明为什么结对编程和单个程序员编程的软件生产率基本上是一样的。

结对编程和同等数量的编程人员单独编程一样有效的原因:

1.结对编程会引发连续非正式地复查，这样会比单独编程更快地发现错误。 2.结对编程过程中，信息是共享的。单独编程中，人们不得不花时间来共享信息。 3.结对编程鼓励重构（代码需要让其他人看懂），这样减少了后期开发和变动的成本。

4.结对编程可能花更少的时间在细节优化上，因为这对其他程序员来说没有好处。（译者注：没看懂）

假设一个软件管理者参与了一个开发某个软件设计支持系统的项目，此系统是要支持将软件需求翻译成形式化软件描述。请评论下列开发策略的优点和缺点。

开发抛弃式原型，评估，然后审查系统需求。用C语言开发此系统。 丢弃原型化方法:快速的开发和快速的用户反馈. 可以带来合理的需求. 需要多种开发语言. 花费更高.

适用java从现存的需求开始开发系统，然后修改它使之适应任何变更的用户需求。

开发使用C和X-Windows培训较少的问题。

已知的管理策略。需求可能的错误需要交付后的改性。训练几乎没问题,已知的管理策略.需求可能的错误的,所以要交付修改.

适用增量式方法并让用户参与到开发团队来开发此系统。

进化的方法.快速的用户反馈.快速的系统交付.容易适应改变的需求. 很难管理,缺少可移植性的标准.无特定系统结构,将导致以后的维护困难.

18.2解释下为什么通过复用已有的软件所节省的成本并不简单地与所适用的组件规模成比例。

如果复用节约的成本和复用的代码成比例，那么复用2000行代码就相当于复用两次1000行代码了。然而，复用2000行代码，那些代码必须要被理解，程序理解的费用不是线性的——越多的代码，就需要越多的努力去理解的。 而且，当需要更多的改动时，就需要更大量的代码复用，这也增加了成本。 18.3给出你认为不应该适用软件复用的4种情况。

一如果代码提供商的运作状况不确定，或者提供商歇业，不支持代码的复用。 二关键部分的代码不可用。要测试这些代码以达到所需标准，可能非常困难。 三再利用所花的成本和再利用所节省下来的差不多的小型系统

四在一些关键需求在于性能的系统里，专门开发的代码通常更有效率。

18.4为什么模式是一种有效的设计复用形式？这种复用方式的缺点是什么？ 模式是一种有效的再利用设计,是因为它是很多人在应用中积累出来的智慧.这种方法有两种缺点:

知道哪一个模式被存档,找到这些模式所花的时间是必要的.

2.很多模式是一般化的,很多性能可能被限制.如果性能是主要要求的话,那么为某一个问题问题特别研究的方法总是更有效率的.

xxx确定了六个可能的风险时可能出现的系统被构造使用COTS。公司可以采取什么步骤来降低这些风险呢？

风险时可能出现的系统被构造使用COTS包括：

卖主风险:卖方无法提供必要的支持,卖方歇业或结束产品开发.

产品风险:和其它系统不兼容,和其它系统组装时性能下降,在特定环境下,产品不可靠.

过程风险:理解如何组装产品的时间超出预期.

可以通过使用第三方系统来解决.这样的话,可以通过深入的研究,投入使用前的产品兼容性的测试,和其它用户讨论等方法来保证源代码的可用,如果卖方歇业的话.

通常,COST是由卖方提供的,要减少风险是困难的.

19.1为什么它是重要的，所有组件的交互是通过定义的“需要”和“提供”接口？

它是通过定义所有的相互作用重要的需要提供接口，组件的使用是完全独立的，它的实现。如果组件交互使用的一些知识的组成部分，是没有定义的要求/提供接口，然后组件之间的耦合增加，很难交换一个具有相同接口的等效组分的一个组成部分。

19.3之间的根本区别是什么组件和Web服务(see Chapter 12).

Web服务只有单一的一个标准，组件则有多个标准，因此服务的内部操作性会更好。

服务的付费是按使用权计算的（你要用时再付费，不用时，可以停止付费），这样用户就不用为一个偶尔使用的组件，支付昂贵的费用。

组件的交互可以作用比Web服务更有效的协议，因此组件更适用于高吞吐量/高性能要求的应用。

一旦一个组件被购买，它就属于用户所有。而与此相反，Web服务总是被提供商拥有，这就意味着用户对于服务的更改永远没有控制权，如果服务变更（或消失），那么可能对用户很不利。而组件不同，用户可以决定什么时候使用新版本。

19.6解释为什么它是很难不组件源代码验证的可重用的组件。以什么样的方式将一个正式的组件规范简化验证的问题？

因为在没有源代码的情况下，我们无法知道该组件是如何处理异常的。唯一的办法就是黑盒测试。因为组件的详细规格说明书很少是完整的，黑盒测试也有很大的困难。标准的详细规格说明书定义了组件的功能，尽管能提供一定的帮

助，但是标准的说明书也很少说明全部的异常，它并不能帮助我们测试组件的性能，可靠性或其它的非功能性特征。

19.8使用的例子，说明需要支持顺序组成的适配器类型不同，分层的组合物和添加剂的组合物。

顺序组合的例子：部件C是由部件A和部件B依次组合而成的。 附加组合的例子：部件C是由部件A的界面和部件B的界面组成的。

层次组合的例子：部件C是由部件B组成的，而部件B是由部件C组成的。

23.1解释为什么测试只能检测到错误的存在，而不是他们的缺席。 假定穷举测试的程序，在每一个可能的有效输入检查，是不可能的（适用于所有但平凡的程序）。测试用例不显示故障在程序或显示一个程序故障。如果他们发现一个程序故障则证明错误的存在。如果他们不显示故障，然而，这只是意味着他们已执行的代码序列，–为输入–是不是错误的选择。在相同的编码序列–不同输入–下测试可以揭示故障。

23.3回归测试是什么？解释锄自动化测试的使用和测试框架，如单元简化回归测试。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。如果设置了自动回归测试，在每次修改代码之后都会自动进行测试，简化了回归测试的工作。一个自动化的测试包括成功的自身测试和其他测试。这样成功的测试成本和回归测试成本较低。

23.6在一个分布式数据库系统，如LIBSYS开发性能测试的问题是什么？ 在软件测试一个系统中碰到的主要问题是：