对于一个计算机从业者而言，不仅要有过硬的业务技术，还需要对项目的管理与开发过程有着宏观理解。这也许能够决定你是一直“搬砖”，还是有机会指挥他人“搬砖”。
那么，今天让我们一起聊一聊项目管理。
下图为传统的瀑布开发模型示意图，从需求出发，自顶向下进行开发，层层递进，项目完成后自底向上进行相应的测试，最终实现客户的需求。
- Unit test：顾名思义，就是由开发人员独立开发的单元模块，进行基本的运行测试。比如，现在团队需要开发一个购物软件，而这个软件需要有“商品浏览”功能，“选择支付”功能，“咨询服务”功能等，而每个功能又分成很多细小的任务派分给具体的开发人员进行开发，那么开发完成后，首先就要确定这些独立开发单元能否正常运行；
- Ingredient test：又称domain test，每个domain相当于一个独立的功能块，每个功能块又有多个程序员共同开发，在Ingredient test环节，只需要保证各个domain测试正常无bug即可。
- Platform integration：基础且比较重要的门槛级测试，主要为软硬件测试，其中硬件测试包括：固件，操作系统，驱动，应用等。
-
Platform validation：指的是具体的细节测试。
Function test：功能测试；
Compile test：兼容性测试，更换不同内存/硬盘等
User experience：用户体验，调查问卷等
Interoperation：交互性测试，如Intel的DPDK和QAT是两个独立的模块，有时需交互工作；
Performance test：性能测试，比如 页的响应时间，一般都有跑分软件；
Stress test：压力测试，时间压力（长时间测试）和系统压力（单位时间很大的访问量）
有时performance和stress也会交叉混合开展。
最终，客户会对项目进行验收，检测是否满足需求。
测试工作主要分为两大部分，Case和Bug。如果你能熟练执行测试案例，恭喜你成为了一名手工测试者，如果你还会编写脚本，那么就有可能实现自动化测试，如果你会根据项目需求理清逻辑编写case，那么你就又离管理者更近一步了。
在测试过程中如影随形的就是Bug，因此，很有必要对Bug’s lifecycle有一定的了解。Bug的生命周期如下图所示：
不过，现在很多公司也都会结合两种开发模型的优缺点以及自身情况，采取适用自己的混合模型进行项目开发。
常用的版本控制工具主要有两种：SVN和Git。
SVN (Subversion) ，是一个开放源代码的集中式版本控制系统，其核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。下面举例说明：
开始新一天的工作：
- 从服务器下载项目组最新代码。
- 进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。
- 下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。
这就是经典的SVN工作流程，从流程上看，有不少缺点，但也有优点。
缺点：
- 服务器压力太大，数据库容量暴增。
- 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
- 不适合开源开发（开发人数非常非常多，但是Google app engine就是用SVN的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
优点：
- 管理方便，逻辑明确，符合一般人思维习惯。
- 易于管理，集中式服务器更能保证安全性。
- 代码一致性非常高。
- 适合开发人数不多的项目开发。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！