刚毕业时的第一份工作，是在一个私有企业，做的国家电网系统的软件公司工作，这里的开发模型是螺旋迭代式，以一个cs程序为主系统，接到不同项目后，在该系统的基础上不断的螺旋迭代上去，接入各种其他的bs、cs系统等，这里的测试方法主要是以计划——用例——执行——回归的顺序，反复执行，出差了解需求、和开发不断的进行交流，这样的测试工作了2年，这2年里我认为，测试策略中除了每个程序自身的功能测试外，很重要的一点就是各个接口的测试使bs、cs数据互通，测试过程中就必须不断增加多整个公司软件的熟悉了解程度。
第二份工作就相对来说简单点，是带着程序前往客户现场进行实施部署，根据客户需求做个性化的需求开发，主要程序和功能大部分都是公司内部里的技术团队和测试团队完成了，拿到手的软件版本都是比较稳定的了，所以在这样一个环境下，测试过程中主要就需要多与客户沟通，了解清楚他们到底要什么功能，让客户参与到程序的测试过程中，是否满足他们个性化的需求开发。
第三份工作是在央企下属的一个银行机构里做了，做的是同行拆借系统，这里的测试流程和制度就非常的完善、测试人数也很多分内部测试、第三方测试，典型的瀑布式开发模型，测试也是典型的瀑布式测试，前期制定测试计划、参加需求评审，制定测试策略、编写测试用例、用例评审、执行、回归测试等，在这一整个测试过程中，测试人数众多，也就有了更多的精力进行交叉测试，再这样的环境下，用例的编写规范性和要求就高许多了，必须能看明白小组全部人的测试用例，自己写的用例也能够让其他人能看明白。
现在这份工作，也就现在在职的一份工作了，这家工作的开发模式就是之前呼声很高的敏捷性开发模式，每个月一个迭代，开发过程中注重开发与测试的交流，轻文档化，只要求每个月迭代能够准时版本进行上线，在敏捷测试过程中，每次版本的需求需要明确，之后编写需求所用到的用户故事，敏捷测试是轻文档化的，所以用例的评审、用例的详细度相对就减少了，相对的针对不同需求的开发，加多了与开发之间的交流，加多了把自己想象成客户，进行用户故事、易用性方面的测试操作了。
时间在滴答滴答的转动着，我的人生还有很长一段道路，虽然我不知道我还会遇到哪些不同的开发模型，不过定期的将自己经历过的工作经验进行总结还是很必须的，当中也有很多不足的地方，也有可以让大家借鉴的地方，希望可以进行交流，交流下自己的心得体会。
本文由会员 lhlcw007 首发于51Testing软件测试论坛[软件测试新手上路]版块。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
