在测试过程中加入可用性测试

　　在专业祝作利，充满了关于怎样实现测试的详细建议，但是如果基于软件的产品还没有开发出来，就是说它还不存在，怎样找些东西来测试它，这方面的内容在书里几乎没有。在实践中。必须建立和测试一些软件的替代品。它们通常采取如下形式：或者是一个快速写成的原型程序，或者是兼职拼凑而成的“木偶戏”，也或许是一些类似的低技术的材料。
　　你可以从“剪纸的木偶戏”中国看到很多用户的反应，但是如果不先做设计，被测试的东西还是很不恰当的。而且，在这种形式的测试中，用户的个性表现不可避免地出现很大的差异，一个字，一个点头，或者一撇都可以轻易地使测试结果发生偏差。
　　你不会去做如下昂贵的对比测试：建立两个程序分别来测试。即使那样做了，你所知道的也不过就是这个候选者比另一个好，还是不知道可以达到的最好程度。
考虑周全的用户测试可以暴露设计者不争取的假定。把你的设计工作向用户展示，再反复地重新修改设计，这样做比不做要好。一些新兴技术，如语音识别，由基础的用户测试产生结论有几大的价值。
　　值得一提的是，当程序员被迫坐在单向玻璃窗后面，观看用户苦苦地和他们的程序作斗争的时候，可用性测试最有价值的贡献产生了。程序员被深深地震动了，对那些顽固的软件工程师来讲，可用性测试是很有效的迎头一击，告诉他们，事实上程序有很大的问题。可用性测试对管理者也可以起到同样的作用。
　　对于用户来讲，在目标向设计和有常规专业维护的良好程序中，用户测试的使用，已经显示出它是一个有效的并且可以防止衰退的技术。这里的关键是要记住，其他的因素甚至可能会起到更大的作用。