我毕业之后，大大小小的项目参与了很多。一部分是瀑布开发模式，一部分是敏捷开发模式。相对来说，我比较喜欢敏捷开发模式。因为挑战性大。让我觉得很充实且忙碌。瀑布开发模式呢，说实话，没有挑战性。

     在瀑布开发模式中，阶段都是非常的规整，先是需求分析阶段，再是软件设计阶段，再是软件开发阶段，再是测试阶段，再是UAT验收测试阶段，最后是发布上线。每个阶段都根据工作量预估时间起始和结束点。对于测试来说，其实参与起点并不是测试阶段，而是需求分析阶段。从需求分析到软件设计到软件开发，测试人员一个重点工作是在分析需求文档和开发写的详细设计文档，另一部分重点工作就是根据这些文档，编写测试方案和测试用例，同时准备功能测试数据。如果涉及到性能测试，则需要准备性能测试脚本和性能测试数据。这样说了，是不是觉得测试的活其实也挺多的，需要分析系统的功能，系统的架构，系统的组织结构图，了解系统运行的原理。有些开发总是羡慕测试，觉得测试比他们干的少，持这种观念的开发其实是不了解测试在整个项目过程中起的作用。他们只知道他们是创造出东西的人，老带有些优越感，看不起测试。遇到这样的开发，我只能表示无语，且从此以后从上往下看他。这样的开发比较短视。测试人员真正开始忙的时候，是从测试阶段开始，需要部署测试环境，执行冒烟测试用例。如果冒烟不通过，则版本打回。在我第一份工作中，如果有冒烟不通过，则开发会被罚钱，且影响绩效和年终奖。这个算是对质量要求比较高的公司。所以开发一般在提测前，都会先执行冒烟测试用例。这样的措施，对测试人员来说，省事了很多。并且对项目的质量和进度都是很好的把控。冒烟测试结束后，测试人员会有一轮、二轮、三轮测试和回归测试。这个根据项目大小，如果项目比较小，那两轮测试+回归，基本可以结束所有bug。最后测试人员需要输出测试报告，根据每轮测试发现的缺陷数，进行报表分析，主要是看缺陷是否收敛，每行代码缺陷率多少，根据系统模块归纳缺陷数，了解哪个模块缺陷最多，并给出遗留缺陷数的影响评估。测试报告结束后，测试组还需要给出缺陷报告总结，统计每轮的缺陷遗漏数，统计遗漏的原因。同时需要统计哪些缺陷是根据用例发现的，哪些是随机测试时发现的，得出测试用例的有效性。整个项目过程，非常的有序，且项目质量很高。项目组成员都很happy，因为压力并不大。

      敏捷有很多模式，如极限编程模式、Scrum模式。敏捷模式核心即迭代开发。即将一个项目分成了好几个瀑布开发阶段。标准的Scrum每个迭代是两到六周，一个Scrum团队有几个角色，分别是PO（product owner），scrum master，技术团队。PO负责每个版本发布哪些功能，scrum master负责指导技术团队实行scrum流程，同时保护技术团队不被随便压榨。在每个sprint迭代里面都会有固定的项目活动，开始会有sprint planning会议，所有成员参加，PO会说明哪些story需要在这个版本实现，开发人员给出story规模估计，最后从backlog里面只取出需要实现且能在一个sprint开发完的story。planning会议之后，开发coding，测试分析story，并写测试方案和用例，这个可以用思维导图编写，将这两个文档的内容合二为一。等某个story结束，测试需要考虑其可测性，可以和开发讨论如何测试他的代码。如果可测，则可以将代码拉到本地，在本地部署测试环境进行测试。如果不能测试，则可能需要等到其它story做完后，才可以集成测试。在我经历的项目里，一般都是在几个相关story做完后才可以一起测试。这时候已经是第二周了，开发有story做，根本无暇修复bug。于是bug就会放在backlog里面，除非造成阻塞的bug，否则bug是不会放在下一个sprint修复。所以有时候我不明白测试在scrum流程中的作用，我觉得根本没有多少作用。如果有人有不同意见可以提出。在scrum流程里面，功能点相对bug来说优先级更高。所以如果在本sprint没有时间修复的bug，它的命运就会很坎坷。有时候时间久了，经历几个sprint之后，有可能就变成无效bug。也有可能无法再重现，因为代码一直在变动，很难保证代码改了影响到啥。在这些情况下，有时候我会很沮丧，我觉得在scrum流程里，测试的价值非常小。且很难保证质量。很难保证质量有几个原因，一个是因为开发在一个sprint里很难有时间修复bug，第二个原因是每个sprint版本功能都在增加，需要做大量的回归测试，而在一个sprint里面，开发一般在最后几天才会code freeze。留给测试做回归测试的时间非常短。其实这两个原因都可以解决，关键要看领导重视质量还是进度。

     所以敏捷和瀑布都各自有优点和缺点，他们都有各自适宜的项目，这主要看项目经理的做事方法和理念是什么。在scrum里面，项目经理就类似PO。