zoukankan      html  css  js  c++  java
  • 如何写一个好的缺陷,大牛都是这样的做的

    缺陷管理

    缺陷管理是最开始也是最基础的测试必备技能。在工作了很多年后仍然会发现大量的测试人员没有办法合理的做好缺陷管理。
    在我眼中的缺陷管理包含以下几层概念:

    1. 缺陷的描述
    2. 缺陷的定义
    3. 缺陷的跟踪
    4. 缺陷的度量分析

    也许你觉得作为测试提一个缺陷很简单,但是要提一个好的缺陷其实是非常难的。在这里其实还有个隐藏的属性,叫做缺陷的概念,也就是说什么是缺陷?
    一般来说缺陷有两种情况,一个是违反了所谓的规则,还有一种是我们无法接受这样的情况。比如对于美来说,每一个人心目中都有一种对美的定义,你会觉得她很美,但是换个人来看待就未必。所谓的情人眼里出西施应该是指个人需求下的狭义定义。而大众情人就是那种所谓的约定俗成的广义规则。
    我们做一个软件面向的对象是不同的,甚至我们需要超出用户需求来做一点东西的,所以对于缺陷的判断成为了一个非常困难的事情,这里只能说对于缺陷这种东西,不要用肉眼去看要用心眼去看。

    缺陷的描述

    关于缺陷的描述,无非就是当别人看到你写了一堆关于这个缺陷的巴拉巴拉后,是不是明白了5w1h,然后能够根据你的建议开始进行缺陷的修改。本质上有一点就是缺陷的描述就像议论文,一定要有说服力。如果你写出来的东西都不能让别人觉得有道理,你又怎么让别人愿意按照你的逻辑去修改这个缺陷呢。
    为了方便把缺陷写的更容易理解,所以现在无论是Excel的记录方式还是使用系统的记录方式,我们都会将一个缺陷分割为很多个属性,来便于管理和理解,常见的属性包括:
    标题,详细说明,版本,环境,发现人,发现时间,修复人,修复时间,修复说明,状态,严重级别,优先级别等。
    本着不浪费笔墨和浪费阅读者理解的前提下,缺陷应该是写的越简单越说明问题是最好的。但是在我遇到的大多数情况下,作为小白写出来的缺陷往往是无法阅读和理解的,因为小白总会觉得自己写出来的东西别人肯定看得懂,而忽略了很多背景或者参考的说明,常见的问题无非是:
    我的xx功能出错了;点击某个按钮无效果;无法启动软件等。
    包括在各个QQ群的提问,也经常会出现这样的无头无脑,毫无内涵的提问,让别人完全无法回答。甚至常常让我想当你在工作几年后开始学习自动化或者性能测试的时候,连一个问题或者缺陷都无法合理明确的描述出来,你做自动化和性能测试能靠谱么?能解决问题么?
    但是写好一个缺陷又不是简单看几个例子就行的,它需要时间和足够多的练习才能做到,让别人看了会明白what、why、where、when、who以及how,甚至还能明白什么是对的,并且应该做成什么样。
    如果想要提升自己的缺陷描述能力最简单的方法就是学会吐槽,而且要吐槽吐的到位,那么你就能在生活中反复的锻炼如何使用最精简的语句来说明问题的关键,而不是总在问题的外围徘徊;而同样命中靶心的另外一个要素就是你能从本质知道这个问题的“身世”,就像你手中的一个小骰子,只能有这样几种结果。
    等你能够通过吐槽收集能量让你的呆毛蹦起的时候,你就能完成让别人俯首称臣,乖乖改你的BUG了。

    缺陷的定义

    在这里缺陷的定义主要是指如何判断缺陷的严重级别和优先级别,而不是这个问题是一个建议还是一个缺陷?请注意我用了建议和缺陷来区分问题的两种情况。这和前面说到的有类似之处到底你确定了这是一个问题,还是你觉得这样可能不太合理。
    当一个问题被提出,该问题必须要让别人非常明确的看出它到底会带来什么后果,需要在什么样的时间内修复,这样才能有效的让别人重视它。看过蝴蝶效应的朋友应该知道,一个问题如果被轻视,那么随着放大后其结果可能是非常严重的,也许只是一个很小的疏忽或者不重视。
    对于提交缺陷的我们来说,需要有能力去评估一个问题的优先级(是不是应该立即修复)和严重级别(它会带来什么样的后果),而优先级和严重级别之间又不是完全强联系也并非完全没有联系。
    或许大家对优先级和严重等级的概念会混淆,觉得有点模糊。一般大家会觉得严重等级高的BUG,优先等级一定为高。但这仅是一个包含于的关系,会存在这样一种情况严重等级低(或许只是小的界面问题,例如图片在页面的位置不精确),但优先等级高。或许这样说比较抽象。那么我们来举个例子,INTEL 对于企业LOGO 的精确度要求很高,因为这代表了企业形象。所以有关于LOGO 的相关BUG对于系统的严重等级为低,但优先等级都是高的。 缺陷的属性与你所属的行业以及公司文化也是息息相关的。
    当没有经验的时候,或者你无法知道该问题是否在关键路径以及影响的后果时,问问有经验的人是比较好的方式。而这也是测试人员的一个基本功,能够分清楚轻重缓急。

    缺陷的跟踪

    可能大家对缺陷的跟踪相对来说比较熟悉,因为基本上如果工作了都在使用缺陷系统,不断处理着缺陷的生存周期(new,fix,reopen,close等等),缺陷生存周期的目的是为了方便我们跟踪一个缺陷的不同状态,判断其所在的阶段。
    而在不同公司,不同的流程下,该流程也不尽相同,合适自己公司的才是最好的。好比缺陷跟踪就像是快递跟踪一样,以前我们发一封邮件,完全不知道对方什么时候收到,现在这封邮件到哪里了,而现在我们可以非常方面的在网站上随时查询得到该快递所在的具体位置及签收过程。
    那么对于小白来说首先要理解缺陷跟踪及状态的原理,进一步还要能配置管理这样的系统,帮助公司完成这样的管理工作。
    缺陷的度量分析
    在有了好的缺陷描述,好的定义和跟踪后,那么基本上缺陷已经可以很好的在某个系统内运转起来了,接着我们要做的事情说得好听点就是大数据分析了。从这些项目数据中,我们要分析出一些藏在数据后的规律,比较常见的包含:

    1. 常见缺陷导致的原因
    2. 常见缺陷被修复的时间
    3. 系统每天新增或修复的缺陷数
    4. 缺陷的收敛情况

    这些数据可以有效的帮助我们看出一些以前看不出的问题,但是这个在中国效果并不明显,因为我们的数据进入就存在不少的国情,而在分析及结果处理上也存在着相应的国情,所以一般公司在做度量分析的时候,往往是越做效果越差,吃力不讨好。但是不得不说不能因为它效果不好而不做它,如何正确的采集、分析数据,需要一些时间和团队成熟度后,才能发挥其效果的。
    对于缺陷管理这次我提的内容会比较概念点,因为缺陷本身的例子外面很容易查找到,而大家也会有一些自己比较成熟的看法,让我想起如何拍一张好照片的问题了,答案是啥呢?
    如果你想拍一张好照片,请先拍1000张照片,选最好的哪一张作为参考!
    如果你想写一个好缺陷,请先写1000个缺陷,选最好的哪个缺陷作为参考吧!

    结语

    跟大家推荐一个学习资料分享群:747981058,里面大牛已经为我们整理好了许多的学习资料,有自动化,接口,性能等等的学习资料!人生是一个逆水行舟的过程,不进则退,咱们一起加油吧!

  • 相关阅读:
    LeetCode(111) Minimum Depth of Binary Tree
    LeetCode(108) Convert Sorted Array to Binary Search Tree
    LeetCode(106) Construct Binary Tree from Inorder and Postorder Traversal
    LeetCode(105) Construct Binary Tree from Preorder and Inorder Traversal
    LeetCode(99) Recover Binary Search Tree
    【Android】通过经纬度查询城市信息
    【Android】自定义View
    【OpenStack Cinder】Cinder安装时遇到的一些坑
    【积淀】半夜突然有点想法
    【Android】 HttpClient 发送REST请求
  • 原文地址:https://www.cnblogs.com/nanaheidebk/p/10018663.html
Copyright © 2011-2022 走看看