版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/baidu_37964071/article/details/82290045
测试与调试的区别
- 目的不同–测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题
- 参与角色不同–测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成
- 执行的阶段不同–测试贯穿整个软件开发生命周期，调试一般在开发阶段
测试人员应该具备的素质
- 逆向思维。相当于开发盖房子，测试拆房子
案例：手机中有两条通话记录，进行删除。删除为0后，继续删除。 - 发散性思维：探求多项答案
案例：测试一台自动售票机。正向，逆向，边界，压力，性能，耗电量，断电，外观，没零钱….. - 对测试感兴趣
- 性格特征，有好奇心，成就感，敏感，不浮躁 ，善于怀疑，有批判性思维
- 能力，快速学习能力，沟通能力，文字能力，开发能力
- 责任感和承受压力的能力
责任感：测试往往是产品的最后一个检验者；测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以，责任感是最重要的测试必备素质之一。
压力：来自开发人员、用户、上级、自己的压力。
一个合格的bug描述应当包括：
- 发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量 - 问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。 - 错误重现的步骤
描述问题重现的最短步骤。 - 预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。 - 错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。 - 其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
注意：不要把多个bug放到一起。在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
产生争执怎么办（处理人际关系）
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
- 先检查自身，是否bug描述不清楚
如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后， 好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。 - 站在用户角度考虑问题。应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
- BUG定级要有理有据
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度考虑定位级别。 - 提高自身的技术和业务水平。不光要提出问题, 最好也能提出解决方案或思路，这样才能更让人信服。
- 开发人员不接受时，不要争吵
可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。
Bug评审要注意的问题：缺陷的评审应该包括以下两个层面，决定如何处理Bug和分析缺陷产生的原因，找出预防的对策
解释：
- 决定如何处理Bug。
这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。
（1）测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
（2）开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
（3）产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。 - 分析缺陷产生的原因，找出预防的对策。
缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复 出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。 例如：有些 Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的Bug的游戏。
禅道是什么
- 禅道项目管理软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程，是第一款国产的开源项目管理软件。
- 禅道项目管理软件的主要管理思想是基于敏捷项目管理方式——Scrum。
禅道在遵循其管理方式基础上，又融入了国内研发现状的很多需求， 比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。 - 禅道还首次创造性的将产品、项目、测试这三者的概念明确分开，产品人员、开发团队、测试人员，这三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品