我的测试经历，一起分享了

进入测试行业也两个多月了，在这两个多月中，不说掌握，但是可以是一个了解测试的人了。现在来说说我至今的测试旅程吧！献丑了。

一直看到有很多朋友在论坛中问测试怎么做，这个答案真的很难回答，我刚开始接触测试时，只是看了一本软件测试的书籍，当时看完后只是知道测试的流程，和一些简单介绍，也摸不着头脑，也在论坛里问一些得不到答案的问题。记得那时候刚拿到公司项目需求的时候，面对着八十多页的需求文档不知如何下手，于是便去问别人要怎么来看，我要做些什么，记得别人给我的回复基本都是好羡慕你哦，有这么长的需求看.也有一些人给出过简单的意见，当时真的是纳闷，我看的头都大了，还羡慕我。而且在我看完两遍需求文档后，都不是很理解。在参加需求评审会议时，常常是问题最少的一个，有时候一个会议一两个小时下来，我都没有吱声！呵呵，后来才渐渐明白到需求的详细给我后期写用例提供了多大的帮助，而且后来也发现需求中有很明白的地方，只怪自己当时没有理解这个需求，不然对后期设计用例的思维肯定有更多的帮助。现在是要好好感谢那八十多页的文档啊！！

现在我的第一个项目还正在测试中（项目比较大），在测试过程中，他们也给我提了不少建议，在他们给我建议的同时也觉得自己还有很多的不足，真是受益匪浅啊.发现要学习的东西真的很多。51Testing软件测试网$N
M
C sL:_{+Hu

那天在msn上和一个也做测试的朋友聊天，聊天中发现对于我们这些进入测试行业不久的人来说，当一个模块和其他模块的关联多起来，就会觉得设计用例起来特别的头疼，相信很多朋友都有和我一样的经历吧！？

不过现在我还没有什么技巧性的答案来帮助解决这个问题，我想对于这种情况我们不仅仅需要那些靠实践积累的经验，而且需要主动积极的去思考，对，一定要先把脑筋动起来，根据需求考虑这个功能的大概结构，当搞不清时，可以和开发人员去沟通，相信从与别人一起的探讨中，会把其中的逻辑理的比较清楚一些，而且会发现原本想不通的问题，一下子明白了，呵呵，这就是沟通妙处！！经验需要时间，需要实践，但是我们现在一定要先思考起来，沟通起来，一定不要犯懒哦！虽然能够一次性写出覆盖所有功能点及路径的人少之又少，不过我们还需努力，不断完善我们的用例。51Testing软件测试网 SP q4B/l5f
ZM

说一下个人的看法，测试的过程，如果有一个整体的规范流程，会大大提高测试的质量和效率。回归测试是一个高负荷的测试，需要有足够的耐性去对待，我们常常觉得用手工做回归测试很烦，不过还是得注重起来，听说WR是一个不错的回归测试工具，但我还没有用过，要学习啊。设计用例固然是一个很重要的环节，不过认为bug的整个管理流程，以及做好对bug的分析是最为重要的环节（不过这些正是难点）。51Testing软件测试网)k6mS.?6U.FyC?

0B~Y\ cw0希望有更好意见的朋友给我提供一些意见哦！51Testing软件测试网*D)b%~!IM&J3`

|%N9E,C8x9H5XO3s| j0