测试小故事17：这个BUG该报吗？

 作为测试人员，常常遇到这样的问题，面对一个问题，有时会困惑于它是一个BUG，但自我感觉问题并不大或是不确认是否是个BUG，往往纠结于是否上报这个BUG。
  那么这样的BUG是否该上报呢？

 对于待测系统，测试人员有一条基本原则：不能漏报任何一个BUG。因此，宁可错报也不能漏报。
  新的问题又出现了，错报太多又会影响测试人员的生产率水平和工作效果评估。如何解决这样的问题？

 其时在一些组织的测试流程中，测试负责人除了跟踪进度外，还有一个重要的职责就是确认BUG。一方面确认已上报的BUG是否提交给开发人员修改，另一方面解决测试人员在BUG上报时存在的纠结与问题。
  这就给那些存在报与不报问题的BUG一个解决方法：寻求确认后再决定是否提交。

 面对BUG，是否上报大致可遵循以下原则
  1.有测试用例，有需求，二者一致未出现冲突或二义性。那么系统实现与之不符的则可以直接提交BUG。
   这也从一个方面说明了测试人员为什么要写测试用例。
  2.有测试用例，但需求实现细节不明确，有歧义。那么这样的BUG就需要与相关人员确认，如测试负责人、需求人员、设计人员、开发人员，最终确认是否是一个BUG。
   一些项目，特别是外包项目，各个环节配合本身并不紧密，有时处于异地，别说找相关人员确认，有时连对方是谁都不知道。这种情况下，就需要测试人员根据经验确认系统实现是否正确，也就是多思考一步。根据分析，如果确认直接提交BUG，如果不确定则以ISSUE形式反馈给相关开发方确认后再做决定。
   在确认是否提交BUG后，应及时更新测试用例，澄清事实，细化描述，以保证后期执行的效率。
  3.确认BUG上报的时机
   这个一直是存在异议的问题，原因在于这个BUG为什么不能提交？为什么要隐而不报？这里说说我的看法。
   目前常见的设计多为分层设计，常见的MVC也在其中，其原则就是尽可能的分离业务逻辑与业务实现及数据存储间的影响，实现高内聚低耦合。
   那和对于测试人员来讲，面对不同的测试阶段：单元、功能、集成、系统、验收发布等等，所要上报的BUG应有所测试。
   一个简单的例子，在功能测试阶段，前期应对于UI和页面布局BUG应当有所控制，保证开发和测试集中精力在功能实现上，而其它问题的优先级次之，可以放在功能测试末期或是在单独的UI测试中提出，以提高测试执行的针对性。
  4.理解BUG上报的目的
   测试人员为什么要报BUG？
   首先，测试人员的主要工作就是发现BUG、提交BUG、跟踪BUG，通过BUG的修得提升测试系统的质量。
   其次，测试人员提交BUG的目的是希望所提交的BUG能够被修改。如何才能提交BUG提交的命种率？一方面要加强对业务的学习，熟悉业务了则提交的BUG有据可依自然不会纠结；另一方面在描述BUG的时候，应当考虑到接受和修复BUG的人员的感受，注意BUG描述语言的准确性、简单性、可接受性和可信度，同时应注意BUG的分类和等级。通过BUG数据进行工作评估的不仅是测试人员，还有BUG的修复人员，小问题就不要因为个人喜好而提个高等级了。

  简言之，上报BUG只是动作不是目的，给出充足、合理的理由，让BUG接收者能够接受并最终修改，最终提升系统整体的质量才是测试人员的首要任务。

---------------------------------------------------------------------------------------------------------------------------

 吐吐槽：BUG的属性很多，数量、分类、等级、优先级。。。。。。但单纯以这些评价测试人员的工作，似乎有所偏颇，毕竟不同的测试模块、测试类型，所面临的测试难度也有所不同。如何更加客观公正的评价，是个需要认真思考的问题。