软件开发与测试及版本控制实验报告_软件测试是什么

对于一个计算机从业者而言，不仅要有过硬的业务技术，还需要对项目的管理与开发过程有着宏观理解。这也许能够决定你是一直“搬砖”，还是有机会指挥他人“搬砖”。
那么，今天让我们一起聊一聊项目管理。

下图为传统的瀑布开发模型示意图，从需求出发，自顶向下进行开发，层层递进，项目完成后自底向上进行相应的测试，最终实现客户的需求。

今天，我们就以某公司的测试流程为例，分析下项目开发过程中有哪些不同的研发阶段。
实际测试过程中并非每个环节都要进行，每个功能都要测试，依项目大小/公司正规程度/客户需求而定。

1. Unit test：顾名思义，就是由开发人员独立开发的单元模块，进行基本的运行测试。比如，现在团队需要开发一个购物软件，而这个软件需要有“商品浏览”功能，“选择支付”功能，“咨询服务”功能等，而每个功能又分成很多细小的任务派分给具体的开发人员进行开发，那么开发完成后，首先就要确定这些独立开发单元能否正常运行；
2. Ingredient test：又称domain test，每个domain相当于一个独立的功能块，每个功能块又有多个程序员共同开发，在Ingredient test环节，只需要保证各个domain测试正常无bug即可。
3. Platform integration：基础且比较重要的门槛级测试，主要为软硬件测试，其中硬件测试包括：固件，操作系统，驱动，应用等。
4. 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的生命周期如下图所示：

除了传统的瀑布开发模型外，还有一种开发方式亦广受欢迎，那就是敏捷开发（Scrum）。
在传统的开发过程中，整个项目按照不同阶段层层递进，大家各负其责（办公室里全是开发人员或测试人员），逐层完成各自的工作，最终完成整个项目。敏捷开发则更注重过程的及时反馈，整个项目被划分成一个个小的功能块，每个功能块中都有developer，tester，project manager和business analysis，大家一起工作，共同推进。在敏捷开发过程中最常见的就是燃烧图和大大小小的会议，大家制定计划，完成工作，不断开会总结，及时发现问题，并对项目进行合理修正。因此对于敏捷开发而言，最终的结果很可能与起始设计的路线不完全相同。

敏捷开发模型

不过，现在很多公司也都会结合两种开发模型的优缺点以及自身情况，采取适用自己的混合模型进行项目开发。

常用的版本控制工具主要有两种：SVN和Git。

SVN (Subversion) ，是一个开放源代码的集中式版本控制系统，其核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。下面举例说明：
开始新一天的工作：

1. 从服务器下载项目组最新代码。
2. 进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。
3. 下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。
   这就是经典的SVN工作流程，从流程上看，有不少缺点，但也有优点。

缺点：

1. 服务器压力太大，数据库容量暴增。
2. 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
3. 不适合开源开发（开发人数非常非常多，但是Google app engine就是用SVN的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

优点：

1. 管理方便，逻辑明确，符合一般人思维习惯。
2. 易于管理，集中式服务器更能保证安全性。
3. 代码一致性非常高。
4. 适合开发人数不多的项目开发。
5. 大部分软件配置管理的大学教材都是使用SVN和VSS。
   

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者机器上都是一个完整的数据库。
从一般开发者的角度来看，Git有以下功能：

1. 从服务器上克隆数据库（包括代码和版本信息）到单机上。
2. 在自己的机器上创建分支，修改代码。
3. 在单机上自己创建的分支上提交代码。
4. 在单机上合并分支。
5. 新建一个分支，把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6. 生成补丁（patch），把补丁发送给主开发者。
7. 看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8. 一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

从主开发者的角度（假设主开发者不用开发代码）看，Git有以下功能：

1. 查看邮件或者通过其它方式查看一般开发者的提交状态。
2. 打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
3. 向公共服务器提交结果，然后通知所有开发人员。

优点：

1. 适合分布式开发，强调个体。
2. 公共服务器压力和数据量都不会太大。
3. 速度快、灵活。
4. 任意两个开发者之间可以很容易的解决冲突。
5. 离线工作。

缺点：

1. 资料少（起码中文资料很少）。
2. 学习周期相对而言比较长。
3. 不符合常规思维。
4. 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

说到这里，是不是让你联想到一些快递取件方式的改变。

之前是大家收到短信后，告诉取件员，他们帮你取，而这些取件员就像SVN的服务器，管理着巨大的快件“库”，当人流量比较大时，他们就会很忙。现如今大家收到短信后，自己进入仓库根据取件码找快递，仿佛每个人都有一个仓库（当然肯定不是啦），是不是很像Git管理方式？

好了，今天您的快递包裹就拆到这里了，希望能够带给你一些收获。
如果您想体验拆快递的快感，欢迎关注我的公众号噢，赵小赵的编程哲学（微信号：zxzdbczx），不定时更新计算机学习过程中的一些心得感悟。

今天的文章
软件开发与测试及版本控制实验报告_软件测试是什么分享到此就结束了，感谢您的阅读。