「方法论」既没有单元测试，也没有固定周期的 Code Review， 有可能做出稳定的产品吗？

10位数的用户是指十亿量级？
没有单元测试，但是如果有非常靠谱的黑盒和白盒测试人员，也许也能保证稳定性，还要看项目的大小。

小项目有可能。
多人协作的大项目，估计够呛。

三五个开发人员，没有单元测试和code review一般都不是什么问题。主要还是靠能力

几十个开发的话，就需要有流程来辅助了。

不过最终还是要看人，毕竟流程也是人制订并且执行的

单元测试仅仅是初级阶段，举手之劳而已，很多时候也就只对CRUD的业务有效。
一定规模项目仅仅是单元测试都还不够，更何况完全没有。
不要太相信个人能力，在复杂系统面前谁的能力都不够用。
有可靠的测试只会事倍功半，别怕一开始那点麻烦。

推荐一个Google Talks的讲座，关于Google如何进行连续集成测试的：

@MasterYoda 写错了， 是2位数； 计算量是有点大，目测不到 100 人用就能把它搞崩掉

写错了，事半功倍，=_=

@MasterYoda 以前还有 QA 现在是需求团队直接测了，他们当然是最理解需求的，但是对软件上的测试要点又能知道多少 。

@sunus 人是不多，但是时间久。 代码量累积下来， 隐患也会一点一点累积下来吧。

@soruNis
需求团队测和QA团队测不一样啊，需求团队最多也就是个功能测试，还覆盖不全。
引入职业的QA团队和完善的自动化测试很必要啊。
当然搞一个jenkins玩持续集成也可以。都会提高程序的稳定性。

@akfish 是的， 流程规范化可以保证最低的标准不被打破。 而强调人个能力的观点更多的应该是怕教条的流程规范限制了开发效率。

@soruNis 我的感觉是，抵触测试的开发人员，一般是不懂测试，或者太懒就没去正确的实践过。
根据我的经验，有（合理的）测试只会提升开发效率，而不是相反。

举个最基本的例子就是改了代码，要编译运行验证正确性，没有测试的就需要人肉去捅鼠标捅键盘，反复进行重复的操作，而且还无法保证可重复性。这个过程费时费力，还破坏编码节奏。
而如果有良好的测试流程，配置完善，做到自动化测试，那么修改一行代码只需要编译，测试自动运行，立即就能看到是红是绿，立即得到反馈，甚至键盘输入焦点都不用离开IDE。
这两种模式的效率高低显而易见。

所以我现在就算是自己撸着玩的小项目，都会写测试。

8位数的项目，少量的底层代码单元测试。code review也很少，表示很稳定

@akfish 是这样的，我所希望的情景也正如你所说。 至少在 daily build 完成后自动测试， 很多问题都可以马上发现。 悲伤的是， 由于现行代码中那一点残缺过时的测试代码， 自动编译脚本中不得不加上选项"-x test"忽略测试。

目前产品的可靠情几乎完全是靠需求组的“不完整黑盒测试”保证的。 当然，即使是这么做， 还是有修不完的 bug 的。

code review 还代表着有第二个人熟悉过这段代码。 不然走一个人就等着哭吧。

@soruNis 所以如果要推广测试的话，尤其是在对测试比较抵触懒癌晚期患者较多的团队中，只有渐进式的搞，并且一定要搞得合理靠谱。
不然一被抓到点把柄说影响开发效率了，立即反弹然后又不了了之了。

@hxgdzyuyi 哈哈， good point

单元测试能测出多少人使用会崩溃么？我以为单元测试只是测试基本功能是否可用，对于多少数量级的用户不起作用的啊。你说的那个得压力测试吧？

[技术水平不算含糊]
通过单元测试来保证代码及接口设计的质量，更多情况下是提高工作效率而不是降低，这难道不是一个码农技术水平的体验么？真正牛逼的人不会不屑于做这些和抗拒，反而应该是更重视更欢迎才对

@ivvei 压力测试是也必要的。那单元测试与用户量有毛关系呢： 单个用户的行为往往是很有限的，用户量到一定程度时可以覆盖大部分功能点，这时因没有单元测试或 qa 而被掩盖的问题就会暴露出来。

@griffinqiu 那是怎么做到的， 是有严谨的测试团队吗？

@akfish 有一种“说出来都是泪啊”的感觉