经常有测试人员吐槽或是反馈，明明辛辛苦苦编写好了详细的缺陷报告，但开发人员总是在项目沟通群里反复确认，或是直接拒绝。作为一句测试人员，当被质疑时是好的，但一定要从质疑声中反思，并寻找自己的问题点（包括自身能力与团队协作沟通的问题）那么这里就从测试人员最基本的技能之一-缺陷报告的编写来说起，如何写出让开发人员爱看的缺陷报告。
首先，不同公司对于缺陷报告的要求并不完全相同，有些是直接在缺陷管理工具中提交的，有些需要发布正式的缺陷报告文件（多见于外包公司），除了按照公司规定的格式及风格外，在缺陷的内容上是最可以体现出测试人员的专业水准的。
还是以下图中的缺陷规范框架为例说明，这里主要围绕在管理平台中提交缺陷报告来阐开说明~
缺陷管理平台以Teambition为例，缺陷的创建界面模板属性及缺陷工作流可以由管理员自定义配置。
缺陷标题
不能含有测试流程步骤和模块数据，不能有错别字，描述节点和失败结果时需要与系统中描述一致。同时不可有主观语气，整体以描述事实为基准。不可模糊描述，标题总字数控制在20字内
前置条件
前置条件需要明确地指出提交的Bug是在何种情况下发生的。如4G网络正常 ；已进入XX页面；...但如果是提交给第三方的缺陷报告，需要描述绝对路径
重现步骤
重现步骤需要清晰地分步来描述Bug问题，每步要用数字序号。对于特定数据产生的问题，要提供具体的测试数据。步骤之间要用组合连接符->，步骤描述中的模块不用带引号。同时步骤描述不能过长，语言精炼。步骤中不能含有结果。
测试结果
即实际结果，实际结果要精确描述按当前步骤产生的结果，不能有歧义 ，不要有模糊不确定的描述，如：有误、不正常、不准确等。直接描述结果值。
另外，预期结果要与实际结果相对应。
预期结果
按照复现测试步骤及需求文档的要求准确描述预期结果。同时预期结果必须是无歧义的，可以判定的。描述结果时不要含有步骤。
测试账号
测试时所使用的账号，如果使用了多个账号测试，则需要写清楚各个步骤的账号。
测试环境
常见的测试环境有本地环境，测试环境 ，预发布环境， 生产环境（正式），但一些特殊项目可能会涉及到不同系统包括外部依赖系统，则需要在不同环境切换测试时描述清楚 。Teambition支持下拉选择。
测试设备
附件
一般，常见的缺陷类型可大致分为三类，界面问题、功能问题、崩溃类问题。界面问题要上传问题截图，用红框标注出；功能问题需要上传操作视频（录制视频时，把当前的问题重现出即可，不要有不相关的操作）；崩溃问题需要上传视频及崩溃日志。同时附件的命名要与缺陷标题一致，不要随意编写，如11111、aaaaaaa 等，或是其他字符冗长的名称。
重现频率
发现问题后，要测试多次来判断是否必现，必现则填写重现频率为100%，非必现时，在执行多次后手动统计概率填写。切不可随意填写未经验证的概率 。
缺陷备注
可提供缺陷定位线索或错误日志输出，减少开发人员重新定位的时间。
执行者&参与人
执行者由测试人员提交问题时初步判断前后端问题，指给对应模块的开发负责人。Teambition中指派到某个执行者后，执行者可以在我的工作台中查看到。
缺陷的参与人可以直接继承关联需求的参与人，如果判断需要相关人知悉 ，则可以选择继承。
开始时间-结束时间
根据需求的完成时间来判断 ，指定当前缺陷的结束时间，给执行者一个时间期限。
归属项目
归属项目如果是在需求下直接关联创建缺陷，则所属项目是自动回写的，不需要手动填写。
缺陷状态
缺陷状态需要区分是否线上缺陷 ，或按照当前环境的缺陷工作流来提出。有些数据类缺陷提交后可以直接到测试状态 。
优先级&严重程度
根据当前缺陷由测试人员来界定，也需要参考当前的环境。严重程度级别与优先级别不一定总是成正比，需要结合实际情况来全面考虑。
缺陷类型
常见的缺陷类型如功能 ，需求，变更，性能，数据，兼容，界面，安全等等，便于项目结束后从不同维度评估整体系统质量及复盘失败。
迭代
一般如果主体需求已被规划到某个迭代中，则默认其关联的缺陷也规划入该迭代中。
公开模式
又分为公开模式和隐私模式，如果选择公开模式，则项目组成员均可查看到，如果选择隐私模式，则只有该缺陷的参与人可见。
以上即是Teambition中关于缺陷报告的所有常用信息，项目管理员可以根据项目场景来自定义缺陷的必填项及增删不同的字段。缺陷基础信息是必须完整填写的，缺陷的附加信息可以视情况来填写，但如果需要完整统计或是高层要求，特别是周期较长的项目，需要在统计中有不同维度的分布，则以上缺陷的附加信息需要保证完整及准确性。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
