自己总结一些老大讲的有关测试的知识

１、开发环境—测试环境—线上环境

备注1     打tag

所谓打tag，要从SVN官方推荐的目录结构说起的

SVN官方推荐在一个版本库的根目录下先建立trunk、branches、tags这三个文件夹的

1、其中trunk（主干）是开发主干，存放日常开发的内容

2、branches（分支）存放各分支的内容，比如为不同客户定制的不同版本

3、tags（标签）存放某个版本状态的标签（相当于trunk代码打个标记，在这个时刻所有代码原封不动），比如验收测试版、1.0.3版等。

branhces和tags没有本质区别，都是通过svn copy方式建立的，差异在于通常branches中的内容是需要继续修改或开发的，tags中的内容是存放不再修改的，这一般通过权限设置来解决，tags通常只给管理员开放写权

备注2  持续集成

      在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显，由于很多 bug在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况，在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。

      持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏。

备注3  灰度发布

    简单理解就是给一部分用户发个测试版本，其他用户继续用以前的版本，然后观察测试版本的情况

    灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

备注4  运维相关

运维负责测试环境和线上环境 测试和线上的环境出问题是运维就要找到问题，如果是程序代码的问题就还要返回来，负责项目能跑起来，服务器挂了，短时间不能修复妥妥的是运维的锅。公司是不允许服务器挂掉的成规模的公司都是有备份的服务器，不允许服务器挂掉，所以项目都要在测试服务器上跑好长时间

备注5  组合测试

       简单理解：柏利天的商品的全选功能和删除功能组合到一起测试

        组合测试法：有n个输入参数，每个输入参数可取若干个值，将n个输入参数取值的所有组合进行穷举测试，由于爆炸性，所以是不行的。退一步：对n个输入参数中的任意m个输入参数的所有取值组合要覆盖到，是可行的，称之为强度m的组合测试。由此引出了组合测试的一系列理论研究，

2、bug状态