我在2013年的工作融合中写了这篇文章。 在撰写本文时（2019年），它仍然有意义。
最初，我写下清单作为提醒，包括自己在内。 因为您必须返回任务，包括未检查任务的人员。 例如，在回归过程中，必须检查至少一个基本功能。
因此，您打开了任务，滚动到最后一条注释，以查看哪些文档，哪些有效以及该位置为空。 或谦虚的“一切都检查了，一切都很好”。 文档在哪里？ 我不是任务的主题，我想了解更多！
或者，如果客户写信说某件事对他不起作用，并且您想检查自检是否涵盖了这种情况。 您转到任务，并且没有指向自动测试的链接。 他们根本没有写东西吗？ 还是没有提供链接？ 我必须找出...
因此，出现了用于关闭任务的清单：
- 检查任务（帽盖）。 对典型任务使用现成的清单+避免自动测试中的典型错误。
- 在上面写文档（最小-用户，最大-用户和“同事”）。
- 在JIRA中，留下一条评论“我检查了装配核心***，客户***，查看了这个，那个和这里。”
- 如果手动检查了某些内容，则将测试数据附加到任务。
有点“关于我们”，但实际上是普遍的。 好吧，除非测试人员在您的公司中编写文档，否则我们将第二段更改为“检查是否已编写或更新了所有必要的文档”。
我们将分别分析每个项目。
该文件
如果没有该任务的文档（这是错误还是改进都没关系），则会重新发现它。
如果有文档，但是在JIRA中，最后一个注释中没有指向该文档的链接，则该任务将被重新发现。
（严峻的时期，严厉的措施）最低需要编写/纠正用户要求。
如果项目的配置中有更改，则需要检查是否存在有关此更改的技术文档。 如果不是，请写。
如果添加了迁移任务，请立即编写一般说明以更新发行版。
评注
如果您稍后必须返回该任务，有时找出测试仪测试的版本以及他检查的内容（简而言之）有时会很有用。
我们从mercurial编写版本，并提供文档链接和简要说明：我通过/ SOAP / buffer接口手动对其进行了检查。
测试数据
如果手动检查了任务，请确保将测试数据附加到任务上（如果它们不重3Tb）
是的，可以从共享存储库中获取此数据，但是在此它们已经可以更改甚至删除。
（我们有一个通用的测试数据存储库，但是所有文件都存储在磁盘上。我们在版本控制系统中进行了尝试，我不喜欢它，根本没有人提交，但是他们以某种方式将它们放在磁盘上）有时似乎这都是垃圾，他们创建了一个交易对手或通过视图收集了选择。
但是，如果半年后客户出现问题，并且提出了旧的播放任务，那么这些文件将起到很大的作用，而且已多次验证。 但是存储中的实际数据已经过时了。
请记住-需要1分钟才能进行就绪的sql查询并对照数据库进行检查。 再次坐下来提出此请求-可能需要一个小时，甚至更多。 节省您的时间！
因此：
- 通过dbStart-附件dbStart创建了一个数据库（excel，其中保存了要测试的数据库片段）。
- 我们从存储设备下载了测试数据-我们附加了下载的文件。
- 我们从其他地方下载了它们-将它们添加到存储库中并附加到任务。
另请参阅：如何在Maven中快速创建模板数据库？ -关于我们如何进行dbStart进行测试。
有关测试，文档和数据的评论应该是最终的。 与其说“我编写了这样的测试，发现了这样的问题”，然后与开发人员联系以征求20条评论，不如说，您的“最终”是在中间的某个地方迷路了。 如果您迷路了-重复（可以删除旧的）。
例子
当我们招募新的测试人员时，这篇文章还不够。 因为我重新发现了下级的任务，并告诉了如何修正最终评论，使之易于理解。 然后，他们又要求提供“如何做”的例子。
因此，在文章中出现了另一个方框-“示例”。 在工作中的jira中提供指向实际任务的链接以及其他一些融合的文章非常重要。 这些示例应该有所不同：对于在任务上进行200次自动测试时的巨大注释，以及对于伙计们每天将要面对的小任务，都是如此。
我不会提供链接，但是我希望含义很清楚。 该部分看起来像这样：有大量停靠和测试的大型任务示例：
- TEST-679-对JMS的改进
- TEST-760-将流返回到不同的JMS源
小任务的示例：
TEST-816-扩展了同意模型。
在测试“向演示添加功能”时，应特别注意重构-将文档提交给核心，演示中的所有测试，以及通过包含在内的其余部分，等等。 示例：
TEST-4519-将FL-IP的交叉对帐添加到演示中。
有用的示例示例“我如何测试”，然后再次返回（最好将其放入“ HOWTO”中，但应将其留在任务中）：
TEST-812-使索引的重建不阻塞（在哪里放置中断*以进行检查）
* Bryak：断点（s语）-代码断点。 这是在调试模式下运行源代码时，这些点有助于跟踪参数，定位错误。PS-在我的博客中查看其他测试文章