1.11.         验收测试

验收测试旨在验证软件是否以客户预期的方式履行职能。

根据软件需求规格说明书测试软件符合性，软件需求规格说明书里应该包含“验收标准”部分，验收测试以此为据。

1.11.1.     验收测试标准

通过黑盒测试来验证软件功能是否符合需求。

检查：是否满足了所有功能需求，是否达到了所有性能需求标准，相关文档是否正确（人工检查），和是否满足了其它的需求（如，兼容性，容错性，可维护性）

如果验收测试不通过，这时想在如期交货之前纠正发现的错误，可能会来不及，在这种情况下，需和客户商讨一下解决缺陷的方法。

1.11.2.     配置检查

这是一项审核工作，是为了确保软件配置的所有元素以正确的方式开发，编目，并且有软件维护方面的必要说明而进行的。

1.11.3.     Alpha和Beta测试

很难事先估计用户在实际使用过程怎样使用软件。

如果软件只有一个用户，则该用户可通过执行一系列的验收测试用例来验证软件是否符合所有的需求。

但如果软件有多个用户时，验收测试用例不合用，这时可选择使用Alpha或Beta测试来查找缺陷。

Alpha测试是由用户在开发环境下进行的测试，用户操作软件而开发人员在旁边记录发现的缺陷和可用性问题

Beta测试是在终端用户在一个或多个用户环境下进行的测试，它是一个环境不受开发人员控制的“现场”测试。用户定期报告问题和缺陷。

1.12.         系统测试

开发的软件安装到系统后，只是系统的一个组成部分。

软件与系统的其它组件一起组成系统，所以，软件安装到一个系统后，要进行集成和验收测试。

而针对装载软件的系统平台，我们要进行可恢复性测试，安全性测试，压力测试和性能测试。

1.12.1.     可恢复性测试

很多系统都需要有容错机制－自动处理错误以免因错误导致系统崩溃。

其它的系统则要求在错误发生后的特定时间内恢复。

可恢复性测试是通过各种方式迫使系统发生错误以验证系统能否从错误中恢复。

1.12.2.     安全性测试

拥有敏感或对个人有潜在威害的信息的系统可能会被不当或不合法的使用。

这包括：

l     “外面”个体企图入侵系统以满足娱乐需要或个人私利。

l     心怀不满或不诚实的员工利用系统达到其目的

进行安全性测试时，测试员扮演以各种方法企图入侵系统的角色，有以下方法：

l     试图通过外部文书获取密码

l     使用客户端来攻击系统

l     不断发送请求以求引起系统崩溃

l     制造系统错误并企图在系统恢复时入侵系统

l     浏览不安全的数据

只要有充足的时间和资源，大部分（所有？）系统的安全性可被破坏。

1.12.3.     压力测试

压力测试是测试软件的非常态状况，是为了找出系统可容纳的输入的数量或频率极限。例如：

l     高频率的中断

l     超出“正常”状态的数量级数据传输速率

l     需要最大内存或其它资源的测试用例

l     需要在虚拟操作系统“查找”的测试用例

l     需要过度“检索”磁盘系统数据的测试用例

也可以尝试敏感性测试，以确定对正常输入的组合是否会引起不当处理

1.12.4.     性能测试

对于实时和嵌入式系统，可能功能满足需求，但却因性能问题使得系统可用性不合要求。

性能测试可测试系统在集成环境中的运行时间。

性能测试可结合压力测试。

性能测试可能会需要某些软件工具。

1.13.         调试

调试不是测试。

因为有成功的测试才需要调试。

调试比软件开发更难。

难度在于：

l     症状出现的区域和原因所在区域之间可能没明显联系，大问题一般出现在软件的高耦合区域。

l     一个症状可能会在另一个缺陷被纠正后消失（暂时）。

l     症状可能不是由一个缺陷引发的（例如，硬件限制）

l     症状可能是由于人为错误所致

l     症状可能只是某一时机的问题，而非处理问题。

l     可能很难复制症状的输入条件（特别是在实时系统）

并非人人都精于调试。