软件测试第一阶段_本文档是针对xyc公司开发的xyc邮箱v1.0进行黑盒测试的整体测试计划-CSDN博客

本文链接：https://blog.csdn.net/qq_65548774/article/details/145174148

软件测试的分类（先进行了解）

按照测试原理分类

黑盒测试：把软件看作一个不透明的黑盒子，不考虑内部逻辑结构和代码实现，只关注软件的输入和输出，通过输入各种不同的测试数据，检查软件的功能和性能是否符合要求，常用的黑盒测试方法有等价类划分、边界值分析、决策表等。

白盒测试：也称为结构测试，需要了解软件的内部结构和代码逻辑，通过检查代码的逻辑结构、路径覆盖等方式，设计测试用例来发现代码中的错误，常见的白盒测试方法有语句覆盖、判定覆盖、条件覆盖等。

灰盒测试：介于黑盒测试和白盒测试之间，既关注软件的功能和外部行为，也了解部分内部结构和代码逻辑，用于测试一些接口和集成部分的问题。

按照测试阶段分类

单元测试：针对软件中的最小可测试单元，如函数、类等进行测试，主要检查单元的功能、逻辑和接口是否正确，通常由开发人员自己完成。

集成测试：将已通过单元测试的模块按照设计要求组装起来进行测试，重点检测模块之间的接口和通信是否正确，以及集成后的功能是否符合预期。

系统测试：将整个软件系统作为一个整体，在模拟实际运行环境下进行的测试，包括对功能、性能、兼容性、安全性等方面的全面测试，以验证软件是否满足系统需求规格说明书的要求。

验收测试：在软件交付前，由用户或客户在实际使用环境中进行的测试，主要目的是确认软件是否满足业务需求和用户期望，决定是否接受该软件。

按测试目的分类

回归测试：在软件进行修改或添加新功能后，重新进行测试，以确保修改不会引入新的错误，或者不会对原有功能产生影响，回归测试通常会使用之前的测试用例集，并根据需要进行适当的补充和更新。

冒烟测试：在软件版本发布前，对软件的基本功能和关键流程进行快速测试，以判断软件是否具备进行全面测试的条件，如果冒烟测试不通过，则无需进行后续的详细测试，可将软件退回开发人员进行修复。

随机测试：测试人员不按照固定的测试用例和流程进行测试，而是随机地输入数据和操作软件，以发现一些隐藏较深的、难以通过常规测试用例发现的问题，随机测试通常在测试的后期进行，作为一种补充测试手段。

按测试对象分类

功能测试：主要测试软件的各项功能是否符合需求规格说明书的要求，包括对各个功能模块的输入、处理和输出进行检查，验证功能的正确性、完整性和稳定性。

性能测试：通过模拟大量用户并发访问等场景，测试软件系统在不同负载条件下的性能指标，如响应时间、吞吐量、资源利用率等，以评估软件系统的性能是否满足要求。

兼容性测试：检查软件在不同的操作系统、浏览器、硬件设备、数据库等环境下的兼容性，确保软件在各种目标环境中都能正常运行，且功能和性能不受影响。

安全性测试：检测软件系统是否存在安全漏洞，如用户认证和授权是否有效、数据传输和存储是否安全、是否存在 SQL 注入和跨站脚本攻击等安全隐患，以保障软件的安全性和数据的保密性。

界面测试：也称为 UI 测试，主要关注软件的用户界面是否美观、易用，包括界面布局是否合理、按钮和菜单是否易于操作、提示信息是否清晰等方面的测试。

本阶段主要需要掌握的（本阶段的重点）

在软件测试第一阶段中主要掌握从需求分析到上线的整个测试流程以及使用的管理工具以下我就主要用按测试对象中的功能测试进行笔记撰写

测试流为 1.掌握需求 2.测试计划 3.测试用例 4.测试执行 5.回归测试 6.测试报告

1.掌握需求

在这方面主要就是需要详细阅读公司给你的需求文档（一般公司会给你一封文档以及一份账号密码，文档为需求文档，账号密码为测试管理工具的账号密码）

需求文档的作用

一.提供需求依据

测试人员工具需求文档设计测试用例，确保软件的各项功能都能得到充分测试。

二.明确测试范围

有助于合理规划测试工作，提高测试效率，避免盲目测试。

三.促进沟通协作

需求文档是开发人员、测试人员、产品经理等各方人员沟通的重要工具。它使各方对软件的功能和特性达成共识，便于协调工作。

四.发现需求缺陷

测试人员在阅读需求文档时候要对其进行评审，如发现那块有问题及时跟测试组长或项目负责人反应。

需求评审的依据

1.正确性

对照用户的原始需求，检查需求文档是否偏离用户的原始需求。

2.明确性

检查需求文档中每一个需求项是否有一些表达不清楚的地方，或着是有歧义的地方。

3.完整性

对照用户的原始需求，检查需求文档中是否覆盖了用户的所有需求项，每个需求项有没有遗漏用户提出的一些必要信息。

4.限制性

每个需求项里是否清晰的描述了这个软件能做什么，不能做什么。

5.优先级

需求文档中的哪些功能比较重要，哪些功能比较次要，是否做了标记。

6.一致性

检查需求文档中的内容前后是否一致，确保不冲突，不矛盾。

五.评估测试风险

根据需求文档，测试人员可以分析软件大体是什么样（软件的复杂度、关键功能以及存在的风险），从而制定相关的测试策略以及风险应对措施。

六.为后续的维护提供参考

就是为后续的维护提供参考

2.测试计划

测试计划是一份描述软件 1.测试范围 2.测试环境 3.测试策略 4.测试管理 5.测试风险，我们基于以上方面制定测试计划

一、测试范围

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

二、测试环境

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

三、测试策略

它的内容包括测试的依据、系统测试准入的标准、测试工具的选择、测试的重点及方法、测试准出的标准。

四、测试管理

它指的是测试任务的分配、时间的限定、测试与开发之间的沟通等内容。

五、测试风险

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

测试计划模板

一文档标识

不同的公司对文档标识有不同的要求，其目的是充分体现该测试计划文档的相关信息，如测试对象、测试文档的版本等。具体在测试计划中，可以用下面这句话来体现文档标识：本文档是针对XYC公司开发的XYC邮箱V1.0进行黑盒测试的整体测试计划。

二、测试目的

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

三、测试范围

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

表1-1 系统测试范围模板

四、测试环境

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

表1-2 系统测试环境模板（软件环境）

表1-3 系统测试环境模板（硬件环境）

五、测试策略

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

表1-4 测试策略模板

六、测试管理

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

表1-5 测试管理模板

七、测试风险

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

表1-6 测试风险模板

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

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

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

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

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

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

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

3.测试用例

说白了就是一份详细的 “测试说明书”，告诉测试人员要怎么去测试软件的某个功能，以及判断这个功能是否正确实现的标准。是测试人员执行测试的依据。

一、测试用例的组成

1.测试序号

说白了就是第几个，直接就是从1、2、3、4这样写下去就完了

2.测试模块

就是你要测试的哪个模块。例如QQ邮箱登录模块、QQ邮箱注册模块等。干就完了

3.前置条件

就是你在测试之前的条件，比如网路是否正常。OK不OK？

4.测试环境

就是你在什么样的环境下进行测试的，如：Windows 10操作系统，夸克浏览器这种的。

5.测试步骤和数据

就是你在测试中的详细步骤和数据，比如打开哪个网址，输入什么什么数据，点击确定那个按钮这种的。

6.预期结果

就是你在完成测试步骤和输入测试数据之后，根据用户需求或需求文档应该得出什么样的结果

7.实际结果

就是你在完成测试步骤和输入测试数据并且点击确定按钮后，系统所展示出来的实际结果。

8.是否通过

就是预期结果和实际结果是否一样，如果不一样就不通过如果一样就通过巴拉巴拉巴拉巴拉这种的。

9、重要级别

分为高、中、低三种，一般用于判断此用例的重要级别。如：比如，对于电商系统，“用户支付流程测试” 可能就是高优先级的，因为这直接关系到交易的成功与否；而一些界面的小细节，如按钮颜色在不同分辨率下的显示情况，可能就是低优先级的。

10.备注

就是说明这个测试用例是干什么的有什么目的，如：用于测试输入不存在的用户名时，系统是否能正确给出提示，防止用户因错误输入而无法登录的情况被忽略等。

二、测试用例模板

在此模板中缺少一个重要级别有些公司不需要，有些得要

三、功能测试的用例设计方法

在功能测试领域有很多测试用例设计方法再此我之举五种进行说明：1.等价类划分法 2.边界值分析法 3.错误推测法 4.正交表分析法 5.因果判定法

1.等价类划分法

把所有输入的可能划分为若干个等价类（等价类即为在软件中输入的数据能输出相同或等价的结果），然后取若干个具有代表性的数据进行测试

如

可以划分出以下等价类

可以设计出9个测试用例

2.边界值分析法

边界值分析法是取稍高于或稍低于边界的一些数据进行测试。为什么要取这些数据进行测试呢？因为测试经验告诉我们，程序在处理边界数据的时候较容易出错。

以此又可以写出四条测试用例（因为19包括在小于20的范围内20包括在20-99的范围内巴拉巴拉所以边界值分析法也略包含边界值分析法）

3.错误推测法

错误推测法也是测试人员常用的测试方法之一，指的是测试人员凭借自己的直觉、测试经验、发散思维去设计一些容易导致软件出错的测试点。

此方法也可以划分为等价类划分法的一种。

4.正交表分析法

对于这样一个组合输入框，除了需要按照上文的用例设计方法来对每个输入框进行字符输入测试外，还需要针对这组输入框，进行各个输入框输入状态组合的测试。

对于本例，姓名、身份证号码、手机号码3个输入框，每个输入框2种状态（填或不填），一共有8种组合，一旦运用了本节介绍的正交表分析法，就可以将这8种组合压缩一下，从而达到用更少的测试用例去覆盖更复杂的测试点的作用。如果一个页面的输入框有几十个的话，那列举出来的测试点可能高达成百上千个，这对测试工作来说是不现实的。

正交表分析法是一种有效地减少用例设计个数的方法

表测试点1（未使用正交表分析法）

表测试点2（使用正交表法）

很明显第二个表比第一个表少一些测试用例吗

对此我的理解是除来两条都填写和不填写之外其余的只有一个是填写的另外的不填写。

5.因果判定法

在有些软件页面中，除了输入框之外，还存在各类按钮，而且这些按钮之间存在相互关联和制约的关系，且具有较强的逻辑性。对于这类问题测试人员又应如何测试呢？接下来先看一组需求说明的范例。

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

（1）明确所有的输入条件（因）。

（2）明确所有的输出结果（果）。

（3）明确哪些条件可以组合在一起，哪些条件不能组合在一起。

（4）明确什么样的输入条件组合可产生哪些输出结果。

（5）通过判定表展示输入条件的组合与输出结果的对应关系。

（6）根据判定表设计测试用例。

接下来，便可以按照以上6个步骤开展本例测试点的分析工作。

（1）找出地铁卡充值模拟软件的所有输入条件，并编号。① 投币20元。② 充值20元。

（2）找出所有输出结果，并编号。A：提示充值成功并退卡。B：退出纸币并提示超时。C：提示请先投入纸币，再单击充值按钮。

（3）确定哪些输入条件可以组合在一起，哪些输入条件不能组合在一起。条件①可以单独出现，也就是用户可以做只投币，不充值的操作。条件②也可以单独出现，也就是用户可以做只充值，不投币的操作。条件①和条件②可以组合在一起，也就是用户可以做先投币，后充值的操作。在本例不存在输入条件不能组合的情况。

（4）明确什么样的输入条件组合可产生什么样的输出结果，如图6-22所示对应结果。

（5）通过判定表展示输入条件的组合与输出结果的对应关系，见如下表。

四、评审测试用例

在实际工作中，一般都是只有本项目组的测试人员参与评审。

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

（1）测试用例是否是依据需求文档编写的。

（2）测试用例中的执行步骤、输入数据是否清晰、简洁、正确；对于重复度高的执行步骤，是否进行了简化。

（3）每个测试用例是否都有明确的预期结果。

（4）测试用例中是否存在多余的用例（无效、等价、冗余的用例）。

（5）测试用例是否覆盖了需求文档中所有的功能点，是否存在遗漏。

4.测试执行

一、理解测试环境

软件系统有两种常见环境一种是浏览器与服务器结构的环境（B/S），另一种是客户端与服务器之间的结构环境（C/S）

B/S

B/S全称Browser/Server，即浏览器/服务器，简单一点说就是使用浏览器访问服务器的模式。举个例子，用户要打开新浪首页，那么用户首先要打开浏览器，然后通过浏览器向新浪服务器发送请求

B/S结构软件工作过程

（1）用户的计算机中装有IE浏览器，用来向Web服务器发送请求。

（2）Web服务器也是一台计算机，它里面装有Web服务器软件Apache。Apache是做什么的呢？它用来接收浏览器发送过来的请求，如发现浏览器发送过来的请求是自身可以处理的，则由Apache自身处理这个请求，并把处理后的结果返回给浏览器。

（3）Web服务器中的PHP服务软件是用来做什么的呢？Apache接收到浏览器的请求后如发现自身处理不了该请求，Apache就会把这一请求任务分配给PHP服务软件来完成。PHP服务软件接收到这一请求后首先会检查这一请求的合法性，如不合法则向Apache返回错误信息，再由Apache把错误信息返回浏览器。如这一请求是合法的，则由PHP服务软件来处理。如处理这一请求的过程中发现需要MySQL数据库来协助，则由PHP服务软件和MySQL数据库软件共同完成，请求处理完成后由PHP服务软件把处理后的结果反馈给Apache，再由Apache把处理后的结果反馈给浏览器。

（4）数据库服务器也是一台计算机，它里面装有MySQL数据库软件，MySQL数据库是用来存放和校验数据的，涉及数据处理的请求就会由数据库软件来完成。

B/S环境的搭建

前台环境的搭建

前台环境的搭建前台环境的搭建由测试人员进行，相对而言它是非常简单的，前台的计算机只需要安装一个桌面版的操作系统（常见的桌面版的操作系统有Windows XP、Windows 7、Windows 10等），并在操作系统上安装一个IE浏览器即可，而浏览器往往都不需要安装，因为操作系统上都自带浏览器。测试时测试人员只需要通过浏览器打开要测试的软件系统（其实就是打开一个网站）就可以了。

所以对于初级软件测试人员而言，应具备以下技能：

（1）能熟练地安装和使用前台桌面版的操作系统（如Windows XP、Windows 7、Windows 10等）。初级软件测试人员大部分的测试工作都是在Windows桌面版的操作系统里开展的，所以需要掌握对操作系统的安装和使用的基本知识，否则测试工作无从谈起。

（2）能熟练安装和使用常见的浏览器。常见的浏览器有IE系列、Google的Chrome浏览器、火狐浏览器（MozillaFirefox）、360浏览器、QQ浏览器、搜狗浏览器等。测试B/S结构的软件系统时，初级软件测试人员大部分的测试用例都是在浏览器上（C/S结构的软件系统除外）执行完成的，所以初级软件测试人员需要掌握各种浏览器的安装和使用技巧。另外，网页的兼容性测试（也称Web的兼容性测试）也需要在不同的浏览器上完成。

（3）能熟练安装和使用虚拟机软件。对于虚拟机软件，初级软件测试人员在入职前可能少有接触，但在入职后会经常用到。虚拟机有什么作用呢？通俗来说，它可以把一台计算机变成两台或多台计算机来使用。

后台环境的搭建

后台环境的搭建后台环境的搭建相对于前台来说复杂了一些，需要由具有丰富工作经验的测试人员搭建。一般情况下每个测试组都会有专门搭建并维护环境的测试人员，所以初级软件测试人员无须担心后台搭建的问题。后台环境的搭建主要是依照开发的环境进行搭建的，从而保证与开发环境的一致性。只有后台环境搭建起来了，前台的页面功能才能使用。接下来以图7-2中B/S结构的软件系统为例，简要地描述一下后台环境搭建的步骤。

（1）分别在后台的Web服务器和数据库服务器上安装服务器版本的操作系统，例如可以安装Linux或是Windows等服务器版本的操作系统。后台服务器的操作系统与前台桌面版的操作系统不同，其对安全性和稳定性及性能等方面有更严格的要求。

（2）在Web服务器的操作系统上安装Web服务器软件Apache，同类的软件还有iis、Nginx等。

（3）在Web服务器的操作系统上安装PHP服务软件（如PHP-fpm中间件），同类的软件还有Java服务软件（如Tomcat中间件）等。

（4）在数据库服务器的操作系统上安装MySQL数据库软件，同类的软件还有Oracle、SQL Server相关版本的数据库软件等。

（5）进行各组件之间的连接、代码上传、数据导入、文件配置、权限设置、环境变量设置、网络连接等一系列的操作，直至完全搭建成功。

C/S

C/S全称Client/Server结构，即客户端/服务器结构。通俗一点就是指在用户的计算机上安装一个软件，然后使用这个客户端的软件去访问服务器。例如在使用QQ时，用户需要在计算机上安装一个QQ客户端软件，然后通过QQ客户端软件才能访问QQ服务器。

C/S结构软件工作过程

从图7-34可以看到，用户的计算机只需要安装一个客户端软件，而后台只需要安装一个数据库软件就可以了。安装完成后，用户便可以在这个客户端软件上执行相关的操作和请求，如果用户执行的这个操作和请求，客户端软件本身就能处理，则不需要向数据库服务器发送请求；如果用户的操作和请求，客户端软件自身处理不了，则客户端软件会向数据库服务器发送请求操作，数据库服务器中的SQL Server数据库软件在接收到请求后就开始执行数据操作，并把执行后的结果反馈给客户端软件。

以上展示的就是一个相对简单的两层结构的C/S结构的软件系统（客户端软件→数据库服务器），它是通过客户端软件直接访问数据库服务器的。在实际工作中，每个项目组中的C/S结构都会不尽相同，后台服务器所装软件和配置也都不同，在这里就不做过多阐述了。

C/S的环境搭建

前台环境的搭建

只需要安装一个Windows桌面版的操作系统（如Windows10操作系统等）和相应的客户端软件即可。

后台环境的搭建

（1）在后台的数据库服务器上安装操作系统，如WindowsServer 2003的操作系统。

（2）在数据库服务器的操作系统上安装数据库软件SQLServer 2005。

（3）将数据导入到数据库中，检查数据库的IP地址、端口号、数据库名称、账号、密码等，检查客户端软件和数据库之间连通性等一系列操作后就可以完成搭建。

测试执行

当测试环境搭建完成后测试人员就在搭建的测试环境上进行测试执行。

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

Bug记录的模板

例1：某测试人员打开XYC邮箱的登录首页，输入正确的用户名和密码后成功登录到XYC邮箱内页，然后单击“写信”按钮进入写信页面，随后输入正确的邮件地址、正确的主题、正确的正文，然后单击“发送邮件”按钮，但之后页面没有任何反应，无法发送邮件。很明显，这就是一个Bug，那测试人员应如何记录这个Bug呢？

对于Bug的记录，需要注意以下3点。

（1）Bug的概要一定要清晰简洁。

（2）在Bug的具体描述中，测试的步骤和使用到的具体数据都要清楚地写出来；在Bug的具体描述中尽可能多地提供一些必要信息，如本例具体描述中的第6步。

（3）如果可以截图，一定要截图，因为这是最直接的证据，一般的操作系统都有截图软件。以上3点都是要提交给开发人员的关键信息，开发人员需要依据这些关键信息去定位Bug的原因。

Bug管理工具的介绍

目前市面上的Bug管理工具有很多，我们就于禅道进行演示。（它整合了Bug管理、测试用例管理、发布管理、文档管理等功能，完整地覆盖了软件研发项目的整个生命周期。在禅道软件中，明确地将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合，又互相制约，通过需求、任务、Bug来进行交相互动，最终通过合作使产品达到合格标准。）

一新建部门和用户

（1）在禅道的首页选择“开源版”，如图

2）进入禅道登录页面，如图

（3）使用管理员（admin）账户登录后将出现图8-3所示的界面。

（4）进入“组织”→“部门”的链接页面，新建3个部门并保存，如图

5）进入“组织”→“用户”→“+添加用户”的链接页面，添加“项目经理”账户并保存，如图8-5、图8-6所示（邮箱和源代码账号可为空，其中“您的系统登录密码”为管理员admin的密码）。

添加用户

添加项目经理

（6）添加“产品经理”账户并保存，如图

（7）添加“开发人员”账户并保存，如图

（8）添加“测试人员”账户并保存，如图

二建立产品和需求

（1）产品经理张产产登录禅道系统，进入“产品”→“+添加产品”的链接页面，新建产品并保存，如图所示

2）产品添加成功后系统自动跳转到需求模块的页面，进入“需求”→“+提需求”链接页面，添加需求并保存，如图

三新建项目、组建团队、关联需求、分配任务

由于产品经理已经在“XYC邮箱”这个产品下建立了该产品的需求文档，那么项目经理就要着手建立起一个项目并组建团队，关联项目的需求，分配相关的任务。

（1）项目经理王项项登录禅道系统，进入“项目”→“+添加项目”的链接页面，新建项目并保存，如图所示。

2）当项目添加成功后，系统将自动弹出图所示的提示

3）单击图8-16中“设置团队”链接进入“团队成员”页面，如图所示。

（4）单击图8-17中“团队管理”链接进入“团队管理”页面，添加团队成员并保存，如图所示。

（5）进入“项目”→“需求”→“+关联需求”的链接页面来关联该项目的需求并保存，如图所示。

（6）单击图8-20中“保存”按钮后可以看XYC邮箱第一期项目所关联的需求，如图所示。

（7）单击图中“批量分解”的链接按钮进入“批量创建”的页面，并进行任务的指派、保存，如图所示。

四开发人员领取任务，并提交测试版本

（1）开发人员李开开登录禅道系统，进入“我的地盘”→“任务”的链接页面就可以查看项目经理分配给开发人员李开开的任务，如图所示。

（2）当开发人员李开开完成其中一项任务时，可单击图右侧的完成按钮，在弹出的对话框中设置消耗的时间并保存即代表该任务完成，如图所示。

3）当开发人员李开开的三项任务全部完成时，便可提交相应的测试版本，进入“项目”→“版本”的链接页面进行版本的创建，如图所示。

（4）单击图中的“+创建版本”链接进行版本的创建，并保存，如图所示（图中源代码地址、下载地址、上传发行包为开发人员提供的软件安装包的位置）。

通过禅道系统来追踪Bug

（1）测试人员周测测登录禅道系统，进入“项目”→“任务”的链接页面，此时就可以查看项目经理分配给测试人员周测测的任务，如图所示

2）假设测试人员周测测已完成测试用例设计与测试用例执行的全部工作，并且在测试中发现了问题，那么测试人员周测测就要通过禅道系统提交Bug给开发人员。

3）测试人员周测测进入“测试”→“Bug”的链接页面，如图所示。

4）单击图上图中的“+提Bug”链接进入到提交Bug的页面，此时可提交Bug并进行相应保存，如图所示（从图中可以看到，此Bug的状态为“激活”，此Bug指派给了开发人员李开开）。

（5）开发人员李开开登录禅道系统，进入“测试”→“Bug”的链接页面，此时就可以看到测试人员周测测指派给他的Bug单，如图所示。

（6）开发人员李开开修复好此Bug后，就会单击图中的“解决”按钮，在弹出的对话框中设置解决时的信息并保存，那么此时Bug就已解决完成，如图所示。

（7）测试人员周测测登录禅道系统，并验证所提Bug是否被开发人员李开开修复好，如经验证，此Bug已被解决，将会单击图中的“关闭”按钮，并备注相关信息，如图所示。

（8）当测试人员周测测再次查看此Bug时，此Bug的状态为关闭状态，如图所示。

（9）如果测试人员周测测在验证此Bug时发现此Bug并没有被解决，就会再次编辑此Bug，并将Bug的状态设置为激活状态重新指派给开发人员李开开。至此Bug的基本处理流程已完成。

对Bug起争议时的处理

如果测试人员和开发人员同时对一个Bug产生争议有以下建议

（1）任何争议都需要“对事不对人”，不能因为Bug而激化了双方的矛盾。

（2）有很多初级软件测试人员提交的Bug单流转到开发人员那里后，开发人员看不懂。原因在于测试人员提交的Bug单没有描述清楚，这是一个非常常见的现象。测试人员提交的Bug单一定要描述清楚，并需要有充足的依据和理由。

（3）如果Bug单写清楚了，但开发人员还是不愿意修改的话，可以找一个合适的时间，心平气和地与开发人员沟通，说明此Bug对产品质量可能产生的不良影响，测试人员在沟通过程中不能意气用事。

（4）经沟通后，如果开发人员还是不愿意修改的话（当然开发人员不修改也有他们的原因），那么此时可以向测试经理汇报这一情况，由测试经理出面解决，或是由测试经理召开Bug评审大会（开发人员、测试人员、产品经理三方人员参与，有时也包括项目经理），共同定夺。

（5）有些初级软件测试人员把Bug提交到开发人员那后，经过开发人员的各种解释，就会同意开发人员的意见，也认为这确实不是一个Bug，从而忽略这个问题，这也是经常发生在初级软件测试人员身上的事情。这就要求测试人员提交Bug的过程要有原则性，这也是作为一名合格的测试人员最重要的特征之一，对待问题需要坚持原则。

（6）测试人员应和开发人员面对面或通过电子邮件、电话等方式保持密切沟通，共同协商和处理Bug，以减少两者间的隔膜，增加测试人员与开发人员之间的信任和了解。直接沟通也应贯穿到产品开发、测试的每个环节当中。

5.回归测试

就是开发人员把Bug修复好之后，测试人员需要重新验证Bug是否修复好了，同时在新版本中进行测试以检测开发人员在修复代码过程中是否引入新的Bug，此过程就称为回归测试。

回归测试的基本流程

假如XYC邮箱的测试工作已完成，Bug已全部修复，并已达到上线标准。接下来就以XYC邮箱为例来回顾一下XYC邮箱回归测试的基本流程

以上展示的就是一个回归测试的基本流程，从中可以看到：

（1）即使上一轮的Bug被修复了，在下一轮的测试中还可能发现新的Bug，并不是说上一轮的Bug修复好了就不会再出现其他问题了；

（2）软件测试并不是测试一轮就完成了，一般情况下，一个软件产品可能需要经过多轮反复测试和验证才能达到上线标准。

回归测试是在系统测试人员完成了需求评审、测试计划、用例设计、环境搭建、Bug提交等关键性的测试工作之后所要开展的工作，可以说此时的测试人员已经完全融入测试体系当中，也完全可以胜任相应的测试工作了。至于回归测试的策略，初级软件测试人员可通过先学习测试经理制定的策略，再从执行回归测试策略过程中进一步提升自己的测试经验。