bug的状态的管理流程

（1）bug的状态：
		       一般有：
			         ①新增（new 和 Active ）
					 ②处理中（in progress）
					 ③已修正（fixed）
					 ④重新打开（reopened）
					 ⑤关闭（close）
		(2)bug的流程
		    ①测试人员发现bug,提交。bug的状态为new;
			②开发人员接收bug，bug状态为in progress
			③开发人员修改完毕，提交，bug状态改为fixed
			④测试人员针对开发人员做的修改，再次对bug进行测试，如果bug依然存在，就把bug状态为
			reopened,流程到第二步重新开始，如果问题已经解决，就直接改为close,给bug的流程就做完了。
	   (3)值得注意的地方：
	       ①bug信息不全：
		       有的信息，比如项目，模块，指定处理人（也就是指派给谁处理）等，这些信息会用来作为统计分析，
			   那个项目，那个模块，谁的bug多，谁发现的bug多等，根据这些信息可以大致看出一个人的工作量和
			   工作质量。所以不要嫌麻烦，把bug的信息写全一些。
		   ②所提供的信息不准确：
		        有的bug描述一带而过，表述含糊不清，只是说出了 错误，但是错误的现象是什么，提示信息是什么。
				怎么操作才出现的，都不清楚，这样的bug交给开发人员，智慧给开发人员智慧给开发人员增加
				负担，因为他自己还有再做测试，以发现更多的信息，去排除bug，或者他会到测试那边讨论，询问详情，
				有时要多次反馈才能确定到底是什么问题。
		  ③开发人员关闭bug"
		     只有bug的提交人（也就是发现人）才能去关闭bug,开发人员只能使用两个状态：“处理中”和“已修改”。
		  ④：bug的可重现性：
		      这个重要的属性是在bug管理软件中无法体现和度量的，这个任务主要是在测试这边，如果你发现
			  一个bug，赶紧把开发人员叫过来，人家来了，你要给他看看这个bug,可是却怎么也出现不了，
			  连自己都不知道这个bug是怎样操作后才出现的，这样不能重现的bug几乎就不能算作bug,也是最让人头痛的问题，
			  那么作为测试人员，你的任务就是要尽可能的找到bug出现的规律，尝试各种可能，即使不能重现，起码
			  也要让开发人员知道你作了哪些尝试，而他不必再去走弯路。