黑盒测试常见错误类型及说明.docx
《黑盒测试常见错误类型及说明.docx》由会员分享，可在线阅读，更多相关《黑盒测试常见错误类型及说明.docx（33页珍藏版）》请在冰豆网上搜索。
黑盒测试常见错误类型及说明
软件黑盒测试心得与体会
WrittenbyStevenWang
Version
版本更新历史
●版本
1.创建最第一版本――由正文，版本历史与封面组成，要紧描述了在软件黑盒测试进程中可能会发生的问题及防范建议。
此文档对大多数软件的黑盒测试工作适用，但不适用于软件项目的测试治理及其他类型的测试方式，仅适用于黑盒测试；
2.目前正在规画对此版本的部份内容进行更新与增补；此文档对应的《白盒测试方式与实践》的第一版正在进行资料整理与筹备工作。
黑盒测试常见错误类型及说明
用户界面错误
功能性
易用性（用户学习利用程序的时刻和记住如何利用程序的时刻）
执行速度（多数是启动速度，查询速度，刷新速度及响应速度等）
用户利历时产生错误的比率（在许诺用户任意利用的情形下，越低越好）
用户中意度（专门大程度上决定UI设计及功能设计的好坏）
功能性
若是显现了以下情形之一，以为程序可能存在功能性错误：
程序能够完成的某些事进行得超级困难，笨拙（繁琐），令人迷惑乃至难以忍受。
要紧表现为以下几个方面：
过度功能性
将简单功能复杂化，这是设计上一个较常见的问题。
尝试进行太多工作任务的系统将很难学习和把握，而且容易忘记。
它要求大量的文档（开发文档，帮忙文档和屏幕）。
性能相对可能会好些，可是复杂化所花费的时刻相关于性能（功能）提高不值得；而且，假设功能模块间模块紧密，那么发生关联错误的概率要提高很多。
夸大的功能性印象
用户手册和营销传单不能使程序功能实现得更多。
记住，在用户手册中哪怕宁愿对功能略微轻描淡写也不能夸大其词（固然，咱们并非希望如此，咱们老是要如实地记录）。
对手头任务的不适当性
由于功能关键事项不存在、太有限（多数是因为没有完成）或太慢（需要改良程序结构或是内部算法）而不能完成真正的工作。
举例来讲，查询一个有8000条记录的数据库需要1个小时（天哪，我想我连10分钟都等不了），尽管说具有了查询的功能，可是实在很疑心此项功能是不是会有人利用。
遗漏功能
功能没有实现，却出此刻了用户手册中。
或是本来应该具有地特点性功能，在程序只能看到一个“影子”（有其名无其实）。
多半情形下是由于需求变更时没有对手册进行检查和更新，也有是因为遗漏了需求说明中应包括的功能。
错误功能
一个本来应该完成查询工作的功能却干了排序的活儿。
这种疏忽一样不是因为没有实现功能，而是在分派功能的时候显现了问题。
功能性必需由用户创建
最多见的情形之一确实是要求用户自己配置软环境（如配置数据源，一样都能够在程序中自动完成；固然还包括程序用到的组件在系统中不存在，用户还需要自己购买，这对用户是不能同意的）。
不能做用户期望的工作
例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却依照ASCII码的顺序排序。
他们也可不能指望用它来计算首位空格或区分大小写。
固然用户名的排序仍是要做的，问题是开发者需要从头构思一个新的排序规那么来知足用户需求。
人机交互
人机交互，程序与操作者之间的通信与交流。
这不是科幻电影，咱们或许天天都要做，在取款机前，在自动售卖机前――
遗漏信息
你应该明白，所有的事都能从运算机屏幕上取得有效的消息。
没有任何屏幕指令
如何找到程序的名称？
如何退出程序？
你应该怎么样获取帮忙？
若是程序利用了某种命令语言，如何才能取得命令列表？
程序可能仅仅只在它启动时显示这些内容。
固然你也能够从帮忙手册中获取这些信息，但并非是必要的。
没有任何屏幕指令的程序可能会让人受不了，查询手册的话需要花费的时刻可能会更长——这可能就会让用户感觉软件学习起来太复杂了。
假定打印出的文件随时可得
丢了用户手册如何办？
有体会的用户可不能非要依托打印好的文档，提供一份电子版的吧。
无正式文件证明（说明）的功能特点
若是大多数的功能特点或命令在屏幕上提供文件说明，那么所有的都应如此。
仅略过几个功能特点将会致使混乱。
一样，若是程序为很多命令描述其“特殊情形”下的行为，那么所有的命令都需要提供这种说明。
看起来不可能退出的状态
如何取消一条命令或在一个深层菜单树中进行备份？
程序应该许诺你能够幸免那些你不希望碰到的情形。
比如，在软件安装时，要求插入磁盘，若是不插入正确磁盘就不能退出安装程序。
没有告知你如何幸免就和没有提供一条逃逸途径一样糟糕。
没有光标
大多数用户都依托与光标。
一个光标能够让用户感觉运算机仍然在正常运转（尽管有时候死机也是如此），每一个交互程序都应该显示光标，固然，在关闭光标时别忘了告知用户。
没有对输入做出响应
每一个程序都应该对输入做出回应。
若是没有，呵呵，保管80％以上的用户会对软件产生疑心：
怎么没有响应？
还要等多久？
若是有以下几种情形，一样视为正常：
1．选择一个菜单项时，若是你的按键操作没有回应，只要下一个屏幕立刻显现而且此屏幕上的题目与菜单项那个一样，就能够够视为正常。
2．若是程序轻忽错误的命令或按键操作，固然能够不对其进行回应。
3．若是你告知程序不要对输入回应，它必需不回应，若是它进行了回应，应该告知开发人员：
嘿，看那，它不听话（可能是在忘记了继续处置另一种情形）。
4．若是输入的是平安性代码（如密码等），那么程序决不该在屏幕上做出回应（若是你输入错误那么是另外一回事）。
在长期延迟时没有表示其活动
给一段较长时刻的程序延迟一个适合的响应，将是超级必要的举动。
相信如此不需要再给用户做出过量的说明了。
当某个改变即将生效时没有给出建议
一个程序可能会比你估量的更早或更晚执行一个命令，例如：
删除某些重要数据时，（而那个进程将持续一段时刻），必要的提示是必需的。
没有对已经打开的文件进行检查
据统计，那个错误是超级常见的。
用户可能可不能注意，可是在以后的工作中将发觉略微的一丝更改就会引出大量的问题。
你不能保证程序会对同一个文件在某个时刻做出不同修改所带来的后果。
因此，决不许诺同一文件同时被打开两次乃至更多。
错误的、误导的或令人迷惑的信息
每一个错误都会让你对程序显示的所有其他东西产生疑心。
利用户做出虚假归纳的细小错误，如遗漏条件或是不适宜的类比会比清楚的事实错误更让测试人员感到恼火――因为更难对它们进行更正。
1．简单的事实错误
在一个程序改变以后，更新屏幕显示是低优先级任务，结果那么是：
屏幕上大量的信息过时。
记住：
不管何时程序发生改变，都要认真检查可能指示程序特点的每一个消息，最简单的方法确实是直接对更改后的屏幕进行刷新。
2．拼写错误（错别字）
我相信，这绝对不是设计上的问题，我也相信开发人员可能会不以为然。
Oh，可是客户会在意，会抱怨这些的――仍是更正它们吧。
3．不准确的简化
在维持一个特点的描述尽可能简单的愿望中，一条消息的创作者可能只覆盖特点行为的最简单方面，而忽略了重要条件。
举例来讲，这种情形可能会引发歧义，比如说关闭（究竟是关闭文件仍是关闭程序？
）。
作为一个测试人员，需要你足够认真的研究可能会显现问题的任何一个微乎其微的细节。
宁可错杀，不能放过！
（尽管要极力幸免错杀的情形。
）
4．无效的比喻（图标之类能够指示功能特点的事物）
例如：
回收站的图标可能不是一个好的比喻；关于文件一旦移除就永久消失的情形来讲，碎纸机的图标可能来得更好一些。
5．令人迷惑不解的特点（功能）名称
若是一个命令名称在运算机领域中或语言中有一个标准含义，就必需与其含义一致。
别指望着胳膊能拧得过大腿，确信现行的标准是靠得住的。
6．同一特点（功能）具有多个名称
相同的功能特点只要一个名称就够了――只要能表述清楚；用户可不必然有时刻玩同义词的游戏。
另外，这种情形对软件在用户眼前显示的复杂度也有阻碍。
7．信息超载
不要让你的文档和帮忙屏幕看起来太专业――太多技术细节了。
用户会不耐烦的，何况成效也不行。
若是实在需要，能够把他们另外列出。
尽可能利用直白，用户能明白的话表述这些信息。
8．数据何时取得保留
假设你输入了一些程序需要保留的信息。
当你进行切换或程序退出时，当你需要每隔一段时刻进行保留时，它是不是会把数据依照你想的方式进行保留呢？
何时完成呢？
若是你对答案感到困惑，那就意味着可能有问题显现了。
曾经在同事的项目中发觉过很多次如此的情形：
每次修改后进行切换，不提示保留――我只明白，我又白干了。
在对某个模块进行修改时，你会发觉，是遗漏了必要的步骤。
9．很差的外部模块性
外部模块性指的是程序从外部看起来产品的模块化程度（就像程序是可分割的）。
你如何容易地明白得模块组件？
很差的外部模块会花费大量的时间来学习产品，还会吓跑新用户――天那，它看上去太复杂了！
尽可能让信息独立展现出来，对任何特定任务而言，你需要明白的越少越好。
帮忙文本和错误信息
帮忙文本和错误信息通常被以为是产品的次要部份。
它们可能是由低级程序员编写的（比如我）或是作者编写，对其进行更新的工作可能被给予低优先级。
当你感到困惑或是有麻烦时，寻求帮忙或偏向于利用错误处置程序将是一个明智的选择。
你可能会感觉不爽，更多的时候是不耐烦。
而若是其中有信息误导了你，其余的倒还不如没有来得更好。
以以下出的是几种常见的问题。
1．不适合的阅读层次
在运算机终端上，人们不能专门好的进行阅读。
帮忙文本和错误信息应该尽可能措辞简单明了，多用主动语态，尽可能少利用技术术语，即便用户中有运算机体会也是如此。
2．冗长
幸免你的帮忙文档和错误信息变成裹脚布。
大多数用户在需要更多信息时，会选择通过菜单取得进一步的信息。
最好让他们自己选择所需的信息。
3．不适合的情绪语气
尽可能不要利用感叹号，如“终止”、“崩溃”之类的带有猛烈意味的词语都应如此。
4．事实错误
记得测试时需要测试那些更新过的功能，在旧的帮忙上的方式可能在新软件中是行不通的。
5．上下文错误
不要把上下文之间的关系弄错了。
这会带来阅读时的不便。
6．没有识别犯错误来源
通常，一个好的错误信息不仅能够指出是什么情形，而且还要指出什么缘故有些东西出了错，和如何处置此类错误的方式。
7．16进制转储不是错误信息
8．没有说明缘故就禁止一个资源
若是程序尝试利用打印机、内存控件等资源，却做不到，错误信息应当包括的不单单是宣布失败，还需要说明缘故。
9．报告说没有错误
第一，仍是承认这种情形不太可能显现；错误信息只能由错误状态动身，若是大部份是通常情形的调试消息，亦或是少部份并非必然由某个缺点引发的事件报告，那么，你可能就会忽略所有的错误信息。
显示上的（问题）缺点
这是一个比较客观的问题，至少表面上看上去是如此的。
任何可见的错误都会产生让人不快的感觉（尽管这些问题不必然很严峻），用户就不必然会相信或购买该产品。
可能是因为此类错误大多数都是属于低级错误，通常并非受到开发人员和项目领导的重视，可是咱们必需重视它――它确实是问题（Bug），它确实是咱们要找的东西之一。
两个光标
程序员在跳转屏幕的时候忘记擦除旧光标，嘿，我该相信哪个才是我要的。
更糟的是：
第二个光标可能反映储激活区域周围朝码中的混乱（即便程序能够正确回应，可程序仍是有可能误解）。
若是光标在测试期间行为不正常，仍是先保留再检查你输入的任何数据。
光标消失
有时候光标会消失，因为程序员在其上显示了一个字符，或移动了它，可是忘了对它从头显示。
但是，一个程序的光标指针可能不可用。
当它指向一个用于数据或程序存储的内存位置，而不是屏幕内存时，你会看不见光标。
不管何时程序尝试显示光标，它都会重写内存中的信息。
光标显示在了错误的位置
程序在某个位置显示了光标却在另一个位置对输入做出了回应。
这不是令人兴奋的发觉，至少它误导了你走向了错误的方向。
一个错位的光标可能会警告：
程序会截断输入的字符串，或用无用数据将其填满。
在有双光标的情形下，输入文本可能取得正确响应，却未必会正确保留。
光标移动到数据录入区域之外
光标不该该离开数据录入区域，这一般是由于编码错误引发的。
有些程序员成心让你把光标移动到屏幕的任何地址，然后告知你一个错误信息，说明你不能在此输入任何东西――－这仍是一个错误――设计错误。
数据写到了错误的屏幕位置
光标提示在正确的位置，可是数据却显示在屏幕错误的位置（张冠李戴）。
未能清除部份屏幕
一条信息在屏幕上显示了几秒钟，接着却只有一部份被擦除；或你对前一问题的回应仍然留在屏幕上。
为了输入一些新东西，不能不在提示或不相关的回应上输入，这是令人头疼，而且迷惑不解的。
在以前测试的项目中，就曾经显现过由于屏幕未正确刷新致使的清屏不完整及无端弹出不相关提示的问题――这种问题比较普遍，需要多加注意。
未能突出显示部份屏幕
若是程序常常需要突出显示某个特定类别的项目，例如提示或在激活窗口中的所有文本，那么它就必需一直这么做。
未能清除突出显示
屏幕位置的属性与显示的文本分开贮存时这是很普遍的。
程序员删除突出显示的文本，可是忘记了从屏幕的那一区域清除突出显示。
显示的字符串错误或不完整
显示的消息可能是毫无价值的文本，一个冗长的信息的一个片断或是一条应该显示在其他时刻显现的完整信息。
这其中任何一条都可能反映出程序逻辑上，用来发觉消息文本的指针的值或已贮存的文本副本中的错误。
显示信息太长或不够长
消息在屏幕上显示的时刻应该足够长，至少应该维持到能让用户读到终止为止。
对同一条消息有时显示时刻长，有时显示时刻短需要注意，这可能预示着外部资源之间的竞争条件，往往这些条件是在咱们考虑之外的，需要认真对待。
界面布局的显示
屏幕看上去应该是很有层次的，别让它看起来像是一个乱糟糟的房间。
不同类别的对象应该在可预知的区域分开显示。
你能够参考一些关于UI布局的文章，但归结起来讲：
显示布局应该很容易让你在屏幕上找到你要的东西。
从美学角度看屏幕布局很拙劣
屏幕可能是不平稳的，大多数情形下是如此子，行或列不对齐，或只是看起来很“糟糕”。
好好利用你的鉴赏力，若是没有信心，能够问问他人的意见，参考一些界面设计很合理的软件。
若是对你而言它的布局的确看起来很糟，相信你的直觉，确信有什么东西错了，尽管此刻你尚未发觉。
菜单布局错误
这是最多见的问题之一了：
咱们有时候会发此刻编辑菜单下突然冒出了一个文件关闭的选项，而一样它是放在文件一栏下的。
在很多的参考文献中，已经对这方面的内容做了比较详实的说明，我想强调的是以下一些问题：
1．相似的或从概念上相关的菜单项选择择应该分组，或应该在屏幕上说明。
2．选择一个菜单项通常应该独立。
为了取得一个独立的结果，用户不该该必需在不同的菜单上做出两个或更多的选择（这可绝对“难”用）。
3．通过键入其首字母来选择菜单项通常要比利用数字来得好。
固然，你要留意不要给菜单项过于奇怪的名称，另外，还要注意不要在同一栏下面不要出项重复的字母。
对话框布局错误
就强调几点吧。
1．对话框应该一致。
如：
他们应该一致利用大小写，字体和文本对齐规那么。
对话框题目应当占据某个一致的位置，并与用来挪用该对话框的命令名相符合。
相同的快捷方式在不同对话框之间应该起相同作用――如不该取消某些对话框，而完成其他的任务。
2．对话框中的控件布局必需合理安排。
应利用必要的距离把组隔开。
3．选择和录入区域应该垂直和水平排列，如此用户就能够够以直线模式操作光标的运动（为了方便）。
4．留意对话框之间的彼此依托性。
若是某个对话框中的选择将最终决定另一个对话框的选项将是令人困惑的。
模糊不清的指示
你应该老是明白去哪里查找以找出下一步。
若是屏幕排得很满，老是应该为命令和消息留出一块空间。
在屏幕中央显示信息也是一个不错得选择。
闪烁的误用
闪烁的图片或文本很引人注意，只是记得不要太多闪烁。
太多的闪烁会让人感觉不舒畅。
你应该每次最多只让一个目标进行闪烁而且频率不能太高。
颜色的误用
不要太多颜色，它会让咱们的眼睛很疲劳。
颜色不该该使咱们分散注意力，也不能使屏幕看上去杂乱无章，尽可能利用统一风格的颜色，若是程序的颜色组合看上去很难看，抗议吧，没有人会情愿买毫无美感的产品的。
过于依托颜色
若是程序在项之间利用颜色为唯一分隔符，那么它将限制利用者的范围，关于一些特殊的产品，需要考虑到例如色盲之类对颜色不灵敏的人群或是利用单色显示器的用户。
与环境风格不符合
若是与运算机相关的风格提供了某种一致性和便利，尽可能好好利用。
或许对程序员来讲能够利用更好的技术来代替，关于用户来讲也未必不是不可同意的。
例如：
在适应了鼠标和图标以后，恐怕很少有效户会适应敲击键盘书写命令来完成运算性能够利用鼠标完成的工作。
当大多数其他的程序以某种特定方式在屏幕的特定位置显示错误信息时，新程序也应该是如此的。
不能去掉屏幕上的信息
在屏幕上某个部份的可用命令选择菜单是专门好的选择。
一旦用户精通了程序，有些菜单就会成为屏幕空间资源的浪费。
你应该能够提交一个命令能去掉和从头挪用它。
这点上，值得向微软的Office系列软件学习。
命令结构和录入
那个地址只处置实现中的缺点。
（即假定程序员对风格的选择是合理的）
不一致性
增加永真规那么的数量能够缩短学习时刻，并减少文档，而且使程序看上去更专业。
不一致性如此的普遍，是因为它需要计划并进行斗争来选择能一直遵循的操作规那么。
每一个微小的不一致性都是不重要的，可是一旦量变到质变，一个本来构思专门好的产品有可能会变得难以利用，乃至变成废品。
一个好的测试实践要标注出所有发觉的不一致性，不管何等微乎其微都要如此。
“最优化”
程序员有时候会成心引入不一致性来对程序进行优化。
的确很吸引人，可是也要注意优化所带来的风险和一些优化的必要性：
保留一两次按键操作是不是与学习时刻的增加或信任度的减少价值相当？
未必。
不一致的语法不一致的命令录入风格
你能够通过指向它，按下一个功能键，或键入其名称、缩写或数字来选择一个命令。
一个程序应该利用一个命令风格。
若是程序为完成一样的任务提供了可选的风格，那么它应该在每处都提供相同的可选项。
若是必需在程序的不同部份之间转换风格，那么它必需弄清楚何时用哪个。
不一致的缩写
若是没有很明确的缩写规那么，缩写就不能容易地被记住。
把Delete缩写为Del，把Grep缩写为Grep，是没有任何意义的。
不一致的终止规那么
程序应该为多重键录入要求终结符。
不一致的命令选项
若是一个选项对两个或更多的命令成心义，那么它就应该对这些命令都可用（都不可用），它应该具有一样的名称，而且应该在两种情形下以一样的顺序被挪用。
名称相似的命令
若是两个命令名称相似，就很容易弄混。
尽可能不要利用相似的名称命名命令。
不一致的大写
若是命令录入是区分大小写的，所有命令的第一个字符都应该利用大写（小写）。
命令中嵌入单词的第一个字符应该一直大写（小写）。
另外，如非必要，不要在一个命令中利用多国语言。
不一致的菜单位置
若是同一命令在不同子菜单中显现，那么要在不同菜单的同一名置保留同一命令是很困难的。
不一致的功能键用途与其说明
功能键的意义在程序中应始终维持一致（倒置或是功能冲突是不能同意的）。
不一致的错误处置规那么
当程序检测到一个错误以后，它可能会发布该错误，或尝试更正错误。
任何一个程序的行为都应该是可预测的。
不一致的编辑规那么
当你输入或稍后检查任何数据时，一样的键和命令应该能够用来对其进行修改。
不一致的数据保留规那么
应该在每处都以一样的方式，在一样的时刻和范围内保留数据。
它不该该在每一个区域输入数据时保留数据，而其他时刻那么在一个记录、一组记录的末尾保留数据，或恰好在退出前保留数据。
浪费时刻
看起来为了浪费时刻而设计的程序会激怒每一个人。
曲折途径
若是为了抵达想要的命令，你必需一个接一个做出选择。
结果到最后发觉，该命令不存在或是不能实现亦或要求你先完成某件事乃至几件事后才能利用。
――明显的讹诈行为。
相信客户的不满和你的几乎没有任何区别。
不能采纳的选择
事实上没有任何接口在一个不能成立的菜单中包括选择项。
若是没有任何数据存在，你如何评审、保留和擦除数据？
没有打印机，如何打印文档？
有的命令不适合出此刻某些条件下（尽管对利用没有什么阻碍），可是开发人员可能为了图方便而保留了此类命令（很遗憾地说：
这太不专业了）；有时候，程序会提示寻求帮忙，而当你真的去利用的时候，程序却告知你“您没有利用帮忙的权限”――这还不如不让用户利用来得更好。
这种情形很常见，至于常常被开发人员和测试人员一起忽略――但这是不该该存在的错误。
你真的，真的确信么？
严峻损坏数据的命令需要如此重复的确认。
是的，这是必需的，如：
对一个写满数据的硬盘进行格式化的确需要多次确认。
可是没有必要对每一个细小的删除操作进行繁复的多次确认操作，用户会变得不耐烦，其结果是：
当用户进行严峻损坏性命令时，无视屏幕提示，造成不可估量的后果。
模糊不清或带有个人风格的命令
命令名应该明确指示该命令的作用。
不要让用户一边利用软件，一边查询用户手册中关于该命令的说明。
调查说明：
大多数用户在利用软件产品的时候只对软件手册做可能的了解，乃至全然不阅读。
别指望用户会很完整地阅读手册，那是咱们的工作。
没有任何理由在发布的程序中生成如：
finger等带有个人风格的命令，固然，若是在程序中显现了脏话，哦不，这是绝对不能许诺的。
菜单
菜单应该尽可能简练，当存在了太多风格不一，冗长和拙劣的图标或命令名，和被选择隐藏在不明显的主题之下的子项时，明白得它们将会变得超级复杂。
一个菜单覆盖的命令越多，不管如何计划，都会变得复杂，若是没有良好的计划，这对用户的利用将是一大障碍。
过于复杂的菜单层次
若是必需在最后抵达你想要的命令之前很费力地通过一个又一个菜单，那么我想我会选择利用另外一个功能相近的程序。
创建深层菜单树的程序员所引用的设计规那么说明，没有哪个菜单应该具有七个以上的选项，这一点对新手来讲可能时最好的。
有体会的用户更偏向于每一个菜单级别有更多项选择择，犯更少错误并更快速有效的做出反映，只要选项能合理组织，整齐排版，而且没有好笑的拥堵或拼写错误就好了。
不适当的菜单导航系统
即便在一个最适当的深层菜单系统中，你也必需能够返回到前一菜单，或移到菜单结构的顶层，并能在任何时刻离开程序。
太多途径抵达相同位置
若是许多命令在菜单中重复显现，那么程序就需要从头组织。
让一个命令在不同位置重复可能会很便利，可是存在必然的限制。
若是感觉上你能够从程序的任何位置抵达另一个任意位置――那就得从头考虑下程序的内部结构和靠得住性。
相关的命令被归属到不相关的菜单
把一个复杂菜单中对命令或主题进行分组并非是一件容易的情形。
人们都很容易轻忽两项之间明显关系，并把它们分派到分开的菜单中去，当需要对此进行调整时，咱们需要做的是：
说明两项之间的关系，并建议二者都应属于哪个菜单。
不相关命令被放置到同一菜单下
有些命令被扔到了完全无关的菜单下，如此并非好，宁可重新选择一个更高级别的题目并从头组织这些命令也不要那么做――若是那样做致使的混乱比较严峻的话。
命令行【一样比较少用到】
在没有提示的情形下键入命令要比在菜单中识别命令要宝贵多。
可是若是存在许多命令和选项，有体会的用户会更乐意利用更快更有效的命令行输入方式录入。
此类软件如AutoCAD等。
菜单系统对用户可能太过于庞大了。
大小写之间的强迫性不同
若是没有正确的大小写，有些程序不能识别一个正确的拼写命令。
通常，这不是一个特色，而是一件麻烦事。
参数倒置或是命令意义模糊
最多见的例子确实是源文件和目标文件之间的不同。
比如：
CopyFile1File2；你可能全然就不明白它是指文件1到文件2的拷贝，仍是文件2到文件1的拷贝，或仅仅是拷贝了文件1和文件2？
顺序并非重要（这些适应能够被后天培育），可是需要使命令的意义明确并维持一致。
应用程序必需遵循操作系统的老例，而不是特意地从头概念――除非必要。
全命令名不被许诺
缩写是专门好，可是你总应该许诺Delete的存在，而不单单只是Del。
一个可记
升级会员 