测试流程

以下是自己整理的测试流程，算是对2020年的计划的一个答复，因为在20200101的制定的计划中，需要总结一次在软件生命周期中测试在这个过程中扮演的相关角色。

主要是以功能测试的视角进行阐述的，不同的测试阐述的视角是不相同的，以后有机会可以在来一波；

这是在20201230日完成的，20210104记录于博客园。

测试流程

 

一、软件生命周期... 3

二、软件测试分类... 3

三、软件测试流程... 3

1、前期的需求确认... 3

1.1、伪需求... 3

1.2、如何避免出现伪需求... 4

1.3、需求评审... 4

2、详设评审... 5

3、编写测试计划... 6

4、编写测试功能点... 6

4.1、以点切入... 7

4.2、以面切入... 7

5、评审功能点... 7

5.1、评审前准备工作... 8

5.2、评审时间... 8

5.3、评审形式... 8

5.4、评审后的工作... 8

6、编写及评审测试用例... 8

6.1、测试用例定义... 9

6.2、测试用例包含元素... 9

6.3、通用用例八要素... 9

6.4、测试用例模板... 10

6.5、测试用例编写方法... 11

7、执行测试... 11

7.1、环境部署... 11

7.2、提测标准... 12

7.3、冒烟测试... 12

7.4、正式执行测试... 13

7.5、回归测试... 15

7.6、测试准出规则... 16

8、测试报告的梳理... 16

8.1、背景概述... 17

8.2、测试过程... 17

8.3、功能实现清单... 17

8.4、测试统计... 17

8.5、测试总结... 17

8.6、测试风险... 17

 

 

 

 

 

 

 

 

 

 

 

一、软件生命周期

常规我们说描述的软件的生命周期是指软件的设计产生直到停止使用的过程。通俗的说，就是它先从无到有，再从有到无的整个过程。专业点的说法：是指从形成开发软件概念起，所开发的软件使用以后，直到失去使用价值消亡为止的整个过程。

大致可以将整个过程划分为以下6个阶段，从上到下进行串行发生；

第一阶段：计划阶段(planning)，

第二阶段：需求分析(requirement)，

第三阶段：设计阶段(design)，

第四阶段：编码(coding)，

第五阶段：测试(testing)，

第六阶段：运行与维护(running maintrnacne)

二、软件测试分类

按照不同的划分标准可以分为不同的测试类型分类，大致可以按照以下的几种分类方式，软件测试类型如下方所示：

1、 按照开发阶段：单元测试、集成测试、系统测试、验收测试

2、 按测试实施组织：α、β、第三方

3、 按测试执行方式：静态测试、动态测试

4、 按是否查看代码：黑盒测试、白盒测试、灰盒测试

5、 按是否手工执行划分：手工测试、自动化测试

6、 按测试对象划分：性能测试、安全测试、兼容性测试、文档测试、易用性测试（用户体验测试）、功能测试

现在软件测试类型还有：冒烟测试、回归测试、随机测试、探索性测试。

三、软件测试流程

    这里只描述关于软件测试活动中功能测试的相关测测试流程，主要可以分为以下主要几个部分：

1、前期的需求确认

在软件项目中，需求分析是最开始的工作，同时也是最重要的工作。需求分析做的不够详细或者不能精确定位客户需求或者是需求存在缺陷的话，往往会给项目带来灭绝性的灾难，基于官方统计数据，90%失败的项目都是由于需求分析工作不到位所致，这些血的教训告诉我们不重视需求分析过程的项目团队往往会自食其果。因此如何保证需求分析的正确性、准确性就成了决定软件项目成败的关键因素。软件需求规格书的正确性必须得到彻底的验证，利益相关方必须彻底理解需求，并达成一致。要达成这一目标、降低需求风险，需求评审是一个行之有效的方法。

    如何评审完成一份常规需求，非伪需求？

1.1、  伪需求

什么是伪需求，百度百科中给出的阐述是：伪需求是指当下的供给并不是用户真正的需求，产品就没有切中用户痛点。直白的说就是，你认为有可能有用，其实没有用的事情，忽略了刚需，来弄一些，不那么重要的东西，也就是，看似有这种需求，但是这种需求，没有使用频次，以及使用依附性很弱。说了半天还是无法区分真、伪需求。

1.2、  如何避免出现伪需求

这是在知乎找的，我也没做过产品经理，虽然每个人都在说；“人人都是产品经理”，但是没做过真不知如何辨别。

1.2.1、需求采集阶段，各种方法要灵活应用——比如“不但要听用户怎么说，还要看用户怎么做”，虽然放在这里有点猥琐？

1.2.2、 需求转化阶段（用户需求-->产品功能），不能直接照着用户说的做，而要分析用户的目标，这得靠领域知识和对目标用户的理解；

1.2.3、 产品概念验证，自认为想清楚了新功能，在动手开发前，再找几个用户沟通一下吧，注意方式方法，比如你可以问——如果我们这里有自习室，你会推荐同学来学习么？

1.2.4、新功能上线时，多用用灰度测试，大爷，不要一下子把整个宾馆都改了嘛，先改个一两间，看看市场反馈好不？

    看了半天字面意思看懂了，但是还是是似而非的样子，这里就不在展开了，描述这个伪需求的目的只是为了后续引申出后续的话题“如何进行需求评审”。

1.3、  需求评审

1.3.1、什么是需求评审

    需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员（开发、测试等）了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看，需求评审是一个非常重要的环节，它串起了前期的需求收集、需求分析和后期的需求实施和产品落地。

1.3.2、为什么要进行需求评审

    a、明确产品需求，达成统一认知。对于明确产品需求，主要面对的是需求提出方，即相关的业务人员或者用户代表。讲清楚自己对于用户需求的理解是什么，是否深入分析了用户需求背后的真正动机。例如用户想要一个钻孔机，背后真正的动机是想要墙上的一个钻孔，还是想挂一副画，或者是想要一个温馨的环境。然后与需求方沟通，阐述自己的分析过程，确定自己的理解是否正确，并与其达成一致。因为对动机的理解不同，解决方案也会不同。当动机达成一致后，接下来介绍相关的解决方案，也就是他们将得到什么样的按钮，进行如何的操作，会看到什么样的数据或分析等。然后进行沟通，这些解决方案是否实现了其目的，是否带来了工作效率的提升。

b、沟通需求细节，优化实现方式。对于需求细节的沟通，主要面对的是需求实现方，即相关的设计或开发人员。在这个环节主要是讲清楚“为什么做”和“做什么”，首先交代需求的相关背景和设计原因，让实现方从源头就清楚自己要做的功能为什么是这种形式，其次详细描述需求的实现方式的相关细节，让实现方知道自己接下来做的东西是什么，特性是什么，具有什么样的流程，如何操作等。最后针对相关细节进行沟通和讨论，实现方会站在他们的角度，对实现方式提出自己的疑问或建议，一般情况下，他们提出的相关问题，会弥补产品经理前期没有想到的地方，从而让实现方式更加合理。

c、体现专业能力，获得团队支持。需求评审，体现了产品经理的综合能力。而这种综合能力，不仅体现在需求评审会议的主持和沟通上，更重要的是在需求评审前，对需求的收集、分析和实现，也就是把用户需求转化为产品需求的过程，需求评审只是对这个过程完成度的体现和考验。所以，长期深入的思考和足够专业的能力是开好需求评审会议的前提。作为产品经理，要认真对待需求评审，清楚自己的核心工作在什么地方，通过什么方式能进行更好的呈现，如何沟通能让需求更准确的传达，把它当成一次考验和锻炼自己的机会。只有自己足够专业，才能得到团队的支持，有了团队的支持，才会更加自信，在良性循环中，使产品不断的迭代和完善。

1.3.3、如何进行需求评审

    a、提前准备。凡是预则立，不预则废。只要你认为比较重要的事情，想获得比较好的结果，前期的认真准备都必不可少。对于需求评审会议的准备工作，主要有三个方面。第一，资料方面，一定要详细，齐全，至少包括产品需求文档和会议议程，形式越正式，大家对会议的重视度也越高。第二，人员方面，要考虑清楚都需要谁来参加评审，是一次性把相关内容都评审完，还是分批次小范围评审，然后提前把资料发送给相关人员。第三，沟通方面，分析相关人员的关注点在什么地方，需要对方在哪些方面给出建议，最好提前逐个进行沟通，让对方在会议之前就对相关内容有所了解，这样在评审的时候会更有针对性，效率也更高。

b、足够具体。在讲解具体产品需求时，不要陷入自己的逻辑不能自拔，而是要把参与会议的人员当成小白用户，站在对方的角度，尽量讲的详细具体，主要有三个方面。第一，形式多样。产品需求文档，不要只有Word版本，Word一般作为相关人员的后期查看使用，在需求评审时，最好使用PPT、流程图或Axure形式，也可以多种形式交叉使用，避免枯燥。如果有可以实际操作和带交互的原型更好，面对具体的软件，更容易调动大家的积极性。第二，背景清晰。一定要把产品设计的背景信息以及需求分析的来龙去脉讲清楚，让大家“知其然”的同时也“知其所以然”，对需求的理解越深入和全面，越有利于需求的落地和实现。第三，代入场景。不要直接讲产品的功能，尽量把功能代入用户的实际使用场景，通过故事来串联操作。例如苹果在发布MacBook Air笔记本电脑时，直接从档案袋中把电脑拿了出来，惊艳全场。这种方式就比直接讲电脑的尺寸参数要形象的多。

c、长期跟踪。不要指望一次评审和几次沟通就能让大家全面理解产品需求，会议结束后，还需要进行以下三方面的工作。第一，形成文档。会议结束后要及时形成会议纪要，对于会议中没有确定的争议点，产品经理要给出解决方案，并结合已形成的决议和后续相关工作等，尽快编写出详细的文档，并在后续过程中不断更新和完善。第二，沟通确认。把文档以邮件的形式发送给大家后，找相关人员进行沟通，确认双方理解一致，并敲定相关功能的设计开发时间点。第三，长期跟踪。需求评审只是开始，开启了产品具体实施和开发的另个一环节，在此过程中，产品经理要不断找相关人员确认需求细节，推进功能开发。

2、详设评审

详细设计文档就是在完成需求评审后，开发人员根据评审后的需求写的设计文档，如要实现这个功能使用的框架、语言、类、建表或者修改sql、数据流向、活动图、内部实现逻辑等，这儿不展开叙述；

3、编写测试计划

旨在说明各种测试阶段任务、人员分配和时间安排、工作规范、测试环境等。测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。

这是以前公司的测试计划截图：测试计划中最重要的就是人力分布图，详细统计了测试活动中每个测试环节的预计时间，和现项目组使用的azure devops工具中的us-用户故事功效是类似的，us下有分解的任务。测试通过与失败的标注和测试挂起与恢复的条件可以根据实际的项目组情况确定标准；

 

4、编写测试功能点

什么是测试功能点，指能够单独完成的某个具体业务流程。 一般在软件测试工作流程中的需求分析阶段，要根据需求说明书或者原型图提取功能点，功能点是和需求点相对应的。我们写用例的时候一般是先写测试点，然后再写测试用例，也可以这么理解，测试点就是精简版的测试用例。编写用例四个基本方法：等价类、边界值、正交法、场景法、流程图、错误猜想法等。我认为对于一般的企业测试来说，前面四个方法足够了。编写测试用例的策略：先点后面，先局部再整体，最忌讳的是点和面混在一起，局部和整体不明，导致遗漏测试功能点，影响整体测试效果，引发各种线上问题；

编写测试功能点可以使用常规的excel表或者xmind脑图工具，主要是根据需求文档以及项目所处的行业背景默认的规则来进行编写。这是以前写的app端的测试功能点如下，其他端（web端，APP端-android、IOS，小程序、公众号、PC端、H5页面）的测试功能点可以根据端的特性做不同的调整：

 

 

 

测试功能点设计思路，以点、面两个方面来进行描述：

4.1、以点切入

点阶段是项目测试前期执行中的最小单元，这个阶段测试点的设计及执行有几个要求：

4.1.1、测试点设计要简单、独立、明确、减少与其它点的交叉；

4.1.2、测试点设计的范围局限于单个模块内部；

4.1.3、测试点设计以功能验证为主，性能指标、可靠性、可用性等暂不涉及；

4.1.4、测试点设计以正向测验为主，异常测试及复杂场景模拟先不考虑；

4.1.5、测试点执行时的策略：优先选择简单、执行难度小、功能最核心的指标，尽早暴露问题；

4.1.6、项目前期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部基本功能测试；

4.2、以面切入

面阶段是项目测试中期执行中的单元，这个阶段测试点的设计及执行有几个特点：

4.2.1、测试点设计要稍微复杂些，考虑单模块内部的异常和复杂场景；

4.2.2、测试点设计的范围不仅包括单模块的复杂设计要求，还包括模块间的接口测试；

4.2.3、测试点设计以功能验证为主，单模块及模块间的性能指标、可靠性、可用性可以涉及；

4.2.4、测试点设计以正向测验为主、异常测试及复杂场景模拟为辅；

4.2.5、测试点执行时的策略：优先选择功能最核心的指标，必要的性能和异常场景，尽早暴露问题；

4.2.6、项目中期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部高级功能和性能测试，模块间的接口测试；

5、评审功能点

测试功能点的评审是测试活动中非常重要的一个环节，可以为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题） ，避免测试用例编写过程中遗漏测试项， 为了避免三方需求理解不一致，为了每个测试人员的质量标准与项目要求标准达成一致。那功能评审前、评审中、评审后测试人员需要做哪些工作？

5.1、评审前准备工作

5.1.1、需求评审结束后，就可以着手把需求拆分为功能点。工具：建议用XMind，需包含预期结果和测试结果；

5.1.2、功能点写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善功能点，仍有疑问的可先做标记，评审会上抛出一起讨论；

5.1.4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试功能点以邮件的形式发给参会人员查看。针对我们的项目邮件抄送考核人；

5.2、评审与会人员

主要是产品、开发（客户端和后端）、测试、项目负责人，以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加；

5.2、评审时间

对于敏捷开发项目，建议控制在半小时以内，如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的功能点，再针对疑问多的功能点评审，最后对于功能简单的功能点可简单带过。时刻记住我们功能点的评审目标，不能流于形式。

5.3、评审形式

5.3.1、评审要按功能点的优先级，功能的复杂程度进行；先对功能复杂，优先级高，疑问多的功能点进行评审，再评审功能简单，优先级低的功能点。

5.3.2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；

5.3.3、超过5分钟无法确定结果的问题留作会后讨论跟进。对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。

5.4、评审后的工作

评审结束后，第一时间整理测试功能点，把修正的内容重新整理补全。修改的功能点用黄色标记。会上未确定的内容，会后继续跟进，直到确定结果。如果有遗漏的功能点，新增后用绿色标记。没有任何有疑问的地方了，再做个简单的功能点评审会议总结（如修正了哪些功能点（黄色），补全了哪些（绿色）？哪些模块功能有变动（紫色）？哪些功能推迟到下一期做（红色）？等）

6、编写及评审测试用例

在很多项目测试过程中，没有对测试功能点及测试用例进行，在这儿我进行拆分，所以如何评审测试用例就不在这人叙述了，评审测试用例的过程同评审测试功能点。在这儿只做如何进行功能测试用例的编写，其他的测试对象如安全测试、性能测试、接口测试、兼容性测试、不同端的专项测试可以根据实际情况对测试用例的要素进行修改。

6.1、测试用例定义

    对一项特定的软件产品进行测试任务的描述，指定输入，预期结果和一组测试项的执行条件的文档。体现测试方案、方法、技术和策略；内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

6.2、测试用例包含元素

    试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤等，概括为5W1H。

6.2.1、测试目标：Why——为什么而测？功能、性能、可用性、容错性、兼容性、安全性等。

6.2.2、测试对象：What——测什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。

6.2.3、测试环境：Where——在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网络环境。

6.2.4、测试前提：When——什么时候可是测？测试用例运行时所处的前提或条件限制。

6.2.5、输入数据：Which——那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

6.2.6、操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

6.3、通用用例八要素

6.3.1、用例编号

    用例编号是唯一标识一个测试用例的标识符，测试用例编号命名规则的不同可以直观有效的区分执行用例的的测试环境以及测试测试类型

6.3.2、测试项目

    测试项目对应的就是测试对象，测试的是哪个项目，哪个模块。

6.3.3、测试标题

    测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，或者可以叫做测试目的。

6.3.4、重要级别

    常规的测试用例等级划分为三个几倍：高、中、低。高级别对应的是系统的基本功能、核心业务、重要特性、实际使用频率比较高的用例，中级别对应重要程度介于高和低之间的测试用例，低级别对应实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。

6.3.5、预置条件

    测试用例在执行过程中需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件。比如项目模块中有搜索框，如果数据库中没有任何数据，对搜索测试时无法进行下去的。前置条件通常分为两种：测试环境的预置；测试用例的依赖；

6.3.6、测试输入

    用例执行过程需要加工的外部信息。

6.3.7、操作步骤

    执行当前测试用例需要经过的操作步骤，需要明确的给出每一个步骤的描述，测试用例执行人员可以根据该步骤测试用例执行；

6.3.8、预期结果

    预期结果是测试用例非常重要的部分，要想判断测试对象是否工作正常，都需要通过预期结果来进行判断。一旦预期结果写的不准确或者不全，整个测试的作用将会大打折扣。

6.4、测试用例模板

    这是当前项目使用的模板（测试用例导入到禅道中的模板）

 

 

 

    这是敏捷开发模式下使用的敏捷工具devops自带的测试用例模板

 

 

 

6.5、测试用例编写方法

    测试用例的编写方法和测试功能的编写方法是相同的，见上文测试功能的编写方法，测试用例只是测试功能点的具体描述。

7、执行测试

用例编写完成并通过评审后，就进入到软件测试最主要的阶段，就是执行测试用例，进行软件测试，不过在执行测试过程中需要注意几个问题。

7.1、环境部署

    经历了几个项目，关于测试环境对测试的影响深有体会。一个良好的测试环境对测试人员进行测试是一个很好的保障，提高测试效率，也是对项目质量的一个保障。同时测试环境与否会严重影响测试结果的真实性和正确性。

    在设计测试环境根据客户的需求进行环境设计，当然期望测试环境无限接近于客户所需软件运行的真实环境，这样能够测试出真实环境中的所有问题，同时也需要理想环境以便找出问题的真正原因。但实际上由于各种资源的限制，只能在近似的模拟环境中进行测试。

    相反理想环境有利于代码的调试和分析，但测试结果就无法视为真实结果。测试环境可以说是测试的基础，它贯穿了测试的各个阶段，每个测试阶段中测试环境对测试的影响是不一样的。

    在最初环境的设定中，比如版本情况，在错误的版本下测试就可能得出完全错误的结果，发现很多无效的bug，这些白费徒劳的工作可能就会导致真正环境的测试延期，最后导致项目延期。在中途测试环境的宕机，就可能造成测试无法执行。有时候测试环境无法实现的情况就需要测试人员手工配置，修改系统配置，这样就可能忽略了实际使用可能会出现的bug。

    所以在测试过程中，测试人员要记录好这些环境版本不同而造成的bug；环境由于什么原因宕机，以及宕机的时间及影响测试的功能块；无法模拟的测试环境也都需要记录项目上线后，出现问题这也是一种有源可寻。这些都可提供PM、PD、TL来评估这些风险对项目的风险以及上线后带来的影响，也便于开发进行问题排查。

    一套良好的测试环境并不只依赖于环境配置人员，需要大家一起配合，将环境因素对项目的影响降到最小。

7.1.1、代码合并到测试分支

    开发在开发环境自测通过后将dev分支合并到测试分支；

7.1.2、测试版本构建

    测试版本构建有不同的方式，取决于项目使用的架构方式及环境部署方式。截止目前经历过三种部署方式。

a、 单体应用部署

通过jinkens部署，从gitlab上拉取代码到服务器的jinkens工作目录空间，然后执行编译程序，编译为jar包，然后执行java -jar的方式运行程序，采用的是单个应用部署的方式；这种单个应用部署的程序的复杂性非常高，每次代码的改动都会牵一发而动全身，很容易堵了西墙漏了东墙；扩展能力差，无法根据业务模块进行伸缩；技术债务累积，随着时间的推移，需求的变更和技术人员的更替，形成应用程序的技术债务；

b、 微服务架构jinkens构建

方式2是方式1的升级版本，使用的微服务部署，将单个应用程序进行业务拆分，拆分为不同业务模块，每个模块为一个微服务，使用docker部署的方式；还是使用的jinkens部署的方式，每个模块在jinkens中创建一个构建工程；

c、 微服务架构pipeline构建

现在项目采用的是敏捷开发模式，项目管理工具使用的是微软的Devops，项目管理、代码管理全部转移到devops上，代码管理使用pipline进行部署，采用的是微服务docker部署的方式，使用的是K8s的编排工具；

7.2、提测标准

    虽然说开发和测试一家人，应该相互信任，不过在关键环节有法可依，还是非常必要的，“提测”环节便是其中之一，每个角色做好分内工作，有助于整体研发效率的提升，毕竟，一个BUG半小时嘛。

7.2.1、开发自测通过，整体主流程是可以跑通无阻塞。

7.2.2、提测资料齐全，开发自测报告，提测说明-版本范围、版本修复bug、影响范围、相关配置文件，数据库sql脚本、上次bug  修复率达到要求，部署资料等信息齐全；

7.2.3、比较严格的提测准入规则中还有单元测试报告、代码扫描的测试报告；

7.3、冒烟测试

    在开发提测后，测试版本在测试环境中构建成功，就可以执行测试了。当然首先第一件事还是的进行常规的冒烟测试，对项目进行主流程、主场景测试，保证整体流程是通畅的，避免出现提测后测试过程中功能无法使用，导致测试阻塞等现象，导致项目组成员无组织无目的性的加班。

7.3.1、什么时候进行冒烟测试

测试是测试人员确认软件存在bug的过程，此过程中不可避免是需要开发人员要不停的修改bug，那么常常会发现一个功能的改动，导致下一轮系统测试出现问题。即发现也许以前修改的bug的确是解决了，可是由于修改一个或多个bug导致其他功能模块出现新的问题，测试跑不通了，只能测试终止。那么我们如何确保开发人员修复了bug后，这个bug的修复没有影响到其他功能模块呢？这时就需要进行冒烟测试啦。

7.3.2、什么是冒烟测试

冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来修复这个Bug，冒烟测试是否通过决定了下一轮系统测试是否可以执行。

　　

诚然第一次看到他的时候，有人给过解释即：使用一袋烟的功夫快速对软件的主要功能进行测试，理所当然仍人为很简单，随便点点就好啦。这次正式开始了解后明白冒烟测试的重要性不作用于本身而是决定了下一轮测试是否能达到理想的效果，与系统测试不同之处在于冒烟测试是一种不要求覆盖面有多广测试，但是要保证被测对象的主要部分功能要得到测试，不要求每一个功能都面面俱到，但是要保证所有被修改过以及与修改相关的功能、主要的功能都是可用的，即证明这个版本可进行系统测试。

7.3.3、执行冒烟测试的前提

前面提到冒烟测试是与开发的合同协作，因此有几个合作前提：

a、初步了解代码中进行了什么更改。若要理解该更改，必须理解使用的技术

b、开发需告知此修改对其他功能是否影响

c、更改对各组件的依存关系有何影响。

7.3.4、冒烟测试注意事项

a、列出冒烟测试的主要功能、测试点。

b、冒烟测试不是只对修改过功能进行测试

c、重视平时测试时容易忽略的隐藏功能

d、重视常见又很重要的步骤如：下载安装

7.4、正式执行测试

7.4.1、测试执行

    测试用例是测试过程中和重要的一部分内容，用例编写也是一项很考验测试人员对业务知识的理解和分析能力的工作，所以编写测试用例的水平也能一定程度上反映出测试人员的测试水平，而很多测试人员特别是刚进入测试行业的测试人员，往往忽略了测试执行的重要性，不屑于做测试执行的工作，觉得测试执行没有什么技术含量；

   我在之前的两家公司，因为人员结构或者测试组织方面的原因，没有执行过别人写的用例，都是自己写好了自己执行。来到现在公司后，由于项目已经进入了尾声，用例也比较完整了，所以就安排我先做用例的执行工作。一方面在不熟悉业务的情况下，执行用例相对编写用例会简单点，另外一方面也可以通过执行用例来熟悉业务。在执行他人编写的用例也算是交叉执行的一个过程。在用例的执行过程中，一方面是对我业务理解能力的检验，另外一方面也是对用例编写者的用例的检验。用例的执行环境、前提条件、操作步骤和预期结果都会影响到用例能否顺利的执行，这些如果都写的清晰了，用例执行的效率也就更高，对业务的理解也就更容易。

    所以不要总以为测试执行是非常简单的任务，细节决定高度，简单的测试执行一样可以体现测试人员的水平。

7.4.2、bug管理流程

    bug管理工具有很多，jira、禅道、QC、bugfree等，有些公司甚至会用word、excel表来记录bug，不论是工具或者是文档，只要能够记录跟踪问题，都是可以的，俗话说不管白猫黑猫只要能抓老鼠都是好猫。只要跟踪bug的形式适合现阶段的项目组，都是非常好的。在以前的项目早期中，就是使用的excel来进行记录问题，我当时推荐至少用一个禅道吧，领导说现阶段项目组人员少，尽量使用比较简洁轻便的工具。

 

 

 

bug提的好，测试走的早。提好一个bug也是一个测试人员必修之课。

7.4.3、什么是好的bug

a、根据bug步骤能够重现bug；

b、其他人看见你的bug，心情没有变糟，要记住你报的bug，阅读对象可能是其他测试、开发、产品经理、甚至是你的领导；

c、开发看到你的bug后，基本上95%指导问题出在什么地方了。

7.4.4、一个好的bug例子

    一个好的bug包括了简洁的标题，详细的步骤，明了的bug截图等。

a、 bug标题力求精简，表达清楚，避免出现写作为似的标题，一个好的标题应该尽量不要超过50个字符；

b、 优先级在时间不够项目周期比较紧张的情况下，开发会根据优先级来修复bug，标好优先级方便开发处理问题，提高整个团队的效率，原则上，在上线之前所有提交的bug都应该被修复，最次也要达到无严重级别及以上的bug都被修复；

c、 发生bug的环境是什么，比如浏览器是Chrome60.0.0.1、操作系统是win10、或者 AndroidQ、IOS11等，明确表示bug产生的环境；

d、 Bug是否发生在特定的账号里面，想复现bug是否需要非常复杂的步骤，如果是，给出复现bug的账号吧，开发只要登录，找到对应的位置，就可以轻松复现解决。

e、 一个好的bug描述决定了其他人拿到这个bug之后，是否能准确复现bug，不要漏掉任何一个步骤。

f、 贴上bug的截图，开发就会明了，不会在重复的询问，有的时候一张图更能传到bug的意图。问题不好用文字来描述，使用录屏可以让开发很好的理解并重现bug。

g、 客户端崩溃了，客户端发生了一个不能重复的bug，贴上崩溃的crash，发生问题的时候的log，开发一看就明了。

7.4.5、bug状态管理

测试人员应该跟踪一个bug的整个生命周期，从open 到 close状态。

Bug的不同状态以管理工具禅道来进行描述：

New：发现bug，未经评审决定是否指派给开发人员进行修改。

Open：确认bug，并且认为需要进行修改，指派给相应的开发人员。

Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

Rejected：如果认为不是Bug，则拒绝修改。

Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。

Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。7.5、回归测试。

Bug状态变化流程图如下：

 

 

 

7.5、回归测试

    回归测试是指修改了旧代码后，重新测试以确认修改没有引入新的错误或导致其他代码产生错误。什么时候会出现回归测试的场景，主要有以下两种场景：开发修复完bug后、迭代上线前。

7.5.1、开发修复完bug后

    测试提bug开发修复完成后，会重新进行构建新的版本，此时测试同学们需要将之前发现bug的用例再次执行一遍，已验证此问题已经修复，然后关闭对应的bug，备注相关信息。这就是我们常规所说的回归测试，在此种回归场景下，有不同的回归策略：完成重复性测试、选择性测试（覆盖修改法、周边影响法），可以根据项目的重要程度以及项目制定的测试策略选择回归策略。

a、 完全重复性测试，如字面意思将这个迭代的所有的测试用例完全重新测试一遍，这种方法基本上是不会采用的，太耗费测试资源了。

b、 覆盖修改法，针对被修改的部分，选取或重新构造测试用例来验证是否有错误再次发生；

c、 周边影响法，不但包含覆盖修改法的测试用例，还要分析修改后的扩散影响。对那些修改后间接影响的部分选择测试用例来验证该部分是否受到影响；

7.5.2、迭代上线前

    每个迭代的版本有很多不同类型的bug，在前面所说回归测试类型中都是属于有针对性的对测试过程中发现的bug进行回归，在这儿说的就是迭代版本封存代码后的测试。该回归测试的测试用例执行范围为本次迭代全部的测试用例，抽取其中部分用例作为回归测试用例。抽取回归测试用例的技巧

a、 如果系统目前为止已经比较稳定，那回归测试的用例可以根据2/8原则来进行挑选（80%的用例出现在20%的功能模块中），可以根据各模块缺陷的情况，将出现问题较多的模块执行测试用例；其他缺陷不多的模块，可以根据缺陷出现对应的功能点进行测试。

b、 业务程度较复杂的，用户使用频率较频繁的功能模块进行回归测试。

c、 开发近期对某个功能模块进行了小功能的修改，也需要进行回归测试，因为开发进行功能修改或者优化时，不怕一万就怕万一的情况。

7.6、测试准出规则

    在测试活动的尾声，如何判断本次迭代测试结束，或者说每个迭代测试活动结束的依据是什么？测试活动结束不是测试人员随口说一说：“本次迭代测试活动结束”就完了，而是根据实际测试活动中测试功能的覆盖比例及bug的修复情况来判断的。如下是测试准出的规则，可以根据项目组的实际情况来进行做出适当的调整。

a、 系统测试执行对需求覆盖率达到100%；

b、 系统功能测试中高级别和中级别测试用例100%执行，低级别的用例执行率达到60%以上，该标准主要是用于在迭代中测试时间比较紧张，有选择性的执行测试用例；

c、 缺陷修复率达到80%以上，且无致命及严重级别的缺陷未修复；

8、测试报告的梳理

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。该定义是直接从百度百科上截取下来的。

常规的软件测试报告一般包含：背景概述、测试过程、功能实现清单、测试统计、测试总结和测试风险。

8.1、背景概述

       主要包括项目背景、项目需求及相关的环境说明；

8.2、测试过程

       主要包括上文提到的需求评审记录、功能点评审记录、测试范围、测试用例；

8.3、功能实现清单

       该模块主要是罗列项目实现的功能模块及模块细分的功能点，是否符合测试计划中罗列的测试模块；

8.4、测试统计

       该模块主要分为测试资源统计-人力、时间等，用例的执行情况统计-执行成功、执行、阻塞、block等，bug统计-bug在模块中的分布情况、严重等级统计等可以用于测试分析，遗留bug列表-迭代由于项目期限等原因遗留下来的未修复的bug；

8.5、测试总结

       主要包含本次迭代测试结论是否通过及测试内容、用例覆盖比例、bug统计；

8.6、测试风险

       主要包含本次迭代测试活动中有哪些潜在的风险（主要来源于测试过程中的测试方式、方法、测试问题、遗留的bug会对模块产生怎样的影响）。测试风险的陈述是非常有必要的，必须要在测试报告中给出。一旦线上环境出现bug造成相关的损失这是会涉及到责任追究的；