软件GUI测试中的关注点(8)

　　2)危机预防

　　系统故障和用户错误发生了，程序应具备将其后果降到最低的能力。

　　――没有备份工具

　　对开发人员而言，为了一个文件做一个额外备份应该不是一件困难的事。如果你正在修改一个文件，计算机应当保留原始版本的一个副本，因此如果你的更改有错误，还能返回到一个已知的好的版本。

　　――不能撤销

　　撤销一个你已经发出的编辑命令，至少是一步。恢复被删除的文件是一种受限制的撤销，它能让你恢复错误删除的数据。撤销是可取的，恢复被删除文件也应是必须的。

　　――没有“你确定吗?“的提示

　　提交一个大量数据清除的工作，或者提出一个清除少量数据但是会影响其他作业的命令或者很容易错误提交的命令，都需要程序在用户操作时进行确认，不声不响地进行将会带来安全方面的隐患(尤其是在后台进行暗箱操作时，这种危险性更高)。

　　――没有增量保存

　　当输入大量文本或数据时，你应该能告诉程序相隔一定时间对你的工作进行保存，至少应该提供用户此类选项。对于突发的掉电和硬件损坏情况这样做将是非常有好处的。

　　3)由用户进行的错误处理

　　人们可以捕获自己的错误，而经验告诉我们，他们还容易犯其他的错误。他们应能自理修复错误，并建立自己的错误检查机制。

　　――没有用户能指定的过滤器

　　当设计数据录入表格和电子表格模板时，你应该能够让每个区域指定什么样的数据类型有效、程序应忽略或拒绝什么。例如，你可以让程序拒绝数字、字母、不在某个特定范围内的数值，一个有效日期或者与磁盘上匹配的日期等等。

　　――难用的错误更正

　　修改一个错误应该很容易。不应该因为犯了错误的数据录入而让整个系统重新启动。在输入一串数据时，你应该能在不重新输入剩余部分的情况下，更正错误的数据。

　　――不能包括注释

　　当设计数据录入表格，电子模板，专家系统时，你应该能够为未来参考和调试输入注释信息，这是很必要的。

　　――不能显示变量之间的关系

　　录入表格、电子模板中有些变量是相互关联的，应该能很容易的检查任意变量对其他变量的依赖性。这在设计时应该被周密考虑到。在大多数的财务管理系统中，这类应用是较普遍的。

　　4)其他问题

　　――隐私和安全性

　　对于某些特定的程序，需要考虑数据的充分安全性，保护公司，集体或个人的机密和隐私。在多用户系统上，你应该能很好的隐藏你的文件(一般都是通过加密手段实现的)，并且能很好的锁定你的文件不被篡改或阅读。

　　――安全性的困扰

　　一个程序的安全性控制应尽可能谨慎考虑与实施。

　　――隐藏菜单

　　很多程序在顶端、底部或屏幕边缘显示一个菜单(包括我以前测试的大多数应用程序)。它们使用屏幕的剩余部分作为数据录入和处理的区域。菜单只是记忆的辅助物。一旦用户了解了他所需要的所有命令后，就应该给予用户充分的自由，让其选择是否需要保留菜单的权力。

　　――不支持标准O/S特征

　　例如：如果系统使用了子目录，那么程序就应该能引用其他子目录。如果操作系统提供了通配符(比如*)，那么程序也应该能使用。

　　――不允许长名称

　　应当允许使用长名称(只要不是太离谱)，毕竟，内存不足和编译器反应迟钝的时代已经成为过去了。别让自己的程序也成了文物。

　　5、程序僵化

　　程序有灵活与固定之分。灵活的程序更显个性化一些，而固定僵化的程序一般都是由于业务流程的关系而不得不如此。如借还书的过程，必先借了才能还。别给用户太多的自由，否则程序看起来会让人觉得松散，也不要把程序定得死死的，那看上去给人太多压力了。

　　1)用户可调整性

　　――不能关掉噪音

　　犯错误时，许多程序都会给出“咄”的警告声。而如果每次接触键盘都发声，这简直是不能容忍的――特别是在公共场所。必须关闭没有必要的噪音，至少程序要提供这类控制选项。

　　――不能关闭大小写区分

　　一个能区分大小写的系统应该允许你告诉它忽略大小写的问题。

原文转自：http://www.uml.org.cn/Test/200711195.asp