工作项命名约定

发布于 2024-07-29 08:16:51 字数 1433 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

青瓷清茶倾城歌 2024-08-05 08:16:51

您的项目管理、错误跟踪和时间管理(如果与 pm 工具不同)应该遵循相同的模式,无论模式是什么。 我通常喜欢采用自上而下的方法:项目应用程序页面(例如:亚马逊订单输入确认页面) - 如果项目/任务管理、错误和时间管理都遵循相同的模式,那么您可以跟踪任务开放的问题很容易花费时间。 在该页面之后,您输入问题的简短描述性文本。 在描述区域中,您需要说明:

  • 环境(操作系统/浏览器)
  • 正在测试的
  • 版本服务器环境(开发、QA 或生产)
  • bug(屏幕截图有很大帮助)
  • 预期结果(您预期会发生什么)
  • 问题级别(对“有的很好但永远做不到”表示阻止)

Your project management, bug tracking and time management (if different from the pm tool) should follow the same pattern, no matter what the pattern is. I usually like to do a top down approach: project-application-page (for example: Amazon-Order Entry-Confirmation Page) - if the project/task management, bug and time management all follow the same pattern then you can track tasks to open issues to time spent easily. After the page you enter a short descriptive text of the issue. In the description area, you need to state:

  • environment (OS/browser)
  • version being tested
  • server environment (dev, QA, or production)
  • the bug (screen captures help greatly)
  • the expected results (what you expected to happen)
  • level of issue (show stopper to nice-to-have-but-will-never-get-done)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文