一、对于日活超过1W的项目基础认知

1、版本测试：针对于日活超过1000的产品，应该构建自己的监控系统，最粗略的应该包含报错反馈、邮件报警、错误统计等功能；这样可以不仅可以提高工作效率，也可以从测试端定位出来很多问题。

2、版本控制：在拥有多个开发流程，且测试流程先后顺序不定的情况下。我们应该采用gitflow模式，因为综合项目采用svn的trunkbase模式会有以下问题：

1） 打分支极其麻烦；

2） 合并代码麻烦；

3） 异地专线网络不稳定；

4） 日志无法保留；

给研发带来的问题：

5） 升级版本不自由，必须要等待主版本发布；

6） 本质的问题，把产品当成了项目开发；

3、日志系统：对于系统稳定来说，强大的日志系统。是我们系统稳定的前提保障，强大的日志可以帮助我们：

1）针对无法复现的用户操作行为进行追踪，找到一些“理论上”来说不可复现的bug；

2）日志系统可以后续帮助我们统计一些对应的报表，针对访问量大的接口进行拆解。针对于可以异步的操作的流程可以一定意义上避免服务器的压力；

4、文档系统：文档系统是用于书写接口问题所用，它的作用是：

1） 帮助我们测试由于新上接口/老接口调整导致其它接口无效问题，避免上线之后还要版本回退，一定意义上帮助我们做一次简单验证；

2） 另外具备完备的接口文档将会使我们交接过程变得简单；

5、测试掌握基本的抓包工具：针对于测试我们不要可以写测试用例，但是需要具备一定的能力。

1） 作为一个专业测试的基本素养，出现需要写测试文档以外，还需要掌握基本的抓包工具。可以快速准确的给开发人员，指出错误所在。

2） 测试文档的测试，同样也是一个专业测试的基本素养，帮助程序快速定位。

6、架构方案（推荐SOA架构）

1）好的架构方案不仅可以帮助我们方便的开发，还能够快速知晓更多表结构的信息，不用担心多方开发导致表结构混乱而一发不可收拾。

二、针对一期发布过程中的项目总结

1、 测试应该通过专业，抓包工具、测试文档等工具进程初步问题的断言，这样可以方便程序快速的定位问题。而不仅仅是提出问题。这样很多时候一些设备问题是无法通过程序的设备复现的（APP本身就有兼容版本的问题）。

2、 针对于svn版本控制，他不是一个适合多个团队，多版本快速迭代的，对于产品的定位有问题，它不是一个项目。

3、 对于bug如何解决没有完善的机制，人脑都是有限的，正确的bug提交和解决应该是有追溯的，可以开启和关闭的，应该是和绩效挂钩的，而不是一个微信消息可以替代的。这就是项目管理工具的作用。Bug是有发起人和结束人的，还有抄送过程中的修改回复，这才是敏捷开发的正确方式。

4、 没有数据库中间层，导致了数据库具有很多冗余字段，因为多方开发的时候没有一个统一管理方案。