在慢速终端上,帮助文本,长菜单以及漂亮的图片常常会令人不耐烦。你应该使用简要的语言取而代之。不要使用诸如“你真的想以500k/s的速度传送此邮件到某邮箱”么之类罗嗦的语句。
7、输出
程序的输出应如输入一样完整。它要求更精确,尽量快速和能实现多路径及对输出内容更有效的管理,这四类标准几乎决定了输出功能的主要表现特性。
1)不能输出某种数据
你应该能打印出你输入的任何信息,打印不出输入的内容对任何程序而言都是致命伤。
2)不能重定向输出
你应该可以重定向输出。特别是,你应该能向磁盘发送一个很长的“打印输出”标记,并稍后打印该磁盘文件。程序不应该阻止你把数据输出发送到预料之外的设备,如绘图仪,磁带,打印机等。
3)与一个后续过程不兼容的格式
如果一个程序声明能够以第二个程序可以理解的格式保存数据,那么就应该测试它是否可以真正做到。这意味着购买或借用第二个程序的副本。使用第一个程序保存数据,用第二个程序读数据,同时看看第二个程序得到了什么,这是对此进行测试的最简单方法。
4)必须输出的很少或很多
你应该可以修改报告,从而呈现你需要的信息。不得不在仅包含少量有用信息行的打印输出的大量页中找出所需信息,几乎和没有得到信息一样糟糕。
5)不能控制输出布局
你应该可以改变字体,对输出信息增加特殊标记来强调信息。你应该可以修改信息之间的间距,最低限度来说,程序应该可以以一种由合适文字处理进行修饰的格式把报告输出到磁盘文件。
6)荒谬的精度输出级别
要是说4.2加上3.1等于7.3000000或者说3.1111+2.11等于5.22110102都是很愚蠢的。在最终输出的结果中,程序应该按照规定的格式和精度输出最后的数据。
7)不能控制表或图的标记
你应当能够改变字型,措辞及任何说明,包括标题,表格,图形或是图表中文本的位置。
8)不能控制图形的缩放比例
绘图程序应该提供默认的垂直和水平比例,不要告诉我你最后输出打印报表中的图形超出了整个页面或是只占据了整个页面的一角。
二、错误处理
在处理错误时发生的错误通常是最常见的缺陷。错误处理产生的错误包括:未预料到错误发生的可能性并防止其发生,没有注意错误状态,以及较严重的:程序可能与错误数据一起工作并最终产生错误结果的情况。
1、错误预防
程序应具备这种能力:它能保护自己不受到系统其他部分的影响(包括有害输入和有害处理)。如果程序可能与错误数据共同工作,确保其在发生严重可怕的影响之前(如程序崩溃,数据丢失与错误,系统崩溃等),检查并消除这些问题。
1)不充分的初始状态验证
如果内存的某个区域必须以其中所有位都是0开始,那么程序应该可以运行一个抽样检查,而不是假定已经存在0值。这会导致程序初始化时发生内存错,甚至不能启动。
2)不充分的用户输入检查
此类问题非常常见,开发人员可能会在编写程序时遗漏掉大量这方面的问题。告诉人们输入1位到3位数是不够的,有些人可能会输入5位甚至更多,也有人 会输入特殊字符或是运算符,还有些人会按下功能键一次或多次,如果程序允许输入,那么程序就应能顺利应付,而不是一打非专业人士不能明白的提示甚至更糟的 情况。
3)对受损数据不能充分预防
没有人能保证磁盘上的数据是好的。可能是有人已经编辑过或者根本是有硬件问题。即使开发人员认定在保存前的文件是有效的,那么他也应该检查(校验)下次打开的是否是同一个文件。
4)不充分的参数传递测试
一个子程序不应该假定得到了正确的调用(事实上,采用相反的想法可能会让测试进行得更加顺利一些)。它应该确保传递给它的数据在其可控制的范围之内。
5)针对操作系统的预防不充分
操作系统存在缺陷――不光是过去,现在甚至将来也是,应用程序可能会触发其中存在的问题。如:如果开发人员知道,他把数据送到磁盘后很快又把数据送到打印机,会引起一些操作系统的崩溃,那么他就应该确保程序在任何情况下都不会这样做。
原文转自:http://www.uml.org.cn/Test/200711195.asp