前言
进目前公司也有大半年了，其他技术学到的不多，但是业务测试学到了不少，之前以为就是点点点，现在泪流满面。
ps：我们部门女生比较多，so 她们对业务的了解很恐怖。。
正题
一来公司就主要测试一个项目，对公司的其他项目不熟。下面就这个项目来展开，这个项目是 web 端的，项目测试流程是很普遍的流程：需求评审--->设计评审--->测试用例设计--->测试用例评审--->测试--->上线
- 需求评审
产品提前二十四小时发出评审邮件，附上 PRD。测试和开发看完后做好笔记，做好撕逼的准备。测试在需求评审上要做的是：站在用户角度上看设计是否反人类，是否会影响性能，是否太复杂了用户不会操作等等；站在开发角度上看是否比较难以实现，是否会影响到已有功能的设计。站在测试的角度，是否需要很长的测试时间。最后各种拍需求，然后 PRD 超过 10% 的改动，要重新开需求评审会。最后才是开移交会。常常跟产品说的话是：
你们这么想，用户不这样想啊，你们做过调研吗？调研报告呢？这个需求不做了。开发根本没法实现。而且这么设计不影响性能吗，你知道一个页面两个实现逻辑有多么逆天吗？这个功能怎么能用同步，肯定要走异步，你们再好好想想吧。
- 设计评审
开发的设计评审会邀请开发的领导，产品，测试一起。开发的领导指出设计有哪些地方不合理（包括数据库表不正确，设计理念不合理），产品从扩展性来指出现在的设计不兼容以后需求方向。测试要会前面两者。设计评审不通过要一直开会，一直到评审通过为止。常常跟开发说的话是：
权限肯定不能这么设计，你考虑到以后了吗？你的这个表字段为什么加在这个表里面，为什么不新建一张表？
- 设计测试用例和测试用例评审
设计测试用例：除了根据 PRD 上的业务来设计测试用例以外，还要根据设计文档。包括逻辑是怎么样的，数据从哪里来的，保存到哪里去。另外还要考虑到兼容性，安全性等方面。
测试用例评审：重要的功能需要先内部评审，内部评审过了再拉产品和开发一起评审。然后产品会说：我不是这样想的，我的 PRD 上的意思是那样的。开发会说，原来产品是这么想的，我们没做这个逻辑，换了个逻辑了。还有这个数据库表的字段改了，没通知到你，嘿嘿。
- 测试
测试打回：测试用例的 P1 和 P2 级别开发没有通过自测，发邮件测试打回，抄送到上面的领导。
测试 bug：每天的 P1 和 P2 的 bug 必须修完，每个 bug 关闭的时候要给出理由。
测试：只有这个时候才是点点点，还要注意各种不同的测试场景等等等。
- 上线
在测试环境测完，到 beta 环境连接线上数据库测一遍，beta 通过后再上线。最后到线上再简单测一遍。
总结
业务测试真的不是简单的活，要学习的还有很多。。。
其他的我不关心，我就想问问妹子的联系方式
感觉现在都是业务为王了
那你们比较正规了，我们这来了项目就测，就算再乱也要测，没有打回给研发那边一说，哈哈哈
—— 来自 TesterHome 官方 安卓客户端
加精理由: 对测试的日常工作介绍形象, 让人一叶知秋.
测试还是蛮强势的啊，肯定要有强势的领导支持才能做到如此吧
其实我当年也是这么过来的. 在阿里几乎连续 2 年都是这种工作节奏. 这对保证项目质量还是非常有用的. 作为测试有必要牵制天马行空的产品和随性编码的研发.减少无谓的折腾就是对公司的价值
#1 楼 @liyalin900416 我们公司 30 多个妹子，你问哪个的
—— 来自 TesterHome 官方 安卓客户端
#7 楼 @seveniruby 对的，不制定这样的流程，产品和开发都要上天了。
—— 来自 TesterHome 官方 安卓客户端
前来学习
本来就应该这样做，我公司这边也是功能测试这边推动了这样的流程。这才是功能测试要做的事情。
以前的公司就是这么做的，虽然前期会繁琐一点，但是后续进行下来真的会顺畅很多。
这样的流程是谁建立起来的？
跟我们的流程大致一样，不过我们还要多一步流程。
app 的，上线前，加一步：统测
web 的，上线后，加一步：线上测试
仿佛回到了过去的公司，原来我们大家都是这样子过来的。
奔泪。
那么问题出来了，记得以前在这个模式中用了大量的时间撕产品撕研发，成了典型的白天上班开会，晚上加班干活。
然后干活得过程中各种通不过打回去给研发，浪费了太多时间。
拍个砖，如何来减少时间浪费捏~？
哎~~典型 996 模式。
沟通=撕逼是做不出好东西，靠测试补漏只会疲于奔命，顾此失彼。
这样时间长了，就会感到毫无成就感，然后就开始 “往上爬” 不在点点点，开始混日子，与人撕逼。
好正规的流程，整个公司只有我一个测试已经无力吐槽了。
—— 来自 TesterHome 官方 安卓客户端
流程还是挺规范的 不像我们现在公司 哎
基本一致哈哈哈,而且我们也妹子多,不会在一起吧、、、
一个才准备进入测试行业的小喽喽获益匪浅，谢谢
基本都是这样的流程，没什么新奇的。
楼主在用于描述的字眼，看似测试很强势。
关键还是要看，测试在各种评审当中能提出多少真正有价值的意见和建议，如果每次抓到点都是以一种盛气凌人的态度去说话，对于整个团队的关系和谐未必是个好事。
而且，也不太可能每次都有评审都能发现那种原则性的漏洞，往往都是有两种或以上的方案选择，到了最后实现才知道到底有多坑。
#37 楼 @chrislee1982 评审想得到的就提出来，想不到的就问开发和产品在技术和需求上面能否做到实现。也不是测试强势，只是想站在一个平等位置上，本来团队之间就是要互相妥协的。
"不制定这样的流程，产品和开发都要上天了。"……目前公司打算做一套，用例评审流程，但又感觉推行不下去
自动化只是手段，脱离了业务的测试不是好测试
楼主 真幸福 生活在花丛中
学习了