软件黑盒测试心得与经验.docx
《软件黑盒测试心得与经验.docx》由会员分享，可在线阅读，更多相关《软件黑盒测试心得与经验.docx（26页珍藏版）》请在冰豆网上搜索。
软件黑盒测试心得与经验
软件黑盒测试心得与经验
WrittenbyStevenWang
Version1.00
Http:
//Blog.51T
版本更新历史
●1.00版本
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？
顺序并不重要（这些习惯可以被后天培养），但是需要使命令的意义明确并保持一致。
应用程序必须遵循操作系统的惯例，而不是特意地重新定义――除非必要。
全命令名不被允许
缩写是很好，但
升级会员 