前言

软件测试是软件研发过程中的一个重要环节，作为一个独立的工作是在我国20世纪末和21世纪初逐渐形成的。随着软件行业的发展，至今已有一支十分庞大的专门从事软件测试工作的队伍活跃在软件企业中。

我是国内最早一批从事软件测试的工程师，先后在北京炎黄新星互联网络有限公司（公司产品：中国家庭网和800buy电子商务网站）、中兴通讯（南京）有限公司、意法半导体（中国）有限公司（公司产品：数字电视机顶盒）以及爱立信（中国）通信有限公司等单位工作过。十几年来，软件测试从无到有，我经历了整个过程，所以对软件测试有比较深入的了解和体会，也积累了一些经验。我把在工作中遇到的一些问题和案例写成数十篇文章，在51Testing等各大网站上发表，得到广大软件开发和测试人员的认可和支持，遵照一些朋友的建议，我把网上的这些文章重新整理修改，并增加了一些新的内容，集结成一本书。在这本书中，我主要以案例为驱动，介绍软件测试工作中一些常用的方法、思路、遇到的问题以及解决这些问题的方法。

1997年，我毕业于北京工业大学计算机学院软件工程专业，在学校里，软件测试仅仅作为《软件工程》的一个章节进行介绍。毕业后，我进入一家互联网公司从事网站的开发工作。当时软件测试在许多单位都不是一个独立的部门，软件测试一般都由开发人员自己来完成。由于没有专职的软件测试人员，所以软件的安全性、稳定性、可靠性等都很难得到保证。实际工作中遇到过不少案例，下面几个例子就可以得到证实。

2000年我所在的公司与CCTV“开心辞典”栏目组合作开发网上答题的项目，这是一个智力娱乐性节目，我编写了前端的答题代码，考虑到可能有人用计算机程序来答题，如编写一个死循环，一直选择B（或A、C、D），这可以使答题的速度很快，命中率也非常高，为此，我选用JavaScript过滤了使用死循环的答题者。可是，到了“开心辞典”正式使用这个软件时，发现仍然有人使用死循环来答题，可我的程序是正确的。后来，在一次聊天模块中，通过登录账号我找到了这位“达人”，他说我们前端的确没有漏洞，他是通过自己编写的程序绕过我们前端进入到系统后端的，而我们的后端并没有进行校验。当初如果有专业的测试人员，这个Bug是有可能避免的。

众所周知，软件产品的安全性是很重要的问题，而软件测试是保证产品安全的关键所在。下面的例子说明如果没有做好软件测试，就可能造成严重的后果。有一次我所在的公司开发了一个产品，用户曾经投诉，采用我们公司的这个产品后，经常发现一些没有登录的用户也会进入系统，损毁了公司的形象，造成很大的损失。后来经过数个月的排查才发现，这是开发人员没有对SQL语句进行专门处理，由于SQL注入造成的。像这样的问题，如果在正式上线前，经过严格的测试，这个Bug是可以事先找到和解决的，这样就不会造成那么大的损失。当然，要能够测试出上面出现的Bug，是需要有一定工作经验的，只有具有丰富软件开发经验的人才能胜任，所以我一直强调从事软件测试工作前最好进行3年以上的软件开发工作。为此，在本书的有关章节中我将会进行详细阐述。

本书还将介绍一些功能测试和性能测试相互依存的例子，这源于我在某家公司做BBS系统的测试工作，系统在前4个月运行一直非常好，可后来系统显示的速度明显降低了，原来几秒钟显示一个页面，现在变成要两分钟才能显示页面。以前好评如潮，现在投诉不断。经过查找，发现这是由于当时只做了功能测试，而没有进行规范的性能测试造成的。“重功能，轻性能”，这是在软件测试工作中经常犯的一个毛病，值得引起重视。

软件测试必须对相应的业务有所了解。记得我刚到意法半导体有限公司时，从事数字电视机顶盒测试工作。这是一种嵌入式软件产品，这种类型的测试工作往往比较复杂，因为这种软件在开发初期是看不见、摸不着的，只有到后期才可以在仿真器、模拟器，甚至移植到真机中才能测试，再加上我对数字电视业务知识的缺乏，在测试中不太容易发现Bug。记得在2005年12月31日，开发人员当天下午5点才把一份软件测试版本交给我们测试人员，为了交给客户作元旦的献礼，我们必须在当天下午6点半做完测试，时间紧迫，我们只能对一些最重要的功能进行测试，又加上我对业务不太熟悉，选择重点时没有把握好，产品交付给用户在2006年元旦使用时，开始系统运行得非常好，但一个多小时后，数字电视的音量达到最大，更糟的是，根本无法用遥控器来进行操控。后来究其原因是嵌入式软件的内存空间很小，而程序中存在着野指针，所以发生了内存溢出，导致音量失控。

开发与测试之间经常是一对矛盾，这往往需要开发与测试之间进行有效沟通来解决。记得2008年上半年，我所在公司的产品进入一个开发的关键时期，开始大规模地招聘开发人员，公司40%多的开发人员都是新员工。这段时间，测试人员总能发现许多Bug，使得大部分开发人员要疲于修改这些Bug，根本没有时间去开发产品的新功能，这就导致开发人员对测试人员的意见很大，甚至有些开发人员认为测试人员是故意给他们找麻烦。当时我作为测试经理认识到测试人员与开发人员之间的矛盾必须解决，必须协调双方的关系，于是我一方面要求测试人员不但要能发现问题，还要逐步学会从Log日志中定位到问题，尽可能协助开发人员解决问题。同时我又主动和开发部门经理协商，要求开发人员在提交测试版本之前必须认真做好自测。之后，开发人员与测试人员之间关系得到改善，产品的质量也得到提高。

由于新兴的敏捷开发模式便于在相对短的迭代周期内发布一个新版本，往往几个月就可以发表一个新的版本。这就给回归测试带来很大的挑战，也促使自动化测试得到不断发展。在回归测试中，自动化测试扮演了非常重要的角色，特别是后来采用持续集成（CI）技术，自动化测试的优势得到了更好体现。当然，自动化测试也不是万能的，由于自动化测试工具本身也是软件，它也会有Bug，特别是刚开发出的自动化测试脚本，用它验证产品代码，当发现一个测试用例没有通过时，就很难判定是产品的问题还是自动化测试脚本本身的问题。另外，随着需求的变更，自动化测试脚本的更新也要随时跟进。这会使得测试人员的大部分精力都集中在调试和维护自动化测试脚本上，而不能更好地做好测试分析与设计工作。自动化测试在软件基本功能验证以及性能测试等不能用手工方法来完成的测试工作中，取得了很好的效果。但是，在一些基于经验的测试方法，如“探索式测试”“缺陷攻击法”中，大部分还是需要通过手工方法来实现。

有了一定的测试经验如果没有理论的结合，也是不完美的。例如，进行兼容性测试时，组合的对象往往很多，穷举测试是不太可能的，随机抽样测试也不靠谱。根据一种叫“正交测试法”的测试理论，可以把测试用例减少很多。另外，它有统计学的理论作为保证，其测试的可靠性也得到提高。这说明，由于IT行业发展十分迅速，从事软件测试的工作者也要与时俱进，不断学习新的理论和方法。

以上只是本书中的一小部分，我把十几年在软件测试中的实践、体会和思考总结成书，希望为读者打开一扇通往软件测试之路的大门，使读者寻找到解决测试问题的技术和方法，体验到测试工作中“逮”Bug犹如“寻宝”的乐趣。本书可供软件测试同仁借鉴。由于现在许多大学里，计算机专业都开设了软件测试课程，所以本书也可作为大专院校计算机软件专业学生的参考书。

全书分为“设计”“工具”和“管理”3篇，共14章，每个章节之间虽有一定的联系，但也可各自独立成章，读者可以根据自己的需求，按照书的内容顺序阅读，也可以根据自己的兴趣选取相关章节阅读。

最后，感谢人民邮电出版社张涛先生及其编辑团队、51Testing编辑严代丽对本书的出版做出的辛勤劳动，没有你们的大力支持，出版本书的愿望是不可能实现的；感谢微信平台，它将我与全国的软件测试爱好者连接起来，共同分享软件测试给大家带来的喜怒哀乐，让大家能够利用这个平台分享软件测试的经验、思想和方法，进一步丰富本书的内容；在这里特别感谢杨艳艳、叶微、刘琛梅、赵明、刘莎莎、万巧、张晓丽、陈佳丽、詹露、张子繁、金鑫、冯昌、帅敏、沈晓静、赵院娇和蹇辉在出版后期对本书进行了仔细的校对。另外，我还要感谢我的家人对我这次出书工作在精神、物质及生活上的支持。祝愿软件测试行业能够在中国得到更好发展，有更多的测试专家能够在中国出现。本书的全部附录、代码以及探索式测试课程均可扫描下面的二维码从网站上下载。

由于本人水平以及时间有限，书中难免存在错误或者不足之处，请广大读者不吝指正。我的E-mail:xianggu625@126.com，微信号：xianggu0625。个人网站：www.3testing.com。编辑联系与投稿邮箱为zhangtao@ptpress.com.cn。