测试基础入门-摩杜云开发者社区

@Author: Basil Guo @Date: Feb. 19, 2021 @Description: 测试基础入门 @Keyword: test @Type: tutorial

1.初识软件测试

根据Google软件测试之道，软件测试人员分类：[^1] 不同公司有不同的分类，大可不必拘泥于此。

SWE: Software Engineer，软件工程师，是传统的开发角色，创建设计文档，设计数据结构以及整体架构，更多时间用于写和查看code。他们的测试代码是TDD测试驱动开发以及单元测试。更加关注功能和性能。功能开发人员。
SET: Software Engineer in Test，测试开发工程师，也是一个开发的角色，关注重点在于可测试性以及通用测试框架。关注点在于设计以及代码质量和风险。重构代码以使得代更加可测试，并撰写单元测试框架以及自动化测试。更加关注质量和测试覆盖率。测试开发人员。
TE: Test Engineer，测试工程师，类似SET，也是更加关注测试甚于开发。不过他们更加关注用户甚于开发者。在于自动化测试脚本，构建使用场景以及模拟用户。组织SWE和SET的测试工作，解读测试结果，驱动测试执行。用户开发人员。

在Google软件开发人员承担了部分的测试的内容，例如质量控制是由开发人员来承担的，而不是由测试来做。“You build it, you break it”。“Eat your own dogfood”表明一件产品交付时，第一个用户应该是开发者自己。Google的组织架构是SWE划分属于某个Focus Area【可能理解为事业部更好】，SET以及TE可以跨越这些Focus Area。这样测试人员是独立于开发人员和部门的，可以精简测试队伍。

Google的测试名称不按照常规的叫法，而是叫做小型测试、中型测试以及大型测试，分别对应称谓：单元（模块）测试、集成测试、系统测试。能够自动化测试，就要实现自动化测试，Google也有很多需要手动的测试。小型测试的范围一般只涉及到单个函数、基本不涉及到外部依赖，中型测试验证两个或多个模块之间的交互，大型测试是验证系统整体是如何工作的。

软件测试的目的不是证明软件系统没有问题，恰恰相反，<span style="color: #FF0000">软件测试就是为了发现系统存在的问题</span>。软件测试保障的是软件的质量，虽然质量不仅仅是测试人员的事情，也有开发人员的事情。测试开始是从需求设计时候开始的，而不是从实现之后开始的，如果在一开始就能发现问题，那么其成本将会比后续低得多。

1.1 软件功能测试

软件功能测试技术通常来说就是手工测试技术，手工测试听起来似乎有些“老套”，但它是最基础的，也是不可替代的测试之一。软件功能测试技术主要包括软件需求规格说明书的评审、测试计划、测试用例设计技术、环境搭建、测试执行（缺陷提交、回归测试）、测试报告等；软件功能测试主要体现在两个方面，一个是用例设计，另一个是缺陷提交。

1.2 Web自动化测试

目前，Web自动化测试是软件测试行业中最高端的测试技术之一，也是未来测试领域的发展趋势。所以对于初级软件测试人员而言，对Web自动化测试技术应有一个初步的认识和应用。

1.3 接口测试

越来越多的企业意识到接口测试的重要性，进行接口测试意味着软件测试人员从单纯的界面测试转向底层测试，这一过程意义重大，它在一定程度上降低了开发成本，缩短了软件开发周期，所以对初级软件测试人员而言，很有必要了解一下接口测试的基本过程。

分层测试已经越来越普遍了，基本可以分为UI界面层、服务层、单元层。而从UI到单元，自动化比例是在上升的。因为自动化对于相对稳定的层次具有更高的价值，而UI界面时常变化，可能维护自动化脚本比较费时费力。[^2]

单元测试框架：Java-JUnit、TestNG，C#-NUnit，Python-unittest、pytest
接口测试：URL或者某个方法，如SoapUI
UI测试：QTP、Watir、Selenium

2. 软件测试入门

2.1 CASE 1: 如何测试矿泉水瓶

瓶子的外观界面测试。瓶子的外观界面测试主要是测试瓶子的大小、瓶身所体现的各种信息（如字体、颜色）等瓶子的外观特征是否满足公司最初对瓶子的设计要求。

（1）瓶身上广告和图案的背景颜色是否符合公司的设计要求。（2）瓶身上所有的字体颜色是否符合公司的设计要求，是否有错别字。（3）带广告的图案遇水后是否会掉色或变模糊，广告内容与图案是否合法。（4）瓶身上是否有防止烫伤、垃圾回收、年龄限制等提示。（5）瓶身上图标布局是否合理，其间距、大小是否符合公司的设计要求。（6）瓶子底座尺寸、高度尺寸是否符合公司的设计要求。（7）瓶子的口径尺寸是否符合公司最初的设计要求。（8）瓶身上的纹路及线条是否符合公司的设计要求。
瓶子的功能测试。瓶子的功能测试主要是测试瓶子的装水功能、喝水功能以及瓶子自带的一些功能特点。

（9）在装少量的水、装半瓶水、装满水这几种情况下，分别将水倒入准备好的量筒中，查看量筒的读数，检查矿泉水瓶的容量是否符合设计要求、装满多少水后会漏水。（10）将空瓶和装满水的瓶子放在电子秤上，检查瓶子装满水前后的重量，看是否符合公司的设计要求。（11）将瓶子装满水后拧紧瓶盖，将其倒置或使劲摇晃、挤压，看是否漏水。（12）拧紧瓶盖后，请小孩、成年男性、成年女性分别去拧瓶盖看是否都能拧开。（13）将瓶子装满水后倒入口中看能不能喝到水，是否存在漏水的现象。（14）用手挤压空瓶子，挤扁后观察瓶身能否自动复原。（15）分别在装水或不装水的情况下观察瓶身的透明度，看是否清澈透底。
瓶子的性能测试。瓶子的性能测试主要是测试瓶子的抗摔、抗压、抗高低温的这些情况。

（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）将空瓶子燃烧掉，观察燃烧时的火焰，闻燃烧时的气味，查看燃烧的残留物是否符合材质的燃烧特性，是否产生有害的毒气。（24）空瓶长时间放置（一个月、三个月、半年），用仪器检测是否会产生塑化剂或细菌。（25）装满水后（其次可装入不同的液体，如果汁、碳酸饮料）分别放置1天、5天、10天后，检测瓶身与液体间是否发生化学反应，是否产生有毒物质或细菌。（26）装入热水（50℃～100℃），分别放置1min、5min、10min，然后观察瓶子是否变形，是否有异味产生。
瓶子的易用性测试。瓶子的易用性测试主要是测试瓶子用起来是否方便，例如拿在手上或装在包里是否方便等，如果瓶子设计得太复杂估计就没有多少人用了。

（27）用手去抚摸瓶身的内壁和外壁，是否感觉光滑舒适不刺手。（28）试着喝口水，并将瓶口在嘴中转动，感受瓶口的舒适度和圆滑度。（29）用手轻拿已装满水的瓶子看是否容易掉落，检查瓶身是否有防滑措施。（30）瓶子分别装入30℃、60℃、80℃的水时用手掌感受瓶身的温度，因为感受不到的话更容易烫嘴。（31）分别将瓶子放入手中、口袋、包中、车上，观察是否易于携带。
瓶子的兼容性测试。瓶子的兼容性测试主要是测试瓶子除了可以装水之外，是否还可以装一些其他的东西，例如其他液体或固体等。

（32）瓶中分别装入碳酸饮料（如可乐）、果汁、咖啡、茶水、油类（如菜油）等液体，放置0.5h后再倒入口中测试是否变味。（33）瓶中是否可以装入固体（例如饼干、沙子，石头等），且瓶子与装入的固体是否会发生化学反应。

对一个产品做通用测试的时候，最初是可以基于产品的**<span style="color: blue">外观界面、功能、性能、安全性、易用性、兼容性</span>**这6个方面进行测试的，而事实上这6个方面也是必须要测试的。

2.2 CASE 2: 邮箱测试

2.2.1 邮箱之登录测试

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

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

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

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

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

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

2.2.2 邮箱之发信测试

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

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

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

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

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

第六，写信页面的易用性测试。写信页面的易用性是指整个写信流程是否易于操作，其各项功能是否易于理解，各项提示是否清楚明了等。如果存在某个功能很难使用，一般人无法理解，那写信页面的易用性就大打折扣了。

2.3 软件测试基本6部分

软件的外观界面测试（简称UI测试）：主要测试软件界面功能模块的布局是否合理，整体风格是否一致，界面文字是否正确，命名是否统一，页面是否美观，文字、颜色、图片组合是否完美等。测试难度：相对简单。
软件的功能测试：主要是测试软件所呈现给用户的所有功能点是否都能正常使用和操作，是否满足需求文档里的要求。测试难度：中等。
软件的性能测试：测试软件在不同环境和压力下是否能正常运转，其中有一个很重要的指标就是系统响应时间，例如多人同时访问某个网页时，网页是否能在规定的时间内打开等。测试难度：较高。
软件的安全性测试：测试该软件防止非法侵入的能力。测试难度：较高。
软件的易用性测试：测试软件是否容易操作，主观性比较强，站在用户的角度体验软件产品好不好用。测试难度：相对简单。
软件的兼容性测试：测试该软件与其他软件的兼容能力，作为初级软件测试人员，主要考虑软件与浏览器的兼容能力，包括分辨率的兼容。测试难度：相对简单。

3. 评审需求

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

3.1 评审原因

（1）需求文档毕竟是一个文字描述性的文档，开发人员和测试人员在阅读它的时候可能会有不同的理解，如果开发人员把需求文档理解错了或者漏掉了某个需求细节，那么开发出来的产品一定不是产品人员想要的，那问题就严重了。（2）如果测试人员把需求文档理解错了或是理解存在偏差的话，那么测试人员就会按照错误的标准去测试软件，结果可想而知，测试人员提的问题都是无效的，都是在做无用功。（3）对于产品人员制定的需求文档，开发人员和测试人员不能想当然地去理解它，而是需要由产品人员召开需求文档评审大会，项目组全体成员参加。评审的方式一般是这样的：由产品人员对需求文档中的内容一一讲解，如开发人员和测试人员有不清楚的或有疑问的地方都要及时提出来，然后由产品人员解释其中的意思。当然如果大家对需求文档有新的看法和建议，都可以提出来，最终采纳与否由产品人员决定。需求文档评审的目的在于消除歧义，完善需求细节，最后达成共识。评审完后，产品人员就会重新整理需求文档，最后形成一个标准的、统一的需求文档，然后分发给开发人员和测试人员。

3.2 评审准则

正确性：对照用户的原始需求，检查产品人员制定的需求文档是否偏离了用户的原始需求。
明确性：检查需求文档中每一个需求项是否存在一些含糊其辞的词汇，用语是否清晰，是否有歧义。
完整性：对照用户的原始需求，检查产品人员制定的需求文档是否覆盖了用户所提出的所有需求项，每个需求项有没有遗漏用户所提出的一些必要信息。
限制性：每个需求项里是否清晰地描述了这个软件能做什么，不能做什么，能输入什么，不能输入什么，能输出什么，不能输出什么。
优先级：需求文档中的哪些功能比较重要，哪些功能比较次要，是否做了标识和编号。
一致性：检查需求文档里的内容前后是否一致，确保不冲突，不矛盾。

4. 软件测试基本概念

4.1 定义

软件质量：软件经过开发测试完成后，软件所展现出来的各项功能特性是否满足需求文档，是否满足用户的需求。
软件测试：从前期需求文档的评审，到中期测试用例设计及测试执行，再到后期问题单的提交和关闭等一系列的测试过程。
软件错误：测试人员在测试软件的过程中，当发现实际运行的结果和预期的结果不一致时（这个预期的效果其实就是指需求文档里面的规格要求），就把这个不一致的地方统称为软件错误。
80/20原则：80/20原则指的是80%的Bug集中在20%的模块里面，经常出错的模块经修复后还会出错。

4.2 分类

按照测试原理
1. 黑盒测试：把软件当成一个黑盒子，不关注软件内部代码的结构和算法，只关注这个软件外部所展现出来的所有功能特性的测试。
2. 白盒测试：白盒测试是只关注软件内部代码的结构和算法，而不关注这个软件外部所展现出来的功能点的测试。
按照测试阶段
1. 单元测试：开发人员开发完一小段代码后就能实现一个小的功能模块，开发完多个小段代码后就能实现多个小的功能模块，然后再把这些小的功能模块串联在一起就组成了一个大的功能模块。在这里把最初的这一小段代码称为软件系统的最小组成单元，而单元测试就是指对这小段代码进行测试。单元测试是测试代码的，采用的是白盒测试的方法（因为白盒测试是基于软件内部代码测试的），主要由开发人员来做。
2. 集成测试：单元测试完成后，开发人员就会把已测试完的单元模块组合在一起并形成一个“组合体”。一般也是由开发人员进行，采用的是黑盒测试的方法。
3. 系统测试：系统测试简而言之就是测试人员对这个软件系统做全面测试。系统测试就是测试软件的外观界面、功能、性能、安全性、易用性、兼容性这6个方面是否满足需求文档里的要求。采用的也是黑盒测试的方法，并由测试人员进行。
4. 验收测试：是由用户进行的测试，测试的内容与系统测试的内容相似，主要测试软件系统是否满足需求文档里的要求、是否满足用户的需求。采用的方法也是黑盒测试。

测试类型	测试方法	执行者	测试依据	测试内容
单元测试	白盒测试	开发人员	详细设计文档（主要）、概要设计文档	代码以及代码的逻辑结构
集成测试	白盒测试为主，黑盒测试为辅	开发人员	详细设计文档（主要）、概要设计文档、需求文档	模块与模块之间的接口
系统测试	黑盒测试	测试人员	需求文档	软件的外观、功能、易用性、性能、兼容性、安全性
验收测试	黑盒测试	用户	需求文档	与系统测试的内容相似，主要测试软件的外观、功能、易用性、性能、兼容性、安全性

5. 软件测试计划

5.1 内容

测试范围：用来确定需要测试的功能性需求和非功能性需求。测试计划会明确指出进行系统测试时主要测试哪些内容，哪些内容不在本次测试范围中，是否需要进行外观界面测试、功能测试、易用性测试、兼容性测试、性能测试、安全性测试或其他测试等。
测试环境：定义了执行系统测试的软件环境和硬件环境。
测试策略：指的是测试的依据、测试的准入标准、测试工具的选择、测试的重点及方法、测试的准出标准等内容。
1. 测试的依据，即测试时需要指明软件测试依据的标准文档有哪些，其中有两个重要的文档，一个是需求文档，另一个是测试用例。
2. 测试的准入标准，即测试时需要指明系统满足怎样的条件后才能进行系统测试。通常测试的准入标准是指通过冒烟测试。简单来说就是筛选一部分先进行测试，没有问题再进行后续的测试工作。
3. 测试工具的选择，即测试时需要指明在测试的过程中会使用哪些工具。如用工具“禅道”来管理Bug，又如部分的功能点可以利用自动化测试工具“Selenium3”进行测试等。
4. 测试的重点及方法指的是，在进行系统测试的过程中，应当标明要测试的重点模块和区域、测试的优先次序以及所使用的测试方法。目前大家所了解到的测试方法主要是黑盒测试（功能测试），也就是手工测试。
5. 测试的准出标准也叫测试通过的标准。可以理解为，未关闭Bug的数量在不超过规定数量的情况下，可视为通过测试（也可以理解为未关闭Bug数量在不超过规定数量的情况下，软件产品才符合上线的标准）。即产品上线可以有Bug，但是Bug的数量有限制。
测试管理：主要指测试任务的分配、时间进度的安排、沟通方式这三方面的内容。
1. 测试任务的分配指的是确定整个测试范围后，测试经理会根据团队中每个测试人员的特长分配相关的测试任务。测试任务主要包括两项重要的工作：一个是测试用例的设计和编写，另一个是测试用例的执行和操作。
2. 时间进度的安排指的是根据实际分配的工作任务来指定每个测试人员进行每项测试工作的起始时间和完成时间。
3. 沟通方式指的是测试过程中如果发现有需要沟通的问题，测试人员如何与项目组中其他成员进行沟通。沟通的方式有很多种，测试中常用的是面对面沟通、电子邮件沟通以及通过Bug管理工具沟通。
测试风险：在软件测试计划中，需要指明测试中存在的各种风险，常见的风险有不透彻理解需求文档、估计不足测试时间及测试执行不到位等。
1. 不透彻理解需求文档：不透彻理解需求文档会导致测试人员对软件功能模块的理解存在偏差，进而影响判断遇到的问题，从而产生无效Bug。
2. 估计不足测试时间：每个测试人员都要在规定的时间内完成测试，对自己工作量的估计不足而导致在规定的时间内无法完成相应的任务，会直接影响整个测试工作进度，造成推迟测试计划的风险。
3. 测试执行不到位：有些测试人员存在侥幸心理，认为有些功能模块不重要或是不会存在问题而不需要去执行它。在实际工作中，也有一些测试人员因不理解某些功能模块而无法执行相关测试工作，既不积极主动地与相关人员请教探讨，也不去想办法解决疑问，从而导致执行不到位。

5.2 模板

文档标识：本文档是针对XYC公司开发的XYC邮箱V1.0进行黑盒测试的整体测试计划。
测试目的：本次测试是针对XYC邮箱软件项目进行的系统测试，目的是判定该系统是否满足需求文档中规定的各项要求。

测试范围：下表是一个测试计划中系统测试范围模板。

序号	XYC邮箱的测试范围	说明
1	外观界面测试	检查XYC邮箱的外观界面是否符合需求文档中所要求的界面规范、是否美观、合理、人性化
2	功能测试	根据需求文档检查XYC邮箱的主要功能是否正确实现
3	易用性测试	检查XYC邮箱是否操作简单钠、易用，是否符合通用的操作习惯
4	兼容性测试	检查XYC邮箱与市面上主流浏览器的兼容性，例如360浏览器、Firefox 60、Google Chrome等
5	安全性测试	检查XYC邮箱是否达到需求文档中的安全要求、是否存在安全隐患
6	性能测试	检查XYC邮箱是否达到了需求文档中所定义的性能需求

测试环境：软件环境：PC、Windows 10、IE 11、360浏览器、搜狗浏览器。硬件环境：PC、联想商务机、CPU酷睿i5、内存三星8GB、硬盘三星500GB

测试策略：下表为测试计划中描述测试策略的模板。

序号	策略	内容
1	系统测试依据	需求文档和系统测试用例
2	测试准入的标准	1.冒烟测试通过；<br />2.测试组的人员全部到位，并且测试人员的专业技能符合测试的要求
3	测试工具的选择	1.本次系统测试中，登录和通讯录的功能模块适合进行自动化测试，因此这两个模块将使用自动化测试工具Selenium 3；<br />2. 本次系统测试中所发现的Bug均使用“禅道”作为Bug测试管理工具进行提交，发现问题后首先提交给测试经理，经测试经理审核后再指派给开发人员。
4	系统测试的方法	本次系统测试均采用黑盒测试（手工测试）的方法，登录模块和通讯录模块进行自动化测试前也必须进行必要的手工测试
5	系统测试的重点	1. 在XYC邮箱的外观界面测试中要确保菜单的大小和位置，确保模块之间的协调、背景颜色的美观性都符合规格要求<br />2.在XYC邮箱的功能测试中要重点测试邮箱登录、写信、收信、附件模块的测试工作，这些模块应当优先进行测试<br />3.在XYC邮箱的易用性测试中，要确保邮箱使用过程中的易操作性和易理解性等<br />4.在XYC邮箱的兼容性测试中，要确保能与IE 11、360浏览器、Firefox 60、QQ浏览器、搜狗浏览器的兼容性<br />5.在XYC邮箱的安全性测试中，要防止他人利用已知的账户名进行非法侵入<br />6.在XYC邮箱的性能测试中，要重点测试用户登录、收信等操作的系统响应时间
6	测试准出的标准	1.测试用例已全部执行完成<br />2.遗留Bug数量不能超过3个，并且没有严重和致命的Bug，遗留的Bug并不影响用户对产品的使用和体验

测试管理

分配任务	具体事宜	测试负责人	测试的起始时间	测试结束时间
负责XYC邮箱的性能测试	编写性能测试用例、执行测试用例、提交Bug单、回归测试、编写测试报告	张三<br />（测试经理）	2018-03-01	2018-03-31
负责XYC邮箱的安全性测试	编写安全性测试用例、执行测试用例、提交Bug单、回归测试、编写测试报告	李四<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱写信模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写写信模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	王五<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱收件箱模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写收件箱模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	赵六<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱发件箱模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写发件箱模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	孙七<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱草稿模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写草稿箱模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	周八<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱通讯录模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写通讯录模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	吴九<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱附件上传模块的功能测试、界面测试、易用性测试以及兼容性测试的工作	编写附件上传模块的测试用例、执行测试用例、提交Bug单、回归测试、编写该部分的测试报告	郑十<br />（测试人员）	2018-03-01	2018-03-31
负责XYC邮箱测试环境的搭建工作以及Bug管理工具“禅道”的安装工作	搭建XYC邮箱的后台环境、安装Bug管理工具“禅道”并进行维护	刘一<br />（测试人员）	2018-03-01	2018-03-31

测试风险：下表为测试计划中描述测试风险的模板。

风险分类	具体风险情况	解决方案
不透彻理解需求文档	可能存在对需求理解有误差或者对软件的业务功能不熟悉的情况	有疑问的地方需要与产品人员沟通确认，在测试执行期间尽量保持同产品人员和测试组同事之间的沟通，多咨询、多请教
预估不足测试时间	工作中遇到突发情况或是工作计划没有合理安排而导致测试时间预估不足	1. 改进测试方法以提高效率<br />2. 请求同事的协助<br />3. 必要时可以适当加班<br />4. 遇到问题需要及时向测试经理反映情况
测试执行不到位	测试人员存在侥幸心理而导致部分模块没有测试到，或是对业务功能不熟悉并且未虚心求教，未进行相关内容的测试	及时向测试经理反馈，寻求解决方法，不能蒙混过关

6. 测试用例的设计

6.1 测试用例

在软件测试领域，一个测试点指的就是一个测试用例。举例来说编写一个测试用例：

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

很详细，但是很冗余，费时费力，可读性和可写性差。可以写成如下表：

测试序号	测试模块	前置条件	测试环境	操作步骤和数据	预期结果	实际结果	是否通过	备注
1	邮箱登录	网络正常	Windows 10操作系统、IE 11浏览器	1. 通过`http://mail.***.com`打开邮箱登录页面；<br />2. 输入正确的用户名“test123”，输入错误的密码“123456”；<br />3. 单击登录按钮查看是否登录成功。	1. 邮箱登录页面可以正常打开；<br />2. 用户名和密码可以正常的输入；<br />3. 比提示用户名或密码错误。

从表中可以看到，这9个基本元素分别是测试序号、测试模块、前置条件、测试环境、操作步骤和数据、预期结果、实际结果、是否通过、备注。但是这只是一个模板，可能还有其它元素，如测试人员等。
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便核实是否满足某个特定需求。
测试步骤和数据一般要细致到什么程度呢？在实际的工作中，对初级软件测试人员曾有这么一个标准，即如果你写出来的测试步骤和数据能够让一个从未接触过测试工作的普通人也能顺利执行的话，那么说明这个测试步骤和数据就写得很详细了。

测试人员是依据需求文档来进行测试用例的设计的。在开发人员进行软件开发的这段时间里，测试人员会设计出各模块的测试用例。

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

在功能测试领域有很多种测试用例的设计方法，每种方法都有相应的应用领域。在这里将介绍其中5种常用的测试用例设计方法。

6.2.1 等价类划分法

等价类划分法即把所有可能输入的数据划分为若干个区域，然后从每个区域中取少数有代表性的数据进行测试即可。

如对于一个年龄输入框，提示范围是20~99。不是说只要把20～99的整数及其区间以外的整数都测试了就可以了。还要测试这个输入框除了可以输入整数外，还可以输入其他数据，例如带小数点的小数、负数、中文字符、英文字符、特殊字符、空格、全角字符或不输入任何字符等，这些都是有问题的。

通过以上的分析，对于年龄输入框，需要测试的数据有20～99的整数、小于20的正整数、大于99的整数、**其他非法字符（小数、负数、中文字符、英文字符、特殊字符、空格等）**等。

可以把符合需求文档中规定的数据称为有效等价类。把不符合需求文档中规定的数据称之为无效等价类。

则上述年龄输入框的测试点汇总如下表：

输入条件	有效等价类	有效等价类取值	无效等价类	无效等价类取值
20 ~ 99 的整数	20≤年龄≤99	50	小于20的整数<br />大于99的整数<br />小数<br />负数<br />中文字符<br />英文字符<br />特殊字符<br />空格<br />空的（无任何输入）	16<br />1001<br />1.2<br />-1<br />我<br />basil<br />`&nbsp`<br /> <br />

:star:测试的基本思想：凡是需求文档限定内的数据，测试人员需要进行测试；凡是需求文档限定以外的数据，测试人员一样也要测试。

6.2.2 边界值分析法

它通常被视为对等价类划分法的一种补充。边界值分析法是取稍高于或稍低于边界的一些数据进行测试。边界值分析法在以下两种情况下经常被用到。

输入条件是一个取值范围，对于这个取值范围的边界要进行边界值测试。
输入条件中规定输入的数据是一个有序集合，对这个有序集合的边界要进行边界值测试。

以上述年龄输入框举例，边界分别是20和99，但是测试的时候需要测试：19、20、21、98、99、100。如果是小数，则更应该小心测试，例如10.00~60.00Kg，则要测试9.99、10.00、10.01、59.99、60.00、60.01。

6.2.3 错误推测法

错误推测法也是测试人员常用的测试方法之一，指的是测试人员凭借自己的直觉、测试经验、发散思维去设计一些容易导致软件出错的测试点。错误推测法也可看作是对等价类划分法和边界值分析法的一个补充。

对于年龄输入框测试案例，根据经验给出了除等价类划分法和边界值分析法外的4个测试点，它们分别是“超长混合字符串”“全角字符串”、数字“0”以及单引号“‘”，为什么会是这4个测试点呢？原因在于程序在处理“超长混合字符串”、“全角字符串”、数字“0”以及单引号“‘”时极易出错。在这里请注意全角字符与半角字符的区别。

在一般情况下，程序在处理空格、空的、边界值、超长字符串、全角字符串、0以及单引号等情况下较容易出错。

6.2.4 正交表分析法

前面讲的3种用例的设计方法都是针对单个输入框进行的，但往往有些软件页面的输入框可能有2个、3个甚至更多，那么对多个输入框又该如何测试呢？

对于一个组合输入框，除了需要按照上文的用例设计方法来对每个输入框进行字符输入测试外，还需要针对这组输入框，进行各个输入框输入状态组合的测试。输入框输入状态即“填”与“不填”两种状态。由于用户不可预知其行为，所以测试人员需要把这3个输入框中任意一个输入框不填内容或填写内容的排列组合都罗列出来，然后对它们依次进行测试。但是这是一个指数幂O(2^n)量级的，这不可接受，基本不能完成。

正交表分析法是一种有效地减少用例设计个数的方法。测试人员需要根据实际的业务场景和组合特点进行算法设计，必要时还可以咨询开发人员，最终的目的就是选择一些典型的组合进行测试。可以借助正交设计助手工具，利用正交表分析法设计出测试点。还可以补充一个正交表用例，即不填姓名、不填身份证号码、不填手机号码。实现用最小的测试用例集合去获取最大的测试覆盖率。

6.2.5 因果判定法

它们的业务逻辑都不是很强，主要是对一些合法和非法字符的输入做一些基本检查。在有些软件页面中，除了输入框之外，还存在各类按钮，而且这些按钮之间存在相互关联和制约的关系，且具有较强的逻辑性。

因果判定法需要进行以下几个步骤。

明确所有的输入条件（因）。
明确所有的输出结果（果）。
明确哪些条件可以组合在一起，哪些条件不能组合在一起。
明确什么样的输入条件组合可产生哪些输出结果。
通过判定表展示输入条件的组合与输出结果的对应关系。
根据判定表设计测试用例。

增加条件后

6.3 用例设计的基本思路

如何去找隐含的需求？可以从以下四方面入手。

要紧扣需求文档，挖掘需求细节，并针对这些需求细节进行用例设计。
除了应用所学习过的用例设计方法外，测试人员还应充分利用自己的发散能力和逻辑推理能力来设计，因为人的思维是开放的。
想要更快地获取更多的测试思想，比较直接的办法就是通过互联网来获取相应的资料（因为常见功能点的测试网上几乎都有而且很全面），以此来充实自己的基础测试能力，并扩充视野。
多与测试人员、开发人员、产品人员交流，多看测试人员之前写过的测试用例和相关文档。本例的用例设计主要考察测试人员对用例设计方法的运用能力以及测试人员的发散思维能力和挖掘需求的能力。

6.4 测试用例的评审

一般情况下，测试人员会从以下几个方面对测试用例进行评审。

测试用例是否是依据需求文档编写的。
测试用例中的执行步骤、输入数据是否清晰、简洁、正确；对于重复度高的执行步骤，是否进行了简化。
每个测试用例是否都有明确的预期结果。
测试用例中是否存在多余的用例（无效、等价、冗余的用例）。
测试用例是否覆盖了需求文档中所有的功能点，是否存在遗漏。

在产品上线前，测试人员需要一直维护测试用例。

7. 了解测试环境

本章主要涉及环境的搭建。具体环境具体分析。不多涉及。

8. 测试执行

当测试人员在执行测试用例的过程中发现Bug时，测试人员应该如何记录这个Bug？如何确保开发人员能理解测试人员所提交的Bug？

通常情况下，一个Bug应包括以下信息点，见下表。

Bug包括的基本信息点	各信息点的含义
Bug的摘要	写清楚每一个Bug的主要信息，一般一两句话即可。一定要清晰简洁。
Bug的具体描述	即Bug重现过程，每一个步骤、每一个细节、以及发生过程中所涉及的具体数据清晰地描述出来。尽可能多地提供一些必要信息。
Bug地严重程度	在禅道系统中，Bug等级划分为4个等级：<br />等级①：致命问题（造成系统崩溃、死机、死循环、导致数据库丢失等）；<br />等级②：严重问题（系统重要功能部分丢失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用，但是不影响其它功能的测试等）<br />等级③：一般性问题（功能没有完全实现，但是不影响使用，功能菜单存在缺陷但是不会影响系统稳定性等）；<br />等级④：建议问题（界面、性能缺陷等建议类问题，不影响操作功能的执行）
Bug的优先级	在禅道系统中，Bug的优先级同样划分为4个：<br />等级①：代表此Bug需要立即进行处理；<br />等级②：代表此Bug需要紧急进行处理；<br />等级③：代表此Bug需要正常速度处理即可；<br />等级④：代表此Bug可延后处理
Bug指派给	每个Bug都要指定解决这个Bug的开发人员
Bug的状态	在禅道系统中，Bug的状态有：激活、已解决、关闭三个状态。每个Bug的状态在不同的管理工具可设置不同
必要的附件（图片或日志）	截图或者日志。如果可以截图，一定要截图，因为这是最直接的证据，一般的操作系统都有截图软件。
Bug其它信息点	根据实际测试环境或者公司要求如实填写

目前主流的Bug管理工具有很多，如Test Director（简称TD）、Quality Center（简称QC，它是TD的升级版）、JIRA、禅道、Mantis以及各公司自行开发的Bug管理工具等。重视思想，熟练使用。

当测试人员通过Bug管理工具把所发现的Bug全部提交给开发人员后，开发人员就会对这些Bug展开修复工作，等到开发人员把Bug修复好之后，测试人员就要进行回归测试。

即使上一轮的Bug被修复了，在下一轮的测试中还可能发现新的Bug，并不是说上一轮的Bug修复好了就不会再出现其他问题了；
软件测试并不是测试一轮就完成了，一般情况下，一个软件产品可能需要经过多轮反复测试和验证才能达到上线标准。

进行回归测试是在修复的版本上重新进行测试。

回归测试时执行全部的测试用例。
选择重要的功能点、常用的功能点、与Bug相关联的功能点进行回归测试。
选择性执行关键功能点的测试用例。
仅测试出现Bug的功能点。

9. 软件测试的报告

测试报告是一份描述软件的测试过程、测试环境、测试范围、测试结果的文档，用来分析总结系统存在的风险以及测试结论。

测试过程需要对测试人员、测试时间、测试地点、测试版本等信息进行描述。其他测试过程中发生的关键信息均可在这里进行描述。
测试环境指的是软件环境和硬件环境（主要描述前台环境，此环境同测试计划中的环境），其他相关联的辅助环境均可在这里进行描述。
测试范围指的是具体所测模块及分布在该模块上的所有功能点。与之有关联的信息也可在这里进行描述。
测试结果主要指测试用例执行情况的汇总、执行结果通过率、Bug的问题汇总、Bug的分布情况等。其他有关联的测试结果均可在这里进行描述。
系统存在的风险主要指的是系统中遗留的Bug会对软件造成什么风险。其他风险信息均可以在这里进行描述。
测试结论指在报告的最后给出一个是否能上线（通过）的结论。
附件清单主要指测试用例的清单和Bug清单，这些清单也需要一并放在测试报告中。

测试报告划分模板：

编写目的
模块功能描述：需要对测试模块的功能进行整体性描述
测试过程：模板中采用了表格的形式，将测试过程中的测试时间、测试地点、测试人员、测试版本具体展现出来
测试环境：软件+硬件
功能点测试范围
测试执行结果：需要对测试执行过程中发现的Bug汇总情况及分布情况进行说明，通常会用一段文字概述
风险评估：需要根据测试结果评估本次测试存在的风险以及应对策略
测试结论：需要对本次测试进行总结，给出测试结论
附件：可以附上测试过程中所产出的各类输出文档

参考引用

[^1]:Google Testing Blog: How Google Tests Software - Part Two (googleblog.com) [^2]: 京东质量团队转型实践 (豆瓣) (douban.com)