测试员的使命：为bug生，为bug死，为bug奋斗一辈子！
这话略有夸张，但毫无疑问，软件测试员的核心工作就是找出软件中的bug。包括小酋前面提到的需求分析、测试需求提取、测试用例设计等，都是为此服务。
何为bug？
这个不清楚？可以在小酋测试系列文章中开篇《小酋测试：演变中的软件测试》查看其详细定义。这里我们再简单回顾一下：
bug，中文释义：臭虫、小虫（所以，每个测试员都是“捉虫师”）。我们可以把它们看成是软件中的“虫子”。
bug（又叫软件缺陷），为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
通俗的讲，bug就是软件产品与用户需求（或预期）不符合之处，可以是问题、错误、故障或功能的缺陷等。
为什么会有bug呢？
小酋总结起来有以下几点：
需求人员需求收集的不完整，与用户期望存在偏差；
需求人员与项目其他成员间（开发、设计、测试等）存在理解性偏差，导致产品 部分不合预期；
设计人员因需求理解存在偏差，个人喜好、审美差异等，导致设计与用户期望存在偏差；
开发人员编码实现中，因对需求理解存在偏差，以及自身无意间引入的错误，导致部分功能实现不合预期；
引入第三方组件，及运行软件所依赖的设备、系统、底层服务等存在差异，破坏软件正常运行。
从上面五点不难看出，bug出现防不胜防，我们要做的就是从上面五方面针对性的进行规范与控制。
思考下：测试人员在以上五方面具体能做什么？
小酋认为大家或多或少都有自己的看法，这里暂不作答。关注“小酋测试”系列文章后，大家应有更清晰的答案。
bug分类
bug分类因公司、项目而异。
通常类型包括：功能、样式、功能建议、UI建议、性能、安全、需求、设计、文字描述、易用性和配置错误等等。
bug分类的主要作用：
- 便于项目决策者做出bug修复策略（如“优先修复功能、安全和需求bug，其他放缓”这样的策略）；
- 测试活动是否退出，软件是否发版的依据之一；
- 根据项目各类型bug的统计，以及结合其它bug维度统计分析，找出质量的薄弱环节，为后面产品质量改进提供数据支撑；
bug严重等级
bug严重等级，即bug的严重程度。不同的公司、组织有不同的等级划分，小酋主要用过4级、5级划分，甚至看到有分为7个等级的。
小酋推荐划分为5个等级，这是10年时小酋团队经历CMMI3认证时，咨询顾问给出的建议：阻塞级（blocker）、严重（critical）、较严重（major）、一般（Normal）和轻微（Trivial）。
不管分为几级，都必须对每个等级有着清晰、明确的定义，测试员不能因为个人观感、喜好随意定级，这样不利于后续bug分析，也失去了bug严重程度等级划分的意义，也避免了开发与测试间因bug定级意见不合而 互相伤害。
那具体从哪些维度去衡量bug等级呢？
小酋的做法是，从bug的破坏性（功能、数据），是否涉及“钱”，需求实现程度，使用体验等四方面进行划分定级。
下面来一个具体例子：
bug优先级
bug优先级，即bug修复的先后次序。同样，不同公司、组织，乃至不同项目有不同的等级划分。至少划分为三个等级：高、中、低。
怎么衡量bug的优先级？
可以从以下几方面去考虑：
- bug的严重等级，如验收必须清零的bug优先级较高，允许遗留的bug优先级较低；
- bug修复的投入与产出，即单位时间投入较少、产出较大的优先级就应该较高；
- 根据项目决策者的要求确定bug优先级，如优先解决功能类型的bug，则功能bug优先级最高。
至于怎么定义每个等级，相信现在你心里有谱了。
如何记录bug？
bug记录的好不好，这是衡量一个测试员是否优秀的重要标准之一。
bug记录的好坏，直接影响其他人员对你的感官，具体来讲就是：是否专业。
其他能力突出，bug描述的一塌糊涂者众。那怎么记录好bug呢？
下面，我们来看bug记录的构成要素：
标题：bug摘要
内容：测试环境，测试浏览器/测试设备，测试数据，问题描述，复现步骤，期望结果，附件。
其他要素：指派人、bug归类、所属项目、所属模块、严重程度、优先级，等等。（通常在工具中作为选项填写）