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