验证和校验
　　一旦你有了可执行的用户界面或原型，你需要回答一个重要的问题：用户告诉了你他们需要什么，但那是他们需要的吗？
　　它满足系统的功能需求吗？这也需要进行测试。没有bug，但回答的问题本身是错误的，这样的系统不会太有用。要注意用户的访问模式，以及这些模式与开发者所用的测试数据的不同。
　　资源耗尽、错误及恢复
　　现在你已经很清楚，系统在理想条件下将会正确运行，你需要知道的是，它在现实世界的条件下将如何运行。在现实世界中，你的程序没有无限的资源，它们会把资源耗尽，你的代码可能遇到一些限制包括：
　　● 内存空间
　　● 磁盘空间
　　● CPU带宽
　　● 挂钟时间
　　● 磁盘带宽
　　● 网络带宽
　　● 调色板
　　● 视频分辨率
　　你可能会实际检查磁盘空间或内存分配的失败，但是否经常检查其他各项呢？你的应用适用于有256种颜色的640 x 480的屏幕吗？它能在有24位颜色的1600 x 1280的屏幕上运行，而不会看上去像一张邮票？批处理是否会在存档开始前结束？
　　你可以检查环境的限制，比如视频参数，并进行相应的调整。但是，不是所有失败都是可以恢复的。如果你的代码检测到内存已经耗尽，你的选择有限：除了失败，你也许没有足够的资源去做任何事情。
　　当系统确实失败时，它会得体地失败吗？它会尽可能设法保存其状态、防止工作丢失吗？或是会当着用户的面造成core-dump吗？
　　性能测试
　　性能测试、压力测试或负载测试也可能会是项目的一个重要方面。
　　问问你自己，软件是否满足现实世界的条件下的性能需求——预期的用户数、连接数、或每秒事务数。它可以伸缩吗？
　　对于有些应用，你可能需要用专门的测试硬件或软件模拟现实情况下的负载。
　　可用性测试
　　可用性测试与到目前为止讨论的其他测试类型不同，它是有真正的用户，在真实的环境条件下进行的。
　　根据人的因素考察可用性，需要处理需求分析过程中的任何误解吗？软件对于用户，像是手的延伸吗？（我们不想让自己的工具顺手，也想让我们为用户创建的工具让他们觉得顺手。）
　　与验证与校验的情况一样，你需要尽早在还有时间更正时进行可用性测试，对于较大的项目，你可以引入人员因素（human factor）专家。（至少，玩一玩单向镜也很有意思）。
　　没能满足可用性标准像是零除错误，是个大bug。