找到bug以后如何做呢？

What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:

• Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
• Bug identifier (number, ID, etc.)
• Current bug status (e.g., 'Released for Retest', 'New', etc.)
• The application name or identifier and version
• The function, module, feature, object, screen, etc. where the bug occurred
• Environment specifics, system, platform, relevant hardware specifics
• Test case name/number/identifier
• One-line bug description
• Full bug description
• Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
• Names and/or descriptions of file/data/messages/etc. used in test
• File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
• Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
• Was the bug reproducible?
• Tester name
• Test date
• Bug reporting date
• Name of developer/group/organization the problem is assigned to
• Description of problem cause
• Description of fix
• Code section/file/module/class/method that was fixed
• Date of fix
• Application version that contains the fix
• Tester responsible for retest
• Retest date
• Retest results
• Regression testing requirements
• Tester responsible for regression tests
• Regression testing results
• 
  应该通知和分配buf给能够修复它的开发人员。问题被修复后，需要重新进行测试，并依据需求规格判断修复bug没有引起其它问题。假如使用缺陷跟踪系统，会包含这些过程。有很多商业化的缺陷跟踪/软件配置管理工具可供使用。下面列出了缺陷跟踪过程的项目：
  1、开发人员能够理解bug的所有信息，bug的严重程度以及如何重现bug；
  2、bug标识（数字、ID等）；
  3、bug的当前状态（例如：复测版本，新bug等）；
  4、应用程序名称和标识、版本号；
  5、测试环境描述、系统、平台以及相关的硬件信息；
  6、测试用例名称/版本/标识;
  7、简要的bug描述；
  8、bug的详细信息；
  9、如果bug不是被特定的测试用例发现的或者开发人员不容易访问测试用例/测试脚本/测试工具，则需要描述产生bug的步骤；
  10、测试中使用的文件/数据/信息等的名称和/或描述；
  11、文件引用/错误信息/日志文件/截屏/测试工具的日志等信息能够有助于找到产生问题的原因；
  12、严重级别（例如使用5级，从1-5为，通常使用“严重的”到“低的”划分）；
  13、bug是被再次发现的吗；
  14、测试人员姓名；
  15、测试日期；
  16、bug报告日期；
  17、bug涉及到开发人员姓名、组、部门；
  18、描述如何产生bug的；
  19、修复的代码段/文件/模块/类/方法；
  20、修复的日期；
  21、包含修复bug的应用程序版本；
  22、测试人员负责复测；
  23、复测日期；
  24、复测结果；
  25、需求规格回归测试；
  26、测试人员负责回归测试；
  27、回归测试结果。