测试工作对测试工程师要求太高？

　　微软的软件质量控制实践三篇写完了，收到很多评论。不可能一一回答，所以在这里我挑几个评论最多的和有代表性的，和大家再多讨论一下。希望有所帮助。

　　1. 对测试的要求太高了

　　在国内培训的时候经常遇到的一个说法：“(比如测试自动化，工具，流程)的确好处很多，但是它对测试的要求太高了”。刚开始的时候我很惊讶，第一次听到对测试要求太高的说法，后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后N年的话，我觉得“对测试的要求太高了“的观念就是导致这个落后的根本原因。我一直在观察和对比国内外测试的区别，当然有技术上的，工具上的，流程上的区别等等，但是这些差别都只是表象，根本的差别是观念上的差别，也就是测试在研发中的真正角色。这个不是找到多少个bug的问题，也不是采用什么测试方法的问题，而是是否把测试做为支撑研发两条腿中的一条腿的问题。测试是一个专门的职业，和开发一样有不同级别。初级人员解决简单的事情，高级人员必须负责解决复杂，高难度的事情。这样才能形成一个完善的测试人员职业发展体系。很多测试经理一直很困惑说我们也在加大在测试上的投资，参加很多技术、流程、管理培训，但是效果都不好。原因就是我们不能总是希望通过学习一个技术，或一个工具来解决观念上的问题，当然没有效果。也容易跟风，刚学会手工测试，又要测试自动化了;刚学会测试自动化;又要ET了。刚学会ET，又要敏捷了。没有观念就没有主见。所以改变观念才是提高软件质量的根本途径。

　　那么如何改变观念呢?我也不知道。公司老板不愿改变呢?我也没有办法。但是重要的是你知道问题所在了，这就是解决了最大的难题。如果自己都觉得测试没有难度，没有前途或者对测试要求太高了的话，如何指望得了别人?所以我们搞测试的人的一个重要职责就是：把这个观念灌输给其他人，把测试的门槛提高，对测试的要求没用很高只有更高，其它问题也都解决了。

　　2. Dev不愿意修改bug.

　　这是一个很多测试抱怨的问题：自己辛辛苦苦找到一个bug，开发却认为不是bug。或者更为令人气愤的是开发在没有沟通之前直接resolved as “by design” or “not repro”。这个情况通常在质量控制成熟度级别(1级或2级)较低的组出现较多。根本上解决的办法是提高整个组的成熟度级别，当然需要在很多方面加以提高，这个问题就随之而去了。可以使用以下几个策略：

　　首先这里牵涉到两个问题：一个是resolve as “not repro”的问题。很多时候dev resolve as ‘not repro’是因为bug本身不清楚没有足够的信息来判断或进一步investigate(当然他应该和你确认一下先)。所以测试在报bug是一定要记录足够信息。基本原则是当别人在看该bug是否有足够的信息来判断该bug是怎么回事或进一步investigate。我总结过一个好的bug描述应该是Concise,Accurate, Searchable, Entirety, 也就是 CASE 原则。可能你会觉得这需要太多的时间才能报一个bug了。的确是，但是总比你花了两天找到一个bug，花了10秒钟就把bug写完了，结果过两天dev resolve 成not repro强吧。另外就是自动报bug的工具，还有就是创建bug模板等都可以减少报bug的时间。

　　其次是’by design’的问题。很多时候测试不服气认为就是bug，但是开发不同意修改。我想借用一句话来说明我的观点：a good idea is not really good until it is accepted. 也就是说如果你不可以说服别人接受你的主意，再好的主意也没有用。同样的道理你认为的bug，如果不能说服别人，它也不是一个bug。或者bug只有在被修复时才是真正的bug。如果dev/test有分歧的话，通常PM负责一个功能，应该有PM做最后决定;如果没有PM的话，通常有整个team来决定。当然如果你非常肯定，可以继续找更多的理由来支持你的观点。但是最终如果还是不能说服别人的话，还是要服从team的决定，虽然我们常说真理往往掌握在少数人的手里，但是绝大多数时候都是少数人考虑不周。另外一点就是我们通常很少在是不是bug上有分歧，而是在什么时候修复上有分歧。这是另外一个话题了，需要考虑很多其它非技术因素了。

　　3. 如何做到自动报bug,并把相关的信息放到bug 里面.

　　我在comments里已经回答过了，就把它拷贝一下吧以是完整：我前面提到微软有很多工具来提高测试人员的工作效率，也就是说把时间花在需要专注的地方而不是在其他繁琐的地方浪费时间。其中一个好的实践就是自动报bug。其实整个过程比较直接：首先用来管理bug的工具应该会有API接口，所以可以使用工具来自动报bug。其次是添加分析处理工具，测试的出错信息比较容易获取，比如测试用例出错了，或者抛异常或者返回错误结果，可以容易地把异常信息或错误信息放到bug里面;分析产品的日志找到错误点有写难度，需要和dev共同努力把测试日志和产品日志通过某些属性(时间戳或操作id)关联起来。或者简单地把相关日志、windows event log,等拷贝到network share，在bug中指向该路径即可。还有对于UI测试，如果测试错误，一定要把当时的屏幕截图抓下来放到bug中去。还是那句话，专注于应该要专注的地方而不是把时间浪费在其它步骤上了，测试用例出错，不应该花太多时间去报bug (最多2分钟)。同样道理有了bug后dev可以直接去investigate，而不是花时间去找日志在那里?那里出错了?等等。有条件的产品组还可以进一步提高，比如工具自动报bug的时候可以到到数据库里根据异常或错误信息查找一遍看一看以前有没有类似的bug，或者做BI，这些信息对于将来的分析和决策非常有帮助，而且也可以帮助预防bug。

原文转自：http://www.ltesting.net