昨天一个偶然的机会，临时充当了下软件测试的角色，体会很深！也让我对软件测试人员有了更多的了解和理解，并对自己（开发者）也提高了要求。

开发、测试不分家，心在一起，劲往一处用可以大大改变产品的质量。这个道理大家谁都明白，但是我们是做到了60分，还是90分呢？这是值得我们深思的！

情景1：

我拿到一个产品，让我测测，我首先根据自己的理解来测试这个产品，保证链接的正确，数据不敢保证，随着测试的逐渐深入，我发现，有些功能根本不知道是做什么用的。

感想：一个产品如果没有需求文档，算有使用文档，那又有何意义呢？

情景2：

我找到了需求文档，对里面的内容进行查看，多多少少还是帮助了我理解了这个产品的功能，但是好多页面展现，无从考究！例如一些展现的关系图，是根据什么绘出来的？箭头代表什么？等等等等！总之给我的感觉是功能依照使用手册会用了，但是不知道是用来做什么的！顿时你会想到，这些都是什么做什么用的？为什么文档没有写清楚？难道还要我逐条写下来，依依的问？

感想：情景2做到了60分，因为有了需求文档，但是这份需求文档，有跟没有差别不大，主要是解决了有、无问题。对于根本性的问题还是没有解决。

这时候想想我们自己做开发的时候，是不是以为这个很简单，我们组内都清楚，没有写在需求里呢？现在想想，开发觉得自己明白的东西，往往别人是不明白的！看来以后写文档的时候，我们需要转换一个角度来写这个文档。逐渐达到70分！

情景3：

找到开发问了这个功能，开发简述一遍，是简述哦！大体知道这个功能是干啥的了，也能看到展现，但是展现的对错与否，谁又知道呢？

感想：测试点很重要，我们的展现对错，是要考虑测试人员对这个系统的理解，如果我们能够在文档中，写清楚测试点，那么测试人员会更有依据来判断展现的内容是否正确了，如果做到这点，我相信应该可以打80分了！

情景4：

随着时间的推移，我烦躁了起来，感觉能用，不知道为什么用，每个功能都可用，但是如何串联在一起呢？看了产品的SPD，使用手册，没有对各个模块串联着用的一个概览，这让我和恼火，我当时心里只有一个想法，这咋测？没有需求评审吗？双方之前没沟通吗？

后来得知沟通过，需求是因为项目多，开发没时间，只是简略的说做了什么，没有说做到什么程度，什么效果！

感想：看来对需求的沟通事值得我们深思的，开会了、沟通了，依然没有解决问题。所以我觉得只要是会议，一定要双方达成一致，且一定要形成结论，不然那是扯淡！话糙理不糙！是这么个道理！

本以为这的时间是浪费了。其实不然，通过这的实际换位，真正的达到了换位思考的效果，理解了测试人员的苦衷，也了解了一些作为测试人员需要的是什么样的文档，需要的是开发怎么的配合。同时自己身为开发人员的我，觉得在今后的开发中，一定要落实文档，积极配合测试人员！当然开发人员也有苦衷！但是我们需要先从自身找原因，解决掉自身问题，也许很多难题会迎刃而解也说不定呢？