对软件测试之路的思考

    第一家公司的软件产品已经进入系统测试，包括根据客户需求修改，以及去客户现场支持。测试问题的记录用EXCEL记录，偶尔写一些用例，最后由于版本发布人员离职我有开始学习版本发布，最后是版本发布兼测试，其中也学习到了一点知识，但是至今已经忘的差不多。中间做过一些性能测试，但是仅仅知识跑起来而已，并没有实际投入，也没有做系统瓶颈分析等，因为实在摸索中，所以最后也就放下了。

     第二家公司有专门的软件测试部门，每天的任务都是规定好的，拿到版本，执行用例，发现问题及时录入缺陷管理系统，缺陷管理系统是公司花钱的买的，测试用例很少写，在这边最要学会了对问题的分析，在开发与测试之间最好的方式，就是你能及时发现问题，并且根据工具或者经验来分析问题，以帮助开发快速定位问题。同时科室要求的总结，让对自己的学习的知识不断总结、归档。但是这个方法至今的模样保留下来，实在惭愧。离开公司虽然有诸多的不舍，但是更多的事情也容不得自己过多的忧郁。

    第三家公司，也是目前自己所在的公司，没有专门测试部门，我们当时这些测试也仅仅只是为项目而招的，期间刚开始使用的事QC来管理缺陷，后来由于一些原因中途弃用。之后一直使用VSTS自带的测试管理系统，从编写测试用例，到执行测试用例，提交问题，跟踪问题解决，由于甲方的需求不断变化，测试无法制定准入准出原则，往往之前定好的，在下一秒就改变，有时候做好的功能，随时都可能推到重来，因为要适应不同领导的喜好，但是下面把控的需求的人也不知道领导到底要个什么样的，当然测试也是紧跟其后，功能完成，就开始点点，有问题及时反馈，解决完继续测，有时候修改了没有测试直接就发布使用。因为甲方不停的催，甲方发现问题，就说测试是干什么吃的。没办法，只能低头挨批，下来再和开发沟通，我们也在不断尝试一些其他的测试策略来控制版本的发布，比如开发功能甲方签字、测试签字等，控制问题的可追溯，但是时间久了，源头的人不乐意，这样的方式也坚持没有多长时间，最后我们使用月中和月末集中版本发布，其余时间不进行版本发布，以此来控制频繁的版本发布，导致连续的质量问题。

     以上虽然懂得了很多的测试工作的一些策略、方法，但是感觉自己知识还是很零散，也许是项目或者本身一些小公司都存在的问题，在闲暇之余很想将测试的工作做一次总结，但是始终不知从何下手，感觉自己缺乏的太多。