在创业公司做测试

   兜兜转转，入这行快十年了。十年的光阴，走过了民营企业，淌过了某巴，某讯的长河，如今坐上了开往创业的“列车”，虽其驶向一个叫”梦“的站点......
   看过了知乎上一个关于“离职大公司，去小公司做CTO如何？”的讨论，读过了“在创业公司做开发”，“在创业公司做架构”，“在创业公司做运维...   运营“的热帖，似乎唯独没有见过”在创业公司做测试“的相关话题，本着独思而无友，必孤陋寡闻也的考虑，决定就当前自己所见，所闻，所感，所思做一个分享，权且当作抛砖引玉之用就好！

一、所见、所闻、所感（三体合一篇）

  首先，出于某些原因，我当前所在的这家公司名字就不提了，总之，从网上”2015年获得A轮的公司，截至到2016年3月23日左右，一共死掉了867家 ......“的数据来看，至少它不在这867家里面，并且也成功拿到了B轮的融资，从这一点来说，PR上，是一个很不错的话题点。也说明了，作为决策者的高层们，是非常之优秀的。所以，后面所谈到的内容，完全只是作为执行者的我个人一些浅显的感受和看法......

  好了，做了一个简单的说明和介绍，言归正传，正式开始这个话题，就先从需求作为源头，往下聊吧～～～需求，无论作为开发，还是测试，其重要性，我就不废话了。创业型公司，由于其本身所在大环境的原因，往往都期望自家的产品能够快速迭代，速度抢占市场，hold住用户，万众归心，独步天下～～～也因此，前期更多的是一种处处敏捷，时时开花的打法。短时间内，当看到自己的产品从无到有到上线发布，到有第一个用户，第一笔业务诞生，那份激动，我相信绝对不亚于中了双色球一等奖，因为那预示着开往“梦”的列车正式启动了，在前面，说不定是N个双色球一等奖，能不激动嘛，万一还有个沉鱼，落雁啥的，，，哎呀，就是想一想，那画面也是极好极好的啊～～～在此基础上，开足马力，招兵买马，奋力向前冲，做一名追梦的汉子，早日名言天下吧！！！别的兵，马，我不知道，但作为这个过程中新加入或加入时间不长的测试兵，测试马，，，只想说，翻开需求的那一刻，那是两眼泪花啊，”XX系统改造“，”XX流程优化“ ......这个是啥啊，，，是啥，作为“宝宝”的测试，“宝宝”真的不了解，面对紧迫的发布deadline“宝宝”真的委屈啊～～～

 聊完了需求，再聊项目开发过程管理。别的都不说了，本来前面大家一起评估的，按照功能实现复杂度和功能点进行估算，需要至少一周的测试内容，中间忽然因为一些研发联调也好，需求变更也好，还是穿插了别的项目，相关项目被做了压栈处理也罢，为啥最终的这些延时统统在deadline来临之时，都压在了测试这最后一个环节？测试宝宝们可以加班加点，但，其实很多时候，一些因素真不在测试宝宝可控范围内啊，比如：bug修复时间，bug修复后的影响面回归时间，reopen的bug数，因bug而带出的需求变更消耗时间......此时，作为“宝宝”的测试，可以弱弱的说一句：“宝宝”还是真的很委屈...很委屈吗...

 聊过了需求，项目开发过程管理，还聊个啥呢？那就再聊聊发布管理吧～～～理论上，测试过的代码，是不该带有很明显，很低级的bug上线发布的，但，有时候就偏偏很奇怪，很奇怪，测试环境好好的功能，一上线发布，就像着了魔一样，一用就出bug，还是关键路径的bug......然后，各方诸侯，虎目四聚，默契空前一致，第一时间脱口而出的都是“这个为啥没有测试出来..."但事实呢？Debug排查之后，发现不是业务人员自己操作误报，就是代码发布错误或者漏发～～～测试“宝宝”心脏承受能力有限，经不起多次这样的惊吓，咋下次能一起看个X片，来营造这样的氛围，而不是通过这样的方式可好......

 以上，就作为一个业务系统测试的角度，聊了需求，项目开发过程管理，发布管理的过程，最后，再以该角色聊聊环境管理？啥？为啥环境管理要放到最后聊？很简单，因为......没有独立，没有独立，没有独立的测试环境，测试数据经常被不知名的从db删除，代码在测试过程中也会被忽然的更新，web服务器也会偶尔因某种需要，重新启动......so，对于测试来说，你，没有，环境，给你-------》管理，也正因此，也只能以一个业务测试的角度谈这三体，而缺失了作为一个专项测试“宝宝”谈这三体的可能～～～

二、所思

  再次声明，以下所思权且抛砖引玉，楼主笨鸟一只，所以，所思之处难免会有一些不足，轻拍，手下留砖～～～

  对于创业型公司，前面也说了，本身大环境问题，敏捷可用的产品是王道，我个人表示赞同。但是不是可以说，一些关键性的文档还是不该出现断层。无论是技术测的还是业务侧的，这样也便于公司的组织级财富积累，是否也能有效的降低人员流失带来的断层风险过渡期？

 对于项目开发过程管理，想说，是不是插队的时候还是慎重，如果确实需要插队，那么就当前资源，插队所带来的影响面以及涉及到的各部门，干系人等大家能有个合理的心理预期和准备？这玩意吧，有时候真不是说多加点班就可以了的......

对于发布管理，是否可以做到例如自动发布以及发布前的一个确认环节？例如：研发确认提交的代码有效，运维确认发布的机器ip有效，发布的配置修改有效等？同时，加入类似的后台代码运行监控日志，如果说有因某业务操作导致的exception报错，也能第一时间定位问题，如无相关的exception报错，再由对应的产品确认，该操作不属于违需求操作，拉上对应的开发，测试定位。定位后，开发，测试邮件同步分析问题发生的原因和后续措施？（视影响面，不一定说每次都要去发这样的一个邮件）

再者，是否应该建立独立的测试环境（包括但不限于独立的web服务器，db服务器等），配置和台数不一定非要跟线上真实部署的一致，但至少从运维的层级关系上应该做到一致，这样，在人力充足的情况下，可以逐步建立测试环境与系统发布上线后的质量对比的一个闭环，从而在一定的时间积累后，尝试得出一个系数：在测试环境的表现能力，在实际发布上线后，表现会如何的这样的一个质量模型？当然，这里也就有必要说，组建并成立测试专项技能组。

最后，知易行难～～～尽管这趟列车并不是看起来那么好坐，但因为行程表中有一个叫“梦”的站点，还是可以在车上看到很多人的，人群中的测试“宝宝”们，有时候你们有没有一种感觉，CTO的那篇知乎里面有一句话是：开发，总是短时间内被高估，而长时间内被低估。而我们是不是应该说：测试，总是短时间内被低估，而长时间内被高估。呵呵，你别得意的笑，得意的笑......我说这句话的原因是建立在，每次一有线上问题就会四处响起的 “哎，这个测试怎么没有测出来......"哈哈哈哈～～～

以上仅仅只是一个入行快十年，但始终还是笨鸟测试的抛砖引玉Contents，由于人也上了点年纪，所以上下文切换时不免有些临乱，见谅！～

晚安，坐在列车上的战士们，哦，当然～～还有，这群XX的测试“宝宝”们～～～