由于事业部发展需要，当前项目组的项目已经开发完成，并且项目的单元测试与自动化集成测试已经完成，到了上线前
的交付测试的时候，但是我们事业部并没有专业测试团队人员，于是把我们几个参与自动化集成测试的高级开发调到测
试事业部，学习专业的自动化测试理论和知识，为以后事业部独立发展奠定基础
接触软件开发也有几年了，将我司以及之前公司的几种开发风格(模式)整个过程进行总结，基本分为下面三种开发模型:
瀑布模型
瀑布模型属于线性模型的一种，几乎是其他的开发模型的基础模型，瀑布模型的特点是按照线性顺序执行流程，标准化开发执行，不会串行执行
好处： 开发的各个阶段比较清晰，需求稳定的产品开发或者早期计划完善的产品开发会降低大量开发难度和管理成本
坏处:由于按照顺序线性执行，则依赖于早期的需求调查，不适应较频繁需求的变更，并且由于测试在开发完成以后才会介入，介入时间较晚，风险往往延至后期才显露，失去及早纠正的机会，软件缺陷较多或者出现较严重的产品缺陷，会传递并扩散到后面的阶段，甚至可能导致项目失败，风险较大
快速原型
在开发真实系统之前，先构建一个原型，在这个原型的基础上，逐步添加整个系统的开发模块，基本上属于第一步先开发个原型出来，然后经过测试和交互，找出不合理的点，然后逐步调整原型，尽量使其满足用户需求或者较为符合设计的产品，在此基础上正式开发真实系统，完善整个系统的开发模式
快速原型的开发模式，好处非常明显：
由于在正式开发真实系统之前，我们预先设计了一个小原型，有短暂或者第一个周期的调整，可以很大程度调整设计缺陷和交互缺陷，减少较大的软件缺陷和设计缺陷
同样的坏处也很明显:
只适合有参照或者有明确需求的产品设计，尤其是较小的、灵活度很高的系统，由于需要提前出一个用于展示的小型原型，对于一些很大的系统，尤其是无法提供完整的产品设计的系统基本不适合此模型
螺旋开发模型
现在我司的开发模型，趋向于专业稳定的开发模式，有专业的产品负责同类产品调研和功能分析，也有专业的db团队和运维团队，所以现在的开发模型趋向于多个迭代周期设计稳定的模型--螺旋模型，此模型会将开发周期明确划分为几个阶段或者几个周期，每一个周期(阶段)都与最基础的瀑布开发模型类似，按照螺旋的方式，不停迭代和扩展需求、修改产品、测试，使得系统稳定的产出与风险控制，大致如下:
此种开发模型的优点如下:
采用了风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都首先进行风险评估，然后按照风险与迭代需求制定开发计划，进行实施开发，可以稳定的产出对应的产品，也可以长期的稳定维护更新优化产品，完成产品的多个版本周期过度以及迭代升级，由简单的产品原型过度到完善的产品
缺陷则更加明显：
采用螺旋模型需要具有相当丰富的风险评估经验和过硬的专业开发及项目管理知识体系，在风险较大的项目开发中, 能够及时标识风险规避风险，合理安排项目周期，准确指出项目开发方向和整体目标，对于个人及团队专业度要求很高。并且采用当前模型，必须是能接受多个周期迭代带来的较长的开发维护迭代时长，以及较高的开发成本的工程，对于一般的快销产品或者快速开发的产品不适合
软件测试分类
以上是我司以及之前的企业经常采用的开发模式，但是无论是哪一个开发模式，都可以看到软件测试的部分，并且都在较为重要的位置，所以说一个产品的好坏，可用程度，很大程度上取决于软件测试的结果和风险把控，那么软件测试具体有哪些测试分类呢？
如图所示，软件测试一般会按照测试阶段、是否参与源代码覆盖、是否运行产品进行测试以及是否为自动化测试四个大类，以及其他的一些测试类型，那么这些测试分别是做什么的？区别在哪？
黑盒与白盒
现在接触到的软件测试人员，以及招聘网站上的招聘需求中基本都会出现黑盒测试/白盒测试这两个分类，那么什么是黑盒测试？黑盒测试也称之为数据驱动测试，即不需要关心代码结构和内部特性，完全站在不透明的层次，只关注与某个产品的功能是否实现，以及某个功能的输入数据和结果是否满足需求。而白盒测试更大的参与到源代码的分析，去研究产品功能内部的代码构造以及程序逻辑代码等，对于代码细节要求较高的测试
黑盒测试由于专注于系统的完整功能和性能等相关测试，也会分为基础的功能测试和进阶的性能测试两类:
功能测试
逻辑功能测试、UI界面测试与交互测试、安装测试以及兼容性测试等
性能测试
时间测试(事务、接口响应)、空间测试(资源消耗)、负载测试、压力测试、稳定性测试等
静态测试与动态测试
软件测试过程中，可能存在不运行具体软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程，即评审(产品评审、数据库评审、代码评审)，根据专业人士经验和积累提前找到软件缺陷并优化，此类测试为静态测试
而实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程称之为 动态测试
阶段测试
所谓阶段测试则是按照开发的阶段不同进行的测试，一般分为单元测试、集成测试和系统测试
单元测试
单元测试又称最小模块测试，基于针对每一个功能的最小单位，比如每一个方法进行覆盖测试，此阶段一般在开发的前中期，针对每一个模块的每一个功能开发完毕以后，从内部衍生编写出的测试用例，针对每一个可能进行覆盖，验证每一个分支结果
集成测试
集成测试又称之为组装测试，一般此阶段都属于开发的中期，属于独立的完善的功能开发完毕阶段，基于之前的单元测试用例，进行测试功能组装的测试方式，重点在于接口功能的完善性
系统测试
系统测试一般在整个软件主要核心流程开发完毕，在即将准备送测阶段，开发团队内部/软件测试小组提前将整个系统运行起来，串联化核心流程场景的方式检测整个系统功能的完善性、兼容性等
三阶段验收测试
首先在软件正式上线之前的验收测试过程中，往往会做一次冒烟测试，并且会有三阶段测试，来尽可能保证测试的准确和软件的可用性，所谓三阶段测试则是α测试、β测试和γ测试，分别对应三种不同阶段的测试
α测试
α测试(Alpha)一般称之为内测版本测试，该阶段的软件基本成型，初步完善，一般仅在团队内部流通，由测试人员进行一次测试，该版本一般bug很多，不会流通给用户使用
β测试
β测试(Beta)属于公测版本，该版本一般经历过内测的完整化测试以后的完善版本，该版本一般为了尽可能接近线上环境，往往会切换到真实部署环境，发布在指定的站点或者指定访问地址，由测试人员再次针对性的用例测试，也可能会开放给相关用户或者专业爱好者测试，并提供bug和修改意见
γ测试
γ测试(Gamma)也称之为正式版的候选版，到了这个阶段，该软件基本已经完善，从测试和体验角度达到真实上线标准，此版本的测试一般会针对核心接口或者场景覆盖测试，并且辅助回归测试和随机测试，来验证软件最终的大体可用性，经过此轮测试的版本基本已经可以作为正式版准备发行了
冒烟/回归/随机测试
在测试过程中，还有一些测试会用来辅助其他测试流程使用，比如常见的回归测试和随机测试。所谓随机测试，主要是针对系统一些核心功能的多次复测，或者测试之前未覆盖的部分，如果软件有版本更新，针对更新和改动的部分进行重点测试，一般会在验收测试过程中，辅助回归测试，将可能出现软件缺陷最大的部分尽可能的再次验证保障。而所谓冒烟测试，是对软件的基本功能进行测试，测试对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，保证软件系统能正常跑起来，可以进行后续的正常测试工作的进行，如果最基本的测试都有问题了，就直接打回开发部了，所以正式交付的测试版本，必须先通过冒烟测试的考验，所以一般在做软件交付测试之前，尽可能要保证冒烟测试的成功率达到100%可用或者接近标准值，这是软件交付测试的前提。
冒烟测试的前提
由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作，必须要保证以下几点：
1.在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查，比如很多互联网企业每周都进行的代码审查和静态代码检查等
2.必须保证冒烟测试的环境干净并且与当前送测版本的内容完全一致，比如新开发的java工程，尽可能部署在新的docker环境或者新的Tomcat环境中，并且代码一定要保证最新版本且可用，决不能出现开发版代码和冒烟测试版本有差异情况
3.保证代码更改构建做到每日构建或者尽可能版本同步，和上一条一致，测试过程和开发维护可能同步进行，一旦有版本改动，尽可能保证每日都发布一个新的改进版本或者同步版本
4.在进行冒烟测试之前，一定要保证系统整体可用，软件开发团队尽可能完成了阶段测试操作，确保一切都已正确配置并可按预期运行
冒烟测试的准备
测试经理和项目经理等相关人员从测试用例库中选定重要的测试用例，标记为冒烟测试用例，主要包含以下内容:
1.主流程和主功能的确认,在冒烟测试之前，测试人员一定要找产品或者开发人员确定需要测试的这部分流程业务，做到测试过程中业务熟悉
2.根据列出的功能点和开发人员代码质量的可信度，评估冒烟测试在不同环境下可能花费的最长和最短时间，列到测试计划中
3.在正式测试之前，对数据库或者对应核心表有一定的了解，提前准备对应的数据
准备完毕以后，就可以开始冒烟测试，严格按照前期的约定去校验主流程，全部校验完和开发人员报告情况，编写测试报告，决定下一个测试任务或者是冒烟失败以后软件退回，准备二次复测