一、前言
工作以来，真正意义上负责测试从0到1的项目，总共负责过2次。一次是刚刚工作的时候，被安排去独立负责一个web型的机票网站，包括web页面、后端服务、数据等；最近的一次则是今年负责的招聘类业务，包括B端、C端、后端服务、数据等等。二者无论是测试任务量、跨团队沟通、测试深度、测试广度等等，第二次的经验/收获都远远超过了第一次。这里把对此类项目的一些心得罗列在此，仅供大家参考。
二、0到1项目最核心要求
根据成熟度，项目大致可以分为3种：成熟期业务、发展期业务、起步期业务。这3种业务无论在业务把控、测试要求、质量把控方面都有各自独特的要求。对于刚起步项目，显然属于野蛮生长型，以最快速度打造产出1.0版本，并推给用户试水才是最核心的业务要求。因而，作为QA，最应该注意的点：
- 跨团队沟通的效率。沟通常常面临的问题：找不到人、找不对人等问题，而且常常要根据第三方的进度，来决定自己的项目进度。这里的原则是：以最快的时间找对人来沟通。因而，涉及跨多个团队沟通时，最好针对每个模块、每个服务的问题去找具体的对接人。
- 测试驱动开发。起步阶段，由于大量的新服务实现，联调时间不够等等，主流程不通问题基本会一直阻塞项目进度。这个时候测试应该在项目启动后，立即开始介入把控整个项目的开发进度，并在可测的时候提前介入实质性测试。
- 阻塞问题跟进。业务对接、技术对接、环境问题、数据不通等等，在野蛮生长的项目期间，往往属于"白纸作画"阶段，毫无经验可参考，一切都要“摸着石头过河”，因而，种种问题需要有类似每天站立会等形式来快速同步给团队，寻找更多资源来解决。
- 预上线的buffer时间。由于所有的服务都是新服务、线下环境无法与线上100%一致等原因，线下测试完成后，直接发布上线会存在极大的用户使用风险。因而，在线下与线上直接，增加一个预上线，来模拟上线后的使用。这里要求预上线环境与线上环境在以下方面是相同的：
- 关联的第三方
- 使用的数据/缓存
- 部署的代码/分支
三、可测性改造
这里的可测性改造是指：在改动需求/技术实现不需要大改的前提下，通过前端、后端、数据等等方面的改造来达到快速/容易测试的母的。这里大致举几个例子来说明：
- 前端页面层面的改造。比如页面缓存往往会发现无法确认当前页面是否是最新页面，这里一种方法是增加一个动态变化的“页面版本号”，代表页面的新鲜度。
- 后端的改造。比如，测试中，往往有清理数据/缓存的需求，或者想让某些场景更加方便的呈现出来，这里一种方法就可以增加测试需求的接口，来实现各种场景的模拟了。
- 线上测试数据隔离。这里数据隔离要达到几个目的：一、用户看不到测试数据；二、QA可以看到测试数据；三、QA对真实数据操作时有所控制
四、mock
无论是新起步的业务、还是成长期、亦或是非常成熟期的业务，mock一直都如影随形似的。广义上来说，mock分为几个层次：
- 数据层面的mock。 通过修改DB/缓存中的数据等，来模拟需要的场景
- 服务层面的mock。无论单测，还是集成测试，当某个服务尚未就绪时，可以使用在服务中写死返回的方式来模拟该服务的返回
- 第三方的mock。无论第三方未就绪，还是不稳定，抑或是想测试某种返回场景，可以直接mock掉第三方返回
- 接口的mock。为了解耦前后端，互不干涉进度，通过平台等直接mock掉接口
当然了，在恰当的场景、恰当的时间点mock，会大幅度增加整个研发测试效率。但应该不要忘记的原则是：
- 不要过度mock
- 不要忘记mock。出现的问题往往是:忘记了mock这件事，导致上线后的接口依然是mock接口