软件测试概念篇

---

一、什么是软件测试？

1.1 软件测试的定义

在软件测试的过程中，我们需要对软件产品进行全方面的检测，以达到查找缺陷，验收缺陷的工作目的。
1983年，Bill Hetzel将软件测试定义为：软件测试就是一系列活动，这些活动是为了评估一个程序或者 软件系统的特性或能力，并确定是否达到了其预期的效果。
这也就意味着在软件测试的过程中，我们要以测试人员的“预期结果”为依据，验证软件功能执行的正确性。所谓“预期结果”指的就是需求定义。
简单概括来说：软件测试是在验证软件产品的特性（功能性，非功能性）是否能够满足用户的需求。
我们所说的测试是指：测试人员通过黑盒，白盒，UI测试，接口测试，功能测试等一系列测试方式，对软件产品的特性是否能够满足用户需求做出的一个全方面测试的过程，在这个过程中测试人员需要找到bug，验收bug。

1.2 为什么要有软件测试？

不知道大家有没有想过一个问题。当我们开发完一个软件产品之后为什么不能直接上线呢?直接上线不是能够减少人力和时间资源的投入吗？能够尽早获得收益吗？那么为什么我们还要进行软件测试呢？
其实严格意义上说，一个软件产品开发出来之后必须要经过测试，因为测试是软件产品的最后一道把控关卡，测试人员是在保障软件的质量。 测试人员在进行测试的过程中能够通过对软件全方面的检测检查出可能存在的缺陷，让这个bug不至于到了上线后才出现在生产环境中，给用户造成不好的感受。

1.3 学后练习

如何测试一个软件登录系统：
1.当用户输入正确的手机号码/账号以及该账号下对应的正确密码时，登录成功，跳转到页面。
2.当用户输入错误的手机号码/账号或者是错误的账号密码时，提示登录失败，无法正常跳转到页面。
3.当用户的权限不同时，通过所登录正确账号及正确密码的不同，可以成功跳转到不同的页面。
4.密码是否是隐藏式输入。
5.在密码正确的状态下，对于用户多输入的空格的处理效果。
6.登录成功后，是否能够正常的访问页面，是否会产生无法访问的错误。
7.在多并发的状态下，用户能否正常登入页面，是否会出现长时间等待的问题。
8.多次密码输入是否会提示无法登录账号或者是多长时间内暂时无法输入密码。

1.4 软件测试的特点

从这道练习中我们可以得出一个结论：软件测试只是一个样本试验，具有不可穷尽性。

二、软件测试和研发的区别

2.1 技术要求的区别

• 开发技术深度和专业度要求高，但广度相对要求更少；测试技术广度大，但专业度相对而言会更低。

2.2 工作内容的区别

研发：利用各种编程技术实现软件，并发现缺陷，解决缺陷；
测试：利用各种测试方式，验证软件是否符合用户预期。并在这个过程中发现缺陷，验收缺陷；

2.3 思考

为什么说是开发的专业度高呢？因为开发需要针对某些具体的类似于数据结构等要有更加熟悉的掌控力，但对于其他方面不做硬性要求。
但对于软件测试人员而言，测试时需要全方面的对软件进行测试。所以对例如：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理解，编程能力，性能，UI，接口，前端，后端等方面的要求会更高，当然也要求有能力写出自动化测试用例或测试工具。

2.4 软件测试和研发在五个方面的不同之处

• 1.目的不同
  -调试(Debug)：发现缺陷并处理缺陷，以确保程序做了程序员想让它完成的功能。
  -测试(Testing)：发现缺陷，验收缺陷，以确保程序解决了它该解决的问题。
• 2.参与角色不同

软件研发由开发人员完成。

**软件测试由测试人员和开发人员来协同执行，部分白盒测试由开发人员完成，剩余的白盒测试由测试人员完成；黑盒测试主要由测试人员完成，单元/集成测试主要是由开发人员完成。 **

• **3.人员执行。 **

**-调试由开发人员完成。 **

-测试由测试人员完成并将程序中发现的缺陷返回给开发人员处理。

• **4.执行的阶段不同 **

–测试贯穿整个软件开发的生命周期。（测试是在需求阶段就开始了，介入时间是比开发更早的。）

**-调试一般在开发阶段完成。 **

• 5.方法

调试：debug，打印错误日志，打断点…

测试：黑盒测试，白盒测试，UI测试，性能测试，接口测试…

三、优秀的测试人员所具备的素质

3.1 综合能力（非技术方面）

1、沟通能力
2、 快速学习能力（对不同业务需求和功能的快速学习与理解能力， 对于测试新技术和新方法的学习能力。)
3、 团队合作力
4、 文字表达能力 5、抗压力（ 责任感是任何工作的都需要的，对于测试工作者而言： 测试往往是产品质量的最后个把关者；由于测试工作成效很难衡量，测试用例执行、bug数目的多少都
无法说明产品的质量是否合格；所以，责任感是最重要的测试必备素质之一。 ）
6、 责任感
7、 探索性思维 ( 探索性思维是指，测试工程师在执行测试的过程中不断学习被测系统，结合自己的经验，知识，直觉， 进行系统的错误猜测和逻辑推理，整理和分析出更多有针对性的的测试关注点。 ）

3.2 掌握自动化测试技术（技术方面）

1、 优秀的测试用例设计能力（软件测试的依据是软件测试用例） 测试用例设计能力是指，无论对于什么类型的测试，都能够设计出高效地发现缺陷，保证产品质量的优 秀测试用例。
2、 编程能力：掌握自动化测试技术（掌握自动化测试技术可以从大量重复性的手工劳动中解放出来，然后把更多的精力花在更多类型的测试上。）

3.3 如何提高测试用例设计的能力？

1、掌握设计测试用例的方法
2、积累，总结
3、阅读好的测试用例设计案例

四、什么是需求？

衡量软件测试结果的依据—需求

4.1 需求的概念

软件需求是
：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。这个文档叫做软件规格说明书prd
(1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
软件需求是一种反映上面(1)或(2)所述条件或权能的文档说明。
它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求
> 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成 的任务。该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

4.2 为什么要有需求？

需求是对软件功能的规范，是开发人员的一个标准，也是测试人员编写测试用例的一个依据。
大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据
就是软件需求，这也就是说软件需求是测试人员进行测试工作的基本依据。

4.3 软件测试用例的流程

需求是测试人员开展软件测试工作的依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出
每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
即：业务需求—>软件功能需求点—>测试需求点—>测试用例 。

4.4为什么需求对软件测试人员如此重要

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

4.5 如何才可以深入理解被测试软件的需求

1.积极参与需求评审会议，了解清楚软件的诞生背景，软件的需求，预期收益，未来软件发展的规划等。
2.积极参与技术评审会议，了解研发围绕技术开展的需求。
3.测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

4.仔细阅读相关需求文档，技术文档，bug库等。
深入理解需求的目的是：写出较为完善的测试用例。

4.6 测试用例的包含要素 /bug的提交流程

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

4.7 为什么要有测试用例？

1.测试用例是测试人员执行测试的依据；
2.测试用例可以降低测试工作的冗余度；
3.测试用例也是执行自动化的依据。
测试用例解决了两大问题：测什么，怎么测。

4.8 手机打电话测试用例

显示区域：
1.不输入任何数据，不显示任何内容。
2.输入信息过长，数字会逐渐变小。
3.输入信息过短，数字会变大。 … 键盘区域：
1.输入正确的电话号码拨打电话，电话可以拨打成功;
2.输入错误的电话号码拨打电话，电话不能拨打成功；
3.不输入任何信息拨打电话，无法拨打电话；
4.输入正确的电话号码拨打电话，对方长时间不接听，电话会被自动挂断。

五、什么是bug？

当且仅当规格说明是存在的并且正确，程序与规格说明之间的 不匹配才是错误。 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

六、开发模型(流程)和测试模型(流程)

6.1 开发模型和测试模型的概念

随着软件工程学科的发展，软件工作的范围也不再局限于程序编 写，而是扩展到了整个软件生命周期。
如：软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。
软件工程还包括很多技术性的管理工作，例如在过程管理、产品管理、资源管理和质量管理等方面逐步建立起标准或规范。

6.2 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。
软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。

6.3 每个阶段的工作

1.需求分析：需要的需求，需求的正确性，产品经理产生需求文档。
2.计划：开发开始时间，开发结束时间，测试开始时间，测试结束时间。开发人员与测试人员。
3.设计：UI/UE设计师将需求转换成图（UI视觉图）；技术人员产出技术设计文档。
4.编码：编写代码实现软件。
5.测试：执行测试用例，验收bug，并产出测试报告。
6.运行维护：上线。如果上线后项目有Bug，也需要解决bug后再重新上线。

64 瀑布模型（Waterfall Model）

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次，因此是线性顺序进行的软件开发模式**。 优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。 缺点：
–依赖于早期进行的 唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
–风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到缺陷。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶
段的工作大面积返工。
在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

6.5 螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代 表之一。
该模型的特点是：软件没进入到下一个阶段时，都会进行风险分析。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的
要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重 要性就不言而喻了。 •优点：
–强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下去，可以避免一些问题出现在线上。 •缺点：
–引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。因为一旦风险分析错误，就会将问题暴露到线上。

6.6增量、迭代

:::tips

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。 增
量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量和迭代的区别：增量是逐块建造的概念，而迭代是反复求精的概念。

6.7 敏捷

6.7.1 敏捷宣言（敏捷思想）

6.7.2 scrum

6.7.2.1 scrum里面的重要角色

crum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。 其中product
owner负责整理user story(用户故事/需求)，定义其商业价值，对其进行排序，制定发布 计划，对产品负责。 scrum
master 负责召开各种会议，协调项目，为研发团队服务。 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4
周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交 付。

6.7.2.2 scrum的基本流程

(1)product backlog：产品负责人负责整理user story，形成product backlog（需求池）。
发布计划会议：product owner负责讲解user story，对其进行估算和排序.
(2)发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责人，并完成工时的初估计。
(3)每日例会（daily scrum meeing）：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
(4)演示会议：迭代结束之后，在发布前召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
(5)回顾会议：项目上线之后，项目团队对本期迭代进行总结，发现不足。如果有新的合理需求，经过产品经理审核放入需求池内，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

6.8 软件测试v模型

6.8.1 背景

V模型最早是由Paul Rook在20世纪80年代后期提出的，目的是改进软件开发的效率和效果。是瀑布
模型的变种，明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间的工作。

6.8.2 介绍

用户需求：产品经理po将用户需求进行收集，形成软件规格说明书prd。
需求分析与系统设计：分析需求的可行性与正确性；架构设计。
概要设计：设计框架。
详细设计：每个模块如何具体实现。
编码：编写代码实现需求。
单元测试：每个class和方法的测试。
集成测试：方法与方法之间的调用。
单元和集成测试应检测程序的执行是否满足软件设计的要求；
系统测试：将项目全部运行起来，进行黑盒测试。
系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
验收测试：由客户或者产品经理，运营验收，测试人员辅助验收。
验收测试确定软件的实现是否满足用户需要或合同的要求。

6.8.3 缺陷

测试介入时间太晚，仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试 ，出现问题需要层层回溯，会大大浪费时间与人力资源。

6.9 软件测试W模型

6.9.1 W模型背景

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分
别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

6.9.2 W模型特点

测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。

6.9.3 W模型优点

有利于尽早地全面的发现问题。 例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

6.9.4 W模型的局限性

需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，
上一阶段完全结束，才可正式开始下一个阶段工作。无法拥抱变化，这也就意味着W模型无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

七、软件测试的生命周期

7.1 软件测试的生命周期（重）

• 软件测试的生命周期：需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

• 需求分析：测试人员了解需求、对需求进行分解，得出测试需求。判断用户的需求是否合理，是否可以实现。

• 测试计划：计划项目的测试人员组成，测试的开始时间，结束时间，上线时间。根据需求编写测试计划/测试方案

• 测试设计：测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例 。

• 测试开发：开发可以支持测试，提供测试效率的测试工具。计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。

• 测试执行：执行测试用例，目的是发现bug，验收bug。 测试评估：根据测试用例和计划执行测试，在执行的过程中

• 记录、管理缺陷，测试完成后编写测试报告。

7.2 测试报告

抄送人：项目相关人（测试领导，产品领导，研发领导） 收件人：项目直接相关人（开发，产品）
内容：测试项目名称；仓库地址；项目直接人员；测试用例链接；bug；产品规格说明书；技术文档。

八、如何描述一个bug

8.1 bug的提交（重）

一个合格的bug描述应该包括以下几个部分：
1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于
统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是
app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现 最短 步骤。
4、预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需
求提出的故障，能写明需求的来源是最好的。
测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级
的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

8.2 如何定义bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。 1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）： 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他
功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）： 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4、Minor（次要）： 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。 如：错别字、界面格
式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
bug级别提交时，一定要有理有据。如果项目需要按时交付，但项目中还存在很多bug。这个时候需要先周知项目相关人，开发再改bug的时候，优先级较高的先修复，优先级较低的可以放到下一个版本迭代。

8.3 bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

8.4 BUG状态转换图

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。 ●
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。 ●
Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。 ● Rejected：如果认为不是Bug，则拒绝修改。 ●
Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
如果出现了Delay和Rejected 这种bug，QA一定要将这些bug告知给项目相关人，以及项目相关人的leader。
发送测试报告的时候也一定要指出Delay和Rejected这种bug。 ● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。 ●
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。 无效的bug：open->closed
open-rejected-closed

8.5 Bug的跟踪/状态变更应遵循的基本原则

1.测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同 的问题不再出现，才能关闭缺陷。
2.对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

8.6 如何开始第一次测试

1、阅读所有项目有关的文档，包括：需求文档、技术文档、用户手册 。
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务 专业性较强的项目。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式。 4、阅读已有的测试方案和测试案例 。
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则 。
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规 范等 。

8.7 需要与测试组长确认的具体工作内容

1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了

8.8 测试的执行和BUG管理

1. 将软件部署到服务器上
2. 打开待测试的系统
3. 打开测试管理工具用例模块，开始执行用例
4. 发现bug！进行复现并确认bug的复现步骤
5. 记录bug
6. 沟通bug
7. 验证以前提交的bug
8. 确认本次测试完成
9. 编写测试报告

8.9 如何发现更多的bug？

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度 和深度！
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强 他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维 4、不要局限于用例和需求文档 5、尽早介入项目, 不要等到开发的差不多了再介入项目

8.10 产生争执怎么办? （重点）

1、先检查自身，是否bug描述不清楚 。
2、站在用户角度考虑问题，应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员
更加积极地、高质量地修改Bug。
3、BUG定级要有理有据 。
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的
是有区别的，需站在用户的角度定考虑定位级别。
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案 。
5、开发人员不接受时，不要争吵。
6、发起Bug三方讨论会。
Bug评审要注意：缺陷的评审应该包括两个层面 ● 决定如何处理Bug。 ● 分析缺陷产生的原
因，找出预防的对策。
(1)决定如何处理Bug。 这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开
发代表、产品代表。
测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。
开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可
能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出
自己的意见。
2)分析缺陷产生的原因，找出预防的对策。 缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其
是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不
再出现。