零基础快速入行入职软件测试工程师

1.初识软件测试

1.1初级软件测试专业知识点

1.2初级软件测试员“非专业”知识点

1.3软件测试工程师需具备两大核心素质：人格品质和沟通能力。

2.软件测试入门

2.1实体产品测试用例

2.1.1测试矿泉水瓶

2.1.2测试白板笔

2.2软件测试实例

2.2.1邮箱之登录测试

2.2.2邮箱之发信测试

3.测试工作从评审需求开始

3.1项目成员

3.2项目成员与需求的关系

3.3评审需求文档

3.4如何评审需求文档

3.5 求职指导

4.软件测试的基本概念

4.1软件测试的定义

一）软件质量定义

二）软件测试的定义

三）软件错误的定义

四) 什么叫80/20原则

4.2 软件测试的分类

4.2.1测试原理分类

4.2.2 测试阶段分类

4.3 初级软件测试人员的定位

4.4 软件测试分类关系表

4.5 本章小结

4.5.1学习提醒

4.5.2求职指导

5.软件测试计划

5.1软件测试计划的内容

5.2软件测试计划的模板

5.3本章小结

5.3.1学习提醒

5.3.2求职指导

一）本章面试常见问题

第6章 测试用例的设计

6.1 什么是测试用例

6.1.1 测试用例的格式

6.1.2测试用例的作用

6.1.3测试用例与需求的关系

6.2功能测试的用例设计方法

6.2.1等价类划分法

1.初识软件测试

初级软件测试专业技术分三类：一是软件功能测试技术；二是Web自动化测试的初级应用能力；三是接口测试的初级应用能力。

1.1初级软件测试专业知识点

一，软件功能测试。通常来说就是手工测试，是最基础和不可替代的测试技术之一。软件功能测试技术主要包括软件需求规格说明书的评审、测试计划、测试用例设计、环境搭建、测试执行（缺陷提交、回归测试）、测试报告等；主要体现在用例设计、缺陷提交。

二，Web自动化测试的初级应用能力。 Web自动化测试是软件测试行业中最高端的测试技术之一，也是未来测试领域的发展趋势。有Selenium自动化工具。

三，接口测试的初级应用能力。它在一定程度上降低了开发成本，缩短了软件开发周期。

1.2初级软件测试员“非专业”知识点

一，操作系统：Linux操作系统。越来越多软件应用开始基于Linux操作系统运行。初级软件测试员应当熟悉Linux操作系统中的常用命令行。

二，数据库：Oracle数据库方面。常用的数据库有MySQL、SQL Server、Oracle等。

1.3软件测试工程师需具备两大核心素质：

人格品质和沟通能力。

人格品质：为人诚实，为人自信

沟通能力：沟通能力是软件测试人员综合素质的重要体现，在开发和测试软件的过程中，测试人员需要对遇到的各种问题同开发人员或产品人员进行持续有效的沟通解决问题。

2.软件测试入门

2.1实体产品测试用例

矿泉水瓶和白板笔

2.1.1测试矿泉水瓶

测试点：

外观界面测试：1-8

1.瓶身广告和图案的背景颜色是否符合公司设计要求。

2.瓶身上所有字体、颜色是否符合公司的设计要求，是否有错别字。

3.带广告的图案遇水后是否会掉色或变模糊，广告与图案内容是否合法。

4.瓶身是否有防止烫伤、垃圾回收、年龄限制等提示。

5.瓶身图标布局是否合理，其间距、大小是否符合公司的设计要求。

6.瓶子底座尺寸、高度尺寸是否符合公司设计要求。

7.瓶子的口径尺寸是否符合公司最初的设计要求。

8.瓶身上的纹理及线条是否符合的设计要求。

功能测试：9-15

9.在装少量的水、装半瓶水、装满水这几种情况下，分别将水倒入准备好的量筒中，查看量筒的读数，检查矿泉水瓶的容量是否符合设计要求、装满多少水后会漏水。

10.将空瓶和装满水的瓶子放在电子秤上，检查瓶子装满水前后的重量，看是否符合公司的设计要求。

11.将瓶子装满水后拧紧瓶盖，将其倒置或使劲摇晃、挤压，看是否漏水。

12.拧紧瓶盖后，请小孩、成年男性、成年女性分别去拧瓶盖看是否都能打开。

13.将瓶子装满水后倒入口中看能不能喝到水，是否存在漏水现象。

14.用水挤压空瓶子挤扁后观察瓶身能否自动复原。

15.分别在装水或不装水的情况下观察瓶身的透明度，看是否清澈透底。

性能测试：16-22

16.将空瓶、装半瓶水的瓶子、装满水的瓶子分别放在水平桌面上及放在有20°和30°倾斜角度的桌面上，看瓶子是否倾斜或不稳。

17.将装满水的瓶子和装半瓶水的瓶子分别放置于-10℃、-20℃、10℃、30℃、50℃、80℃、100℃的环境中，连续放1天、10天、20天、30天，然后观察瓶子是否漏水，瓶身是否破裂。

18.将空瓶、装半瓶水的瓶子、装满水的瓶子分别置于太阳光下曝晒（0.5h、1h、3h、5h），观察瓶子是否漏水，瓶身是否破裂。

19.将空瓶、装半瓶水的瓶子、装满水的瓶子分别从不同高度（1m、3m、8m、15m）摔下来，观察瓶身是否破裂，是否漏水。

20.成年人分别使劲摔（或各种角度按压）空瓶、装半瓶水的瓶子、装满水的瓶子，摔一次和摔多次，看瓶子是否摔坏（漏水和破裂）。

21.将空瓶、装半瓶水的瓶子、装满水的瓶子分别置于水平桌面上，用电风扇吹桌面上的瓶子，调节电风扇的风力大小，观察瓶子是否会被吹倒或吹走。

22.满瓶的水加包装后，六面震动，检查产品是否能应对铁路/公路/航空等运输环境。

安全性测试：23-16

23.将空瓶子燃烧掉，观察燃烧时的火焰，闻燃烧时的气味，查看燃烧的残留物是否符合材质的燃烧特性，是否产生有害毒气。

24.空瓶长时间放置（一个月、三个月、半年），用仪器检测是否会产生塑化剂或细菌。

25.装满水后（其次可装入不同的液体，如果汁、碳酸饮料）分别放置1天、5天、10天后，检测瓶身与液体间是否发生化学反应，是否产生有毒物质或细菌。

26.装入热水（50℃——100℃），分别放置1min、5min、10min，然后观察瓶子是否变形，是否有异味产生。

易用性测试：27-31

27.用手去抚摸瓶身的内壁和外壁，是否感觉光滑舒适不刺手。

28.试着喝水，并将瓶口在嘴中转动，感受瓶口的舒适度和圆滑度。

29.用手轻拿已装满水的瓶子看是否容易掉落，检查瓶身是否有防滑措施。

30.瓶子分别装入30℃、60℃、80℃的水时用手掌感受瓶身的温度，因为感受不到的话更容易烫嘴。

31.分别将瓶子放入手中、口袋、包中、车上，观察是否易于携带。

兼容性测试：32-33

32.瓶中分别装入碳酸饮料（可乐)、果汁、咖啡、茶水、油类（菜油）等液体，放置0.5h后再倒入口中测试是否变味。

33.瓶中是否可以装入固体（如饼干、沙子、石头等），且瓶子与装入的固体是否会发生化学反应。

把这33个测试点分为6个方面：

第一，瓶子外观界面测试：瓶子外观界面测试主要是测试瓶子的大小、瓶身所体现的各种信息（如字体、颜色）等瓶子的外观特征是否满足公司的最初对瓶子的设计要求。示例中编号1-8测试点是瓶子外观界面测试。

第二，瓶子的功能测试：瓶子的功能测试主要是测试瓶子的装水功能、喝水功能以及瓶子自带的一些功能特点。编号9-15是功能测试点

第三，瓶子的性能测试：瓶子性能测试主要是测试瓶子的抗摔、抗压、抗高低温的这些情况。编号16-22测试点是瓶子性能测试。

第四，瓶子安全性测试：瓶子安全性测试主要是测试瓶子在使用过程中瓶子本身是否会对人体或环境造成一些伤害，是否存在潜在的安全问题。编号23-26的测试点是到瓶子的安全性测试。

第五，瓶子易用性测试：瓶子的易用性测试主要是测试瓶子用起来是否方便，例如拿在手上或包装在包里是否方便等，如果瓶子设计得太复杂估计没多少人用。编号27-31测试点是瓶子易用性测试。

第六，瓶子兼容性测试：瓶子的兼容性测试主要是测试瓶子除了可以装水之外，是否还可以装一些其它的东西，例如其它液体或固体等。编号32、33测试点是瓶子的兼容性测试。

2.1.2测试白板笔

1.产品的外观测试：测试产品的外观界面是否美观，是否符合设计规范。

2.产品的功能测试：测试产品的各项功能是否能正常使用。

3.产品的性能测试：测试产品在特定环境下是否能保持它的稳定性。

4.产品的安全性测试：测试产品自身或在使用过程中是否会产生安全性问题。

5.产品的易用性测试：测试产品使用起来是否复杂，用户体验是否良好。

6.产品的兼容性测试：测试产品使用过程中是否可以兼容其它产品。

现代社会对产品质量越来越高，产品无论在哪一方面存在问题都可能影响其质量和用户体验，因此做好上面6个方面的测试是非常重要的。

2.2软件测试实例

2.2.1邮箱之登录测试

第一,对邮箱登录模块的页面做外观界面测试：邮箱登录模块的页面外观主要包括了背景颜色、字体颜色、字体格式、页面图案、动画、窗体布局等元素。这些元素组成了登录页面,同时也给了用户第一视觉体验,如果当中的任何一个元素出了问题,例如字体的风格不一致、颜色搭配错了、窗体布局不合理、文字有拼写错误等,可以想象这会给用户带来什么样的影响，所以邮箱登录模块页面的外观界面是必须要测试的。

第二,对邮箱登录页面做功能测试：邮箱登录模块的一个重要功能就是登录操作。邮箱的登录功能主要是保证当用户输人正确的用户名和正确的密码时才能登录到邮箱系统中，而当输人错误的用户名或密码时则禁止用户登录。在登录邮箱的过程中，只要输人了正确的用户名和密码肯定能登录成功，输人了错误的用户名或密码肯定就登录失败。可是，在软件产品刚刚被开发完成时,当输入了正确的用户名和正确的密码时,不一定能登录成功;同样，当输入了错误的用户名或错误的密码时,也未必就一定会登录失败。所以邮箱登录模块的功能是必须要测试的。

第三，对邮箱登录页面做性能测试：邮箱登录模块的性能测试主要测试什么?在平常的邮箱使用过程中也许遇到过这些情形：有时候打开某个网页要等待5s ~10s,甚至更长的时间，网页才能把内容全部显示出来;有时候无论等待多久,网页也打不开;有时候不到2s,网页的内容就全部显示出来了。这等待时间就称为系统响应时间(或称用户等待时间),系统响应时间是性能测试中的一个重要指标。同等条件下，系统响应时间越长,说明该网站性能越差;系统响应时间越短，则表明该网站性能越好。邮箱登录模块同样存在性能测试,例如当输入完邮箱的用户名和密码并单击登录按钮后,用户要等待多长时间才能成功登录到邮箱呢?正常情况下，用户只需要等待1s~2s就可以成功登录邮箱系统，但如果每次登录都需要等待十几秒甚至更长的时间，那这款邮箱产品的性能就需要改进了。所以邮箱登录模块的性能也是必须要测试的。

第四，对邮箱登录页面做安全性测试：有时在一台公用的电脑上登录过QQ邮箱后，虽然进行了退出操作，但你会发现你的邮箱名或QQ号还是留在了那台计算机上。那么黑客就可以利用这些已知的信息人侵你的系统，导致你的QQ号或邮箱被别人登录。所以在邮箱产品上线之前,登录模块的安全性测试也是必须要做的。

第五，对邮箱登录模块的页面做兼容性测试：当你使用某浏览器打开网页的时候，有时会发现其排版异常或是页面出现乱码，但换成另一款浏览器打开同样的网页时又显示正常了，这就是网页代码跟某些浏览器不兼容所造成的。邮箱登录模块需要在不同的浏览器上运行，因此需要测试该页面与各类型浏览器是否兼容。

第六，对邮箱登录页面做易用性测试：可以将易用性测试理解为用户体验测试，主要就是测试用户在使用邮箱登录模块的过程中是否顺畅，是否容易操作。可以把自己当作是-一个用户，然后把自己感觉费解或是难以操作的地方找出来，让开发人员和设计人员修改。软件易用性好，用户体验才会好，所以邮箱登录模块的易用性也是必须要测试的。

从以上的分析不难看出，邮箱登录模块的测试同样也可以基于软件的外观界面、功能、性能、安全性、兼容性、易用性6个方面进行。

2.2.2邮箱之发信测试

第一，写信页面的字体格式、颜色格调、输人框大小的一致性以及界面布局排版等，都属于外观界面，这也是给用户的第一视觉体验， 所以外观界面不能出错，是必须要测试的。

第二，写信页面比较重要的功能就是写信和发送邮件这两大功能。这些功能主要表现在用户能否正常写邮件，写好的邮件能否保存为草稿、能否发送或定时发送，收件人能否正常收到邮件。如果写完邮件后不能发送，或者发出去的邮件对方收不到，那写信功能也就失去了它的意义。

第三，写信页面性能是否要测试。前文已提到过，初学者可以将邮箱的性能理解为系统响应时间。比如从单击写信按钮到写信页面完全显示出来，需要用户等待多长时间;又比如你发送了-封邮件给你的朋友，你的朋友多久能收到你的邮件，这些都是性能问题。如果你发完一封邮件后你的朋友要等三天才能收到，那估计也没有人会用这个邮箱了。

第四，写信页面的安全性测试。有些人的收件箱里可能收到过一一些病毒附件，如果你单击或下载了它，很可能会导致你的计算机中毒。这是因为有些恶意用户故意上传一些病毒附件发送给你，如果你的邮箱不能对这些附件进行安全性检测的话，就会存在很大的安全隐患。

第五，写信页面的兼容性测试。这就是要测试一下写信 页面在不同浏览器下能否正常显示。能正常显示则说明它是兼容的，不能正常显示则表明邮箱的显示页面在该浏览器下存在兼容性问题。

第六，写信页面的易用性测试。写信页面的易用性是指整个写信流程是否易于操作，其各项功能是否易于理解，各项提示是否清楚明了等。如果存在某个功能很难使用，一般人无法理解，那写信页面的易用性就大打折扣了。有关写信页面具体的测试细节在这里就不进行过多分析了，但很容易看出来，写信页面的测试也可以基于外观界面、功能、性能、安全性、兼容性、易用性6个方面进行。

问：你对某某是怎么测试的？

答：对这个软件的测试主要是基于6个方面，它们分别是软件的外观界面、功能、性能、安全性、兼容性、易用性。

3.测试工作从评审需求开始

3.1项目成员

有项目、项目经理、需求、产品人员、开发人员、测试人员、用户。

项目：这里指软件研发项目，包括了从前期项目预研、立项、组建项目团队、设计开发软件、测试调试、交付验收，以及软件运营等各项具体的工作。

项目经理：是软件项目的总负责人。项目经理既需要有广泛的计算机专业知识，有需要具有项目管理技能，能够对软件项目的成本、人员、进度、质量、风险、安全等进行准确的分析和卓有成效的管理，从而使软件项目能够按照预定的计划顺利完成。

需求：这里指的是用户需求，有了用户需求，开发人员才能开发相应的产品。它通常包括功能性需求和非功能性需求。

用户：这里指的是提出需求的用户，同时也是软件验收的主要人员。

开发人员：这里指的是该软件项目组中负责研发这个软件的技术人员，也叫程序员，他们通过代码来实现软件的各项功能。

测试人员：这里指的是该软件组中负责软件测试的测试人员。

产品人员：负责软件产品的设计

3.2项目成员与需求的关系

1.客户（用户）提供原始需求；

2.产品人员根据用户原始需求制定规范的软件需求规格说明书（需求文档）。

3.产品人员把制定好的需求文档分别发给开发人员和测试人员。

4.开发人员按照需求文档进行相关的开发工作，开发出相应的软件产品。

5.测试人员根据需求文档里的要求测试开发出来的软件产品是否符合要求。

项目组中的成员关系：

(1)一般情况下，一个软件项目组由开发人员、测试人员、产品人员组成。当一个项目启动的时候，公司就会从产品部抽调出熟悉此产品的产品人员进驻这个项目组，从开发部抽出熟悉这款产品研发的开发人员加入到这个项目组，同时公司也会从测试部抽调出相关的测试人员参与到这个项目中，三方人员要对这个项目负责到底。

(2)测试人员要经常与开发人员进行沟通，因为一旦测试过程中发现了问题就要反馈给开发人员，并要推动开发人员去修复问题，既相互配合，又相互监督。

(3)测试人员也需要同产品人员打交道，对于需求文档中有不清楚或有歧义的地方，需要向产品人员确认。

(4)开发人员和测试人员通常是不需要与用户直接沟通的(除非是特殊情况下)，主要是产品人员和其他销售人员与用户打交道。

(5)产品经理:领导产品人员进行需求设计、需求变更等相关工作，安排产品人员的工作。

(6)测试经理:负责测试技术、测试计划、测试总结等相关工作，安排测试人员的工作。

(7)开发经理:负责开发技术等相关工作，安排开发人员的工作。

(8)项目经理:本项目的负责人，负责整个项目中重大问题的决策、沟通、协调、进度、交付的工作，对产品人员、开发人员、测试人员三方负责。一般情况下软件的项目经理都是有开发技术背景的。

3.3评审需求文档

转存失败重新上传取消

从图可以看到：由产品人员制定的需求文档发给开发人员和测试人员后，并不是直接进入开发和测试的相关工作中，而是先由产品人员、测试人员、开发人员三方共同评审这个需求文档。

需求文档评审原因如下：

(1)需求文档是一 个文字描述性的文档，开发人员和测试人员在阅读它的时候可能会有不同的理解，如果开发人员把需求文档理解错了或者漏掉了某个需求细节，那么开发出来的产品一定不是产品人员要的，那问题就严重了。

(2)如果测试人员把需求文档理解错了或是理解存在偏差的话，那么测试人员就会按照错误的标准去测试软件，结果可想而知，测试人员提的测试问题都是无效的，都是在做无用功。

(3)对于产品人员制定的需求文档，开发人员和测试人员不能想当然地去理解它,而是需要由产品人员召开需求文档评审大会，项目组全体成员参加。评审的方式一般是这样的：由产品人员对需求文档中的内容一一讲解，如开发人员和测试人员有不清楚的或有疑问的地方都要及时提出来，然后由产品人员解释其中的意思。当然如果大家对需求文档有新的看法和建议，都可以提出来，最终采纳与否由产品人员决定。需求文档评审的目的在于消除歧义，完善需求细节，最后达成共识。评审完后，产品人员就会重新整理需求文档，最后形成一个标准的、 统一的需求文档，然后分发给开发人员和测试人员。

当开发人员和测试人员拿到已通过评审的需求文档之后，他们便进入各自的工作流程，这里再简要地描述一下他们的工作流程。

(1)开发人员会根据这个需求文档去编写概要设计文档。什么是概要设计文档呢?打个比方，你想建个房子，那你得把这个房子的整体框架先画出来，这个房子的整体框架就好比是软件的概要设计文档。概要设计文档写完后，还会根据它去编写详细设计文档。为什么又要写详细设计文档呢?继续打比方，这个房子的整体框架设计好了，接下来就要针对这些大的框架内的一些更小的框架进行详细设计，如建房子之前的详细图纸，这个详细图纸就好比软件的详细设计文档。当然这个比方不一定恰当，只是为了便于理解。有了这个详细设计文档，开发人员再来编写代码就容易多了。当然开发人员的这些工作暂与初级软件测试人员无关，了解一下就可以了。

(2)测试人员拿到已通过评审的需求文档之后会开展什么工作呢?从图3-2可以看到，测试人员会根据需求文档编写测试计划和测试用例。什么叫测试计划？测试计划包括什么内容?什么叫测试用例？如何设计测试用侧?

3.4如何评审需求文档

简要地介绍了需求文档的评审方式，那么测试人员要从哪些方面来对需求文档进行评审呢?

具体如下：

(1)正确性：对照用户的原始需求，检查产品人员制定的需求文档是否偏离了用户的原始需求。

(2)明确性：检查需求文档中每一个需求项是否存在一些含糊其辞的词汇，用语是否清晰，是否有歧义。

(3)完整性：对照用户的原始需求，检查产品人员制定的需求文档是否覆盖了用户所提出的所有需求项，每个需求项有没有遗漏用户所提出的一些必要信息。

(4)限制性：每个需求项里是否清晰地描述了这个软件能做什么，不能做什么，能输入什么，不能输人什么，能输出什么，不能输出什么。

(5)优先级：需求文档中的哪些功能比较重要,哪些功能比较次要，是否做了标识和编号。

(6)一致性:：检查需求文档里的内容前后是否一致，确保不冲突，不矛盾。

请注意，需求评审是测试人员非常重要的一项工作。据统计，50%以上的软件缺陷是由于前期的需求没有评审确认好而造成的。如果开发人员和测试人员不能把需求文档理解透彻或是对需求文档的理解存在偏差，那么最终开发出来的产品一定不是用户想要的，并将会导致软件产品开发失败。产品人员在需求文档的制定上起到了主导和决定性作用，如在开发产品和测试产品的过程中遇到了对需求文档不理解或怀疑的地方，一定要及时和产品人员确认它原本的意思，并按照产品人员给出的标准进行相应的工作。

3.5 求职指导

一、本章面试常见问题

问题1：测试工作是从什么时候开始的?

参考回答：我之前做的测试工作，一-般都是在拿到需求文档的时候就开始了，主要的工作就是评审需求文档，评审的目的是消除歧义，完善需求细节，最后达成共识。谢谢。

问题2：需求评审的目的是什么?

参考回答：我觉得需求评审的目的主要是消除歧义，完善需求细节，最后达成共识，如不进行评审，就意味着开发人员和测试人员可能对需求文档的理解存在偏差，最终可能导致产品质量不符合需求文档的要求。

问题3:你是如何评审需求文档的?

参考回答:我们公司之前评审需求文档的时候，主要从6个方面进行(具体请参考3.4节的内容。) 基本上，我们会从这6个方面进行需求评审，当然每个公司评审的机制可能会有一些差异，但主要目的就是把需求文档的细节理解清楚，谢谢。

二、面试技巧

初级软件测试人员面试的时候需要注意以下3点。

(1)回答问题的时候一定要注意缓冲。例如在回答问题前，可以先说“嗯” 或者“好”，然后停几秒钟思考后再回答。这样有利于将问题拓展开来，不要抢着去回答，因为不假思索就回答容易紧张。

(2)在回答每一个问题之前， 最好加上-一句开始语，如“ 我们之前是这么做的”又如“我们公司的需求文档评审主要包括以下几方面的内容”等，而不要一开始就直奔主题，具体可参考本小节问题3的回答方式。

(3)当回答完问题之后要加一个结束语，如“我们主要是基于这几点来做的，谢谢”又如“我们主要是基于以上几个方面进行的，谢谢”等。问题回答完毕后，别忘了说“谢谢”，这不仅代表了对面试官的尊重，同时也是在告诉面试官我的问题已回答完毕。

4.软件测试的基本概念

4.1软件测试的定义

一）软件质量定义

本文对软件质量的定义是指软件经过开发测试完成后，软件所展现出来的各项功能特性是否满足需求文档，是否满足用户的需求。如果满足，则表示这个软件质量很好，如果不满足，则表明软件质量不好。

二）软件测试的定义

软件测试是一个动态的过程，而不单指某一项的测试工作和技术。

本文对软件测试做如下定义：软件测试是从前期需求文档的评审，到中期测试用例设计及测试执行，再到后期问题单的提交和关闭等一系列的测试过程。

三）软件错误的定义

测试人员在测试软件的过程中，当发现实际运行的结果和预期的结果不一致时(这个预期的效果其实就是指需求文档里面的规格要求)，就把这个不一致的地方统称为软件错误。当然软件错误不仅是指与需求文档不符的地方，在测试过程中，测试人员发现有影响用户体验和使用的任何地方，都可以把它当作软件错误提出来。在工作中也把软件错误称为Bug(Bug、错误、缺陷、问题，这四类表述是同一个意思) 。

四) 什么叫80/20原则

就软件测试而言，80/20原则指的是80%的Bug集中在20%的模块里面，经常出错的模块经修复后还会出错。具体分析有如下两点。

(1) 80%的Bug集中在20%的模块里面，它的意思是指，如果一个软件中发现了100个Bug,那么其中80个Bug很可能都集中在该软件20%的模块里。为什么这么说呢?打一个比方，在开发一个软件的时候，并不是所有的模块都很复杂，例如一个软件包括10个模块，可能其中2个模块比较复杂，而剩下的8个模块比较简单，那么复杂模块出现问题的概率就会高一些， 所以说如果这2个关键模块没有处理好的话，那么这2个模块的Bug数量可能会占Bug总量的80%。所以在测试软件的时候，记得关注这些高危多发“地段”， 在那里发现软件Bug的可能性会大很多。

(2)经常出错的模块经修复后还会出错，它的意思是，同一个地方如果经常出现Bug,即便Bug被修复，这个模块可能还是是不稳定的，还会产生新的Bug当然。80/20 原则的结论只是经验之谈，也就是说，80/20原则并不是绝对的，只是带有相对的普遍性。

4.2 软件测试的分类

根据不同的分类标准，软件测试会有不同的分类。常见的两种分类方式是按测试原理分类和按测试阶段分类。

4.2.1测试原理分类

按测试原理，软件测试可分为黑盒测试和白盒测试，初级软件测试人员很有必要了解它们的意思和区别。

一）黑盒测试：

黑盒测试是不关注软件内部代码的结构和算法，只关注这个软件外部所展现出来的所有功能特性的测试。初级软件测试人员可以这样理解：黑盒测试只测试软件外部的功能特性，而不测试软件内部的代码结构。由于QQ邮箱的用户体验做得很好，本节还使用QQ邮箱的登录页面来举例说明。

图4-1是QQ邮箱的登录页面(简化版)，那么黑盒测试要测些什么呢?答案是，黑盒测试只测试QQ邮箱登录页面所展示给用户的所有功能点能否正常使用(软件外部功能)。例如，当用户输人正确的用户名和密码时能否正常登录，输人错误的用户名或密码是否不能登录系统等功能点，而不会去测试登录页面的代码结构( 软件内部代码)。其内部代码实现逻辑相当于封装在了个黑盒子里面 ，只需要关注这个黑盒子的输入和输出是否符合需求定义，黑盒子里面具体的实现逻辑并不需要测试。

转存失败重新上传取消

二）白盒测试

白盒测试的定义刚好与黑盒测试相反，白盒测试只关注软件内部代码的结构法，而不关注这个软件外部所展现出来的功能点的测试。初级软件测试人员可以这样理解：白盒测试只测试代码结构，而不测试软件的外部功能点。下面举例说明。

如图4-2所示，在QQ邮箱的登录页面的空白处单击鼠标右键，选择查看页面源代码，弹出登录页面所对应的源代码，如图4-3所示。那么白盒测试要测试什么?答案是，白盒测试只测试QQ邮箱登录页面所对应的源代码结构有没有问题(图4-3所示的代码)，而不会去测试登录页面所展示给用户的各项功能点。

转存失败重新上传取消

转存失败重新上传取消

4.2.2 测试阶段分类

按测试阶段，软件测试可分为4个阶段，分别为单元测试、集成测试、系统测试、验收测试。

一） 单元测试

开发人员开发完一小段代码后就能实现一个小的功能模块，开发完多个小段代码后 就能实现多个小的功能模块，然后再把这些小的功能模块串联在一起就组成了一个大的功能模块。接着把几个大的功能模块组合在一-起就成为最终的软件系统。在这里把最初的这一小段代码称为软件系统的最小组成单元，而单元测试就是指对这小段代码进行测试。当开发人员开发完这段代码后，开发人员会测试该软件的最小单元里的代码有没有问题。只有通过单元测试才能把这些单元模块集成在一起， 形成一个大的功能模块。由此看来，单元测试是测试代码的，采用的是白盒测试的方法(因为白盒测试是基于软件内部代码测试的)，主要由开发人员来做。

二）集成测试

单元测试完成后，开发人员就会把已测试完的单元模块组合在一起并形成一个‘组合体”。在集成模块的初期，由于集成到一起的单元模块比较少，此时的“组合体”如果出现问题，很多时候可能还要追溯单元模块内的代码，所以初期的集成测试主要由开发人员来执行，采用白盒测试的方法。但到集成的后期就不同了，由于集成到一起的模块越来越多，各模块之间的依赖性也越来越强，离目标系统也越来越近，软件系统核心模块也基本组装完毕，此时软件的部分功能点也已经展现出来，可对软件进行部分的功能测试，一般也是由开发人员进行，采用的是黑盒测试的方法。

三）系统测试

随着软件集成的规模越来越大，直至最后组装成为一个完整的软件系统，此时软件的所有功能点和特性已经就位，而这个时候就该项目组的测试人员登场了。系统测试简而言之就是测试人员对这个软件系统做全面测试。本书在第2章介绍过，当测试人员对一个软件进行全面测试时，主要是基于6个方面开展的，即软件的外观界面、功能、性能、安全性、易用性、兼容性。那么系统测试就是测试软件的外观界面、功能、性能、安全任、易用性、兼容性这6个方面是否满足需求文档里的要求。同时由于这6个方面的测试并不需要关注到软件内部的代码结构和逻辑，所以系统测试采用的也是黑盒测试的方法，并由测试人员进行。由此看来，测试人员是在系统测试这个阶段介人进来的，如图4-4所示。

转存失败重新上传取消

接下来，在这里简要描述一下这 6个方面测试的基本含义。

(1)软件的外观界面测试(简称UI测试) ：主要测试软件界面功能模块的布局是否合理，整体风格是否一致， 界面文字是否正确，命名是否统一，页面是否美观，文字、颜色、图片组合是否完美等。测试难度：相对简单。

(2) 软件的功能测试:：主要是测试软件所呈现给用户的所有功能点是否都能正常使用和操作，是否满足需求文档里的要求。测试难度：中等。

(3)软件的性能测试:：测试软件在不同环境和压力下是否能正常运转，其中有一个很重要的指标就是系统响应时间，例如多人同时访问某个网页时，网页是否能在规定的时间内打开等。测试难度：较高。

(4)软件的安全性测试：测试该软件防止非法侵入的能力。测试难度：较高。

(5)软件的易用性测试：测试软件是否容易操作，主观性比较强，站在用户的角度体验软件产品好不好用。测试难度:相对简单。

(6)软件的兼容性测试：测试该软件与其他软件的兼容能力，作为初级软件测试人员，主要考虑软件与浏览器的兼容能力，包括分辨率的兼容。测试难度:相对简单。

四）验收测试

验收测试是由用户进行的测试，测试的内容与系统测试的内容相似，主要测试软件系统是否满足需求文档里的要求、是否满足用户的需求。采用的方法也是黑盒测试。通常验收测试通过之后，软件才能交付投产上线，由于验收工作由用户执行，在这里不做过多阐述。

4.3 初级软件测试人员的定位

项目组中的测试人员对软件进行系统测试的时候，初级软件测试人员在系统测试中的定位以图4-5为例进行说明。

转存失败重新上传取消

图4-5中的相关内容如下。

(1 )软件项目的名称: QQ邮箱。

(2)项目组的测试人员: 12名。

(3)测试人员要对QQ邮箱进行系统测试。

(4) QQ邮箱的系统测试涵盖了6个方面，分别是QQ邮箱的外观界面测试、功能测试、易用性测试、兼容性测试、安全性测试、性能测试。

(5)测试组的12名测试人员中，每个测试人员都会有不同的分工，有的做功能测试，有的做性能测试，有的做安全测试等。

(6)初级软件测试人员主要是定位在功能测试这一块。 初级软件测试人员进入项目组一般就是做功能测试的，因而初级软件测试人员等同于功能测试人员。

(7)软件的外观界面、易用性、兼容性这3个方面的测试相对简单，大多数情况下也都是由初级软件测试人员来完成测试的(当然少数的项目也设立了独立的兼容性测试人员、易用性测试人员和外观界面测试人员)。

(8)由于安全性测试和性能测试的难度相对要高一些，并且需要一定的 工作年限，所以这两块的测试工作- -般会由测试组中的安全性测试人员和性能测试人员分别完成。

QQ邮箱的功能模块可以细分出很多个功能，如图4-6所示。初级软件测试人员又是如何分工的呢?

转存失败重新上传取消

从图4-6可以看出，初级软件测试人员进入项目组后，最终会被安排具体负责一个或多个功能模块的测试工作。

为了让大家更清楚初级软件测试人员的定位，有以下几点需要说明。

以上的示例是虚拟出来的一个项目，其中测试人员配比在实际的项目中并不是固定的，每个项目都会根据实际情况进行相应的安排。

一个项目组中的测试人员除了初级软件测试人员外，还包括安全测试人员和性能测试人员等。实际项目中具体要包括哪些测试人员，每个项目都会根据实际的情况进行相 应的安排。

初级软件测试人员就是功能测试人员，在众多的用人单位中，初级软件测试人员都被定义为功能测试人员，主要的任务就是测试软件的功能是否符合需求文档里的要求。功能 测试是最基础的，也是最重要的测试之一 ，因为一个软件如果连功能都没有实现的话，就 不用谈软件的性能和安全了。

功能测试是系统测试的一部分，系统测试采用的是黑盒测试，功能测试自然也是采用黑盒测试。如果面试时被问到:你是做黑盒测试的吗?答案是肯定的。如果被问到:你是做功能测试的吗?答案也是肯定的。如果对方问你:你是做系统测试的吗?答案是肯定的。三者的关系要能区分清楚。当然在很多时候，人们习惯于把黑盒测试称作功能测试。

在功能测试的队伍中有从业时间较久、经验较为丰富的老员工，也有刚人职的初级软件测试人员，测试经理会根据每个人的工作能力进行相应的工作安排，复杂的功能模块会优先安排给经验丰富的功能测试人员：较简单的功能模块则会安排给刚人职不久的测试人员，并指定相应的导师。

4.4 软件测试分类关系表

表4-1更加直观地描述了软件测试类型之间的关系。

转存失败重新上传取消

从表4-1可以清楚看到每个测试阶段所使用的方法、测试人员、测试依据及测试内容,如测试人员正处在系统测试中，采用的是黑盒测试，测试的依据是需求文档，测试的内容是软件的外观界面、功能、易用性、兼容性、安全性 及性能这6个方面的内容。

4.5 本章小结

4.5.1学习提醒

本章所描述的测试概念都是实际项目中出现概率比较高的，是作为一 名初级软件测试人员所应当了解和熟悉的。项目组中的测试人员一般是在系统测试阶段才介人进去的，通过本章的学习，应该掌握和了解系统测试所包含的测试内容以及初级软件测试人员在系统测试当中的定位。

4.5.2求职指导

一）本章面试常见问题

由于本章介绍的是测试的基本概念，这些基本概念一般在实际的面试过程中几乎不会被问到，但在笔试中却非常常见，比如什么是黑盒测试;什么是白盒测试;它们之间的区别是什么;软件测试按不同阶段可分为哪些测试;如何理解软件质量等。这些内容本童已有详细介绍，这里不再重复。但对于笔试部分需要说明以下几点。

(1)公司在招聘初级软件测试人员时，大概只有35%的公司会出笔试题目，大部分的公司招聘是没有笔试的，主要针对应聘者的简历直接进行面试。

(2)笔试考察的是测试人员对基础理论的掌握情况，具有一定的实用性，但由于笔试的题目是有限的，并不能全面考察测试人员的综合能力。而软件测试的工作更注重测人员的动手能力和沟通能力，所以初级软件测试人员应聘时如果笔试没有做好，也不以张和懊恼，因为笔试成绩在整个面试过程中起不了决定性作用。当然，如果笔试做得很好，也是可以加分的。

二）笔试技巧

笔试的时候要写清楚自己的名字和申请的职位。

笔试的时候字迹一定要工整，这表现了你做事情的心态和细节。

笔试一定要按要求和格式作答，它反映了一个测试人员能否按照要求去工作。

笔试的时候尽量不要空题，如果了解的话，尽量说出自己的看法。

尽量不要过早或延后交卷，可以在笔试结束前十五分钟左右交卷。

当发现笔试的内容跟自己的技能不太匹配时，可以跟面试官说明情况并申请是否可以 换一份笔试题。

5.软件测试计划

通过前面章节的介绍，已经了解到当完成需求 文档评审后，开发人员和测试人员就会投入到具体的工作中。测 试的工作会由测试经理负责安排， 测试经 理首先会制定好软件测试计划， 测试计划中会描述测试范围、 测试环境、 测试策略、测试进度以及测试人员的工 作安排和测试中可能出现的风险。 测试人员 可以依据这份 测试计划 展开测试工作。

5.1软件测试计划的内容

如何理解软件测试计划呢?软件测试计划是一 份描述软件测试范围、 测试环境、测试 策略、测试管理、测试风险的一份文档， 由测试经理制定完成。 依据这份测试计划，测试 人员就可以有计划地发现软件产品的缺陷， 验证软件的可接受程度。接下来， 将对软 件测试计划中的内容进行详细讲解。

一）测试范围

在软件测试计划中，测试范围用来确定需要测试的功能性需求和非功能性需求。测试 计划会明确指出进行系统测试时主要测试哪些内容，哪些内容不在本次测试范围中，是否 需要进行外观界面测试、功能测试、易用性测试、兼容性测试、性能测试、安全性测试或 其他测试等。

二）测试环境

在软件测试计划中，测 试环境定义了执行系统测试的软件环境和硬件环境。

软件环境：主要指进行系 统测试的软件运行环境。以及软件运行所需的周边软件等。例如，对QQ邮箱做系统测试时，测试人员是在Windows10操作系统的IE11浏览器上测 试的，那么本次系统测试的软件环境就是Windows 10操作系统和IE11浏览器。实际工作 中的软件环境不限于Windows 10操作系统和IE11浏览器。

硬件环境：主要是指进行系统测试的硬件设施。例如，用于测试的计算机配置为酷睿i 5处理器的CPU、三星8GB的内存等，那么这个硬件配置情况就是本次系统测试的硬件 环境。实际工作中的硬件环境并不限于这些硬件配置，还会涉及诸多方面，如测试的温度、 湿度，也属于硬件环境。

三）测试策略

在软件测试计划中，测试策略指的是测试的依据、测试的准入标准、测试工具的选择、 测试的重点及方法、测试的准出标准等内容。

(1)测试的依据，即测试时需要指明软件测试依据的标准文档有哪些，其中有两个 重要的文档，一个是需求文档，另一个是测试用例，软件测试工作主要是依据它们来进行 的。有关测试用例将在第6章详细介绍。

(2)测试的准入标准，即测试时需要指明系统满足怎样的条件后才能进行系统测试。 通常测试的准人标准是指通过冒烟测试。冒烟测试指当测试人员拿到待测软件后，并不立 即投人到系统测试的用例执行工作当中，而是首先筛选一些基本的功能点进行测试，如果 筛选的这些基本功能点经测试后没有问题再进行系统测试。如果有问题则会停止测试，待 开发人员修复好这些问题后再进行系统测试，比如，某软件一共有300个测试点，那么可 能会筛选出常用的30个测试点来测试一下系统是否正常。只有当这30个测试点都没有问 题后，才会进行全面的系统测试，那么对这30个测试点的测试工作就称为冒烟测试。在 实际工作中，测试的准人标准可能并不局限于通过冒烟测试这一个条件。

(3)测试工具的选择，即测试时需要指明在测试的过程中会使用哪些工具。例如， 测试人员在提交Bug的过程中需要用到Bug管理工具，市场上可供选择的Bug管理工具 有很多，在制定测试策略时，测试组需要决定具体选择哪个工具，如用工具“禅道”来管 理Bug，又如部分的功能点可以利用自动化测试工具"Selenium3” 进行测试等。有关“禅 道"和"“Selenium3”这两款测试工具，将会在第8章和第10章分别具体介绍。

(4)测试的重点及方法指的是，在进行系统测试的过程中，应当标明要测试的重点 模块和区域、测试的优先次序以及所使用的测试方法。目前大家所了解到的测试方法主要 是黑盒测试(功能测试)，也就是手工测试。

(5 )测试的准出标准也叫测试通过的标准。可以理解为，未关闭Bug 的数量在不超 过规定数量的情况下，可视为通过测试(也可以理解为未关闭Bug数量在不超过规定数量 的情况下，软件产品才符合上线的标准)。例如，某测试组测试的准出标准 (通过的标准) 是，未关闭Bug的数量不能多于3个，并且没有严重和致命的Bug，遗留的Bug并不影 响用户对产品的使用和体验。实际工作中测试通过的标准并不局限于Bug的数量，还要看 Bug的等级(根据严重程度一般分为致命问题、严重问题、一般问题、轻微问题、建议性 问题)，有关Bug等级的详细说明，将在第8章讲解。

四 )测试管理

在软件测试计划中，测试管理主要指测试任务的分配、 时间进度的安排、沟通方式这 三方面的内容。

(1)测试任务的分配指的是确定整个 测试范围后， 测试经理会根据团队中每个测试 人员的特长分配相关的测试任务。测试任务主要包括两 项重要的工作：一个是测试用例的 设计和编写，另一个是测试用例的执行和操作。

(2)时间进度的安排指的是根据实际分配的工作任务来指定每个测试人员进行每项 测试工作的起始时间和完成时间。

(3)沟通方式指的是测试过程中如果发现有需要沟通的问题， 测试人员如何与项目 组中其他成员进行沟通。沟通的方式有很多种，测试中常用的是面对面沟通、电子邮件沟 通以及通过Bug管理工具沟通

五)测试风险

在软件测试计划中，需要指明测试中存在的各种风险，常见的风险有不透彻理解需求 文档、估计不足测试时间及测试执行不到位等。

(1)不透彻理解需求文档：不透彻理解需求文档会导致测试人员对软件功能模块的 理解存在偏差，进而影响判断遇到的问题，从而产生无效 Bug。如果完全不理解需求的某 一项， 则会导致测试人员无法理解该需求项所对应的软件功能模块，也就无法对软件的功 能进行正确测试。

(2)估计不足测试时间：每个测试人员都要 在规定的时间内完成测试， 对自己工作量的估计不足而导致在规定的时间内无法完成相应的任务，会直接影响整个测试工作进度，造成推迟测试计划的风险。

(3)测试执行不到位：有些测试人员存在侥幸心理，认为有些功能模块不重要或是不会存在问题而不需要去执行它。在实际工作中，也有一些测试人员因不理解某些功能模块而无法执行相关测试工作， 既不积极主动地与相关人员请教探讨，也不去想办法解决疑问，从而导致执行不到位。

当然，测试风险并不局限于以上3条。

对于上述所列出的风险，很多时候可以想办法避免或者降低这些风险。

(1)需求文档评审期间，测试人员需要认真深人地阅读相关内容，凡是有疑问的地方都要和产品人员沟通确认，井且在测试执行期间保持与产品人员及测试组同事沟通，多询问、多请教，明确掌握需求文档中的内容。

(2)在测试过程中如果发现测试时间不够，首先要想办法改进自己的测试方法以提高工作效率，另外可以申请得到团队同事的协助，最后如果实在因工期紧迫可以适当加班。

(3)软件中很多Bug都是因为测试执行不到位导致的，测试中有这样一条规律: 越被认为没有问题的地方，可能就越容易出现问题。测试人员的侥幸心理是不可取的，也是一种不负责任的表现。而对于因不理解需求而无法执行的功能模块，应当及时向测试经理反馈以寻求解决方法，绝不能蒙混过关。测试人员要有认真负责的态度和优秀的专业素养。

5.2软件测试计划的模板

通过5.1节，了解到测试计划需要考虑的内容，那么测试计划中的这些内容将如何在一份测试计划文档中体现出来呢?本节将介绍通用的软件测试计划模板，从而让读者能够了解如何编写测试计划文档。

一）文档标识

不同的公司对文档标识有不同的要求，其目的是充分体现该测试计划文档的相关信息，如测试对象、测试文档的版本等。

具体在测试计划中，可以用下面这句话来体现文档标识：本文档是针对XYC公司开发的XYC邮箱V1.0进行黑盒测试的整体测试计划。

二）测试目的

以下是在通用的测试计划模板中，体现测试目的的一段内容：本次测试是针对XYC邮箱软件项目进行的系统测试，目的是判定该系统是否满足需求文档中规定的各项要求。

三）测试范围

表5-1是一个测试计划中系统测试范围模板。

转存失败重新上传取消

四）测试环境

表5-2和表5-3分别为测试计划中描述系统测试软件环境和硬件环境的模板。

转存失败重新上传取消

五）测试策略

表5-4为测试计划中描述测试策略的模板。

转存失败重新上传取消

六）测试管理

表5-5为测试计划中描述测试管理的模板。

转存失败重新上传取消

七）测试风险

表5-6为测试计划中描述测试风险的模板。

转存失败重新上传取消

对以上的测试计划模板，进行以下几点说明。

(1)以上测试计划模板中的项目和人物均是虚拟出来的。

(2)以上模板中出现的某些内容，如测试用例设计、测试环境的搭建、Bug 管理工具、提交Bug单、回归测试、测试报告、自动化测试工具等，均会在后面的章节中进行详细讲解。

(3)有关测试计划的模板.每个公司都不大-一样，具体会根据实际项目制定。但有一点是相通的:测试人员的工作任务安排和时间进度计划这两部分是必须有的。

(4)本模板中的内容相对简单，其中并没有引入太多细节性的内容和复杂的测试策略及限定条件，而尽量用所学到的内容以及易理解的方式表达。原因在于:软件测试计划涵盖了项目测试中的方方面面，如果一开始就在测试计划中引人太过复杂的内容，这对于一个没有实际工作经验的初级软件测试人员是不实用的，也不利于后续的学习。

(5)软件测试计划是测试人员进行有序工作的一个基本依据，但是也要明白，测试中的进度安排并不是固定不变的，因需求的临时变更、测试时间被压缩、产品要提前上线等因素，测试计划都会根据实际情况调整。

(6)初级软件测试人员在进人项目的初期，在接收到测试计划中的任务后，按照规定的时间把本职工作做好、做细才是最重要的。

5.3本章小结

5.3.1学习提醒

对于本章测试计划中的内容，初级软件测试人员暂只需大体了解，随着测试工作的不断深入，测试经验的不断增加，制定出一个完整的测试计划并不是一件很困难的事情。

5.3.2求职指导

一）本章面试常见问题

问题1:你写过软件测试计划吗?

参考回答：写过，不过我可的是自己所负责模块的测试计划，项目的整体测试计划一 般是由测试经理来写的。(这里有一点需要注意: 项目的整体测试计划理来写的，但有时候测试经理也会要求测试人员把自己所负责的模块列一个详细的计划表出来，当然.内容的格式都是一样的。)

问题2:软件测试计划包括哪些内容?

参考回答: (如果一时记不起来那么多，注意停顿思考下再回答)我们之前写的测试计划主要包括5个方面。

第一，测试范围。它指的是系统测试的范围以及本轮测试是测试全部模块还是只测试部分模块。

第二，测试环境。它指的是测试人员是在什么样的软、硬件环境下进行测试。

第三，测试策略。它的内容包括测试的依据、系统测试准人的标准、测试工具的选择、测试的重点及方法、测试准出的标准。

第四，测试管理。它指的是测试任务的分配、时间的限定、测试与开发之间的沟通方式等内容。

第五，测试风险。它指的是测试中如不透彻理解需求文档、估计不足测试时间及测试执行不到位等情况所造成的一些测试风险。

我们基本上会从这5个方面来制定我们的测试计划。

问题3:冒烟测试筛选的比例是多少呢?

分析：这个问题即是冒烟测试中会筛选多少个基本测试用例来进行测试。测试用例的概念还没有进行讲解，这里进行简单说明，其实测试用例的意思就等同于测试点。在第2章，本书为矿泉水瓶设计了33个测试点，也就等同于设计了33个测试用例。这个面试问题考察的是测试人员在进人系统测试之前，一般要筛选多少个测试用例来进行冒烟测试(进行基本的功能测试)。如冒烟测试通过，测试人员才会正式进人系统测试。

参考回答：在正常情况下，测试人员筛选的比例大概是整个测试用例的1/15 ~ 1/7.，测试用例的筛选工作一般是由测试经验相对丰富的测试人员完成的。 主要筛选软件中最基本且最重要的一些功能点进行测试。但具体要筛选多少，没有一个具体的规定。一方面要结合测试的时间，另一方面要结合需求规模的大小等因素来考量， 当然对于重要的、常用的测试点选择的会多-一点。

二）面试技巧

在面试的过程当中，面试经验不足的测试人员在回答问题时往往会像背书-一样，给人生硬的感觉，这是不可取的，且造成的面试结果往往并不理想。其实对于每个问题的回答，建议在理解的基础上尽可能地用自己的语言去表达，而不必局限于照搬书本上写的来作答。希望大家注意此面试技巧。

第6章 测试用例的设计

通过前面几章的介绍，已经了解到测试人员评审完需求文档后就会开始制定软件测试计划，制定测试计划后，测试人员就要开始设计测试用例，那何为测试用例呢？

测试用例在整个测试流程中扮演了什么角色呢?本章将正式引人测试用例这概念， 并以具体的例子进行详细介绍。

6.1 什么是测试用例

本书前面几章的内容里，多次提到了测试用例这一概念， 那么什么是测试用例呢?测试用例对测试工作会起到怎样的作用呢?测试用例与需求文档之间存在什么样的关系呢?本节将会详细解答这些问题。

6.1.1 测试用例的格式

在第2章的内容里已经为矿泉水瓶设计了33个测试点，然后依据这些测试点来测试矿泉水瓶。其实在软件测试领域，这个测试点指的就是测试用例。接下来一起来看看如何把一个测试点一步步演变成测试用例，下面举例说明，如图6-1所示。

转存失败重新上传取消

假设图6-1显示的是XYC邮箱的登录模块，如果现在要对这个登录模块进行功能测试，那应如何测试呢?以下4个测试点是某同学在没有任何测试经验的情况下想出来的。

(1)输入正确的用户名和错误的密码测试能否登录成功。

(2)输入错误的用户名和错误的密码测试能否登录成功。

(3)用户名和密码都不输人的情况下测试能否登录成功。

(4)输人正确的用户名和正确的密码测试能否登录成功。

针对以上4个测试点，从中任选一个测试点来分析一下，例如直接选择第一个测试点输人正确的用户名和错误的密码测试能否登录成功。单从字面上看，这个测试点似乎写得很清楚，输人正确的用户名，然后再输人错误的密码，之后看能不能登录邮箱。事实真的如此简单吗?本书在这里先提出几个问题，看是否能引起大家的思考?

第一个问题，“输人正确的用户名和错误的密码测试能否登录成功”，这个测试点是针对邮箱的哪个模块进行测试的呢?在测试点中没有明确说明。

第二个问题，测试时如果网络不通畅，是无法进行这个登录测试的，所以测试前提条件就是要保证网络通畅，这一点也没有在测试点中说明。

第三个问题，邮箱登录功能是在什么环境下测试的呢?是在Windows XP操作系统上还是在Windows 10操作系统上测试的，用的是IE浏览器还是360浏览器，具体的测试环境在测试点中没有说明。

第四个问题，在输人用户名和密码前，测试人员是通过什么网址打开登录页面的，这一点在测试点中也没有说明。

第五个问题，输人正确的用户名和错误的密码，那么这个正确的用户名和错误的密码具体的测试数据是什么呢?这个在测试点中也没有明确出来。

第六个问题，“输人正确的用户名和错误的密码测试能否登录成功”，对测试人员而言是期望它登录成功还是登录失败呢?这在测试点中也没有明确写清楚。

对于以上几点，有人会说，我当然清楚这里面相关的测试数据和判断。可如果软件的测试点多达成百上千个时，你真能记得住这些测试点的每个测试步骤和测试数据吗?所以测试人员在最初设计测试点时，一定要把测试所针对的模块、 测试的前提条件、测试所用到的环境、测试的具体步骤、测试步骤中所用到的具体测试数据以及测试人员想要得到一个什么样的预期结果等这些关键元素写清楚，以便在后期执行测试用例时能够顺利进行。结合以上几点，便可对“输人正确的用户名和错误的密码测试能否登录成功”这个测试点进行完善，具体内容如下。

此测试点针对的是XYC邮箱的登录模块，测试之前，确保网络是通畅的。首先在 Windows 10操作系统中打开IE11浏览器，并在浏览器网址中输人该邮箱登录页面的网址 http://.***. com,然后打开邮箱的登录页面，接着在用户名输人框中输人一个正确的用 户名"test123 "，在密码输人框中输人一个错误的密码“123456"， 单击登录按钮，查看是否登录成功。测试人员期望的结果:邮箱登录不成功，并提示用户名和密码错误。

这样编写测试点后，就细致了很多，因为测试的关键元素都被写出来了。依据这个测试点的描述，即使不是测试人员，也能顺利执行。但这里有一个问题，如果每个测试点都写成一段话，那么登录模块的所有测试点会像是y篇文章，写的时候费力，读的时候也费时，无形地增加工作量。为了增强测试点的可写性和可读性，可以把一个测试点所必须包含的内容划分成9个基本元素，并通过表格的形式将它们展示出来，见表6-1。

转存失败重新上传取消

(1)从表6-1可以看到，这9个基本元素分别是测试序号、测试模块、前置条件、测试环境、操作步骤和数据、预期结果、实际结果、是否通过、备注。而原先测试点中的内容也被相应地分割，并把分割后的内容放置在了相对应的元素下面，这就构成了一个标准的测试用例。

(2)测试用例是为某个特殊目标而编制的一组测试输人、执行条件以及预期结果，以便核实是否满足某个特定需求。测试用例是测试的一个例子，而这个例子包括测试序号、测试模块、前置条件、测试环境、操作步骤和数据、预期结果、实际结果、是否通过、备注这9个关键的基本元素。每个公司的规范可能不一样，有的还包括测试时间、测试人 员、软件的版本名称、优先级等一些附加元素 。

(3)接下来再把前面所写的第二个测试点“输入错误的用户名和错误的密码测试能否登录成功”也转化为表格形式的测试用例，见表6-2。

转存失败重新上传取消

(4)从表6-2可以看到第二个测试点也已转化为表格形式，转化的过程其实很容易，就是把测试用例的内容依次填写到相应的表格中。通过以上的表格形式来编写测试用例，测试用例中各个元素信息一目了然，使得用例的编写、阅读和执行更加容易。

(5)其中“操作步骤和数据”是测试用例中最关键的地方，结合表6-2中的第二个测试用例，观察一下操作步骤和数据的演变过程， 如图6-2所示。

转存失败重新上传取消

通过图6-2中3个测试步骤的对比，最后一个操作步骤和数据是最详细的，不仅加入了如何打开邮箱登录页面的步骤，还加入了用户名和密码的详细信息。那么对于初级软件测试人员而言，测试步骤和数据一般要细致到什么程度呢?在实际的工作中，对初级软件测试人员曾有这么一个标准，即如果你写出来的测试步骤和数据能够让一个从未接触过测试工作的普通人也能顺利执行的话，那么说明这个测试步骤和数据就写得很详细了。待有一定的工作经验后， 测试用例的操作步骤可以适当简化，但简化之后也要清晰明了，具体的测试数据也是不能少的。

(6)“预期结果”是测试用例中的第二个关键元素， 结合表6-2中的第二个测试用例，也来观察下预期结果的演变过程，如图6-3所示。

转存失败重新上传取消

通过图6-3中3个预期结果的对比，最后一个预期结果是最全面的。其实核心的预期结果只有一个: 邮箱登录不成功，并提示用户名和密码错误。但严格来讲，每个测试步骤都应该有一个预期结果。 例如在第二个测试用例中，操作步骤和数据中一共有 3个步骤，那么预期结果也应该有3个，对于初级软件测试人员来说，应当尽可能地把每个操作步骤所对应的预期结果写完整。当然，写出操作步骤，就很好写预期结果了，除非测试人员不熟悉测试系统或需求文档。

接下来，再把前面所写的第三个测试点“用户名和密码都不输人的情况下测试能否登录成功”和第四个测试点“输入正确的用户名和正确的密码测试能否登录成功”都转化为表格形式的测试用例，见表6-3所示。

转存失败重新上传取消

(7)对于测试用例的“实际结果”这元素 ，在实际测试软件时才能填写。 例如针对测试点"输人正确的用户名和错误的密码测试能否登录成功"，如果执行测试用例的时候发现邮箱是登录失败的，那么该测试用例的实际测试结果就是“登录失败” 。

(8)对于测试用例的“ 是否通过”这一元素， 指的是如果实际结果与预期结果相符，则表明此测试用例通过;如果实际结果与预期结果不相符，则表明此测试用例不通过，说明程序的处理是有问题的，需要测试人员提交Bug单给开发人员进行修改。

(9)对于测试用例的“备注”这元素，指的是对本测试用例额外补充的一些说明，如无特殊情况，这个选项一般可以不填。

至此，已介绍完测试点演变成测试用例的整个过程了。通俗来讲，测试点就是一个测试用例的中心思想，或者说测试点就是设计测试用例的大纲；而测试用例是在测试点的基础上进一步细化了其中的内容。在实际的工作中，测试人员可采用Excel表格或者是Word文档来编写测试用例，也可以使用相应的测试管理工具编写。

6.1.2测试用例的作用

先回顾一下第 3章图3-2的流程，开发人员在拿到通过评审的需求文档后，就会按照需求文档进行概要设计和详细设计的工作，然后再进人编码阶段，在开发人员进行软件开发的这段时间里，测试人员会设计出各模块的测试用例。待开发人员开发完成软件之后，测试人员就可以依据之前设计好的测试用例测试软件是否有问题，而不是等开发软件完成后，测试人员再去设计测试用例。

测试用例是测试人员具体执行测试的依据，它是非常关键的文档，它作为测试的标准并指导测试人员进行测试工作。测试人员会按照测试用例中的操作步骤和具体数据逐一执行测试用例，发现问题并提交Bug单，最终完善软件的质量。

6.1.3测试用例与需求的关系

在第2章的内容里，设计矿泉水瓶测试点时，放置了矿泉水瓶这个明显的参照物在测试人员面前，所以测试点设计起来就比较容易。但测试人员在设计软件测试用例时，这个软件并没有完成开发，没有明显的参照物可以给到测试人员，那此时测试人员是依据什么来设计测试用例的呢?其实测试人员是依据需求文档来进行测试用例的设计的。

前几章的内容中，本书没有展示需求文档里的具体内容，原因在于需求文档包含了软件的所有需求规格，包括功能需求和非功能需求(例如性能安全方面的需求)等，其信息量很大，可能大部分的需求内容是初级软件测试人员暂时不涉及的，过早的展示会影响测试人员的学习理解。而初级软件测试人员需要关注的是需求文档里每个功能模块的需求，因为初级软件测试人员主要做的是功能测试。接下来，就选取某需求文档中的一个片段，该片段描述的是某网站登录模块的功能需求说明。

(1)功能描述:对用户进行身份验证，只有输入了正确的用户名和密码的用户才能成功登录到网站首页;当输人错误的用户名或密码时，则无法登录到网站首页，并会给出相应的提示信息。

(2)该网站登录原型界面如图6-4所示。

转存失败重新上传取消

(3)输人项:登录模块的输入项包括用户名输入框、密码输入框、确认登录按钮。

(4)输出项:登录模块的输出项有两个情景，一个是成功登录到网站首页，另一个登录失败时的提示信息。

①登录成功:用户直接进人到网站首页。

②登录失败:系统将给出提示的信息，见表6-4。

转存失败重新上传取消

(5)输人框限制:用户名和密码的取值范围，见表6-5。

转存失败重新上传取消

上面的需求项似乎有点多，把以上的需求项整合下就变成了如图6-5的形式，这样就清晰了很多。

转存失败重新上传取消

从图6-5的需求规格可以看到，即使是开发人员已经开发出来了登录页面，也不一定有需求文档描述得详细。

在这里只展示了登录模块的功能需求，需求文档会对软件中每个模块的功能都进行相应的需求说明，这些说明包括每个根块的功能描述、原型界面、输人项、输出项、数据的取值范围等信息，所以测试人员不用担心没有“参照物”。

有了需求文档这详细的“参照物”后，测试人员就有了设计测试用例的依据。(补充一点:正如前文所述，工作中如发现需求文档中有不详细或存在歧义的地方，要及时与产品人员沟通确认。)

6.2功能测试的用例设计方法

需求文档通过评审确认后，测试人员就可以依此开始设计测试用例了。初级软件测试人员在设计测试用例的时候，如果只是依据自己的想象力，设计出来的测试用例一定存在局限性，因为测试人员无法确定是否所有的测试用例都被设计出来。其实在功能测试领域有很多种测试用例的设计方法，每种方法都有相应的应用领域。在这里本书将介绍其中5种常用的测试用例设计方法，分别是等价类划分法、边界值分析法、错误推测法、正交表分析法和因果判定法，这些方法可以应用于大多数软件的测试用例设计中。大家可以运用这5种设计方法，加上自己的联想和发散思维能力，设计出较为完整的测试用例。

6.2.1等价类划分法

在功能测试中，等价类划分法的应用是比较广泛的，对于初级软件测试人员而言，需要熟练掌握这一方法。

等价类划分法即把所有可能输人的数据划分为若干个区城，然后从每个区域中取少数有代表性的数据进行测试即可。下面详细介绍这一方法的使用。

例1:如图6-6所示，它展示的是某网页的一个年齡输人框的需求文档。

从图6-6的需求文档可以了解到，输入条件是20 ~ 99的任意整数。只有输人的数据 是20 ~ 99的任意整数，才能提交成功:如果输人的是20 ~ 99以外的数字或字符则不会提交成功。但对于软件测试人员还应考虑以下几点。

(1)对于一个刚开发出来的系统页面。即使测试人员输人的整数是20~ 99的，系统就一定能提交成功吗?有人可能会认为这肯定能提交成功，因为输人的数据符合需求文 档，实际上对于一个刚开发完成的系统软件，有时即使你输入了20 ~ 99的整数，也可能 提交不成功。它有3种可能出现的结果:第种情况是提交成功了: 第二种情况是提交不 成功:第三种情况是提交后可能会发生其他意想不到的错误。为什么会这样呢? - -是因为代码不是测试人员写的，测试人员没有办法了解程序的内部结构:二是因为程序员在开发软件的过程中，很可能把代码写错了或遗漏了某些功能，导致提交功能出现异常。所以在 测试的过程中，各种情况都有可能发生，为了确保万无一失， 测试人员需要对20 ~ 99的所有整数都进行测试。

(2)当测试人员输人20 ~ 99之外的整数时，系统就- -定提交不成功吗?答案也是否定的，与上文类似，它也有3种可能出现的结果:第-一种情况是提交不成功并给出提示:第二种情况是提交成功第三种情况是提交后可能会发生其他意想不到的错误，道理同上。

所以对于在20 ~ 90之外的整数，测试人员也需要测试。

(3)有些测试人员存有侥幸心理，觉得年龄输人框这个功能很简单，程序肯定能正 确处理，所以没有必要去测试或是少测试一点。 如果这个程序员的编程技术很好，代码质量也很好，对输人的各种整数都能正确处理，那产品上线后也就没有问题了，对用户也不会有所影响。可如果程序员在情急之中写错了代码或者其他原因导致代码有问题，那么这个输人框在产品上线后就很有可能出现问题，例如该提交的年龄数据没有正常提交，不该提交数据的被提交了，那对用户而言就是批量影响了，后果不可想象。所以刚开发出来的系统，谁都不能确保没有问题，而且越是简单的模块可能越容易出问题，因此务必要认真测试。

(4)那是不是说只要把20 ~ 99的整数及其区间以外的友都测试了就可以了呢?当然不是，这个输人框除了可以输人整数外，还可以输人其他数据，例如带小数点的小数、负数、中文字符、英文字符、特殊字符、空格、全角字符或不输人任何字符等，那么这些 字符需要测试吗?有人可能会说，需求文档定义的输人条件是20 ~ 99的整数，谁又会去输人那些非法的特殊字符呢?其实用户是有可能输人这些非法字符并单击提交操作的。例 如，用户在输人数据的过程中原本只想输人一一个20 ~ 99的整数，可是一不小心把一 个英文字符输进去了并单击了提交操作。有的用户是在不知情的情况下输入错误，还有些用户可能是故意输人的，如果不对这些非法字符进行测试的话，这个产品上线后就有可能会出现问题。因为当用户输人这些特殊字符后，系统会出现前面介绍的3种情况:第一种情况是提交不成功并能给出错误提示:第二种情况是提交成功:第三种情况是提交后发生其他意想不到的错误。如果出现了第二、第三种情况，只能说明软件质量容错能力很差。所以如果不测试的话，则不能保证不会出现第二、第三种情况。

通过以上的分析，对于年龄输人框，需要测试的数据有20 ~ 99的整數、小于20的正整数、大于99的整数、其他非法字符等。本书想告诉大家一个测试的基本思想:凡是需求文档限定内的数据，测试人员需要进行测试:凡是需求文档限定以外的数据，测试人员一样也要测试。如果你不测试的话。用户就有可能测试，如果被用户测试出来有问题， 那问题就严重了。简单一点讲就是， 凡是用户有可能做的操作，测试人员都要去测试。在这里把这个年龄输人框所有可能输人的数据划分为4个区城，如图6-7所示。用户有可能输人图6-7所展示的①②③④这4个区域中的数据，所以这4个区城所包含的数据都要进行测试。可是在这4个区城中，每个区域里面都包含了大量的数据，例如 第D个区城中的20- 9的整数就有0个，第2个区城小于30的正整教也有19个，第

③个区域大于99的整数有无数个，第④个区域中的小数也有无数个、负数也有无数个、中文字符有几千个、英文字符有26个、特殊符号也有几十个，如果测试每个数据的话，恐怕永远也测试不完，也是不现实的。那如何解决这个问题呢?这里就要应用到等价类划分法。

等价类划分法是把所有可能输人的数据划分为若千个区域，例如图6-7所展示的①②③④这4个区域:然后从每个区域中取少数有代表性的数据测试即可，这个有代表性的数据应该如何取呢?下面就来分析每个区域如何取有代表性的数据。

第①个区域是20 ~ 99 的整数，这个区域的整数符合需求文档定义的输人条件。对系统来说这些数据是有效的，并且它们都是同一类型的数据，都是整数。那么这个区域中的 每个整数都是等价的( 等价的意思就是说程序对它们的处理方式都是一样的)，所以测试人员只需要取其中的一个整数去测试即可。在这里可以把符合需求文档中规定的数据称为有效等价类(之所以叫有效，是因为它们都是符合需求文档中定义的数据:之所以叫等价，是因为它们都是同一类型的数据)。那么对于第①个区域的数据，测试人员只需要取其中任意一个整数进行测试便可，见表6-6。

第②个区域是小于20的正整数，这个区域的数据不符合需求文档定义的输人条件，对系统来说是无效的。但这个区域的数据也是同一类型的数据，都是小于20的正整数，那么这个区域中的每个数据也都是等价的，所以测试人员只需要在这个区域内取其中的一个正整数去测试就可以。在这里把不符合需求文档中规定的数据称之为无效等价类(之所以叫无效，是因为它们都是不符合需求文档中定义的数据:之所以叫等价，是因为它们都是同一-类型的数据)。那么对于第②个区域的数据测试只需要取其中的任意一个正整数进