原文链接：http://www.51testing.com/html/43/n-246043.html

作为黑盒测试的一个重要阶段，功能测试毋庸置疑是不可缺失的。功能测试的相关话题很多，无论是测试的形式，例如手动测试和自动化测试，还是测试方法，例如数据驱动和关键字驱动，都有大量的研究文章。我这篇博文里却打算从国别不同的角度来讨论一下功能测试的差异，原创文章可能有一些谬误的地方，请读者指摘。

　　日式循规蹈矩

　　日本人给世界其他民族的印象是做事认真严谨，对待问题一丝不苟，犯了错误按严重程度该下跪的下跪，该剖腹的剖腹。他们的这种一贯行事方式也带到了软件行业，而软件行业的摩尔定律，技术的日新月异，代码、框架的多变，都似乎与他们的性格格格不入。日本制造的东西一向以坚固耐用著称，给我映像最深的一个细节是，在日本工作的时候，发现他们的垃圾袋居然都坚固无比，用来逛超市买东西拎重物也是屡用不坏。然而，对于遵从摩尔定律的计算机行业来说，投入大量的精力来尽可能的发现bug以及解决问题是否很值，这真的是有待商榷的问题。

　　但，话虽如此，日企采用的测试用例的设计方法还是非常值得我们学习的，这其中又首先要提一下要因分析法（网上有些说法把鱼骨图等同于要因分析法，我并不赞同此说，后面会有详述）。

　　要因分析法的精髓在于，以产品的某一特性为因子，以这个特性的不同表现（根据等价类划分、边界值分析等方法）为状态，一一列举后，采用二维组合的方式来确定测试用例。

　　下面我举一个简单的例子“我打算从南京去北京”来说明。

表1

　　这即是一张简单的要因表，值得注意的是，因子和状态的确定是必须规定范围的，而这个范围在这个例子中则为“正常人的思考”范围。譬如说，“交通方式”我没有写“步行”，因为这不符合常人从南京去北京的思考方式，当然有人为了挑战吉尼斯纪录，这里非要采用步行方式从南京前往北京，那么状态里添加这项显然是可以的。

　　此外，因子和状态的另一个隐性的确定方针为详细度，这个度如何把握，我们可以从下表来理解：

表2

　　表2将表1的“交通方式”进一步细化，此时状态的选择将进一步增多。如果要求详细度更加提高，例如因子为“动车”，那么可以加上状态为“一等座”和“二等座”，这种组合很灵活，取决于我所需的详细级别。

　　要因确定之后，便是组合，以表1所列要因为例，二维组合有下列共18种：

飞机-晴-白天，飞机-雨-白天，飞机-雪-白天，飞机-晴-夜晚，飞机-雨-夜晚，飞机-雪-夜晚 火车-晴-白天，火车-雨-白天，火车-雪-白天，火车-晴-夜晚，火车-雨-夜晚，火车-雪-夜晚 汽车-晴-白天，汽车-雨-白天，汽车-雪-白天，汽车-晴-夜晚，汽车-雨-夜晚，汽车-雪-夜晚

　　对于表2来说，二维组合则有2*4*2*3*2=96种，貌似有点多，当然你想分析的越详细，那么组合数量自然会相应的增加。

　　回到表1得出的18种用例，假如我的通过条件是从南京到北京的时间越短越好，在实际的外界环境下（例如晴天，预期花费有限额），这18个用例中，就会出现有的测试通过，有的测试失败的情况了。在不同的实际外界环境下，测试通过的情况还会发生变化（例如下雪天，飞机会发生班次延误）。

要因分析法的好处在于“事无巨细，滴水不漏”，坏处在于过程“繁琐冗长，枯燥乏味”。即使如此细致的要因分析，依然存在一定的用例遗漏的风险，这个风险来自于对因子和状态潜在的考虑不周。随着详细级别要求或者系统复杂度的提高，使用要因分析法组合出详尽的测试方案则成为了QA的一种折磨，每一个QA遇到复杂的测试对象，都将成为酷刑下折翼的天使，欲哭无泪的在心中默默呐喊“坑爹啊”（因此要对要因法做一定程度的改良，如何改良，后文将详述）。

　　前文伏笔“要因分析法不是鱼骨分析法”，鱼骨分析法的另一个更加正式的书面称呼是“根本原因分析法”（日本管理大师石川馨先生发展出来的，故又名石川图）。根本原因分析法同样有着折磨常人的地方（题外话：为什么日本人使用的方法总是那么坑爹？），它要求分析者们集中精力寻求发生问题的任何一种可能性（头脑风暴），将这些可能性绘制在鱼骨图上，再寻求所有可能性的根源，其本质上不是一种用于设计测试方案的方法（仅仅用于追溯问题，例如发现bug后追溯引起bug的根源）。关于根本原因分析法的讨论，由于和本文的重点有偏离，因此不做进一步描述，题外话就此打住。

　　欧美式头脑风暴

　　众所周知，欧美企业的风格是强调人性和自由，对于测试来说，自然不可能采纳日式那种条条框框的做法。测试方案设计的基本方法和准则，例如边界值分析、等价类划分、因果图等，被QA们牢牢的记在心中，功能测试方案设计时，根据需求分析或用户手册，众人在一起集中进行头脑风暴，此时包括RD也将参与进来，对于测试合理或者不合理的地方提出建议。因此，方案设计的时候，更强调的是经验和阅历以及对需求的关注程度。测试方案设计是有偏重的，对于一些重要的feature强烈关注，用例也将根据feature的重要性而详略有别。

　　头脑风暴式的测试用例设计的辅助工具往往以思维导图为主，还是以“我打算从南京去北京”为例，其中一种思维导图设计如下：

思维导图的灵活性很高，因此设计出的导图每次都会有所不同，跟随着与会者偏重点的不同而产生不同的设计方案。

　　好比欧洲的菜肴大多以整块烹制为主，而中国人的菜肴则基本上都是切碎的。这是因为受限于传统使用的餐具。而测试方案的设计方法也同样受到西方和东方文化差异的影响，例如Agile首先在欧美出现并迅速得到推广和应用，而Agile绝对不会首先出现于日本。对于头脑风暴式的测试方案设计，这颇有Agile的风格，项目参与者进行充分的思想交流，QA们将每一个闪现于头脑的想法都记录在案，同时根据别的QA和RD的建议来不断地修正或弥补方案，直到完成设计。

　　这种设计方法的好处是拥有很好的灵活性，且可以避免精力被耗费到旁枝末节上。用例可以是很多步骤组合起来的（表现为思维导图的层次较多），通过一个用例测到多个feature，这在进行具体的自动化测试代码编写时可以节省大量劳动力。由于交流足够充分，某些不易被想到的测试用例也可以被挖掘出来（好比绘制清晰的思维导图）。然而，这种方法的缺点也是显而易见的，某些测试用例有可能在头脑风暴中被忽视或遗忘，且受限于人的思维的不严密性，未设计在案的测试用例，往往也没有人会关注到“为什么这些测试用例不用测”这个问题。

　　欧美与日式的比较

　　其实从上述的两个篇章，我已经阐述了二者之间的差异。日式苦行僧般的要因分析法，几乎可以遍历穷举所有可能的组合方式（除非因子有遗漏），设计完毕后，到了具体测试实施阶段，无论是手动测试还是自动化测试，对于QA来说，都是一个比拼耐力的考验，测试用例数动辄过千，大量的测试用例之间甚至只有细微的差别。QA将完全体验不到创作的乐趣，转而成为一名不折不扣的体力劳动者。一个测试对象的测试周期也被大大拉长，所需的人月数也很多。完成这些繁琐的工作之后，测试对象将趋于完美，细微的bug也将被找出并修正。此时不排除测试对象可能已经是一个落后的甚至被淘汰的产品了。当然，这对于用户忠诚度极高的日本人来说，这不算什么问题，他们不厌其烦的强调产品品质，但是对于这颗星球上的其他民族来说，大多宁可忍受一些小bug，也不愿使用一个过期的技术落后的产品。

　　对于欧美式的测试设计，显然比较契合当前的飞速发展的计算机业，但产品中留下的bug数量往往也会比日式测试法多的多。这尤其表现在产品的一些局部的、次要的功能上，这些功能往往将成为bug集中营。

　　两者融合的思考

　　欧美与日本，两者采用的方法各有长处。一者的缺点往往恰是另一者的长处。那么该如何从两者中取长补短，去粗取精以至互相融合呢？这也是我在工作中一直不断思考的一个问题。

　　我认为有一种可行的解决方案可以按照如下的做法进行：

　　1、列出要因表，因子和状态的列举方式可以采用思维导图进行

　　2、根据deadline来划分测试的详略程度，制订测试计划

　　3、头脑风暴，将要因表的二维组合放在参与者的头脑中进行

　　4、在列举测试用例的同时，对不测的用例也要追究一下不测的原因

　　5、归纳测试用例之间的共性，对于差别较小的测试用例，要考虑如何整合到一起，对于可以串行的用例，要考虑是否可以合并为一个多步骤的用例

　　通过以上5个步骤，我想既可以避免要因分析法的要因组合阶段带来的让人抓狂的繁琐和用例数量过多的缺陷，又可以避免头脑风暴带来的某些用例的考虑不周。

　　是否还有其他更好的取长补短的方法呢？这个问题将依然萦绕在我的日常测试工作中，吾将上下求索，并期待您对本文的看法能够给予我茅塞顿开的启迪。

总共分为以下几个步骤：
一、安装配置jdk
二、安装配置Tomcat
三、安装jboss

四、连接数据库

 

所需要的软件：
jdk-1_5_x-rc-linux-i586-rpm.bin

tomcat-5.5.23.tar.gz

jboss4Srv_405GA

=================================================================

一、在linux上安装JDK：

1、 以root身份登录系统，将jdk-1_5_x-rc-linux-i586-rpm.bin文件放到/usr/local目录下。

2、 通过chmod a＋x jdk-1_5_x-rc-linux-i586-rpm.bin命令使其获得可执行权限。

3、  ./ jdk-1_5_x-rc-linux-i586-rpm.bin , 然后会提示是否确认安装，这时输入yes即可。

4、 通过 rpm –ivh jdk-1_5_x-rc-linux-i586.rpm来进行安装。

5、  安装完毕,JDK自动安装在/usr/java/目录下

6、 设置环境变量  vi /etc/profile
 export JAVA_HOME = /usr/java/jdk1.5
 export PATH = $PATH:$JAVA_HOME/bin
 export CLASSPATH=$JAVA_HOME/lib

7、 检查jdk是否安装成功 

   #java –version即可看到生效后的jdk版本信息

#javac version 既可以看到jdk命令帮助，说明配置正确

二、在linux上安装tomcat

 1、把tomcat（tomcat-5.5.23.tar.gz）拷贝到usr/local下

 2、tar zxvf tomcat-5.5.23.tar.gz（解压缩）

设置目录权限（可选）

     #cd /usr/local/tomcat/

     #chmod -R 777 *              --将tomcat目录赋予所有权限

  3、在/etc/profile中添加环境变量： 
       export CATALINA_HOME=/usr/local/ tomcat-5.5.23

       export CATALINA_BASE=/usr/local/ tomcat-5.5.23

 为启动方便，可以建立映射：ln tomcat-5.5.23 tomcat -s（不建立也可以）

4、测试是否安装成功：

       #cd /usr/local/tomcat/bin

       #./startup.sh

     看到以下提示信息：

        Using CATALINA_BASE:   /usr/local/tomcat
        Using CATALINA_HOME:   /usr/local/tomcat
        Using CATALINA_TMPDIR: /usr/local/tomcat/temp
        Using JAVA_HOME:       /usr/java/jdk

       然后打开浏览器，输入http://localhost:8080，如果出现tomcat提示页，则安装成功。

 

三、在linux上安装JBOSS：

 1、把jboss4Srv_405GA拷贝到usr/local下

 2、解压缩jboss4Srv_405GA

四、连接数据库

    通过jboss中的oracle-ds文件来连接数据库，配置相应的数据库

至此，Linux平台下的jsp环境搭建完成，最后要配置本地的服务器的HOSTS 

  Vi /etc/hosts

127.0.0.1                                              Hostname（本机名称，与sysconfig/network中的hostname保持一致，可用uname –a命令获取主机名称）

 

Vi sysconfig/network

NETWORKING=yes

HOSTNAME=test2

GATEWAY=192.168.1.1

 

 

/etc/hosts用于名称解析。不做服务器一般不会用到。相当于windows的dns
/etc/sysconfig/network.用于相当于windows的ip

1.应验证界面显示内容的完整性：

　　a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

　　b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;

　　2.应验证界面显示内容的一致性：

　　a) 如有多个系统展现同一数据源时，应保证其一致性;

　　3.应验证界面显示内容的准确性：

　　a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

　　4.应验证界面显示内容的友好性：

　　a) 对统计的数据应按用户习惯进行分类、排序。

　　b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

　　c) 界面内容更新后系统应提供刷新功能。

　　d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

　　5.应验证界面提示信息的指导性：

　　a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

　　b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

　　c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

　　d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

　　6.应验证界面显示内容的合理性：

　　a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

　　b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

　　c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

　　7.界面测试时，应考虑用户使用的方便性：

　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

8.界面测试时，应考虑界面显示及处理的正确性：

　　a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。

　　b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;

　　c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。

　　d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

　　e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变;

　　9.界面测试时，应考虑数据显示的规范性：

　　a) 确保数据精度显示的统一：如单价0元，应显示为0.00元;

　　b) 确保时间及日期显示格式的统一;

　　c) 确保相同含义属性/字段名的统一;

　　d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

文章出处：http://news.csdn.net/n/20070706/106199.html   来自：CSDN 马京

除了技术类的工作以外，测试经理另外一部份重点工作是组建及发展测试团队。微软的成功很大一部分来自于对人才的重视，而这种重视在招聘期间就可以充分体现出来。

【CSDN独家访谈】通过上一篇对微软测试经理Francis Zhou的采访，我们大概了解了他在软件测试方面的一些成长故事。在任何一家公司，你光遇到一个好的经理还是不够的，还需要好的“战友”和成长环境。于是我们继续请微软测试经理Francis Zhou来谈谈微软在软件测试方面是如何招募人才和培养人才的。

测试经理必须保证“招进来的人要比自己聪明”

除了技术类的工作以外，测试经理另外一部份重点工作是组建及发展测试团队。微软的成功很大一部分来自于对人才的重视，而这种重视在招聘期间就可以充分体现出来。测试经理作为团队里资深的管理人员，必须要参与到人才的招聘和面试流程的每一个环节中去。

Francis说：“我们组的每一个人我基本上都曾经面试过，如果面试的是测试组长或者经理，我一定会参加，因为这个人很可能会成为我的接班人，我必须保证我招进来的人要比我聪明。把最优秀的人才招进微软只是第一步，作为领导我们还有责任为员工创造环境使他们最大化的发掘他们的潜能，其中包括对员工的职业规划提供必要的辅导。”

提到微软亚洲工程院在培养测试人员上的特点时，Francis指出微软为每一个个人贡献者（Individual Contributor）和管理人员都创造了平等的成功发展的机会，让他们得其所好。这是微软多年来一直提倡人才培养理念。除此之外，在微软特别强调对测试工作的重视，将测试人员与开发人员同等对待。这些政策使得由测试、开发、PM组成的团队能更有效的在一起工作，从而对提供高品质的产品产生了直接的影响。

在人才招聘和管理上的经验和教训

一个团队的成功离不开他的管理者，但是不是所有人都能成为管理者。成为管理人员之后，很多最宝贵的经验和教训会来自对人才的招聘及管理上。在这点上， Francis从一些教训中得出了很多宝贵的经验。第一次教训是在他刚刚做测试组长后不久，有一个之前做手工测试很出色的员工调到了他的组里。因为他们测试的是API，需要开发自动化测试工具，因此这个员工开始转向开发测试软件，但这次转行做得很费力。开始他以为只是个时间问题，只要他花更多的时间和精力就能解决的。但后来经过一年的尝试的，这位员工最终还是换到了另外一个更适合他特长的团队。

Francis说：“这次教训使我认识到帮助员工找到适合他而且他喜欢做的工作是多么的重要。从此之后我更加注重员工的兴趣以及特长，为他们创造能最大发挥他们潜能的工作环境。”

IT企业长久发展必须能为个人贡献者和职业管理人员都创造成功的机会

在任何一家企业，根据每个人的不同特长安排不同的工作，不一定每个人都要成为管理者，技术路线和管理路线应该都是可行的。Francis刚成为测试经理以后，在寻找接替他工作的测试组长时发生了一件事情。当时有一个员工工作很努力，技术上也很强，所以顺理成章举荐他做了组长。但之后不久就发现他在带领和管理团队方面遇到了很大的困难，以至于在巨大的压力下病倒了。这个组工作的进度相应也受到了影响，最后通过大家的努力这个项目才得以按时完成。

Francis说：“从这一次我体会到了一个好的技术人员不一定就会是一个好的管理者，而一个IT企业要长久发展就必须能为个人贡献者（Individual Contributor）和管理人员都创造成功的机会。从那儿以后我为个人贡献者创造了更多的机会，让他们不必成为管理人员也能获得个人职业发展的成功。”

采访后记

在采访之后闲谈中，记者得知在微软，测试是一个必须的环节，不是可有可无的。招测试开发工程师时所用的标准是跟开发师一样，因为一个出色的测试人员同时也应该是一个出色的开发人员。其次是对软件开发流程的重视，在开始测试前有测试设计文档，并且在软件生命周期的每一步都明确知道测试队伍的任务。这两点是国内软件企业应该研究以及学习的，当然也要根据自己公司的实际情况去适当改革、引进。

说到最喜欢的书，Francis认为”Lessons Learned in Software Testing“是一本作者们把在现实工作中所积累的经验提炼后写出来的有效参考书，里面有很多值得借鉴的经验教训，比起那些光谈理论的软件测试书籍实用的得多，是本好书。