问题单是版本测试过程中发现问题问题，也可以称作为bug、缺陷。提单是每一个测试人员必备技能之一。但是并不是所有的测试人员都会很好的完成这一项工作。当发现问题时如何提单、如何确保自己提单内容合理，可以减少与开发沟通工作量，甚至后续测试人员重新验证该同步单时可以直接从问题单中获取到有效信息。本文主要从问题单提单规范、提单内容规范和回归问题单内容规范这三个方面来描述。
问题单提单规范
1、提单正确性。当版本测试过程中，发现疑似问题时，需要自己分析问题根因。如果分析不出来，也需要找开发定位确认问题。不能将未经分析的问题直接提单。
2、提单及时性。发现问题时并确认已经是问题时，请及时提单。尽早提单也可以给开发留有足够的修改时间，也可以避免自己忙于手头工作时将之遗忘。
3、不要合并问题提单。尽量不要在一个问题单中合入多个问题。容易造成开发漏改或者测试回归时遗漏。因为有可能不同的问题涉及多个开发，版本经理容易忽略转给某个开发。
4、问题单内容描述规范。通常会包括测试版本、所属特性或类别、发现阶段、问题定级、问题描述等。
问题单提单内容规范
每个公司都会有固定使用的问题单跟踪管理系统。通常问题单都会包括如下几块主要方面：
1、问题单简要描述。通常包括局点、特性、简要描述。
2、测试版本。包括业务包括、主要依赖的平台版本。
3、预置条件。用例涉及的主要参数或者特殊参数。
4、操作步骤。可复现操作的主要步骤即可。
5、预期结果。
6、实际结果。
7、问题初步分析。提单前需要对问题根因进行分析。如果分析不出，找开发协助。
8、问题相关截图、日志、消息等。为问题单分析提供依据。
问题单回归内容规范
当问题单修改走回测试回归时，测试需要将回归场景、过程结果提交到系统。问题单回归内容规范主要如下：
1、测试版本。版本号中带迭代版本。
2、测试思路。主要描述回归问题单的测试方案。
3、测试过程。将回归问题单验证的用例结果保存上传。
4、测试结论。回归验证通过、不通过、部分通过等。
5、其他。如果用例是自动化脚本用例，可以将脚本打包一并放置。如果该问题单需要在其他版本修改，可以方便获取。