软件测试的目的
提出这个问题并不是要准备面试一个刚刚参加工作的新人，世界上所有问题都可以有N 种正确答案。我们知道，很多好的公司会使用笔试的方法来做初步的技能筛选。如果有判断题，我的窍门是千万不要勉强自己，对自己看着不顺眼的一概打上“×”，然后按自己的理解写。越是理解不足的，越要多写。
把判断题做成简答题，不要管题目是不是要求这样，也不要管你未来的经理会怎么判断，写出你自己的理解。
下面是一个常见的笔试题，是我在应聘一家公司测试主管的时候做的，网络上这种题目很丰富的。
软件测试的目的是尽可能多的找出软件的缺陷。（）
这个题目业界公认的答案来自于Grenford J. Myers 在《The Art of Software Testing 》，其中对软件测试做了精确的描述：
✓程序测试是为了发现错误而执行程序的过程
✓测试是为了证明程序有错，而不是证明程序无错误；
✓一个好的测试用例是在于它能发现至今未发现的错误；
✓一个成功的测试是发现了至今未发现的错误的测试。
在我刚从事测试的前两年，我非常相信发现问题就是测试工作的根本目的，我们要象啄木鸟一样把更多的虫子从树干中捉出来，我们的团队曾经有自己一个称号叫“虫虫特攻队”。每天我们都会相互竞争，并在竞争中学会更多的捉虫技巧。这本书的很多内容就来自于我们日复一日捉虫比赛中。
好了，让我从啄木鸟的美好回忆中重新回到笔试现场，来看看软件测试的目的吧。为了更好的说明问题，我在这里采用一问一答的方式来引出答案。
提问：为什么软件要测试
回答：因为怕有不能用的功能
提问：为什么软件会不能用
回答：因为大家都人会出错
提问：会出哪些错
回答：代码会写错、架构会考虑不足、网络安全方面会有盲区、需求会理解错
提问：要找到多少错误才算测试完成呢
回答：……
如果软件测试的目的是尽可能多找出更多的缺陷，那么尽可能多是多少呢？我们再来一段问答吧，这有利于我们找到软件测试的另外一个目的
提问：软件有什么作用？
回答：软件给我们工作、生活、学习、娱乐带来更多的便利。
提问：怎么样的软件是好软件？
回答：满足使用者需要，好学好用，不会出错。
提问：怎么满足需要呢？
回答：通过有效地用户需求调研、业务建模、系统分析等过程，将用户需求转变为软件设计。并通过详细设计、代码开发来实现软件功能，通过软件测试来验证功能符合要求需求。最终形成满足用户需求的软件产品。
提问：怎么做到好学好用呢？
回答：把用户想要软件做的事情列出来，用户通过操作很快就能找到怎么用软件来做想做的事情，或者很快可以通过指导学会做想做的事情，就是好学好用。
提问：怎么做到不会出错呢。
回答：用户想要做的事情，能够按照用户学习到的操作方法来解决，而不会出现不可预期的意外结果。
通过分析，我们可以修正软件测试的目的了。
软件测试的目的是尽可能多的找出软件的缺陷。（×）
软件测试的目的是为了保证软件产品的最终质量（√）
（此处的软件测试限于软件企业自身体系内的测试，如果是第三方评测机构则另当别论。）
保证质量意味着满足需求，满足需求意味着没有影响用户实现的缺陷。
黑盒测试的作用
我们先来复习一下黑盒测试的定义：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。（《软件评测室教程》清华大学出版社）
我想可以这样理解黑盒测试：从用户的角度通过执行软件，来判断软件是否满足需求的测试方法。
在前面我们对测试的目的做了定义：软件测试的目的是为了保证软件产品的最终质量。软件质量是多方面的，而功能方面满足用户需求是最基础质量。而这方面通常是黑盒测试发挥更大的作用。
因为软件的目标是实现用户需求，而黑盒测试是验证软件需求的基础手段，最终系统测试或验收测试也是黑盒测试。因此，可以说测试的基础手段和最终手段就是黑盒测试。
从目前的情况来看，黑盒测试在很多人心目中是很没有技术含量的工作，是较低级的测试工作。在几个热门的测试论坛上，经常有入门的测试工程师迷惘而不安的询问怎么样做性能测试、自动化测试这些高级一些的测试工作，摆脱黑盒测试这种低级的工作。
我写这本书的一个重要的目的在于希望它能够分享我对于测试方面的经验，纠正业内对黑盒测试方面的误解。
第一章理解需求
要做好黑盒测试，一个必要的前提是理解需求，一些工程师对黑盒测试
案例－成绩管理系统
有一个学生成绩管理系统。由三个模块组成
模块一：基数数据设置模块，指年级班级科目设置
模块二：数据录入模块，为每个班级年级编制学生名录，并按考试科目时间输入成绩。
模块三：成绩输入，考试结果统计输出，支持自定义条件，比如考次，平均分数、及格率指标等。
我们通过这个案例来学习如何有效的理解需求。
如果用户需求这样写：“系统能够生成某年级（班级）某科目某次考试的优秀、良好和及格率指标”，你是否能够理解系统想做成什么样子？
我建议读者在这里合上书本，把这个需求抄在纸上，并列出你能够想到的功能点或疑问，对该需求的理解。或者干脆画一个流程图。
下面是我列出的一些疑问，如果你能够想到其中一些或者更多，那说明你已经能够很好的理解用户需求。
①及格的分数线在哪里设置？什么时候设置？
②是否每门课程的及格分数线是一样的？
③是否需要考虑补考及格率？
④补考成绩是计算是否需要单独统计？
我们能够很容易地理解《学生成绩管理系统》的需求，并将需求中存在的疑问罗列出来，是因为我们都对考试有清楚的了解，比如我们知道现在并不是所有的考试满分都是100分，因此，不能简单地把60分算作及格分数线；我们知道除了正考，还有补考；我们也知道补考分数往往不会参与考试分数统计的。
我们对“考试”这个业务非常了解，这方面的业务有足够的经验来支撑我们提出问题。正因为这样，即使用户需求写得再简单，我们都可以提出很多疑问，而不会在拿到需求文档后表现茫然。
从这个案例中，我们可以明确这样一个道理：测试不仅仅需要知道用户提了哪些需求，更应该去了解用户还有哪些没有提出来，这需要测试人员加强对业务的了解，要做好软件功能测试，应该努力把自己培养成业务专家。
案例－数据生成饼图
现在我们来看一个很简单的功能，要求把列表数据生成饼图，很多经营分析类软件中常见的功能。
图一
上面是一个饼图的例子，一个组织中的9种产品利润产出百分比，仔细观察它，我们可以看到该图是按照产品序列顺时针排序的。
图二
再来看图二，它的数据和图一完全一致，所不同的是，它是按照利润贡献大小顺时针排序的。
以上两者的差别视乎并不大，用户都可以方便的使用，那么我们产品扩大到30种。
图三
图三和图二一样按照产品利润贡献排序，但我相信用户不会喜欢这样的展示。因为排名从第12位开始，就已经看不清楚产品名称。
图四
图四是图三的修正，将微小数据合并为“其他”，这不失该为一种解决方案，系统识别前N位，余下的用其他表示，这种方法用在数据差异较大的情况下效果较好，如果数据比较均匀的情况下，则完全不适用。
图五
图五可以显示的信息更多，而且更清晰，但程序的处理更难。
我们可以来考虑一下，如果程序按照图四来实现，程序会增加哪些功能？
图四“其他”之前的累积为90.5，占到了总数据的绝大多数，复合“数据差异较大”的要求，倒数第二个产品――即“其他”前一个――是产品15（占3%），而图三的产品15后面是产品4（占1.5），属于明显的小数据。
可见，我们在取舍数据截止点是需要考虑这两个基本因素，其他之前的占大多数，其他之后的占小份额。
因此，如果要生成这样的图片，系统需要支持灵活定义“其他”的阀值。
请不要怀疑如此花时间考虑一个饼图是否有实际意义，这个例子的灵感来自于某电信运营商的数据分析平台。新的产品卖点被挖掘而不会被埋没在“其他”之中，是企业经营中的关键，这样的功能做好了，无疑是软件产品的卖点所在。
理解需求在于理解它的细节，测试工程师对系统的输入输出要有清晰、敏锐的感知，虽然很少有软件系统针对饼图的显示会有这么高的要求，但这个例子很能说明问题。
需求的来源
上面两个例子已经说明了理解需求对于测试工作的重要性，任何关于软件工程方面的书籍都认同这样一个观点：测试越早介入越好，最好从需求阶段就介入。
这个观点是非常正确的，那么，在需求阶段，测试如何介入呢，这里，我们先来追溯一下需求的来源。
图六（资料来源Rational Unified Process 2000中文版）
关于需求的生命周期，Rational Unified Process 2000（以下简称RUP）中描述的非常清晰，需求首先来自于分析问题和涉众需要，对现有系统的要求反馈和对新系统的问题分析，都需要逐一记录，经过登记、分解，转化为软件功能，并结合工作量的分析，评估系统规模，最终落实开发工作。这所有的一切都接受需求变更流程的管理。
软件工程中，需求有很多分类方法，图七是一种常见的按照需求层次定义方法，利用这种定义方法可以比较清晰地了解软件研发过程中需求是如何一步步变成功能的。
图七
依据需求的一种递进模式，企业对需求的定义或多或少有些差异，这不是原则性差异，我们以上面的做为例子来说明。
业务需求
业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，业务需求是指导后续软件研发范围的纲领性目标，需要通过业务建模（Business Modeling）等手段来完成的工作，业务需求描述的更多是软件产品或项目宏观方面的目标。
比如对于一个ERP系统来说，以下是业务需求的要点描述
1、支持流程重组，用户企业组织架构、流程角色可以系统平台上重组。
2、支持企业知识和数据整合，客户组织的产品策划、市场调研、营销管理、成本控制
等数据可以通过系统进行决策分析。
3、支持全业务流程绩效考核数据整合，系统提供实时跟踪KPI指标。
…………
当然，业务需求不仅仅上面列举的口号式的内容，为保证这些要点的最终实现，在业务需求文档上会有大量的内容来支撑这些最终目标。
并非所有的软件产品或系统都需要业务需求，一个简单的MIS也许不需要专门的业务需求，而一个复杂度更高的ERP系统则一定需要业务需求。
业务需求文档会对业务背景做比较详细的分析，因此，业务需求文档是测试人员学习领域知识的最佳材料。
1：用户需求：反映用户使用本系统需要完成的任务
2：业务需求：反映了组织机构或客户对系统、产品高层次的目标要求
3：系统需求：定义了开发人员必须实现的软件系统能力，使得用户能完成他们的
任务，从而满足业务需求。
用户需求
用户需求是用户方面提出的，反映用户需要系统能够完成的任务，用户需求可以用过用例分析等手段来完成，他描述了系统需要哪些角色、各个角色如何执行操作，所有的用例整合成一个系统。
比如针对《客户服务处理系统》，下面是一些用户需求的要点：
1、客服人员针对客户问题，在知识库内搜索，并将解决问题的建议告知客户；
2、客服人员提交新知识，客服主管审核新知识，归档到知识库；
3、公司领导能够查询到客服人员每日答复数量和答复问题清单；
4、提供7*24小时客户服务，客服人员登记上下班时间；
5、客服主管按日、月、季度、年份等时间指标查询客服工作量统计和客服满意度统计
报表；
…………
这些需求是从用户的视野来描述的，记录了用户对《客户服务处理系统》的预期目标，客户愿意为完成这些目标支付费用。
一般情况看，软件开发有可能没有业务需求，但必须有用户需求，否则，软件开发过程中容易将迷失软件目标，或不知不觉的扩大或缩小软件范围。
对于测试团队来说，用户需求是测试的基本指南，尤其是针对黑盒测试工程师而言，用户需求的作用更像是旅行者手中的地图。
从RUP的观点来看，从用例生成测试用例可以有效的保证测试覆盖。
系统需求
系统需求也叫功能需求，有时也指狭义的软件需求，它定义了软件必须实现的功能，使得用户能利用这些功能完成他们的预期任务（用户需求），从而实现了整个系统的最终目标（业务需求）。
系统需求也可以简单的理解为是系统的功能点，我们再来回顾在“用户需求”小节中我们所举的《客户服务处理系统》例子，我们看看们对应的系统需求如何定义。
1、客服人员针对客户问题，在知识库内搜索，并将解决问题的建议告知客户；
a)客服人员－坐席新建客服工单，简要记录问题信息，并根据关键词搜索，如搜
索到相关信息，则反馈给客户，如果可以解决客户问题，则将该客服工单关
闭。如果不可以解决问题，则提交给客服－技术支撑岗
b)客服人员－技术支撑通过关键词搜索知识库，将搜索到的信息提交给客户。如
问题解决有效，则关闭客服工单。
c)如关键词搜索没有相关信息，则属于新问题，则客服人员－技术支撑点击新建
技术支持申请单，提交客服主管
d)客服主管审核技术支持申请单，提交到技术支持模块。
系统需求的清单也可以做为功能点清单来使用。
测试人员可以通过对系统需求是否实现用户需求来有效地验证软件的质量。
需求的静态测试
需求也是可以测试的，在白盒测试领域有一个术语“静态测试”，指不运行程序，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。
我们也可以把包含需求文档在内的文档类测试称之为黑盒测试领域的静态测试。
我们需要一个专门的方法来让我们记住自己的父母、伴侣或孩子吗？大多数人可能都会不以为然，我们对自己的亲人足够了解，即使我们没有能力把他们的相貌画在纸上，但我们可以保证随时以认得出他们。
但是，需求并不那么容易了解，还记得我们在前面《成绩管理系统》的案例中提出的几个问题吗？这些问题实际上就是一个对需求进行静态测试的例子，但是，这些是零散的，可能存在缺漏的，我们不会象了解我们的亲人一样了解业务需求、用户需求或系统需求，所以我们应该用科学的方法来保证我们对需求测试的理解。
需求一致性判断
我们在前面已经简单地介绍了需求的三种层次，静态测试最基本的是要确认业务需求－用户需求－系统需求之间的一致性，其中业务需求由于涉及的信息更宏观、更抽象，因此一般情况下，需要确认业务需求上描述的信息是否能够在用户需求上得到映射就可以了，不需要非常精确去判断两者间的对应关系。
另外，在通常的定制化系统中，业务需求并非在一个版本中就全部完成，比如整个系统将分多期实现，而业务需求在细节上未必是可分解的，这种情况下，测试计划更依赖用户需求的确认
因此，我们的重点是用户需求和系统需求之间的一致性静态验证。
案例－客服工单处理
我们还是用上面举到的客服工单处理来讨论如何验证用户需求和系统需求的一致性。
1、客服人员针对客户问题，在知识库内搜索，并将解决问题的建议告知客户；
a)客服人员－坐席新建客服工单，简要记录问题信息，并根据关键词搜索，如搜
索到相关信息，则反馈给客户，如果可以解决客户问题，则将该客服工单关闭。
如果不可以解决问题，则提交给客服－技术支撑岗
b)客服人员－技术支撑通过关键词搜索知识库，将搜索到的信息提交给客户。如
问题解决有效，则关闭客服工单。
c)如关键词搜索没有相关信息，则属于新问题，则客服人员－技术支撑点击新建
技术支持申请单，提交客服主管
d)客服主管审核技术支持申请单，提交到技术支持模块。
上面是针对用户需求1的4点系统需求（你也可以把他说成四个功能点）。
我们先不看功能点，而是依据用户需求自己来推导为完成这个用户需求，系统需要做什么。
这里，我使用了思维导图的方式来理解用户需求，如下
上图是对用户需求的功能属性做测试需求分析，这方面的工作不仅仅测试工程师会做，同样的，系统设计师也会根据用户需求来设计界面交互原型，各种角色对于问题的考虑方向会有一定的偏差。而在各角色参与的沟通活动中，会互相分享各自的思维导图，并修正偏差。这种方法在敏捷开发模式中被推崇。尤其是产品化软件开发中，是缺陷预防的重要手段。
第二章编制测试计划
测试计划的编制并非本书的重点，但我前面说过，这本书是入门教程，因此，为了保证内容的系统性，我依旧把测试计划作为一个章节。
众所条件周知，测试越早开始越好，或者严格的说，测试越早发现缺陷越好。
在CMM/CMMI体系中，对软件组织能力成熟度有标准的识别模式。这些是很有用的经
验。建议读者做比较深入的学习。
测试能力成熟度判断
从测试角度来看，我们可以通过测试在软件产品（或项目）研发过程中各阶段贡献大小来做简单的比较。
初始等级的研发团队没有专职测试工程师，或者有测试工程师，但没有有效的工作组织，测试的目标以验证软件功能为主，注意此处是验证软件功能，通常的情况是，测试人员对需求了解不够深入，测试工作量绝大多数主要由运行可执行程序，发现缺陷，记录缺陷为主。通常在组织中会被理解为质量的消防队伍。
在我曾经服务的一个公司中，我们的测试团队也做了很长时间的消防队伍，哪个项目着火就把最大的资源投入到哪个项目中。我带着团队陷入疲于奔命的工作中，但情况并没有得以控制，在软件发布后接连出现低级错误性质的重大缺陷。作为团队leader的我，屡屡在糟糕的问题前不由自主的陷入沮丧中。
有一个被上千企业用户使用的软件产品中，居然正版控制开关是失效的。也就是说，这个需要付费的企业级软件产品可以被随意地安装，并且不需要任何盗版手段。
如果你可以假设这样一个场景，你就会明白我当时有多苦恼。这是最基本的测试，但却在我的手里丢掉了。
那段时期，我一直在怀疑自己是否真的称职。但幸运的是，公司一个前辈给我讲了一个故事，这个前辈在工业领域、企业ERP领域非常资深，这个故事给我很好的启发，我现在分享给各位。
故事－塑料制品厂的质量困境
基本情况介绍
有这样一个小工厂，他们的主要产品是塑料制品，我便于理解，我做了最简单的生产流程图示。
业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业业
业业业业业业业业
业业业业业业业业业业业业业业业业业业业业业业
上图简要的把涉及车间生产环节的四种角色和工作职责进行了罗列，假设现行的检修标准3个瑕疵，也就是超过3个瑕疵的半成品需要报废，重新粉碎后回炉，3个以内（含3个）瑕疵则有检修人员修复。
目前每台注塑设备由一个熟练注塑技师操作，每日运作8小时，生产100个半成品。平均每个半成品有1.2个瑕疵，熟练工人每修复1个瑕疵耗时10分钟。累积每日120个瑕疵需要修复时间为20小时，我们可以了解到注塑技师和检修工人的资源配备是1:3。
另外，企业每天有5％的半成品报废，包装环节合格率为100％，每日成品入库为95个。
面临挑战
这个塑料制品厂按照这样稳定运营，现在一个新的机会来到了，企业通过C2C系统接受了更大的订单，这使得企业的产量要达到300个。按照每日8小时的工作时间，企业需要3台注塑机。以及增加2倍的人工。
要满足需求，意味着需要更多的设备的人力，而这个小工厂的老板认为这是个偶然的机会，这样的额外订单不会经常光临，因此，保守的老板不打算添置2台注塑机。但招聘2倍的人力是值得的。
并且车间每日（8小时）注塑半成品100件，
最优秀的组织在需求阶段测就可以有效的进行缺陷试就可以发现一个简单的组织能力成熟识别能力
但在很多软件研发机构中，测试小组或测试工程师并不能如此早的投入，在后期才
在CMM/CMMI体系中，对于需求
软件缺陷是软件研发中产生的错误，而不是测试团队的成果。
请注意这句话并非要挑起开发团队和测试团队之间的嘴皮子官司。因此，测试团队在面对测试不力的指责，请不要用上面这句话来做为PK的长矛或者坚盾。下载本文
