Usability的概念在中国开始逐渐为企业所认识，但是作为这个领域的核心词汇，usability的中文翻译仍未统一。目前存在着两个主流版本：“可用性”和“易用性”。这两个译法虽然只有一字之差，但它们所传达的含义却大相径庭。对这两者的取舍已经不仅仅是哪个更好一点的锦上添花的问题，而是哪个对哪个错的是非原则问题。“易用性”的使用对于正确理解usability具有极大的片面性和误导性，非常不利于其在中国的开展。

从英文原词上分析，usability是由use（动词）变化到usable（形容词）然后再转变为usability（名词）。Use这个词从动词到名词的过程还有另一种变化，就是从use（动词）到useful（形容词）再到usefulness（名词）。后者要比前者更“单纯”，变化的过程只是词性的改变而不涉及意思的转化。这些变化都围绕着use这个核心展开，因此在意思上都离不开“用”这个概念。-ability这个词根代表“具备某种行为特性”这样一个抽象的概念，故而在中文翻译中通常译为“可…性”，例如：readability（可阅读性）。因此，“可用性”这个译法是在严格遵从语言和翻译习惯的基础上形成的。“易用性”虽然也保留了这个“用”这个核心意思，但是其中的“易”字却完全是无中生有，因为在英文单词的整个变化过程中始终没有任何一丝“易”的意义出现。

对于为什么要人为加上“易”字，一个看似合理的解释是这是意译。那么usability是不是就是“易用”呢？不妨先看看usability的解释。世界标准组织对于usability的定义是“The extent to which a product can be used by specified users to achieve specified goals with effectiveness， efficiency and satisfaction in a specified context of use.”这个定义采用了effectiveness（效果）、efficiency（效率）和satisfaction（满意）三个维度来说明usability.尽管这三个维度并不构成usability的全部，但是在测量usability时它们是被最广泛采用的指标。如果说efficiency和satisfactory这两个维度还可以和“易用”扯上关系的话，那么effectiveness这个维度显然和“易用”是互相独立的两个概念。因此，意译这个说法同样是无法成立的。

事实上，“易用”在usability领域是有一个专门用语的，那就是ease of use.在英文文献中，没有人会简单地将ease of use与usability划等号。但是当usability进入中国以后，“易用性”却堂而皇之地以代言人的身份四处出现。也许有人认为“易用性”这个词比较直观，容易被大众理解和接受。殊不知这正是“易用性”的危害。如果放任“易用性”的使用， usability这个概念在中国恐怕将被局限在ease of use这个狭窄的范围之中。作为一个术语，是不是很容易从字面上理解其含义并不是第一重要的，“递归”这个术语就是一个很好的例子。对一个术语的翻译，在艰涩与误导之间永远都不应该选择误导。更何况“可用性”的译法远没有达到艰涩的地步。

让我们向“易用性”说不！ 

1、分粥

　　有七个人曾经住在一起，每天分一大桶粥。要命的是，粥每天都是不够的。一开 始，他们抓阄决定谁来分粥，每天轮一个。于是乎每周下来，他们只有一天是饱的，就是自己分粥的那一天。后来他们开始推选出一个道德高尚的人出来分粥。强权 就会产生腐败，大家开始挖空心思去讨好他，贿赂他，搞得整个小团体乌烟障气。然后大家开始组成三人的分粥委员会及四人的评选委员会，但他们常常互相攻击， 扯皮下来，粥吃到嘴里全是凉的。最后想出来一个方法：轮流分粥，但分粥的人要等其它人都挑完后拿剩下的最后一碗。为了不让自己吃到最少的，每人都尽量分得 平均，就算不平，也只能认了。大家快快乐乐，和和气气，日子越过越好。

　　同样是七个人，不同的分配制度，就会有不同的风气。所以一个单位如果有不好的工作习气，一定是机制问题，一定是没有完全公平公正公开，没有严格的奖勤罚懒。如何制订这样一个制度，是每个领导需要考虑的问题。

2、表演大师

　 　有一位表演大师上场前，他的弟子告诉他鞋带松了。大师点头致谢，蹲下来仔细系好。等到弟子转身后，又蹲下来将鞋带解松。有个旁观者看到了这一切，不解地问："大师，您为什么又要将鞋带解松呢？"大师回答道："因为我饰演的是一位劳累的旅者，长途跋涉让他的鞋事松开，可以通过这个细节表现他的劳累憔悴." "那你为什么不直接告诉你的弟子呢？""他能细心地发现我的鞋带松了，并且热心地告诉我，我一定要保护他这种热情的积极性，及时地给他鼓励，至于为什么要 将鞋带解开，将来会有更多的机会教他表演，可以下一次再说啊。"

　　人一个时间只能做一件事，懂抓重点，才是真正的人才。

3、鹦鹉
 
　 　一个人去买鹦鹉，看到一只鹦鹉前标：此鹦鹉会两门语言，售价二百元。另一只鹦鹉前则标道：此鹦鹉会四门语言，售价四百元。该买哪只呢？两只都毛色光鲜， 非常灵活可爱。这人转啊转，拿不定主意。结果突然发现一只老掉了牙的鹦鹉，毛色暗淡散乱，标价八百元。这人赶紧将老板叫来：这只鹦鹉是不是会说八门语言？ 店主说：不。这人奇怪了：那为什么又老又丑，又没有能力，会值这个数呢？店主回答：因为另外两只鹦鹉叫这只鹦鹉老板。

　　这故事告诉 我们，真正的**，不一定自己能力有多强，只要懂信任，懂放权，懂珍惜，就能团结比自己更强的力量，从而提升自己的身价。相反许多能力非常强的人却因为 过于完美主义，事必躬亲，什么人都不如自己，最后只能做最好的公关人员，销售代表，成不了优秀的**。
　　
4、金人

　　 曾经有个小国的人到中国来，进贡了三个一模一样的金人，金碧辉煌，把皇帝高兴坏了。可是这小国的人不厚道，同时出一道题目：这三个金人哪个最有价值？皇帝 想了许多的办法，请来珠宝匠检查，称重量，看做工，都是一模一样的。怎么办？使者还等着回去汇报呢。泱泱大国，不会连这个小事都不懂吧？最后，有一位退位 的老大臣说他有办法。皇帝将使者请到大殿，老臣胸有成足地拿着三根稻草，插入第一个金人的耳朵里，这稻草从另一边耳朵出来了。第二个金人的稻草从嘴巴里直 接掉出来，而第三个金人，稻草进去后掉进了肚子，什么响动也没有。老臣说：第三个金人最有价值！使者默默无语，答案正确。

　　这个故事告诉我们，最有价值的人，不一定是最能说的人。老天给我们两只耳朵一个嘴巴，本来就是让我们多听少说的。善于倾听，才是成熟的人最基本的素质。
　　
5、辞职

　 　A对B说："我要离开这个公司。我恨这个公司！"B建议道："我举双手赞成你报复！！破公司一定要给它点颜色看看。不过你现在离开，还不是最好的时 机。"A问：为什么？B说："如果你现在走，公司的损失并不大。你应该趁着在公司的机会，拼命去为自己拉一些客户，成为公司独当一面的人物，然后带着这些 客户突然离开公司，公司才会受到重大损失，非常被动。"A觉得B说的非常有理。于是努力工作，事遂所愿，半年多的努力工作后，他有了许多的忠实客户。再见 面时B问A：现在是时机了，要跳赶快行动哦！A淡然笑道：老总跟我长谈过，准备升我做总经理助理，我暂时没有离开的打算了。

　　其实这也正是B的初衷。一个人的工作，永远只是为自己的简历。只有付出大于得到，让老板真正看到你的能力大于位置，才会给你更多的机会替他创造更多利润。
　　
6、选择

　 　有三个人要被关进监狱三年，监狱长给他们三个一人一个要求。美国人爱抽雪茄，要了三箱雪茄。法国人最浪漫，要一个美丽的女子相伴。而犹太人说，他要一部 与外界沟通的电话。三年过后，第一个冲出来的是美国人，嘴里鼻孔里塞满了雪茄，大喊道："给我火，给我火！"原来他忘了要火了。接着出来的是法国人。只见 他手里抱着一个小孩子，美丽女子手里牵着一个小孩子，肚子里还怀着第三个。最后出来的是犹太人，他紧紧握住监狱长的手说："这三年来我每天 与外界联系，我的生意不但没有停顿，反而增长了200％，为了表示感谢，我送你一辆劳斯莱斯！"

　　这个故事告诉我们，什么样的选择决定什么样的生活。今天的生活是由三年前我们的选择决定的，而今天我们的抉择将决定我们三年后的生活。我们要选择接触最新的信息，了解最新的趋势，从而更好的创造自己的将来。
　　
7、老虎

　　两个人在森林里，遇到了一只大老虎。A就赶紧从背后取下一双更轻便的运动鞋换上。B急死了，骂道："你干嘛呢，再换鞋也跑不过老虎啊！"A说："我只要跑得比你快就好了。"

　　二十一世纪，没有危机感是最大的危机。特别是入关在即，电信，银行，保险，甚至是公务员这些我们以为非常稳定和有保障的企业，也会面临许多的变量。当更多的老虎来临时，我们有没有准备好自己的跑鞋？
　　
8、赶考

　 　有位秀才第三次进京赶考，住在一个经常住的店里。考试前两天他做了三个梦，第一个梦是梦到自己在墙上种白菜，第二个梦是下雨天，他戴了斗笠还打伞，第三 个梦是梦到跟心爱的表妹脱光了衣服躺在一起，但是背靠着背。这三个梦似乎有些深意，秀才第二天就赶紧去找算命的解梦。算命的一听，连拍大腿说："你还是回 家吧。你想想，高墙上种菜不是白费劲吗？戴斗笠打雨伞不是多此一举吗？跟表妹都脱光了躺在一张床上了，却背靠背，不是没戏吗？"秀才一听，心灰意冷，回店 收拾包袱准备回家。店老板非常奇怪，问："不是明天才考试吗，今天你怎么就回乡了？"秀才如此这般说了一番，店老板乐了："哟，我也会解梦的。我倒觉得， 你这次一定要留下来。你想想，墙上种菜不是高种吗？戴斗笠打伞不是说明你这次有备无患吗？跟你表妹脱光了背靠靠躺在床上，不是说明你翻身的时候就要到了 吗？"秀才一听，更有道理，于是精神振奋地参加考试，居然中了个探花。

　　积极的人，像太阳，照到哪里哪里亮，消极的人，像月亮，初一十五不一样。想法决定我们的生活，有什么样的想法，就有什么样的未来。
　　
9、骆驼

　 　在动物园里的小骆驼问妈妈："妈妈妈妈，为什么我们的睫毛那么地长？"骆驼妈妈说："当风沙来的时候，长长的睫毛可以让我们在风暴中都能看得到方向。" 小骆驼又问："妈妈妈妈，为什么我们的背那么驼，丑死了！"骆驼妈妈说："这个叫驼峰，可以帮我们储存大量的水和养分，让我们能在沙漠里耐受十几天的无水 无食条件。"小骆驼又问："妈妈妈妈，为什么我们的脚掌那么厚？"

　　骆驼妈妈说："那可以让我们重重的身子不至于陷在软软的沙子里，便于长途跋涉啊。"小骆驼高兴坏了："哗，原来我们这么有用啊！！可是妈妈，为什么我们还在动物园里，不去沙漠远足呢？"
　　
　　天生我才必有用，可惜现在没人用。一个好的心态+一本成功的教材+一个无限的舞台=成功。每人的潜能是无限的，关键是要找到一个能充分发挥潜能的舞台。
　　
10、陈阿土
　 　
　　陈阿土是台湾的农民，从来没有出过远门。攒了半辈子的钱，终于参加一个旅游团出了国。国外的一切都是非常新鲜的，关键是，陈阿土参加的是豪华团，一个人 住一个标准间。这让他新奇不已。早晨，服务生来敲门送早餐时大声说道："GOOD MORNING SIR！"陈阿土愣住了。这是什么意思呢？在自己的家乡，一般陌生的人见面都会问："您贵姓？"于是陈阿土大声叫道："我叫陈阿土！"如是这般，连着三天，都是那个服务生来敲门，每天都大声说："GOOD MORNING SIR！"而陈阿土亦大声回道："我叫陈阿土！"但他非常的生气。这个服务生也太笨了，天天问自己叫什么，告诉他又记不住，很烦的。终于他忍不住去问导 游，"GOOD MORNING SIR！"是什么意思，导游告诉了他，天啊！！真是丢脸死了。陈阿土反复练习"GOOD MORNING SIR！"这个词，以便能体面地应对服务生。又一天的早晨，服务生照常来敲门，门一开陈阿土就大声叫道："GOOD MORNING SIR！"与此同时，服务生叫的是："我是陈阿土！"

　　这个故事告诉我们，人与人交往，常常是意志力与意志力的较量。不是你影响他，就是他影响你，而我们要想成功，一定要培养自己的影响力，只有影响力大的人才可以成为最强者。

有一天动物园的管理员们发现袋鼠从笼子里跑出来了，于是开会讨论，一致认为是笼子的高度过低，从而导致袋鼠从笼子里跳了出来。所以他们决定将笼子的高度由原来的十公尺加高到二十公尺。谁知第二天，他们发现袋鼠依旧能够跑到外面来，所以他们又决定再将高度加高到三十公尺。

　　然而，沒料到第三天居然又看到袋鼠全跑到外面，于是管理员们大为紧张，决定一不做二不休，索性将笼子的高度加高到一百公尺：“嘿嘿，这下子看你还能不能跳出如来佛的神掌？”

　　第四天，神了，袋鼠还是从笼子里跑了出来，而且，还在与它们的好朋友长颈鹿聊天呢。“你们看，这些人会不会再继续加高你们的笼子呢？”长颈鹿问。

　　“很难说，”袋鼠说：“如果他们再继续忘记关门的话！”

事有“本末”、“轻重”、“缓急”，关门是本，加高笼子是末，舍本而逐末，当然就不得要领了。管理是什么？管理是抓事情的“本末”、“轻重”、“缓急”。

　　其实我们只要界定问题，把问题简单化、明确化、重要化(即判断出问题的重要性)，那么问题就解决了一半。

使用因果图的好处

1 考虑了多个输入之间的相互组合、相互制约关系

2 能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题

利用因果图导出测试用例需要经过的一般步骤

1.分析程序规格说明的描述中，哪些是原因，哪些是结果。

2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图

3.在因果图上使用若干个特殊的符号标明特定的约束条件

4.把因果图转换成判定表

5.把判定表中每一列表示的情况写成测试用例

因果图基本符号

见图一 因果图基本符号；图二 约束符号

因果图实例讲解

某软件规格说明中包含这样的要求：
第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L;如果第二列字符不是数字，则给出信息M。

分开原因和结果

原因：1----第一列字符是A;
2----第一列字符是B;
3----第二列字符是一数字。
结果：21----修改文件;
22----给出信息L;
23----给出信息M。

见图三 因果图

此例子是讲解利用因果图设计测试用例的一个小例子。以中国象棋中走马的测试用例设计为例学习因果图的使用方法。

一、 分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）
1、如果落点在棋盘外，则不移动棋子；2、如果落点与起点不构成日字型，则不移动棋子；3、如果落点处有自己方棋子，则不移动棋子；4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；5、如果不属于1-4条，且落点处无棋子，则移动棋子；6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；7如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。

二、 根据分析明确原因和结果

原因：
1、 落点在棋盘上；
2、 落点与起点构成日字；
3、 落点处为自己方棋子；
4、 落点方向的邻近交叉点无棋子；
5、 落点处无棋子；
6、 落点处为对方棋子（非老将）；
7、 落点处为对方老将。
结果：
21、不移动棋子；
22、移动棋子；
23、移动棋子，并除去对方棋子；
24、移动棋子，并提示战胜对方，结束游戏。

添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表

见图四 图五

考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所以对其施加异约束E.

根据因果图建立判定表：(分为两表)

见图六

　　小提示：Wireshark的前世今生
　　说起Wireshark就不得不提Ethereal了，Ethereal和在Windows系统中常用的sniffer pro并称网络嗅探工具双雄，不过和sniffer pro不同的是Ethereal在Linux类系统中应用更为广泛。而本文介绍的Wireshark软件则是Ethereal的后续版本，他是在Ethereal被收购后推出的最新网络嗅探软件，在功能上比前身更加强大。

　　一、安装Wireshark
　　安装Wireshark的步骤比较简单，基本上和传统软件一样。不过需要特别注意的是Wireshark类网络嗅探软件都需要Winpcap的支持，因此还需要安装WinPcap3.1。
　　启动Wireshark安装程序，该软件是英文界面的。一直点“NEXT”按钮直到组件选择设置窗口，这里需笔者建议各位将所有组件都选中，这样才能够更好的发挥Wireshark的强大网络监控功能（如图1）。

　　在选择附加参数时需要将File extensions文件扩展处的对勾选中，这样方便我们日后通过Wireshark打开这些网络嗅探文件（如图2）。

　　接下来Wireshark会提示自动安装Winpcap3.1，如果本机没有安装该程序的话，我们只需要选中该组件后点“Install”按钮即可（如图3）。

　　二、使用Wireshark监测网络数据
　　安装完毕后会在桌面出现Wireshark图标，我们直接运行他即可。初次启动需要设置Wireshark要监视的网卡，由于很多设备都会虚拟成网卡存在于系统中，包括蓝牙，虚拟网卡等等，因此在选择时一定要选中自己的真实网卡。

　　我们通过Wireshark主界面的“Capture（捕获）->Options（设置参数）”来选择网卡（如图4）。按照笔者所说从interface下拉菜单处找到自己机器的真实网卡，像笔者演示的那样，下拉菜单存在四个选项，从上到下依次为虚拟拨号，虚拟网卡，蓝牙适配器网络以及自身的物理网卡。设置完毕后如果没有其他特殊设置需求直接点“Start”按钮即可开始检测网络中的数据包（如图5）。

　　（1）检测网中是否有MSN或QQ在使用
　　有的时候我们企业不希望员工在上班时通过MSN或QQ聊天，并针对这些IM交流软件进行了封锁，但是封锁和突破总是对立的，很多员工会找到代理工具或者其他方法来突破限制。不过不管他采用何种方法都无法逃避Wireshark的火眼金睛。

　　我们打开Wireshark并设置好监控网卡，之后扫描网络中的数据，收集一段时间后停止捕获来查看数据包，如果网络中有MSN或者QQ在使用，Wireshark会记录这些数据通话，在protocol协议处显示为ICQ的通讯就是OICQ，而显示为MSNMS的话则说明此数据包是MSN发送接收的，并且通过具体内容我们还可以看到MSN的通话对象的邮件地址（如图7）。

　　（2）按需捕获制订扫描规则
　　可能有的读者会遇到捕获后发现的数据包过多，无法分析的问题。实际上Wireshark容许我们制订过滤规则，也就是说让Wireshark只捕获我们感兴趣的数据包。具体方法是在主界面选择“Capture（捕获）->Capture filter（捕获规则）”，然后根据系统自带的过滤规则或者自己研究他的规则语句来指定适合自己的捕获规则（如图8）。

　　（3）检测明文数据包
　　正如前面所说Wireshark可以针对网络中的明文数据包内容进行分析，例如我们在使用telnet来管理路由交换设备时所有的传输数据都是基于明文的，这样通过Wireshark可以将telnet输入的指令分析出来。
　　首先检测网络数据包，如果在检测过程中有人进行telnet操作，那么在数据包显示窗口中会看到对应的telnet协议，以及通讯双方的IP地址信息（如图10）。

　　Wireshark是功能强大的网络数据捕获工具，他可以帮助我们分析网络数据流量，在第一时间发现蠕虫病毒，木马程序以及ARP欺骗等问题的根源。相信各位网络管理员一经使用就会爱上他而离不开他。

关于测试技巧

        黑盒测试，尤其是手工黑盒测试的业绩，有七成决定于个人因素。

        测试需要有高度的责任心和使命感，要有主人翁精神。任何工作只有敬业才能做出成绩，工作主动了，自然会得到回报。

        在很多情况下，问题的现象出现了，但规律却不明显。当问题提交后，在开发那里却死活不能重现，这种情况是很尴尬和无奈的。所以，作为一个出色的测试工程师，仅仅捕获到问题的现象是远远不够的，还要找到其规律，甚至弄懂它更深层次的原因。

        遇到这类问题怎么办？很多人可能就此放弃了，因为说他是"无规律或不能重现事件"。在我看来，这种说法是错误的。我认为，一定要树立起一个观念，那就是："任何错误的出现，都绝不是偶然的。每个错误现象背后都隐含着一个必然的规律，不管是肤浅的，还是深奥的。"而测试的目的，就是要把这个规律挖出来。因为，规律总结得越准确，对问题的定位和解决帮助就越大。

        做好测试工作必须要做到几条：首先，要努力培养起对测试的兴趣；要培养对所测产品的感情，要像对待自己孩子一样去热爱它，呵护它。其次，要胆大并心细。要有游走于高山峡谷边缘的那种"如临深渊，如履薄冰"的胆量和谨慎。要敢于怀疑，大胆假设而小心求证。再次，要有耐心，戒骄戒躁，心要安静。

        如果说测试有技巧的话，也仅占到三成：

        1、对待问题要锲而不舍，并善于总结经验。

        举一个案例，对于"方正飞腾（报社专用排版软件）自动勾边死机问题"规律的发现，我现在还记忆犹新。我1997年刚接触这款软件时就遇到了该问题，但问题变化无常，当时找不到一点儿规律：有时，在关键位置点一下鼠标就死，有时点100多次才死，有时怎么点都不会死。该问题整整困扰了我一年，直到有一天，我盯着屏幕发呆，发现鼠标变成了漏斗，我随便点了一下<调整>按钮，程序立刻死机。当时灵机一动，莫非跟"自动存盘"有关？判断是正确的！一年来的谜终于被解开了，而受此启发，后来遇到"非法字体窗口"、"自动翻页"、以及"删除表格"所引发的死机，不到1秒的时间，我就准确定位与自动存盘有关。

        对于疑难问题，不妨先放他一放，过几天再去想，说不定就会有新思路冒出来，有新灵感被激发出来。对于每一个解决的疑难问题，都要认真分析它的原因，总结定位经验，并推演联想到其他模块。测试过程是一个循序渐进的过程，是一个经验积累的过程。以一年的摸索换来若干个一秒钟的思索，值！还有很多典型案例，限于篇幅，不便罗列。

        2、善于推理，善于运用逆向思维。善于换位思考，变换角色对待问题；

        3、善于和别人共享经验，站在别人已有的思路上进一步深入，多动脑筋，多动手。

        4、简化问题规律的步骤，弄清楚问题产生的原因，总结程序员的教训，对类似问题可以触类旁通。

        5、不断地怀疑，不断地推翻怀疑。突破跳出思维定式，大胆假设，小心求证。

 将军围猎

        曾经在文字所和测试中心流传一句话："软件里的bug如同海绵里的水，要想挤总会有的"。旧bug的修改往往会引发新bug的产生，所谓"按下葫芦起来瓢"。

        如何培养测试人员的对测试工作的兴趣呢？不妨把bug比作藏匿在深山丛林中的猎物，把自己比作围猎的将军。程序中的bug变化莫测，要有将军指挥作战的气度，怎样更快更准更有效地定位它们，捕获住它们？围追堵截之中，尽显英雄本色。

        兵法上说，水因地而制行，兵因敌而制胜。兵无常势，无恒形，能与敌变化而取制者，谓之神。仅仅通过黑盒测试，你就能知道程序员做了什么改动？怎样做的改动？还存在什么缺陷？并快速准确地把它定位出来。若能达到这种境界，让你的思维能力受到如此的锻炼和考验，难道还不会有成就感么？

        当你全身心地投入在测试中，你会感觉到测试，实际上是一场智力游戏。所谓"气痴者技精"，因为一进入状态，坐下来就会忘记时间的流逝。

        一直以来，总想写一写关于测试方面的文章。今天，真的接到这个题目时，却欲言又止，迟迟不能落笔。在这里，我也只将自己的实际经验介绍给大家，抛砖引玉，和大家共同探讨。

        刚开始做测试的同事会有一种感觉，认为测试实际上是在充当这个产品的第一用户。也有人认为，测试其实很简单，没有什么技术可言。

        其实，测试说易也易，因为进入门槛低；说难也难，因为测深测精不简单。黑盒测试很讲究策略，测试也是一门学问。

 初涉测试的心路历程

        对测试的认识，每个测试人员都有一个过程。我对测试的认识，在每个阶段各不相同，其中也走了不少弯路。在此，我用第三人称把自己对测试工作的认识过程写出来，希望后来的同事能从中得到启发。

 第一阶段  学习+验证

        对于新来的同事，刚刚涉及测试，往往踏不下心来。感觉测试是件没完没了地事情，并且单调重复、枯燥乏味，没有激情、没有成就感。这是很正常的现象，刚进入一个新的岗位，总有一个适应过程。

        在这一阶段，新员工需要做的事情是，先学会使用所测的软件，熟悉他的每一个功能，弄清楚每一个功能的正确效果应该是什么？然后才开始尝试着去找一些肤浅的问题。这一阶段的感觉是："测试实际上就是验证产品每个功能的有效性"。新员工这一阶段虽然不太出成绩，但却很重要，因为这是以后工作的基础。

 第二阶段  与开发对立的误区

        当熟悉了所测产品的功能，并且找到测试的感觉后，就开始较深入地测试了。

        在这一阶段，新员工会逐渐发现一些严重的BUG。当看到自己发现的问题被解决后，才真正感觉到自己在参与产品的生产。渐渐地，渐渐地，就会感觉到测试其实也挺有趣。尤其是发现一些死机或特别严重的错误时，有时会兴奋上几个小时。这是他进入状态的必然过程。

        此时，他对测试的认识是："测试，就是要找出产品的缺陷，是证明当前产品不可用的一种行为"。这一阶段非常值得注意！很多软件公司常说："开发和测试的行为是对立和矛盾的"，这实际上是测试工作的误区。

 第三阶段  与开发主动配合

        随着测试经验的积累，对工作的认识也逐步深入。最后，他会发现，开发和测试之间，本质上是一个合作的过程，目标本是一致的。都是为了尽量减少发布产品中的错误，达到用户可接受的程度。于是，他会更多地站在用户角度考虑问题，测试的目的也越来越明确，工作也越来越主动。

 第四阶段  责任感+验证

        当经历了产品的几个生命周期之后，从不断的需求、开发、维护、升级循环过程中，逐渐认识到，测试实际上是降低产品风险的一种行为。逐步认识到，测试介入的环节越早，风险也就越小。

        在和最终用户多次打交道，亲身体验用户的心情之后，油然而生出一种强烈的责任感，对测试的理解也随之升华为一种产品意识：测试工作和研发工作，实际上是一种荣辱与共的关系，取得的成绩和造成的失误，其荣誉和责任是同等的。此时，当他发现一个致命的错误或缺陷时，第二阶段的那种兴奋也许只会存在3秒钟。此时的他，更多考虑的是怎样帮助研发组尽快地把该问题解决掉。在这一阶段，测试工作中更注重产品的实用性和易用性。

        从学习阶段对产品的验证，到与研发的对立，到主动地和研发配合，到一种责任感使命感自发地对功能的验证，这是一个高级测试人员所必然要经历的一个心路历程。

 测试中的几种思维方式

        测试能否出成绩？以及测试工作的优劣，与个人的素质和修养有关。

        测试工作说易也易，只要认真、负责，就能做出一些成绩。但说难也难，测试讲究很多方法和策略，要测的精，问题定位的及时准确，规律找的准确有效，那是需要下一番功夫的。在此，我把测试中常用的几种思维方式共享如下：

正向思维

        在测试一个产品之前，需要做的重要事情是，熟读产品的设计文档，详细了解每个功能的正确效果。然后针对每个模块，顺着程序员的思路，逐个验证，以验证测试功能的有效性。这是以后深入测试的基础，也是做自动测试的前提。

        搞清楚每个模块是干什么的，弄清楚正确的效果，才知道什么是错误的。这是非常关键的一个环节，如果在这方面不下功夫，也就很难测试出有价值的BUG。因为，很明显的错误结果可能就在你眼前大摇大摆地经过，而你却认为这是正确的！我就曾经一度陷入这一误区，好在很快地补上了这一课。

逆向思维

        关于"逆向思维"，我有两种解释，一是针对开发人员。

        开发人员在调试或自测时，总爱顺着已有的思路进行。所以，在很多情况下容易忽略自己所犯的错误，例如边缘条件检查，异常处理等等。所谓当局者迷，旁观者清，是因为你可以跳出他的思维定式，从另外的角度来思考问题。所以，只要你肯动脑筋，不按他的逻辑进行检测，就一定能找出许多破绽。

关于"逆向思维"的第二种解释，是针对具体问题。

        当发生严重问题时，首先要保护好现场，然后努力地回忆，努力地理清思路。要善于从错误现象的最后一步往前倒推。例如死机问题，仅一个现象并不能说明问题，关键要找出它的规律。规律有时是最后一步操作导致，而有时则是前几十步操作的累加，这需要我们追忆刚才的几十步操作，并大胆怀疑其中的疑点，有目的的undo、redo。这一招叫顺藤摸瓜，抓住规律的尾巴，从最后一步开始。

  跳跃性思维

          我也称它为联动思维。

        有时，一个问题表现出来的现象和问题的本质会差着十万八千里，这类问题的规律也极难准确地捕捉到。处理这类问题，需要有扎实的测试基本功，并对产品非常地熟悉，才能把表面上毫不相关，却有着千丝万缕关系的孤立的两点联系起来；才能从一处错误得到启示，联想到其他模块也可能存在类似的问题......

软件测试之文档测试介绍

　产品说明书属性检查清单

　　1.完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？

　　2. 准确：既定解决方案正确吗？目标明确吗？有没有错误？

　　3. 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？

　　4. 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?

　　5. 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?

　　6. 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?

　　7. 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?

　　8. 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?

　　产品说明书用语检查清单

　　说明：对问题的描述通常表现为粉饰没有仔细考虑的功能可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱,也可能含糊其词 无论是哪一种情况都可视为软件缺陷

　　9. 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例

　　10. 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。

　　11. 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。

　　12.等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。

　　13. 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。

　　14. 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。

　　15. 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则"结构的陈述，想一想 " 如果 " 没有发生会怎样。

　　简明性、明确性：在软件开发各个阶段所编写的各种文档的语言表达清晰、准确、简练，适合各种文档的特定读者即提供的用户手册要对系统中每部分的在各个阶段的功能有明确。

　　描述，对于工作流程也有明确叙述，让用户很清楚的知道自己处于流程中的什么位置，在做什么，接下来该做什么或者应该怎么做。

　　内容完整性：按照软件开发流程编制相应的文档，提供用户操作手册及在线帮助。

　　用户操作手册要全面、细致的每个模块操作步骤以及每步所要达到的目标。

　　在线帮助要详细列出用户在工作中可能遇到的问题，并针对每个问题提出详细的解决方案，要充分起到“实时”给予帮助的目的。

　　准确规范性、可读性：用户手册、用户操作手册以及在线帮助要做到用语规范，准确，可读性，符合客户要求的编写规范标准，使用户操作起来简单明了，例如在某环节出现了问题，用户能够利用在线帮助很快且顺利的找到相应的帮助文档，最终达到解决的目的。

　　可追踪性：指在不同文档的之间或则同一文档某一内容在本文档中的涉及范围可追踪性。

　　自说明性：各个阶段中的文档能独立、清楚的表达出对应于该文档所处的阶段而开发出的软件产品所具有的功能。

第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

第四步：提交缺陷。这里要进行缺陷审核和验证等工作。

第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改进。

1. 功能测试

1.1.链接测试

　　 链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。

　　 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。

1.2. 表单测试

　　 当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

1.3.Cookies测试

　　Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　 如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。

1.4.设计语言测试

　　Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript. 、 ActiveX 、 VBScript. 或 Perl 等也要进行验证。

1.5.数据库测试

　　 在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。 　　在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

2. 性能测试

2.1.连接速度测试

　　 用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。
　　 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2.2.负载测试

　　 负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？

2.3.压力测试

　　负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。

　　 压力测试的区域包括表单、登陆和其他信息传输页面等。

3. 可用性测试

3.1.导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？

　　 在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。

　　 导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。
Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

3.2.图形测试

　　 在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　 （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
　　 （2）验证所有页面字体的风格是否一致。
　　 （3) 背景颜色应该与字体颜色和前景颜色相搭配。
　　 （4）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。

3.3.内容测试

　　 内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。

3.4.整体界面测试

　　 整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览 Web 应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个 Web 应用系统的设计风格是否一致？

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　 对所有的可用性测试来说，都需要有外部人员（与 Web 应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

4. 客户端兼容性测试

4.1.平台测试

　　 市场上有很多不同的操作系统类型，最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　 因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。

4.2.浏览器测试

　　 浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java ，、 JavaScript. 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如， ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的， JavaScript. 是 Netscape 的产品， Java 是 Sun 的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。

　　 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

5. 安全性测试

Web 应用系统的安全性测试区域主要有：

　　 （ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　 （ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

　　 （ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　 （ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　 （ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

6. 总结

　　 本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。

　　基于 Web 的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。