记录缺陷禅道

禅道

一、软件缺陷的基本概念

缺陷分为四个

一级致命二级严重三级一般四级建议

软件缺陷管理的目的

对各个阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准，主要实现以下目标：
（1）保证信息的一致性；
（2）保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效；
（3）收集缺陷数据并进行数据分析，作为缺陷度量的依据。

软件缺陷管理工具--禅道

软件缺陷管理的相关角色

（1）软件开发人员；
（2）软件测试人员；
（3）软件测试项目经理；
（4）软件开发项目经理

禅道登陆

http://47.100.175.62/zentao/company-browse.html

二、软件缺陷的内容

1、缺陷标题内容

2、描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测试软件的运行环境
3、简单概括的描述清楚软件出现异常时，测试人员的操作步骤和使用数据；
4、缺陷原因的分析；比如说：因为不支持字符集，而导致的乱码...等等。
5、要写清楚，重复操作了多少次，这个bug依然出现。（不能操作一次就提交bug,因为有可能是自己操作失误。）
6、相关附件：为了让开发人员更好的了解Bug。（如果从界面上可以反映出软件的异常，可以截取界面，粘贴在问题单上）；

三、缺陷的类型

1、质量特性的角度

（1）功能；（2）性能；（3）安全性；（4）易用性；（5）可靠性。
2、功能性角度
（1）错误（2）遗漏（3）多余的（4）可优化
3、缺陷产生的原因：
（1）需求不清晰，导致设计目标偏离客户端需求，从而引起功能或产品特征上的缺陷；
（2）对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误；
（3）新技术的应用，可能涉及技术或系统兼容的问题，事先没有考虑到；
（4）可能由于不支持字符集，而导致的乱码。

四、禅道使用

一个Bug正常应包括以下信息点

每个公司的不同项目对Bug应包括的信息点可能存在一些细小的差异，但大体思想是一致的，进入公司后按照公司的要求和模板书写便可。

Bug记录的正确范例

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

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

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

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

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

例2：某测试人员打开XYC邮箱的登录页面，输入错误的用户名和密码，随后单击“登录”按钮，此时系统无法登录，但系统也没有给出任何提示。很明显，这也是一个Bug。那测试人员应如何记录这个Bug呢？

其中对于Bug的优先级，相信初级软件测试人员都可以正确判断，提醒大家一点：设置处理Bug的优先级的目的是告诉开发人员处理此Bug的优先级别，以便开发人员合理地安排Bug修复工作。

例3：某测试人员打开XYC邮箱的登录页面，输入正确的用户名和密码后成功登录邮箱，然后单击“写信”按钮进入写信页面，测试人员准备在收件人地址栏中输入一个邮箱通讯录中已存在的邮件地址，但当测试人员输入该邮件地址的第一个字符时，发现系统并没有自动联想出以该字符开头的所有邮件地址。

分析：如果该需求文档并没有要求收件人地址栏要具备自动联想功能，那么此问题，测试人员就可以当作建议性问题提出来。测试人员应该如何记录这个建议性的Bug呢？

描述Bug的发生过程并记录相关数据，这对一名初级测试人而言并不是一件很困难的事情。初级软件测试人员在记录一个Bug时，应尽可能多地提供一些详细的信息和截图。本书所列的Bug示例也许并不是最好的，初级软件测试人员入职后应多参考其他同事曾提交过的Bug示例单，并学习其中的优点。

总之，提交清晰的Bug示例单是初级软件测试人员十分重要的一项工作，如果Bug示例单中的内容缺少关键步骤和具体数据等重要信息，这不仅给开发人员修复Bug带来难度，还有可能会被直接退回给测试人员并要求重新书写Bug示例单。

bug的基本处理流程

1、禅道里面缺陷处理的基本流程是：测试提交bug -> 开发解决bug ->测试验证bug ->测试关闭bug

2、如果bug验证没有通过，可以激活：测试提交bug ->开发解决bug -> 测试验证bug ->测试激活bug ->开发解决bug ->测试验证 -> 测试关闭。

3/还有一个流程就是bug关闭之后，又发生了。测试提交bug ->开发解决bug ->测试验证bug ->测试关闭bug ->测试激活bug ->开发解决bug ->测试验证-> 测试关闭。

使用禅道提出bug

在创建bug的时候，必填的字段是影响版本，所属迭代、bug标题，重现步骤、严重等级这些基本的信息。
所属模块，相关任务，需求可以忽略。

创建bug的时候，可以直接指派给某一个人员去处理。如果不清楚的话，可以保留为空。

开发人员解决bug

当一个bug指派给某一位研发人员之后，他可以来验证解决这个bug。

1. 通过各种标签和检索条件找到需要自己处理的bug

在对bug进行出来之前，需要先要找到需要自己处理的bug。禅道提供了各种各样的检索方式，比如指派给我，可以列出所有需要我处理的bug。

研发人员解决bug，选择解决方案，一般来讲有效的解决bug方案是“已解决”

测试人员关闭bug

当研发人员解决了bug之后，bug会重新指派到bug的创建者头上。这时候测试人员可以来验证这个bug是否已经修复。如果验证通过，则可以关闭该bug。

对Bug起争议时的处理

测试人员和开发人员因Bug起争议的事情常有发生，例如开发人员认为这不算是一个Bug，或认为这个Bug不重要，不需要修改，而测试人员认为这是一个很严重的Bug，需要开发人员修改，或因其他原因起了争议等。如果出现了这些情况，测试人员应如何处理呢？

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

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

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

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

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

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

五、求职问题

如何提交高质量的缺陷？

参考答案：

bug概要简洁，清晰，描述缺陷的要点，能够描述清楚是什么问题。
bug的具体描述，细节越详细越好，以及出错数据描述清楚。

可以加上对应的截图和日志。
所测试软件版本号以及测试环境，不同版本，不同环境可能会造成不同测试结果。

如果你发现了一个bug，但是这个bug之后再也无法重现，你会怎么办？

参考答案：

尽可能的保留截图，以及对应的日志，保留好测试现场。没有重现问题可能是没有触发引起此bug的某个点，所以作为测试人员我会想尽一切办法让这个bug重现。
如果实在无法重现，还是会提交bug给开发人员。如果有截图和日志，会一并提交。

如果开发人员要求重现，那么测试人员就需要后期继续观察，如果最终还是无法重现，会将此问题提交给测试经理。由测试经理和开发人员商定解决办法。虽然现在不能重现，但是不代表不会在用户哪里重现。

如果开发人员不修改你发现的bug，原因是因为修改的成本比较高，这个bug只是影响用户体验而已，你会怎么办？

参考答案：

我觉得影响用户得设计不是好的设计，任何影响用户体验的问题都是大问题，这个产品就不是一款好产品。

如果每个问题都因为成本高就不去修改的话，是无法持续提升产品的质量。

我觉得只要是问题，无论大小，测试人员都应该要求开发人员去修改，这是对产品负责，也是对用户负责。

六、Web测试和App测试有什么区别

1、系统架构方面：web项目，一般都是b/s架构，基于浏览器的。app项目，则是c/s的，必须要有客户端，用户需要安装客户端。web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。

2、性能方面:web页面主要会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些。它们服务端的性能没区别，都是一台服务器。

3、兼容方面：web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容。app测试则要看分辨率，屏幕尺寸，还要看设备系统。web测试是基于浏览器的所以不必考虑安装卸载。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件。此外APP还有一些专项测试：如网络、适配性等。

Web测试和APP测试相同点：1、设计测试用例时，依然都是依据边界值分析法、等价类划分等；2、多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；3、需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；4、测试页面载入和翻页的速度、登录时长、内存是否溢出等；5、测试应用系统的稳定性等。