从瀑布模型转向迭代开发

前言

      2017年4月17号，我入职新公司，心里有些忐忑，要重新学习公司的业务，重新认识新的同事，最重要是要改变自己的工作方式，这对我来说是一个不小的突破。

一、瀑布模型的业务流程

      之前的公司是一家大型企业，世界500强，公司采用的是传统的瀑布式业务流程，开发完成90%之后，交付测试部门验证，此时还不算是验收测试，大型企业分为3个开发阶段，EVT（工程验证与测试阶段），DVT（设计验证与测试阶段），PVT（生产验证与测试阶段），MP（量产阶段），之后便进入SOVP（批量生产），最后是SS（上市），而我们测试部门只验证其中的DVT和PVT，DVT阶段还是存在不少问题的，此时可以发现大部分功能上的bug，一些系统上的死锁bug，如系统停止运行，死机，以及少量的硬件bug。PVT阶段的测试是验收测试，这时候主要就是为了少量的功能问题，更多的是在追求更完美的用户体验。

二、瀑布模型的时间

      传统的瀑布式开发在大公司比较常见，因为有足够的人力和资源去支撑，所以有更多的时间去开发测试，一个完整的周期大概在半年甚至更久，每一个阶段的测试至少是两周，这都是需要付出大量的人力成本。

三、测试人员的职责

        每一个测试人员只负责一个part的测试，大公司将系统测试与专项测试分开，系统测试是检测整个系统是否能正常运行，功能是否与设计一致；专项测试，是只负责某一个专项的测试，需要测试人员在某一领域有一定的技术基础，如Camera、Audio、TP、指纹等，另外，还有功耗、性能、稳定性测试，这几项测试需要一定的自动化技术，如果你在几个领域都有所研究，并掌握一定的技术，便可以选择自己更感兴趣的专项，当然，公司同不同意，就另说了。

四、企业文化

        每一个公司都有自己的企业文化，在大公司，企业文化尤其鲜明。在测试部门，也是有一定的企业文化的。不得不承认，企业文化对一个人的影响还是很大的，至少是在对待工作的态度上。测试部门的企业文化是什么呢？我所认为的是，测试是检测和保证产品质量侧存在，而不是找到与产品设计不符的bug。我所在的公司，公司对测试部门放权是非常大的，测试具有一票否定权，测试说那是bug，开发是必须要改的，即使开发要争辩，也需要有充分的理由或技术理论验证，否则是无法向上级部门交代的，当然，这有好处也有不好的地方，对测试人员来讲，这是一件好事，测试人员有足够大的权力去决定产品质量，同时，也对测试人员有严格的要求，乱提bug肯定是不对，还必须时刻准备一些理论，去跟开发撕逼。

      这份工作做了不到一年，我就觉得很枯燥乏味，需要测试就那么一些东西，在技术上并没有多大的提升。但是这份工作也让我对测试这份行业打下了一个良好的基础，在大公司，可以学习到完整规范的测试流程，也让我明白一个测试人员真正的职责是什么。

五、迭代开发的团队模型

      新公司是一家小型企业，开发模式当然不能是传统的瀑布式开发，小型公司没有那么多的人力成本，所以，迭代开发是最近几年越发流行的开发模式，严格来讲，迭代开发还不算是敏捷开发。敏捷开发稍后再叙，先谈谈我理解的迭代开发。首先，在开发团队上，跟瀑布模型就有很大的区别，瀑布模型，开发跟测试是分开的，除了bug上的邮件交流，基本不会有出工作外的交流，二迭代开发，开发与测试是在一个团队，说到这里，传统的瀑布模型，开发与测试的比例大概在2:1或3:1，而迭代开发，开发与测试比例基本在8:2或9:1，这也表示，测试人员的生存环境越来越艰难，只会一点功能测试并不能满足迭代开发的要求了，更不要说要求更高的敏捷开发了，所以，测试人员必须要开始学习技术性的知识，否则被淘汰的几率是非常大的。

六、迭代开发周期

      迭代开发的周期大概在一周~两周，业务难度高的最多也不会超过一个月，迭代开发要求能更快地去响应客户，如客户在开发周期中提出产品业务的更改，迭代开发也是能及时作出调整，二留给测试人员的时间大概在2~3天，所以迭代中每出一个可测试的部分，测试人员需要及时去测试，提出问题，并及时跟进问题的解决进度。在整个过程中，测试人员是全部的迭代周期，在开发前期，测试人员需学习业务逻辑，制定测试计划，写测试case，完成这些工作之后，差不多第一个可测试的部分也就出来了，接下来就进入测试阶段。

七、迭代开发流程

      迭代开发像是给一个大圆以圆心为中点，将其分割成几个小圈，最核心部分的小圈是第一个迭代开发的，即实现产品的基本功能，也是最核心的功能，再一个迭代地往外拓展，直到整个大圆都完成。这种开发模式，是非常迅速的，一个迭代完成之后，立马进入下一个迭代，这就要求测试人员随时跟进产品质量，不能掉以轻心。

八、关于敏捷开发的浅层理解

      从测试角度来讲，我所理解的敏捷开发是比迭代开发更迅速但更稳健的一种开发模式，不仅对开发人员的技术要求有所提升，对测试人员也是。敏捷开发对测试来讲，应更深入到代码底部，到每一个函数，每一个变量，要求开发在完成一段可测试的代码后，便开始测试，从底层就扼杀掉一些bug，这也需要团队的协作能力，需进行单元测试，集成测试，才能算是真正的敏捷开发。

九、总结

      这两个月的测试工作对我来讲，是一个新的突破，让我对当前时代下的互联网开发有了更新的理解，希望以后可以多学习，快速成长起来。