Questions tagged «issue-tracking»

根据组织的需要，跟踪问题的管理和维护过程列表。

3
如何处理似乎已修复的错误？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 4年前关闭。 我是内部系统的Web应用程序开发人员。用户报告存在错误。 错误是某些单词无法显示。该报告包含一个截屏，清楚地显示了该错误。但是该报告已经发布了将近一个月，并且该错误无法再在我们的生产环境中复制。 我应该如何回复客户和用户？
7
偶尔发生错误，但优先级高
我正在从事一个CNC（计算机数控）项目，该项目借助激光将形状切割成金属。 现在我的问题是，有时（每20天奇数次要1-2次）切割是否出错，取决于设置的是什么。 但这会造成损失，因此客户对此并不满意。 我试图找出原因 包括日志文件 调试 重复相同的环境。 但不会重复。 暂停并继续操作将再次使其平稳运行，而不会再次出现该错误。 我该如何解决这个问题？我应该将其声明为硬件问题吗？
6
如何确定“代码改进”的优先级和严重性？
我们的错误跟踪系统中有“优先级”和“严重性”字段。我们将严重性定义为“它如何影响用户”，将优先级定义为“它如何影响产品”。 我的问题是关于如何按照严重性和优先级对“代码改进”任务进行分类。假设改进不会改变任何行为，而是使其成为“更好的代码”。我们预计总体上将获得长期的维护改进，但是很难量化。 当我们将定义用于优先级和严重性时，除非您在图片中引入一些难以预测的长期收益，否则代码改进将使这两个值均达到最低值。因此，这意味着代码改进是一项艰巨的任务，切勿尝试。 但是，我认为不断改进和重构代码至关重要，因为： 软件开发本身就是一个持续的学习过程，如果不对代码进行改进，就无法做得更好。 团队应该为自己的代码感到自豪。 未来的维护将花费更少的时间，从长远来看，节省的费用将是可观的。 还是您认为不应创建此类任务，而只能在“按需”，“与错误关联时”执行此类改进？即使它与错误相关联，这也不是代码审查的讨论重点，例如“为什么您要在结构上进行如此大的改变？”。
6
您如何处理“在某些时候”要解决的不断增长的问题？
我们正在使用JIRA来跟踪软件项目中的问题。我们注意到的一个效果是，我们经常会创建一个新问题，但是根本不知道何时/是否要解决该问题。因此，我们发明了一个伪造的“遥远的未来”里程碑，将其分配给这些问题。 碰巧的是，分配给该里程碑的一堆问题一直在不断增长，因此这似乎不是一个好方法。到现在为止，它们太多了，以至于要审查它们的有效性成为了很多工作。由于与您相关的组件已被删除，因此其中一些变得无效。其中一些被其他问题重复。其中一些描述的措辞很差，以至于没有人真正知道它们的含义了。 其他软件开发团队如何处理有效的问题，但这些问题可能随时都无法解决。您是否会麻烦录制它们？您是否将它们分配给下一个计划的版本，然后在下一个发行版本临近时再次查看它们？还有吗
3
如何影响开发人员的错误优先级并相应地加以对待？
我们正在执行一个错误流程。 我们有3个错误级别： P1错误：阻止用户工作的错误。他们必须当场解决。 P2错误：有影响但用户可以使用的错误 P3错误：不会影响用户并可以在其中工作的错误。 P1是强制性的，必须当场处理。但是对于P2和P3，我们将根据具体情况进行判断。 我们拥有3个级别，因此团队倾向于根据客户的要求进行更紧迫的新开发，而不必处理P2和P3，这几乎很紧急。 问题如下： 我是否应该添加另一个优先级，例如拥有P4？ 我是否还应该像本周一样为他们指定处理非紧急票证的目标，当不分配编码任务时，您应至少处理1个P2？ 当前，我们没有像我上面提出的目标，但是我担心的是给他们这样的目标可能是残酷的。可以确定的是，我需要与他们讨论目标，团队喜欢参与讨论，尤其是在设定目标时。 更新： 我从相似性的角度提出了这个问题。但是，它根本不相似。 我的问题是如何让人们处理错误，而又不施加严格的议程却仍要解决它。因此，不，所隐含的问题对我没有帮助。不过还是谢谢你
12
您将如何主张不使用共享电子表格来跟踪错误/问题？
在我们公司中，开发人员希望使用适当的错误跟踪工具来管理应用程序中的问题。但是，管理层坚持使用共享电子表格（以前是共享的excel文件，现在是基于Web的解决方案上的电子表格，允许并发访问）。 他们的观点是，电子表格可以使他们对项目状态有一个更高级的了解，因为他们可以快速浏览一下打开了多少个错误。这也使他们能够看到谁在处理每个错误，并估计关闭它们所需的时间（因为开发人员需要填写他们正在处理的错误的时间估计）。 如您所知，这对于开发人员来说实际上并不实际（错误跟踪软件的发明是有原因的）。那么，我该如何倡导错误跟踪软件来简化开发人员的工作呢？ 作为奖励，您建议使用哪种软件可以让管理层从高层次的角度获得他们的反馈（打开的漏洞数量，正在研究的漏洞，时间估计）？
4
如何对漏洞严重性进行分类以补充我们的优先级分类？
在我目前的工作中，我们有低，中，高优先级的错误。 低优先级错误是不会停止发货或对任何用户造成实际麻烦的小错误。 中优先级错误会导致一些内部用户麻烦，但有已知的解决方法。 高优先级错误是客户会看到的问题，可能会损坏数据或使系统崩溃。 如何对漏洞严重性进行分类以补充我们的优先级分类？
4
如何处理我认为已修复的错误，但我不确定
有些错误很难重现，很少发生，而且似乎是随机的。可能会发生，我找到了可能的原因，进行了修复，测试了程序，并且无法重现该错误。但是，由于不可能可靠地重现该错误并且它很少发生，因此如何在Bugtracker中指出呢？常见的做法是什么？ 如果我将设置status为固定，并将设置solution为固定，则意味着完全固定了，不是吗？ 是否通常将“ status固定”和“ solution打开” 设置为向测试人员表明“它可能是固定的，但需要更多注意以确保”？ 编辑：大多数（如果不是全部）错误跟踪程序都具有两个用于错误状态的属性，也许名称不相同。通过status我的意思是新的，分配，固定，封闭等，并通过solution我的意思是开放的（新），固定的，无法解决的，不可重复的，重复的，而不是一个错误，等等。
3
使用错误跟踪/问题跟踪软件来讨论设计问题，新工具等
是否有人有使用bugzilla / mantis或JIRA之类的bug跟踪/问题跟踪软件的经验，不仅可以解决bug或任务，而且可以发起并维护最终导致决策的讨论？ 例如，开发人员认为应废除所有受保护的字段，并使用访问它们的受保护方法更改为私有字段。这不是他的电话，他想讨论。通常，他在下一次开发人员会议上提出要点，然后在会议上做出决定。相反，我的想法是让他提出某种“决定”类型的问题并描述他的意图，就像通常描述一个错误或任务一样。 其他开发人员可以根据自己的意愿发表评论，最后，该问题以“已接受”或“被拒绝”结束。 我从中看到的优势： 异步通信：当他们还没有时间监督上述决定的所有后果时，没有人会被迫在会议上发表自己的意见。 导致决定的考虑因素的书面记录。如果后来有人再次提出这个问题，可以向他提出。 可以建立与其他问题的关系，例如可以将一项任务跟踪到一个决策。 与版本控制软件（例如提交）的集成可以追溯到决策。 缺点： 金锤味浓：通常使用问题跟踪软件来跟踪可操作的项目 组织的开销可能不成比例：与人之间无需进行简短的非正式演讲，就必须以书面形式交流自己的想法
5
缺陷状态：“无法修复”与“已取消”
我曾经作为测试人员或开发人员参与过多个项目。在许多项目中，存在以下缺陷状态： 不会修复 取消 您是否使用这些状态，并且您如何区分它们？我问，因为大多数人无法解释差异。我的理解是： 不会解决 -开发者将无法修复的缺陷，因为它不是一个缺陷; 已取消 -由于优先级最低，因此不应修复缺陷
5
如何向开发人员报告错误？程序员寻求受过错误报告的教育
我希望获得有关如何对公司的其他部门进行有关如何提交正确的错误报告的教育的提示和建议。目前，我们获得的门票如下： 当我单击此链接时，我得到一个404。（它们包括404s的页面，而不是导致它的页面） 有时右列会流入按钮列。（无屏幕截图或其他信息） 更改xxx似乎正常。（EOM） 有没有人有一个错误提交过程/表单来指导用户提交尽可能多的信息？
6
管理异常的错误日志记录的最佳方法是什么？
介绍 如果网站或系统上发生错误，则将其记录下来并向用户显示带有错误代码的礼貌消息当然是有用的。 而且，如果您有许多系统，则不希望散布这些信息-最好有一个集中的位置。 在最简单的级别上，所需要做的就是增加ID和错误详细信息的序列化转储。（可能的“集中位置”是电子邮件收件箱。） 另一方面，也许是一个完全规范化的数据库，该数据库还允许您按下按钮并查看每天的错误图，或者确定系统X上最常见的错误类型是服务器A是否拥有更多的数据库。服务器B的连接错误，等等。 我在这里指的是通过远程系统记录代码级错误/异常- 而不是 “基于人的”问题跟踪，例如使用Jira，Trac等进行的跟踪。 问题 我正在寻找使用过这种系统的开发人员的想法，特别是关于以下方面的想法： 您不能没有哪些基本功能？ 真正节省您时间的功能有什么好处？ 哪些功能似乎是个好主意，但实际上没有用吗？ 例如，我想说一个“显示重复项”功能很重要，它可以识别多次出现的错误（而不必担心可能会有所不同的“不重要”细节）。 用于“在[Jira / etc]中为此错误创建问题”的按钮听起来像是节省了时间。 再次重申一下，我所追求的是使用过此类系统的人们的实践经验，最好是对功能令人敬畏/可怕的原因进行备份。 （无论如何，如果要进行理论化，至少要这样标出答案。）
3
是否适合将已知问题直接放入软件中？
我已经接管了一个Android应用的维护工作，虽然有一些残留的问题或多或少已经得到解决，但是由于Android操作系统版本不同，仍然存在一些问题。 例如，使用MediaPlayer类发送Web请求时，操作系统发出请求之前剥离了自定义HTTP标头，但仅在Android 4.X（我经过详尽测试）上，这导致该特定功能失败，因为它依赖在这些标题上。 这是一个已知问题，我正在尝试解决，但是有条件的检查是一个好主意，例如 if (OS.VERSION == 4) { knownIssueDialog(This feature will not work on your Android version... etc."); } 显然，我们会在支持渠道上对此进行说明，但我想知道将这些已知问题也嵌入到软件中并在必要时，必要时进行展示是否是一个好主意（假设一切都已被跟踪）例如我上面所描述的。 基于此类问题，我们不断收到许多不良评论和大量支持电子邮件，因此在我看来，仅阻止已知无法正常工作的功能，它将为每个人节省大量时间和头痛。 我看到两个潜在的问题： 用户以前可能从未见过类似“已知问题”对话框的内容。很多用户可能根本不明白这意味着什么。 有一些开发开销-需要确保在代码中的某些地方跟踪这些问题。幸运的是，有了Java批注，诸如此类的条件检查可以在其之前@KnownIssue或类似的东西进行，这使得查找/修改它们非常简单。 在软件中添加“已知问题”提示是否有意义？ 编辑：我将添加一个大约一个星期前才开始出现的问题。我已经修复了该问题的一半，并且不太可能能够为4.X修复此问题，因为导致问题的是操作系统。我可以发布包含此修复程序的新版本，并使50％的用户群再次满意，并警告其他50％（4.X用户）该问题将继续存在于4.X上，并提出升级建议（或其他建议） ）。问题是是否要在软件中执行此操作（即向4.X用户显示对话框），还是只让他们向我们发送垃圾邮件，我们将通过电子邮件支持“您的修复无效！”的电子邮件！然后将他们定向到支持页面，其中将详细讨论该问题。
4
在提交消息中引用错误/问题是否被视为良好做法？
我正在一个项目中，在该项目中我们设置了源代码控制，可以在Bug跟踪器中自动编写注释。我们只需在提交消息中写入错误问题ID，然后将提交消息作为注释添加到错误跟踪器。 我只能看到这种做法的一些弊端。如果将来某个时候源代码与错误跟踪软件分离（或者报告的错误/问题以某种方式丢失）。或者，当某人正在查看提交历史记录但无法访问我们的错误跟踪器时。 我的问题是在提交消息中包含错误/问题引用是否被认为是一种好习惯？还有其他缺点吗？
8
您将哪种在线/托管的错误跟踪工具用于自己的工作和项目？[关闭]
按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 这些年来，我已经积累了很多辅助项目，随着时间的推移，我会逐渐改进它们。每当我回到原处时，我都会花一些时间阅读文本文件，这些文件包括设计，最新的错误，下一步的功能等，我应该进行研究-这并不漂亮。 我希望改用更正式的方式。理想情况下，这将是一个功能全面的在线错误跟踪系统，该系统可以为我自己的项目提供免费或几乎免费的错误跟踪。而且，理想情况下，这可以以私下方式进行-我真的不希望每个人都看到我的副项目以及我对其中的一些项目造成的混乱。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.