如何让tc和bug具备专业性

1． 为什么要进行TC和bug的规范和专业化？通过一些调研，发现大家的重视程度都一致，因为都身为测试员的缘故，测试用例是测试的指导文档，是保证产品的基本武器，同时也是测试人员的主要输入成果
2． TC的专业性体现
如何体现其系统性? 你的TC是否具备系统性
1. 写TC的作用是什么？—功能覆盖
2. 流程怎么产生？—测试设计—测试执行点—执行标准(TC)
3. 服务对象？—项目组成员
4. 应用对象？ —测试员
当我们拿到PRD拿到技术方案，测试人员就已经在考虑测试的设计，TC的设计，海量的TC和功能点，需要什么进行覆盖，如何进行统计？当然这些都是正确的，直观反应在TC上，TC是为了保证其PRD，产品功能测试覆盖完整，那么最早需要考虑的是TC的结构设计，为什么会产生服务对象和我列出服务对象可能想到这些方面的人确实很少，大家的第一直观就是TC只是测试人员执行测试的一共规范和工作统计，那么如何让项目组其他人员知道测试人员的工作？工作的全面性是否保证？测试质量的监督，同样需要开放的原则，所以会产生评审，意见补充等工作。
当你一个项目有上千个TC时，对于评审你是一个个进行TC评审时，内耗，长时间的细节呈现，那么评审的效果就大打折扣。那么TC的编写之前能做到归类和系统性思维进行TC的划分和编写，就是专业测试人员需要提高和注意的一种工作方式。
每个项目有不同的划分方式，不同的维度划分都是正确的划分，但能正确的进行汇总和区块化，同样也是专业TC必备的要素
如何体现其专业性
有其整体性，系统思维后，如何产生专业性的TC。
a) 根据测试概要，对各个验证点的前置条件、操作步骤、预期结果进行完善
b) 对于自动化测试，在测试用例细化时应提示相关的测试脚本文件。
c) 好的测试用例应该是具体完全的指导性，且无二义的
TC包含的内容说明：
a) 测试名称：直观反应用例的检查点
b) 测试用例优先级：一般在完成所有TC后，再进行后期填写和划分
c) 是否自动化：实现自动化要求的用例标记
d) 前置条件：说明卖家类型，或者买家类型，进行操作前的必备条件的说明
e) 步骤：描述进行执行所进行的操作顺序和操作条件
f) 预期：完成操作步骤后的预期现象
g) 实际：当出现实际结果和预期不一致时，填写实际的现象和结果
TC的执行和维护：
单独提出到专业性中，直接的测试人员在执行测试用例时
1． 根据测试步骤进行操作和比对，是测试质量的基本保证
2． 发散、灵活、探索性测试，是进行用例扩展和深入测试的意识和主动性保证
3． TC的维护和更新的直接执行者，在每次进行测试执行，直接进行部分用例的更新和修改备注，将保证用例的持续更新，主动的更新服务的将是全组的测试人员
如何编写TC：
大家想到的给出的答案基本都是，测试用例的粒度，测试点；校验点；是否方便做自动化测试和接口测试；编写TC的时候言简意赅，步骤按照执行顺序清晰明确，使用规范的符号和描述。测试用例要写得全面。
1. 编写测试用例的原则
a) 测试用例要达到最大覆盖软件系统的功能点。
b) 测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。
c) 应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受能力等
d) 测试用例的管理。使用测试用例管理系统对测试用例进行管理。
2. 如何编写测试用例
a) 产品相关信息
i. 软件产品或项目的名称
ii. 软件产品或项目的版本
iii. 功能模块名
iv. 功能描述
v. 测试平台
这些信息建议可以在测试案例手工选择。
b) 基本记录信息
i. 测试用例入库者
ii. 测试用例入库时间
iii. 测试用例更新者
iv. 测试用例更新时间
这些信息建议可以由测试案例自动生成
c) 测试用例的属性
i. 测试用例的ID（由案例管理系统自动生成，方便跟踪管理）
ii. 测试用例名称：测试用例的名称
iii. 测试功能点：测试的功能检查点
iv. 测试目的：该测试功能点的测试目的
v. 测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。
3. 测试用例的级别划分和类别划分就不进行详述

3． Bug的规范
a) 简要的说：bug的标题摘要需要具备的描述方式应该清晰，明了。
i. 在什么情况下
ii. 进行什么操作
iii. 产生什么现象
b) 如何让你的bug情景化
i. 在发现缺陷之后，只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug
ii. 花一些时间去诊断你正在报告的缺陷。想想可能存在的原因并尝试定位问题，可能到最后你会发现更多的缺陷。在你的bug report中说说你的分析。有助于提高开发的认可度和测试人员的专业程度
c) Bug的元素信息
i. 摘要：见a说明，一个好的摘要应该不超过50到60个字符。而且一个好的摘要不应该承载任何对bug主观的表达。
ii. 在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解
iii. 清楚的列出前提条件
iv. 有清晰的可重现的步骤，可重现步骤应该详尽
v. 备注说明：有页面或者特殊情况下，或者可重新几率不高的问题，尽量保证有截图和相关说明信息。也可在备注中进行问题分析和bug定位的缺陷引导
vi. 简化和剔除步骤：在一个干净的系统里测试你的“可重现的步骤”。你可能会发现有些步骤被遗漏或是毫无关系的，这样可以剔除部分不必要的说明步骤，也能避免步骤过多对于问题定位的干扰。
vii. 预期结果和实际结果，清晰描述现象即可
viii. 附件：截图和一些配置文件，需要进行附件的添加，方便开发进行定位缺陷和分析问题点
d) Bug的级别划分
i. Bug的严重性级别划分一般分为4类：严重、主要、次要、轻微
ii. 对应级别的对应问题的划分，可以见QC中对应级别功能的划分
iii. Bug的优先级别划分
1. 紧急（Urgent）缺陷必须被立即解决
2. 高级别（High）缺陷需要尽快处理
3. 正常（Medium）缺陷需要正常排队等待修复或列入软件发布清单
4. 不紧急（Low）缺陷可以在方便时被纠正，解决的优先级别不高

转载自 http://qa.taobao.com/?p=11627