软件测试人员，能看到整个系统的全貌，可能是对系统要做什么最了解的人，甚至比产品的负责人还要了解（我指的是广度上，具体特性的深度上往往会欠缺一些）。从测试团队那里，你能及时的得到一个系统当前状况的切片，对于防止项目失控，看清当前情况与目标的差距，是非常重要的的信息。

原文见：100 Interview Questions for Software Developers。

想雇到搞软件开发的聪明人可不容易。万一一不小心，就会搞到一堆低能大狒狒。我去年就碰到这种事了。你肯定不想这样吧。听我的，没错。在树上开站立会议门都没有。

问点有难度的问题能帮你把聪明人跟狒狒们分开。我决定把我自己整理出来的软件开发者面试百问发出来，希望能帮到你们的忙。

这个列表涵盖了软件工程知识体系中定义的大多数知识域。当然，如果你只想找出类拔萃的程序员，便只需涉及结构、算法、数据结构、测试这几个话题。如果想雇架构师，也可以只考虑需求、功能设计、技术设计这些地方。

不过不管你怎么做，都要牢记一点：

这里大多数问题的答案都没有对错之分！

你可以把我的这些问题作为引子，展开讨论。例如下面有个问题是使用静态方法或是单例的缘由。如果那个面试的就此展开长篇大论，那他很有可能是个聪明能干的家伙！如果他一脸茫然的看着你，发出这种声音，很明显这就是只狒狒了。同样，想知道一个数是不是2的乘方也有很多方法，不过要是面试的人想用mod运算符，嗯……你知道我的意思吧。（你不知道也没关系，来根香蕉？）需求

1. 你能给出一些非功能性（或者质量）需求的例子么？
2. 如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
3. 你能给出一些用来描述需求的不同技术么？它们各自适用于什么场景？
4. 需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？
5. 你喜欢用什么工具跟踪需求？
6. 你怎么看待需求变化？它是好是坏？给出你的理由。
7. 你怎样研究需求，发现需求？有哪些资源可以用到？
8. 你怎么给需求制定优先级？有哪些技术？
9. 在需求过程中，用户、客户、开发人员各自的职责是什么？
10. 你怎么对待不完整或是令人费解的需求？

功能设计

1. 在功能设计中有哪些隐喻？给出几个成功的例子。
2. 如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
3. 如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
4. 有哪些方法可以保证数据项的完整？
5. 建立系统原型有哪些技术？
6. 应用程序怎样建立对用户行为的预期？给出一些例子。
7. 如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
8. 有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？
9. 用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
10. Web环境和Windows环境各有些什么限制？

技术设计

1. 什么是低耦合和高聚合？封装原则又是什么意思？
2. 在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
3. 你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？
4. 是否了解什么是无状态的业务层？长事务如何与之相适应？
5. 在搭建一个架构，或是技术设计时，你用过几种图？
6. 在N层架构中都有哪些层？它们各自的职责是什么？
7. 有哪些方法可以确保架构中数据的正确和健壮？
8. 面向对象设计和面向组件设计有哪些不同之处？
9. 怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
10. 怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？

程序设计

1. 你怎样保证你的代码可以处理各种错误事件？
2. 解释一下什么是测试驱动开发，举出极限编程中的一些原则。
3. 看别人代码的时候，你最关心什么地方？
4. 什么时候使用抽象类，什么时候使用接口？
5. 除了IDE以外，你还喜欢哪些必不可少的工具？
6. 你怎么保证代码执行速度快，而又不出问题？
7. 什么时候用多态，什么时候用委派？
8. 什么时候使用带有静态成员的类，什么时候使用单例？
9. 你在代码里面怎么提前处理需求的变化？给一些例子。
10. 描述一下实现一段代码的过程，从需求到最终交付。

算法

1. 怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？
2. 怎样找出链表中间的元素？
3. 怎样改变10,000个静态HTML页面中所有电话号码的格式？
4. 举出一个你所用过的递归的例子。
5. 在散列表和排序后的列表中找一个元素，哪个查找速度最快？
6. 不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
7. 怎样把字符串反转？你能不用临时的字符串么？
8. 你愿意用什么类型的语言来编写复杂的算法？
9. 有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
10. 你知道“旅行商问题（Traveling Salesman Problem）”么？

数据结构

1. 怎样在内存中实现伦敦地铁的结构？
2. 怎样以最有效的方式在数据库中存储颜色值？
3. 队列和堆栈区别是什么？
4. 用堆或者栈存储数据的区别是什么？
5. 怎样在数据库中存储N维向量？
6. 你倾向于用哪种类型的语言编写复杂的数据结构？
7. 21的二进制值是什么？十六制值呢？
8. 不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
9. 怎样在XML文档中存储足球比赛结果（包括队伍和比分）？
10. 有哪些文本格式可以保存Unicode字符？

测试

1. 什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？
2. 如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
3. 你用哪些工具测试代码质量？
4. 在产品部署之后，你最常碰到的是什么类型的问题？
5. 什么是代码覆盖率？有多少种代码覆盖率？
6. 功能测试和探索性测试的区别是什么？你怎么对网站进行测试？
7. 测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？
8. 要对电子商务网站做冒烟测试，你会做哪些类型的测试？
9. 客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
10. 你去年在测试和质量保证方面学到了哪些东西？

维护

1. 你用哪些工具在维护阶段对产品进行监控？
2. 要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
3. 如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
4. 你怎样保证代码中的变化不会影响产品的其他部分？
5. 你怎样为产品编写技术文档？
6. 你用过哪些方式保证软件产品容易维护？
7. 怎样在产品运行的环境中进行系统调试？
8. 什么是负载均衡？负载均衡的方式有哪些种？
9. 为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
10. 再造工程（re-engineering）和逆向工程（reverse engineering）的区别是什么？

配置管理

1. 你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？
2. 你一般会把哪些东西纳入版本控制？
3. 怎样可以保证团队中每个人都知道谁改变了哪些东西？
4. Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？
5. 怎样管理技术文档——如产品架构文档——的变化？
6. 你用什么工具管理项目中所有数字信息的状态？你最喜欢哪种工具？
7. 如果客户想要对一款已经发布的产品做出变动，你怎么处理？
8. 版本管理和发布管理有什么差异？
9. 对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
10. 同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？

项目管理

1. 范围、时间、成本，这三项中哪些是可以由客户控制的？
2. 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？
3. 减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？
4. 你喜欢用哪种图来跟踪项目进度？
5. 迭代和增量的区别在哪里？
6. 试着解释一下风险管理中用到的实践。风险该如何管理？
7. 你喜欢任务分解还是滚动式计划？
8. 你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
9. DSDM、Prince2、Scrum，这三者之间有哪些区别？
10. 如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？

对于上面的有些问题，我只想说：给我一只香蕉吧
因为对软件测试部分有一些了解，谈一谈自己的看法

测试

客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
>
可能比较多的情况是：有些功能实现不是用户想要的；不满足特殊的行业要求；性能没达到用户的要求；使用习惯、易用性不符合用户要求等等这类。比较好的方式是渐近的给用户提供产品，让用户能在产品的不同开发阶段介入，提出意见，每个阶段都进行相应的测试。如果用户能作为开发测试组的一员，那就更好了。

安装软件的烦恼

今年我的建议是：不要安装任何新软件，除非你是真的迫不得已。

也许你属于在电脑上安装软件从未遇到问题的那类人。也许你从未象我一样，经历过用半个小时安装软件后却出现“无法更新系统注册表，请使用REGEDIT”这类令人恼火的情形。还好，我知道注册表编辑器(Reg Edit)不是一个人，而是让你编辑所谓注册表的程序。相信我：注册表可不是闹著玩的。这就如同闭著眼睛把你的手伸入一桶螃蟹中一样。这也可以解释为什么这个错误信息没有告诉我怎样编辑注册表。如果我知道如何做，我可能就自己组装电脑，自己编写程序，成功拥有我自己的软件公司，而不必像现在这样痛苦不堪了。也许你与我不同：你聪明好学，并把在安装软件过程中解决问题当作乐趣。

我还是做不到这点。我仍然是看到新软件后，心里想：“太好了，这个软件不错。”然后就下载，或是把光盘放到光驱中，随著安装的开始，专注地等待著。（我认为，最知名的软件品牌不是微软(Microsoft)，而是InstallShield，这是很多软件开发商帮助我们安装软件的程序。不少人坐在那里，看著屏幕上的InstallShield图标，都以为这是微软的一部分。事实上，很多年前鲍勃•柯瑞根(Bob Corrigan)也曾经这么认为，直到有一天他加入了InstallShield，并成为其产品经理。InstallShield目前是授权软件公司Macrovision的子公司。）

因此这种安装烦恼一次一次地重现，直到不太顺利地安装完，或是遇到类似上面所述的错误信息。要么就像我最近遇到的那样，安装了一个能让我从音乐网站下载歌曲的软件，却根本不工作。这个软件在最初令我感到兴奋后，很快地从视野中消失了，只剩下我不知道是应该高兴、重启电脑，还是哭泣。

不过这次，我采取了措施。我给柯瑞根打电话，希望了解为何所有软件都是这么难安装，像InstallShield这样的软件究竟是产生问题的根源还是解决方案之一。（InstallShield是作为第三方软件同新软件产品捆绑到一起的，目的是为了便于用户安装。） 毫不奇怪，柯瑞根将责任推到使用其产品的软件开发商那里。他认为，许多软件开发人员在编写他们的软件方面花了很多时间，而没有用足够的时间思考如何安装到电脑上。（在InstallShield自己网站的用户论坛上，大家的看法却并不一致：并不是所有软件开发人员都认为InstallShield毫无责任。）

可悲的事实是，电脑普遍被认为是擅长处理复杂事物的，但现实却令人感到苦涩。你买电脑时得到的承诺是它能为你做各种各样的事情：你需要做的就是安装软件。但我们很快就会发现，我们越是希望用新软件来提高电脑的性能，它出现的错误就越多。我觉得，你的电脑恐怕不是用来安装过多软件的。安装的软件越多，不同软件间的冲突也就越多，因为它们在注册表中相互干扰。然后情况开始变得复杂起来。也许用“混乱”这个词更恰当。就像软件管理公司Altiris Inc.的系统工程师主管安德鲁•苏特尔(Andrew Souter)所解释的那样，Adobe Acrobat 7（用于阅读pdf格式的文件）这样一个再普通不过的程序就要在注册表中加入1,100多条小代码，修改约500个重要的系统文件。（而其他程序也可能使用这些文件，因此修改这些文件可能会干扰其它程序。）Acrobat可能工作正常了，但使用这500个文件的其他程序呢？他说，同其它程序发生冲突的概率相当高。

苏特尔认为，他的公司拥有一套软件解决方案，就是“虚拟”地安装程序，不需修改注册表，没有共享文件，没有繁琐的安装过程。仅在需要时激活软件，并在完成任务后关闭软件即可。这个想法的确不错，这也可以适用于要大量安装同一软件的大公司。对个人用户而言，一种叫做Web Applications的应用程序或许能够带来希望，它能让你低价或在网上免费获得数据表、字处理和日历的所有主要功能。比如，最近推出的Zoho Writer (www.zohowriter.com)就是Microsoft Word的一种网上版本。当然，InstallShield的柯瑞根承诺改进他的产品，并也在忙于打电话，告诫软件开发商改进使用他的产品制作软件的方式。

但对大多数象我们这样的人来说，这终究有些不舒服。现实常常是，你的电脑在第一次从包装箱中拿出来并开机时是表现最好的，然后就一直走下坡路。我喜欢软件，也希望你也喜欢软件，但在事情变得更简单些之前，我建议你在安装新软件前要三思而行。 

《华尔街日报》中文网络版个人数字中心
2006年01月06日19:09

我认为没有什么问题，ID代表用例标号。ACT代表一种动作，因为测试动作非常复杂，如果手动执行或者自动执行，或者是一种异常状态都可以占用此位置。DATA代表数据，很多的测试类书籍中虽然没有直接讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我不细说了。为什么会在一个文档中体现这些内容——主要是为了以后的测试自动化，一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的经常对这两种值的差异感到困惑，是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入，如果EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着使用权，但决定权在于市场或者高层决策。DATE是一种好习惯，通常记为发现“PASS”、“ERROR”、“FAIL”的时间，很多人会忽略这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅提供给他们T/F是不够的。
》qiuyangzh：不过在我看来，还是要把ACTUAL-T/F-DATE部分抽取出来，因为这部分不能算是测试用例的内容，而是在后面实际执行测试的时候填写的。当然，可以使用同一个格式，在编写测试用例的时候，ACTUAL-T/F-DATE部分的内容空着，在每次执行这些用例的时候，将实际情况填写进去，当然，测试用例和每次的测试执行要写在不同的文档里。

我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，如果你有很多的时间，如果你一年才写一次测试用例，你当然可以从互联网上下载很多的资源把文档修饰的像APPLE的产品一样。
》qiuyangzh：测试用例要简洁、有效，这一点我非常同意。也许你和我一样，也曾经看到过那些格式复杂的测试用例，不能说它们不好，但不一定适合组织的情况。我认为在很多情况下，应该保持测试用例简洁和朴实的风格。简洁不等于简单，真正简洁、朴实的测试用例，仍然是非常有效和实际的。
  不过上面的测试用例格式有些过于单薄，比如测试用例的设计者和对应的测试需求，还是需要写上的。而且我的看法一直是：应该将测试用例和测试用例执行的记录分开，不要混在同一个部分，这样便于工作的进行。

   入行的人员会更进一步的发挥测试偏执狂的能力，这时候的他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个，厉害吧？厉害，我当然说你厉害，你难道不厉害吗？我记得有个500强的面试题就是你能为登录的动作写多少测试用例？我想了半天说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说大概我能写5个吧？当然我自己也没底，我就能写出三个：LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的测试用例就是他们的衍生，一种本源的问题。我们继续讨论3000多个测试用例的事情，有人明眼就会说：这家伙肯定是微软的，没错，除了这种大公司有了充足的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟悉程度，工作经验有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。
   当你开始测试的时候，实际上最终是对代码设定路径的一种验算，如果我们都生活在单线程、无UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年代，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，出发点是好的做法是累死人的，如果你愿意你可以为机器码写1亿个测试用例，如果你还是很偏执，你可以为门电路写上1万亿个测试用例，你有时间执行吗？
》qiuyangzh：如果资源充分，当然测试用例的数量多一些对于检验产品的质量是有好处的。但实际情况往往是资源有限的，这种情况下，就必须挑选出那些最有价值的测试来执行。

我通常不愿意写太多的测试用例，很多人认为我工作态度有问题，我认为这更能说明我的态度：我愿意朴实的构造我的测试用例，但是我有原则来保证我的测试用例的质量：
   1。接到任务不急于作而在于多思考，首先在纸上构造好业务流图
   2。业务流程图构造好，快速挑选出公用的测试用例
   3。构造测试用例，先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
   4。精化测试用例，努力为ERROR多构造1-7种假设
   5。执行测试用例，增加FAIL的标准化失败的测试，但是对应减少PASS测试用例
   6。进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10
》qiuyangzh：就是因为上面这段话，更确切的说是第4、5、6条，使我决定把这篇文章放到我的Blog中来。根据我的经验，在设计和执行测试的时候，应该按照这种比例来操作。

我将继续我的朴实理论，多出来的时间，我可以看看蓝天，享受享受生活！
》qiuyangzh：享受生活，享受工作

    我到现在已经从事软件测试这个工作3年的时间了，读这本书的时候，经常有会心一笑的举动，因为书中所描述的很多内容，也是自己在工作中遇到过、思考过的，在读这本书的时候，感觉有一种自己的想法和别人取得共识，或者是疑惑被打消的喜悦。

    如果是已经从事软件测试有一段时间的朋友，我觉得你可以读一读这本书，应该会有些许收获的。当然，凡是与软件开发相关的人员，通过这本书都会获得有益的知识，不过就象书中的一段话所说的那样——“别指望别人会理解软件测试，或者理解测试员需要什么条件才能搞好测试。作为测试员的你在读本书时，别指望其他人也会读它”

摘要：一年将尽，心理学家或者一些博学者们，又将对2004年或者更久的将来作出预测。
在这次的周末专栏中，Harry Robinson将向我们讲述他对测试未来的预测。

“预测是件很难的事情，尤其是预测未来” —Yogi Berra

每年十二月，小报的“未来预测者”们会向大家切揭示即将到来的一年将要发生的事情：
“麦丹娜将要乘坐航天飞机”，“美国将迁都 Wichita”，等等。我将加入这个潮流，对
软件测试何去何从做一个我自己的预测。并且我希望，我的预测费用能够比我的那些值
得尊敬的小报同事更高些。

我的主要预测就是，将来的软件测试与现在的软件测试看起来很不一样。原因很直接：今
天的软件测试很大程度上是臭名昭著的：软件测试参与到项目中的时间太晚、贡献太少、
花费太高。如果我们关心我们产品的质量以及我们的账本底线的话，我们就需要重新思考
测试和质量的方法。

即使遭到一致反对，我也要说：更好的方法，对测试人员更好的培训、更好的欣赏将改革
软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG预防、系统模拟
这些技术，将在这场演变过程中扮演重要的角色。

下面就是我们在将来的几年里可能看到的情形。事实上，某些趋势已经开始了。

测试人员，需求撰写人员和开发人员，都将看到自己是其中的一份子。

测试人员帮助需求撰写人员

测试人员与需求撰写人员共同工作，在需求完成以后，审查以及理解需求。早期的审查以
及建模可以暴露很多关于一致性、完整性和模糊性的BUG，这个时候修补这些BUG付出的
代价还十分小。

需求撰写人员帮助测试人员

测试小组建造模型，用于产生对其产品行为的测试。需求撰写人员审查模型，以确保他们
充分覆盖了产品特征集。这样产生的测试模块将成为一个“可执行需求”。

测试人员帮助开发人员

因为需求清楚，毫不含糊，开发人员更好的理解了他们的代码将要完成什么。

在正式的将代码提交做测试之前，测试人员提供给开发人员一些模型，以便开发人员可以
在自己的代码中实现它们。

开发人员帮助测试人员

基于”特征对特征”这样的方式(防止以往的“后期才介入开发,一股脑找出产品问题”的
方式),开发人员和测试人员共同保证代码易于实施自动测试.开发人员的代码中处处都是易
测试性的开关,使得错误检测更加容易.

测试人员帮助测试人员

测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以复查
和改进测试模型.这就形成了一个测试专家的共同体.

方法日趋完善

BUG预防和早期检测

因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG), 预防实践和静
态分析仪这样的检测工具将成为主流.

仿真测试

仿真工具变得很普遍,使得仿造计算机环境变得容易起来.在开发过程的早期就可以进行意
外和错误流程的测试.代码稳定后,再用真实环境验证仿真是否准确无误.

及时的测试用例

庞大的测试用例管理系统将成为昔日的东西,大量的测试用例生成了却没有被使用.测试用
例将不再像腐烂的存货一样被收藏起来,因此,让测试用例保持最新变得容易起来.

积极的方法

误导人的方法,比如计算BUG的数量、计算测试用例的数量,将不复存在.有用的方法,比如
需求覆盖、模型覆盖、代码覆盖将驱动项目开发.

更少更精的测试人员

机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作,测试小组需要比以往更
少的测试人员,留下来的测试人员将是经过更多高度培训过的.他们所做的工作将更加有趣,
因为在测试中他们将致力于更大的问题,而不是在抱怨中艰难地开展工作.

更多更好的测试

测试人员将可以在一天中进行成千上万的测试,所以,如何首先运行最有用的测试将成为一
大挑战.相关的工具将允许测试人员为他们的测试区分优先级,以及将测试目标放在那些最
易出现重大BUG的地方.

测试人员的角色更换

测试中界限模糊

在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊,一个既是“通
过程序破坏事物的测试员”又是”创建程序用于破坏事物的程序员”的专业出现了,――关
于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。

测试与开发界限模糊

测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发
人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰、
可测性更高的代码，使得测试人员的工作更易完成。

顾客反馈与测试合为一体

交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如“我们怎么会遗漏
了这个BUG呢？”或者“我们将来如何防止这类BUG？”这些问题，我们的工作就是使
顾客满意。

新的挑战出现

复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工作，
但这没关系――因为这些挑战使测试人员精力充沛。

测试人员获得尊重

测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”，他们将在整个软件开发过
程中提供一个可见的、重要的、增值的服务。人们意识到，测试是有益的、有趣的甚至
富有乐趣。

测试变得流行

软件测试人员开始扬眉吐气，而且，由于破坏事物至少可以带来创建事物一样的乐趣，
人们开始在开发和测试角色之间转换，所有的人将学到更多关于如何得到良好代码的知识。

激情“吸毒者”继续存在

新的过程运行得如此良好，使得需求撰写者，开发人员以及测试人员不再具有生命力，
这就使得那些在激情掌控的世界被提升的人惶惶不可终日，那样的世界意味着工作到
深夜、最后一刻测试才参与，以及如同交战开火般的会议。而这些人对于那些还没有
受新的运行过程控制的公司来说还具有吸引力。

Elvis Presley是一个软件测试员

他的会议发放材料的标题就是：“软件质量：就是现在，否则永远不可能”

今天就为将来准备

不管我的预测是否成为现实，未来也会按照它自己的方式到来，下面就是如何准备面
临未来的五个意见：

1．积极地不满于现状

不要接受测试的现状，四处看看，并且思考“我们在做些什么毫无意义的事情？”

2．抛开人与人之间的封闭

领悟如何更好的测试，并且分享这些知识。只有每一个人都试图使他所写的代码达到
最佳状态时，整体质量才会改进。

3．学习更多关于测试的东西

如今，行业受软件测试的创新思维激发。用参加会议，加入邮件列表，网上冲浪，这
些方式来解在测试前沿发生的一切。

4．学习更多关于开发的东西

参加一个编程学习班，即使你不打算编写大量的代码。将学习班当作是在BUG领土上
的一次侦察飞行。

5．挑战世界

Abstract: Software test is one measure to insure the quality of software, it costs half of time and resource in the whole process of development. If test tools can be used in the process, it would to improve the speed of test and the quality of test, It’s probable to develop software rapidly and to produce high quality. In this document it introduces some software test tools for the different of test moment, it introduce the time for every kind of tools, but the function of the test tool.

关键字：软件测试工具； 测试设计； 静态分析； 单元测试； 功能测试； 性能测试； 测试过程管理；

Keywords: software test tool; test design; static analysis; unit test; function test; performance test; test process management;

1引言

最近几年，软件测试在国内越来越受到重视，因为大家逐渐认识到了软件测试对于保证软件质量的重要性。随着对软件测试重视的提高，国内软件测试技术的发展也很快，逐渐从过去手工作坊式的测试向测试工程化的方向发展。

要真正实现软件测试的工程化，其基础之一就是要有一大批支持软件测试工程化的工具。因此，软件测试工具对于实现软件测试的工程化来说至关重要。本文就从如何进一步提高软件测试质量和效率的角度出发，讨论测试工具在软件测试过程中的应用。

2为什么要引入测试工具

在测试过程中引入测试工具能给我们带来以下的好处。

2.1提高工作效率

这是引入测试工具给我们带来的一个显著好处。那些固定的、重复性的工作，可以由测试工具来完成，这样就使得测试人员能有更多的时间来计划测试过程，设计测试用例，使测试进行的更加完善。

2.2保证测试的准确性

测试是需要投入大量的时间和精力的，人工进行测试时，经常会犯一些人为的错误，而工具的特点恰恰能保证测试的准确性，防止人为疏忽造成的错误。

2.3执行困难的测试工作

有一些测试工作，人工进行是很困难的。有的是因为进行起来较为复杂，有的是因为测试环境难以实现。测试工具可以执行一些通过手工难于执行，或者是无法执行的测试。

3测试工具在软件测试过程中的具体应用

在这一部分，我们讨论测试工具在测试过程中的具体应用。

现在的测试工具很多，基本上覆盖了各个测试阶段。按照工具所完成的任务，可以分为以下几大类：测试设计工具、静态分析工具、单元测试工具、功能测试工具、性能测试工具、测试过程管理工具。下面，我们就针对每一类工具展开介绍。

3.1测试设计工具

测试设计工具，更完整的名称应该是测试用例设计工具，是一种帮助我们设计测试用例的软件工具。

设计测试用例是一项智力性的活动，工具如何能够代替呢？确实是这样，但仔细思考一下我们就会发现，很多设计测试用例的原则、方法是固定的，比如等价类划分、边界值分析、因果图等等，这些成型的方法，很适合通过软件工具来实现。

测试用例设计工具按照生成测试用例时数据输入内容的不同，可以分为：基于程序代码的测试用例设计工具和基于需求说明的测试用例设计工具。下面分别对这两类工具进行介绍。

3.1.1基于程序代码的测试用例设计工具

基于程序代码的测试用例设计工具是一种白盒工具，它读入程序代码文件，通过分析代码的内部结构，产生测试的输入数据。这种工具一般应用在单元测试中，针对的是函数、类这样的测试对象。由于这种工具与代码的联系很紧密，所以，一种工具只能针对某一种（些）编程语言。

这类工具的局限性是——只能产生测试的输入数据，而不能产生输入数据后的预期结果，这个局限也是由这类工具生成测试用例的机理所决定的。所以，基于程序代码的测试用例设计工具所生成的测试用例，还不能称之为真正意义上的测试用例。不过即使这样，这种工具仍然为我们设计单元测试的测试用例提供了很大便利。

3.1.2基于需求说明的测试用例设计工具

这种测试用例设计工具，依据软件的需求说明，生成基于功能需求的测试用例。这种工具所生成的测试用例既包括了测试输入数据，也包括预期结果，是真正完整的测试用例。

使用这种测试用例设计工具生成测试用例时，需要人工的事先将软件的功能需求转化为工具可以理解的文件格式，再以这个文件作为输入，通过工具生成测试用例。在使用这种测试用例设计工具来生成测试用例时，需求说明的质量是很重要的。

由于这种测试用例设计工具是基于功能需求的，所以可用来设计任何语言、任何平台的任何应用系统的测试用例。

我们来看一个这类工具的例子——SoftTest。在使用SoftTest生成测试用例时，先将软件功能需求转化为文本形式的因果图，然后让SoftTest读入，SoftTest会根据因果图自动生成测试用例。在这个过程中，工具的使用者只需要完成由功能需求到因果图的转化，至于如何使用因果图来生成测试用例，则完全由Softtest完成。

所有测试用例设计工具都依赖于生成测试用例的算法，工具比使用相同算法的测试人员设计的测试用例更彻底、更精确，这方面工具有优势。但人工设计测试用例时，可以考虑附加测试，可以对遗漏的需求进行补充，这些是工具无法做到的。所以，测试用例设计工具并不能完全代替测试工程师来设计测试用例。使用这些工具的同时，再人工的检查、补充一部分测试用例，会取得比较好的效果。

3.2静态分析工具

一提到软件测试，人们的第一印象就是填入数据、点击按钮等这些功能操作。这些测试工作确实是重要的，但它们不是软件测试的全部。与这种动态运行程序的测试相对应，还有一种测试被称为静态测试，也叫做静态分析。

进行静态分析时，不需要运行所测试的程序，而是通过检查程序代码，对程序的数据流和控制流信息进行分析，找出系统的缺陷，得出测试报告。

进行静态分析能切实提高软件的质量，但由于需要分析人员阅读程序代码，使得这项工作进行起来工作量又很大。对软件进行静态分析的测试工具在这种需求下也就产生了。现在的静态分析工具一般提供以下两个功能：分析软件的复杂性、检查代码的规范性。

量度量元处于质量模型分层结构中的最底层，它直接面向程序的代码，记录的是程序代码的特征信息，比如函数中包含的语句数量、代码中注释的数量。质量标准是一个概括性的信息，它比质量度量元高一级，一个质量标准由若干个质量度量元组成的。质量因素由所有的质量标准共同组成，处于软件质量模型的最高层，是对软件产品的一个总体评价。具有分析软件复杂性功能的静态分析工具，除了在其内部包含上述的质量模型外，通常还会从其它的质量方法学中吸收一些元素，比如Halstend质量方法学、McCabe质量方法学。这些静态分析工具允许用户调整质量模型中的一些数值，以更加符合实际情况的要求。

在用这类工具对软件产品进行分析时，以软件的代码文件作为输入，静态分析工具对代码进行分析，然后与用户定制的质量模型进行比较，根据实际情况与模型之间的差距，得出对软件产品的质量评价。

下图是一个商业静态分析工具得出的软件质量与质量模型之间的比较结果。

图3-1静态分析工具得出的软件质量与质量模型之间的比较结果

下图是一个商业的静态分析工具得出的程序中某一个函数的流程图。

图3-2静态分析工具得出的程序中某函数的流程图

具有检查代码规范性功能的静态分析工具，其内部包含了得到公认的编码规范，比如函数、变量、对象的命名规范，函数语句数的限制等等，工具支持对这些规范的设置。工具的使用者根据情况，裁减出适合自己的编码规范，然后通过工具对代码进行分析，定位代码中违反编码规范的地方。

以上就是静态分析工具所具有的功能。与人工进行静态分析的方式相比，通过使用静态分析工具，一方面能提高静态分析工作的效率，另一方面也能保证分析的全面性。

3.3单元测试工具

单元测试是软件测试过程中一个重要的测试阶段。与集成测试、确认测试相比，在编码完成后对程序进行有效的单元测试，能更直接、更有效的改善代码质量。

进行单元测试不是一件轻松的事。一般来讲，进行一个完整的单元测试所需的时间，与编码阶段所花费的时间相当。进行单元测试时，根据被测单元（可能是一个函数，或是一个类）的规格说明，设计测试用例，然后通过执行测试用例，验证被测单元的功能是否正常实现。除此之外，在单元测试阶段，我们还需要找出那些短时间不会马上表现出来的问题（比如C++代码中的内存泄露），还需要查找代码中的性能瓶颈，并且为了验证单元测试的全面性，我们还想了解单元测试结束后，我们的测试所达到的覆盖率。

针对这些在单元测试阶段需要做的工作，各种用于单元测试的工具就产生了。典型的单元测试工具有以下几类：动态错误检测工具、性能分析工具、覆盖率统计工具。

动态错误检测工具，用来检查代码中类似于内存泄露、数组访问越界这样的程序错误。程序功能上的错误比较容易发现，因为它们很容易表现出来。但类似于内存泄露这样的问题，因为在程序短时间运行时不会表现出来，所以不易发现。遗留有这样问题的单元被集成到系统后，会使系统表现的极不稳定。

性能分析工具，记录被测程序的执行时间。小到一行代码、一个函数的运行时间，大到一个exe或dll文件的运行时间，性能分析工具都能清晰的记录下来。通过分析这些数据，能够帮助我们定位代码中的性能瓶颈。

覆盖率统计工具，统计出我们当前执行的测试用例对代码的覆盖率。覆盖率统计工具提供的信息，可以帮助我们根据代码的覆盖情况，进一步完善测试用例，使所有的代码都被测试到，保证单元测试的全面性。

动态错误检测工具、性能分析工具、覆盖率统计工具的运行机理是：用测试工具对被测程序进行编译、连接，生成可执行程序。在这个过程中，工具会向被测代码中插入检测代码。然后运行生成的可执行程序，执行测试用例，在程序运行的过程中，工具会在后台通过插入被测程序的检测代码收集程序中的动态错误、代码执行时间、覆盖率信息。在退出程序后，工具将收集到的各种数据显示出来，供我们分析。

目前被普遍使用的单元测试工具中有Compuware公司的NuMega DevPartner Studio，Rational 公司的Rational Suite Enterprise。这些软件产品都是一个工具套件，其中包含了我们前面所讨论的动态错误检测工具、性能分析工具、覆盖率统计工具等。

3.4功能测试工具

在软件产品的各个测试阶段，通过测试发现了问题，开发人员就要对问题进行修正，修正后的软件版本需要再次进行测试，以验证问题是否得到解决，是否引发了新的问题，这个再次进行测试的过程，称为回归测试。

由于软件本身的特殊性，每次回归测试都要对软件进行全面的测试，以防止由于修改缺陷而引发新的缺陷。进行过回归测试人都会深有体会，回归测试的工作量是很大的，而且也很乏味，因为要将上一轮执行过的测试原封不动的再执行一遍。设想一下，如果能有一个机器人，就象播放录影带一样，忠实的将上一轮执行过的测试原封不动的在软件新版本上重新执行一遍，那就太好了。这样做，一方面，能保证回归测试的完整、全面性，测试人员也能有更多的时间来设计新的测试用例，从而提高测试质量；另一方面，能缩短回归测试所需要的时间，缩短软件产品的面市时间。功能测试自动化工具就是一个能完成这项任务的软件测试工具。

功能测试自动化工具理论上可以应用在各个测试阶段，但大多数情况下是在确认测试阶段中使用。功能测试自动化工具的测试对象是那些拥有图形用户界面的应用程序。

一个成熟的功能测试自动化工具要包括以下几个基本功能：录制和回放、检验、可编程。

录制，就是记录下对软件的操作过程，回放，就是象播放电影一样重放录制的操作。启动功能测试自动化工具，打开录制功能，依照测试用例中的描述一步一步的操作被测软件，功能测试自动化工具会以脚本语言的形式记录下你操作的全过程。依照此方法，可以将所有的测试用例进行录制。在需要重新执行测试用例时，回放录制的脚本，功能测试自动化工具依照脚本中的内容，操作被测软件。除了速度非常快之外，通过功能测试自动化工具执行测试用例与人工执行测试用例的效果是完全一样的。

录制只是实现了测试输入的自动化。一个完整的测试用例，由输入和预期输出共同组成。所以，光是录制回放还不是真正的功能测试自动化。测试自动化工具中有一个检验功能，通过检验功能，在测试脚本中设置检验点，使得功能测试自动化工具能够对操作结果的正确性进行检验，这样，就实现了完整的测试用例执行自动化。软件界面上的一切界面元素，都可以作为检验点来对其进行检验，比如文本、图片、各类控件的状态等。

脚本录制好了，也加入了检验点，一个完整的测试用例已经被自动化了。但我们还想对脚本的执行过程进行更多的控制，比如依据执行情况进行判断，从而执行不同的路径，或者是对某一段脚本重复执行多次。通过对录制的脚本进行编程，可以实现上述的要求。现在的主流功能测试自动化工具都支持对脚本的编程。象传统的程序语言一样，在功能测试自动化工具录制的脚本中，可加入分支，循环，函数调用这样的控制语句。通过对脚本进行编程，能够使脚本更加灵活，功能更加强大，脚本的组织更富有逻辑性。在传统的编程语言中适用的那些编程思想，在组织测试自动化脚本时同样适用。

在测试过程中，使用功能测试自动化工具的大体过程是这样的：

● 准备录制

保证所有要自动化的测试用例已经设计完毕，并形成文档。

● 进行录制

打开功能测试自动化工具，启动录制功能，按测试用例中的输入描述，操作被测试应用程序。

● 编辑测试脚本

通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。

● 调试脚本

调试脚本，保证脚本的正确性。

● 在回归测试中运行测试

在回归测试中，通过功能测试自动化工具运行脚本，检验软件正确性，实现测试的自动化进行。

● 分析结果，报告问题

查看测试自动化工具记录的运行结果，记录问题，报告测试结果。

功能测试自动化工具是软件测试工具中非常活跃的一类工具，现在发展的已经较为成熟，象Mercury Interactive公司的WinRunner，Rational公司的Robot，都是被广泛使用的功能测试自动化工具。

3.5性能测试工具

通过性能测试，检验软件的性能是否达到预期要求，是软件产品测试过程中的一项重要任务。性能测试用来衡量系统的响应时间、事务处理速度和其它时间敏感的需求，并能测试出与性能相关的工作负载和硬件配置条件。通常所说的压力测试和容量测试，也都属于性能测试的范畴，只是执行测试时的软、硬件环境和处理的数据量不同。

对系统经常会进行的性能测试包括：系统能承受多少用户的并发操作；系统在网络较为拥挤的情况下能否继续工作；系统在内存、处理器等资源紧张的情况下是会否发生错误，等等。由于性能测试自身的特点，完全依靠人工执行测试具有一定的难度。比如，我们要检验一个基于Web的系统，在10000个用户并发访问的情况下，是否能正常工作。如果通过人工测试的方式，很难模拟出这种环境。在这种情况下，就需要使用性能测试工具。

使用性能测试工具对软件系统的性能进行测试时，大体分为以下几个步骤：

首先，录制下软件产品中要对其进行性能测试的功能部分的操作过程。这一步与前面我们讨论过的功能测试自动化工具中的那个录制过程很相似。功能录制结束后，会形成与操作相对应的测试脚本。

然后，根据具体的测试要求，对脚本进行修改，对脚本运行的过程进行设置，如设置并发的用户数量、网络的带宽，使脚本运行的环境与我们实际要模拟的测试环境一致。

最后，运行测试脚本。性能测试工具会在模拟的环境下执行我们所录制的操作，并实时的为我们显示与被测软件系统相关的各项性能数据。

性能测试工具实际上是一种模拟软件运行环境的工具，它能帮助我们在实验室里搭建出我们需要的测试环境。现在，基于Web是软件系统发展的一个趋势，性能测试也就变的比以往更加重要了，性能测试工具也自然会在软件测试过程中被更多的使用。

3.6测试过程管理工具

软件测试贯穿于整个软件开发过程，按照工作进行的先后顺序，测试过程可分为制定计划、测试设计、测试执行、跟踪缺陷这几个阶段。在每个阶段，都有一些数据需要保存，人员之间也需要进行交互。测试过程管理工具就是一种用于满足上述需求的软件工具，它管理整个测试过程，保存在测试不同阶段产生的文档、数据，协调技术人员之间的工作。

测试过程管理工具一般都会包括以下这些功能：管理软件需求、管理测试计划、管理测试用例、缺陷跟踪、测试过程中各类数据的统计和汇总。

市面上商用的测试管理工具有很多，基本上都是基于Web的系统，这样更利于跨地区团队之间的协作。

4正确认识测试工具的作用

如果一个现在正在从事软件测试工作，但在测试过程中还没有使用过测试工具的人看到以上的这些内容，可能会非常兴奋，因为他觉的只要在测试过程中引入相关的测试工具，那些一直困扰他们测试团队的问题就都能轻松解决了。

在业内经常会有这种想法，认为通过引入一种新的技术，就能解决面临的所有问题了。这种想法，忽视了除技术以外我们仍然需要做的工作。软件测试工具确实能提高测试的效率和质量，但它并不是能够解决一切问题的灵丹妙药。

软件测试工具能在测试过程中发挥多大的作用，取决于测试过程的管理水平和人员的技术水平。测试过程的管理水平和人员的技术水平都是人的因素，是一个开发组织不断改进，长期积累的结果。如果一个测试组织的测试过程管理很混乱，人员缺乏经验，那么不必忙于引入各种测试工具，这时首先应该做的是改进测试过程，提高测试人员的技术水平，待达到一定程度后，再根据情况逐步的引入测试工具，进一步的改善测试过程，提高测试效率和质

量。

5结束语

软件测试在整个软件开发过程中占据了将近一半的时间和资源。通过在测试过程中合理的引入软件测试工具，能够缩短软件开发时间，提高测试质量，从而更快、更好的为用户提供他们需要的软件产品。