目录
测试规范化通常跟测试团队的方法训练同步进行，也可以在方法训练基本完成之后。
测试规范的两个好处，一是保证测试团队产出稳定的质量，二是通过对规范的共识，减少各方的沟通成本。这两点是很多人都忽视的地方。想象一下这样的场景，测试团队写出的缺陷，开发，产品或者项目经理去看，发现各种风格的写法，各种漏洞，或者不严谨的地方，或者无法重现，或者无法理解需要当面沟通。这是令人沮丧而且滑稽的事：这个缺陷有很多缺陷。
1 缺陷规范
缺陷格式有一个最佳实践，能熟练运用的组织，可以自行裁剪以适合自己的业务。但是呢，有太多组织对缺陷格式没有达成共识，甚至组织内的测试人员都对它不了解。前两章说的人员和测试方法的运用可以看作软实力，需要通过时间慢慢训练，但是统一缺陷规范，是可以在立竿见影的。如果没有达成共识，就将对组织跨职能协作造成障碍。
一个缺陷，主要属性包含标题，步骤，期望结果，实际结果，截图，指派人，等级，备注；其他属性包括：发现版本，紧急程度，环境，附件等。下面将逐个分析缺陷的主要属性。
1.1 标题 Title 必填
标题规范：通常只回答两个问题就足够了：在哪里(Where)，什么东西有问题(What)。
千万不要把标题写得又臭又长，包含步骤，包含奇怪的符号，包含多个Where都是非常典型的错误。当多个地方出现类似的问题时，就写一个地方，其他的写备注里。
1.2 步骤 Steps 必填
步骤规范：1动词开头(点击，左滑/右滑，下拉/上拉，拖动/放开，ZoomIn/ZoomOut等)，2动作原子化，3连续操作合并(比如step1：点击菜单1，step2：点击菜单2，step3：点击按钮。可以合并成step1：点击菜单1-菜单2-按钮)。
太多太多测试喜欢乱写步骤，还有一些是偷懒，这跟第一章的人员关系很大，需要踏踏实实一个萝卜一个坑的心态。也许按标准格式写会比随便写两句话要更耗时间，但是比起开发费力读bug，猜意思，甚至需要跟测试当面确认的时间比起来，其实是划得来的。
1.3 期望结果 Expected Result 必填
期望结果规范：回答两个问题：什么东西(What)，应该怎样(Should Be)。如果有多个期望结果，就分1,2,3点列出。
如果测试对期望结果拿不准的话，一定得先确认，哪怕要麻烦很多人。对期望结果的错误判断，就会引起By Design或者Not a Defect的bug，bug被标记成这种状态是很没面子的。
1.4 实际结果 Actual Result 必填
实际结果如果有多个，就分1,2,3点列出。
1.5 截图 选填，指派人 必填，等级 必填
缺陷等级规范
其实缺陷等级并不是一个急需的东西，只是在没有对等级定义达成共识之前，就尽量把缺陷都提到同一级，省得产生不必要的麻烦，其实开发内心对bug的等级还是很在意的。我在测试岗的时候，会有一个缺陷等级定义表，规定一共有几个等级，每个等级的定义，当然总体来说不算规定，只是一个大家约定而成的建议。
缺陷生命周期
缺陷生命周期
其中比较敏感的状态是Rejected，开发人员必须有正当的理由标记Rejected，通常是以下原因：By Design，Not a Defect，Duplicate，Not Repro，Won’t Fix等。
case规范
当然前面讲过，测试用例管理成本高，见效慢，如果企业规模达不到，或者产品级别达不到，或者管理水平达不到，就不建议搞。
关于case，这里有个误解，一些测试人员做了excel表，表头包括编号(甚至不包括)，标题，内容等，认为那就是case，PM也觉得那是case。这里的关键是要看内容是不是包含完整步骤，如果包含12345步，每一步分别点什么，输入什么，那么没问题那是case；如果内容只是一些文字说明，把对应的情况列出来，那么这种东西根本不是测试用例，只能算是等价类划分表。
一旦错误地把等价类划分表认为是测试用例，它会极大限制你对其他测试方法的选择，这是很糟糕的错误：你永远都在用等价类的形式去设计，沟通和评审。决策表，因果图，场景法都有各自最适合的情景，但都被无形地放弃了。想象你说“出门钓鱼”和“出门钓武昌鱼”的区别。
测试用例规范，如果要做，就是一个比较有意思的事情。因为它的规范，跟bug规范几乎一模一样，主要属性包含标题，步骤，期望结果，状态，指派人，备注；可以看到，跟bug规范比起来，就是把“实际结果”换成了“状态”。
测试用例的状态包含：No Run：未执行，Pass：执行通过，Fail：执行失败，Block：因故阻塞，N/A：无需执行。
通常来说，Block是敏感状态，需要增加备注的，比如是因为另一个bug导致这个case无法执行，就备注那个bug的编号。N/A是指在这轮测试里这条case根本不用走。比如case是测试拖拉机在载重情况下的发动机动力情况，而当前产品是轿车，就可以标记NA了。
看起来讲到case规范似乎很简单，但背后做支撑的，其实是case库管理，需求管理，产品测试生命期管理等，随便拿一个都是对投入和管理水平有要求的东西。
case与bug的转换
在有case的情况下，其实就不需要单独写bug了。所以没明白那些有case的组织，走完一条case，如果失败了又要写一条bug是什么逻辑。通常来说，case设计好之后，执行的过程应该类似下面：
网友评论