在现在的公司从事软件测试已一年半时间了，从单独的测试部门，到测试与工程部门合并，再到测试与研发部门合并，测试一直都在被否认。
作为一名测试人员，多少会认为这都归咎于：众人都认为“发到现场的程序质量高是研发的功劳，而出了问题则都是测试的不足。”
但总结一下，测试团队确实存在很多问题，主要在于：
1、没能保证质量
2、没有积累、总结和共享
没能保证质量：
我记得我刚进公司的时候，现场升级倒回的次数并不多，而渐渐的，倒回的次数已经引起很多领导的关注。这中间有产品设计的问题，测试的问题也有工程实施的问题，没有人能说的清。公司最后的结论当然最主要的问题还是测试问题。我们想辩解，也无从辩解。因为这些导致现场倒回或影响用户使用的问题，测试中确实遗漏了。
对于这一点我也不知道为什么，也不知道该怎么改进，有种想突破却找不到方向的感觉。唯一能想到的就是明确测试范围，将更多的精力放在bug较多的功能，现在系统的功能已经像滚雪球一样，越滚越多，每次测试功能全部覆盖这是不可能的。但是如何明确测试内容，这就需要经验的积累和不断的总结（这句话和废话差不多）。究竟如何明确测试内容？？
另一个同事说的很有道理，我们的测试用例太概论，一个测试用例可能包含了多个功能点。这样就导致虽然测试用例上写着通过，但是最后现场还是可能有问题。这样的测试用例需要细化，尽管这样也许测试用例从原来的100变成了200个，但起码我们可以保证我们测试过的那100个用例没有问题，而不像现在这样现场升级风险完全无法评估。
没有积累、总结和共享
首先，新功能的使用方法没有文档记录，其他人使用时查看相应的手册，总是各个模块说一点，最后还是需要问测试过此版本的人。随着新功能的不断增加，没有一个人可以确定所有功能的使用方法。
测试中遇到的问题，解决的思路和方法没有记录，没有共享，总是有很多人为同一个问题耽误很长时间。
对测试方法、测试用例的改进和完善没有积累和共享，比如，增加对应功能的码流，备注功能点出现bug的TD号，写明各功能点需进行的配置等。
其次，现场出现的问题没有总结，现场问题中那些测试遗漏的，应及时补充到测试用例中。
最后，测试质量没有总结，每个季度，甚至每个周，测试的质量是否在提高。比如本月发布了几个版本，几个版本现场升级了，升级后是否出现问题，哪些问题测试遗漏了，都需要拿来总结，并从中吸取教训，而我们现在就是无视那些教训。
在总结的过程中发现那些能够提高测试质量的方法，也不断验证哪些方法是无用的。让大家有一个共同的目标，那就是改进这个月的数据。也让公司其他的部门和领导看到测试人员的进步，测试团队的改进。而不是现在这样辩解都没得辩解。
写了这么多，从我自身的角度来说，在过去的时间里我因为承担了很多繁琐并烦心的工作而没有好好做测试，而因为重新分部门，那些工作我已经交出去了，虽然在那些工作中我收获很多在测试中无法收获的东西，但我依然很高兴，我可以专心做测试了。所以说这是个新的开始。
总是写过无数的计划，而没有真正执行完成的。所以在接下来的团队以及工作情况还不是很明确的情况下，我未来的计划就是在测试工作中做点值得自己肯定的成绩出来，哪怕能够总结到一堆行不通的方法也可以。
版权声明：本文出自 bisheng.880719 的51Testing软件测试博客：http://www.51testing.com/?363238
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
