前言
　　进目前公司也有大半年了，其他技术学到的不多，但是业务测试学到了不少，之前以为是点点点，现在泪流满面。
　　ps：我们部门女生比较多，so她们对业务的了解很恐怖。。
　　正题
　　一来公司主要测试一个项目，对公司的其他项目不熟。下面这个项目来展开，这个项目是web端的，项目测试流程是很普遍的流程：需求评审--->设计评审--->测试用例设计--->测试用例评审--->测试--->上线
　　需求评审
　　产品提前二十四小时发出评审邮件，附上PRD。测试和开发看完后做好笔记，做好撕逼的准备。测试在需求评审上要做的是：站在用户角度上看设计是否反人类，是否会影响性能，是否太复杂了用户不会操作等等；站在开发角度上看是否比较难以实现，是否会影响到已有功能的设计。站在测试的角度，是否需要很长的测试时间。后各种拍需求，然后PRD超过10%的改动，要重新开需求评审会。后才是开移交会。常常跟产品说的话是：
　　你们这么想，用户不这样想啊，你们做过调研吗？调研报告呢？这个需求不做了。开发根本没法实现。而且这么设计不影响性能吗，你知道一个页面两个实现逻辑有多么逆天吗？这个功能怎么能用同步，肯定要走异步，你们再好好想想吧。
　　设计评审
　　开发的设计评审会邀请开发的领导，产品，测试一起。开发的领导指出设计有哪些地方不合理（包括数据库表不正确，设计理念不合理），产品从扩展性来指出现在的设计不兼容以后需求方向。测试要会前面两者。设计评审不通过要一直开会，一直到评审通过为止。常常跟开发说的话是：
　　权限肯定不能这么设计，你考虑到以后了吗？你的这个表字段为什么加在这个表里面，为什么不新建一张表？
　　设计测试用例和测试用例评审
　　设计测试用例：除了根据PRD上的业务来设计测试用例以外，还要根据设计文档。包括逻辑是怎么样的，数据从哪里来的，保存到哪里去。另外还要考虑到兼容性，安全性等方面。
　　测试用例评审：重要的功能需要先内部评审，内部评审过了再拉产品和开发一起评审。然后产品会说：我不是这样想的，我的PRD上的意思是那样的。开发会说，原来产品是这么想的，我们没做这个逻辑，换了个逻辑了。还有这个数据库表的字段改了，没通知到你，嘿嘿。
　　测试
　　测试打回：测试用例的P1和P2级别开发没有通过自测，发邮件测试打回，抄送到上面的领导。
　　测试bug：每天的P1和P2的bug必须修完，每个bug关闭的时候要给出理由。
　　测试：只有这个时候才是点点点，还要注意各种不同的测试场景等等等。
　　上线
　　在测试环境测完，到beta环境连接线上数据库测一遍，beta通过后再上线。后到线上再简单测一遍。
　　总结
　　业务测试真的不是简单的活，要学习的还有很多。。。