由软件测试bug状态转换想到的

　　上周四，不得不对客户新启用的bug管理工具Redmine中的bug状态进行验证。当然Redmine其实是一个项目管理工具，bug管理只是它的一部分功能而已。我在验证之前，是让一个经验不多的同事去验证的，主要是因为Redmine是客户的testmanager自定义了，我们发现之前的配置下某些状态下不能修改bug的状态了，或者说bug可选的状态不对。所有有必要在客户又重新调整后验证一下，是否符合我们一般的要求。同事的工作经验不多，估计又是忙着下班，着急的看了就画了个流程图，用邮件发给我且没有标题。收到以后，我自己也看了看，自己创建了一个testbug，发现流程图中出现的一个reopen状态，在现在的配置下根本就没有，我就不知道他是怎么画的了，我知道的是之前有reopen的，但最新的是没有的嘛。因此，我不得不重新研究。

　　说实话，我被气的够呛。如果简单的一个任务，作为测试每天都要接触的问题，怎么就不能研究好了，我自己也画了一个，发了邮件，发之前为了验证我画的流程图是不是，找了一个开发来帮我一起看看，让他看看在我不解释的情况下能不能理解。其实工作很简单，根据现有的配置，检查在各个状态下是否能流转到想要的状态去，不对的地方就提出来。为什么会做不好呢？同样一个任务，我和他做的效果就完全不一样。这个应该有那位同事去思考，而我却得到了一个新的面试题。

　　面试题：

　　1、请列出你说知道的bug的状态一般有哪些？

　　2、请根据你列出的状态，画出bug状态的转换流程图？

　　3、请根据上述的流程图，写出或列出对该流程图的用例

　　我觉得这是一个不错的面试题。第一个问题比较基础，但不容易答全了，bug的状态很多，并且各个公司对状态的定义可能会存在差别，但这种差别不影响回答这个问题。特别想提的是客户在bug状态中加了一个monitoring，我觉得很好，这是用来监控哪些不易产生，但有时常产生的bug，开发说改了，这样的bug测试人员就很纠结，验证的时候是没有出现，但这能代表问题真的修改好了。所以在一定时间内做监控，是有必要的。

　　第二个问题能考察应聘者的综合能力。是否仔细想过各状态之间转换的关系。是否能够将理解的内容转换成图形。是否有足够的耐心去做好事情。这基本和测试技能没什么关系，重点在其他基本素质。

　　第三个题目，考测试用例编写的思想。对于状态转换如何测试。这就是一个状态机的测试。也可以用场景法（路径法）测试。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/