转眼间，离毕业就有半年的时间了，从今年的五月中旬进入公司，我的第一份工作手机软件测试也有半年的历史了。总觉得应该记录一些什么东西，记录工作的状况，也记录现在的心态，更是记录还尚未成熟的想法，也许再过半年回来看看，可以对比一下半年后的自己与现在的自己的区别。再过半年后，是喜是悲，就看自己接下来的努力与否了。
测试工作做什么
所在公司是做手机软件产品的，以敏捷形式半个月更新一次产品，所以我所做的工作就是负责产品上线之前没有存在各种各样的bug。一般一个项目2、3个测试成员，其中一个为主要负责人员，负责整个项目的测试管理。那整个流程是怎样的呢？
一、需求确认会
会上你可以从测试角度提出建议以及其他测试角度的问题。需求确认会也只能讲个大概，具体细节在会上面是没法考虑全面的，所以在私下（一般是在我们进一步了解需求以及准备编写测试用例的时候）还要与产品和开发再次确认，但是由于是三方面的沟通，一开始往往很容易发生其中两方确认了该需求点，但是另外一方理解有偏的情况，最后还要再去确认一遍。后来进行沟通之后，以及彼此都比较熟之后，就没有这种情况发生了。
二、测试用例
接下来就是在QC上面编写测试用例了，在编写用例的过程当中，还会发现一些需求不够完善的地方，这个时候还要去跟产品开发去讨论确认清楚。用例写完之后，负责人对组员的用例进行审核，审核过之后，测试组员再一起过一遍所有的用例，每个人所看待事物的方式角度都会有差异，所以集思广益，是对用例进行改进的一个最好的方式。
三、执行测试
用例完善的差不多了，开发那边的成果也差不多了，开始提交测试，一般一轮测试刚好一天的时间可以测完。在测试的过程当中，我自己一般是第一次根据测试用例来测，直到测试用例通过为止，接下来就可以进行自由测试了，自由测试不是说胡乱随便测，这个时候更要站在用户的角度去测试，以及站在自己作为专业测试的角度去测试。测试方法不固定，大家都可以总结出属于自己的一套好用的测试方法。
四、确认报表
我们的测试报表都是先以邮件的形式发给产品进行确认，确认完了之后，才在相关的bug管理系统建立问题，然后对自己建立的问题进行跟踪。
五、测试总结
差不多经过平均四、五轮的测试，基本没有问题就可以更新程序了。测试负责人需要对本次项目做一份测试报告，发给所有项目相关人员。测试小组还会组织开个总结会议，每个人都总结一下在本项目中自己任务完成的如何，在下一期项目当中需要做出什么改进，以及对测试过程中遇到的问题，同时可以提出自己的意见。
测试工作是乏味的
在入这个行业之前，就听业内相关人士说过，做软件测试工作是非常枯燥乏味的，在找工作面试的时候，面试官也频频问起到类似这种问题。的确，试想一下自己所做的一些事情确实挺乏味的，每天基本上对着手机进行纯粹性的手工测试，还需要编写很多相关的文档。对于一份新的需求，你要很深入的去吃透它，尤其在编写测试用例的时候，需求上简简单单的一句话，你要想尽各种有可能出现的情况，往往编写了一天测试用例下来，会觉得很累很辛苦。
在测试上面，就最近测试CBAS的时候感触更深，n多的页面，每个页面至少进去20次，需要获取这些操作的日志文件，每一轮测试持续一两个小时，不同的联网方式还要进行测试，又要在同一个机型上面测试。在做这种重复性的眼球运动，往往会造成眼睛的不适，这个时候是真正感觉测试是多么乏味的时候。
测试工作是有趣的
但对于我来说，总体感觉测试工作还是有比较多的乐趣的，自认为所在的公司测试流程上面还是比较规范的，虽然只要求进行功能测试，不需要深入的了解代码结构，但是纯手工的测试对于一个刚入门测试行业的我们是最最基础的测试方式，在测试之前，需要对产品的整个业务知识弄清楚，在这个层面上，你可以很自豪的说你比开发懂得多。
在平时的测试过程当中，当你发现一些比较深层次的bug，你会觉得特别有成就感，有些概率比较低的bug，只出现了一次，接下来怎么操作都无法重现，这个时候心里就有一种不甘心的感觉，一定要把它重现出来，因为他出现过就证明他存在，也一定能够再次重现，这种bug一旦再次被你重现出来步骤，就更会有成就感了，这种乐趣也许就只有从事测试工作的童鞋才能体会到吧。重现不出来的时候，也可以去问问开发有这种现象，他也会根据自己写的代码去思考这种情况，他的指点就更有利于你重现了。
