不上不下的“中型”公司如何解决没有测试问题？

[zzNaLOGIC]

公司目前到了发展瓶颈期，不算小但也算不上“大”，更奇葩的是每年营收倒是不少，但至今没有测试部门，点点功能的黑盒测试都没有，一度令我震惊。现在每次上线就靠自测和最终产品点点验收一下，约束基本靠出问题之后写事故报告扣钱（虽然目前很少真的扣钱）。
也跟老板反馈过很多次加测试，但是阻力一直如下：
1.没有正儿八经的测试流程，对应的招点测试来也基本没有上升渠道，基本招不到测试。
2.招一个没用，招一堆开个部门成本太高，舍不得。

现在业务量越来越多，再加上我们是一周发一次版，出事故的概率越来越高。而且因为系统比较老，牵一发动全身，没有测试开发的也测不到哪里会有影响，不少人觉得事故报告写的很冤。

不知道有没有类似情况的公司，你们是怎么解决测试和验收问题的？

[saulshao]

我觉得第一步是要招一个测试进来，最好是比较资深的测试人员。
先把测试搞起来，如果不能全搞，就先搞一部分。
完全没有测试的软件，是会让所有人提心吊胆的。

[54xavier]

我们也没测试，都是开发自测，上线 bug 如果没造成损失就没问题，如果造成损失，需要签事故单，还好一般开发只用承担部分，并且一般都不多。入职半年多还没签过，希望别签。

[customer]

@qooweds 中肯的回答，第一次看到有人把白盒测试跟黑盒测试的成本放在明面上比较的

我们都明白问题丢给黑盒不合理，但是人力实在太便宜了

[yule111222]

开发自己测，测试驱动开发
不过，你得真学会了 TDD 再大规模推广，不要为了测试而测试，不然测试代码反而容易变成技术债

[Kumo31]

作为程序员，从技术角度来说，大家都希望有一个完善的流程和做出稳定的软件。但实际上，公司在测试上投入多少主要是看解决质量问题的成本和质量问题带来的损失之间如何平衡。当你们发现质量问题带来的损失远高于组建一个测试部门或改进流程的成本时，自然就会推进这个事情，就像 IC 设计中甚至还要做形式化验证一样

我们是做 infrastructure 的小公司，产品上跑着客户的上层应用和数据，小到几百 TB ，上到数十 PB 。对我们来说稳定性就是高于一切的，在开发之初会花费大精力先实现测试框架和模拟器，流程上也有很多的混沌测试。但对不少互联网业务的公司来说，几次质量问题带来的损失并不高，甚至解决质量问题的时间成本还会导致无法快速上线而损失大量收益，也就认为测试无关紧要了

[recot]

@iyobucuo 这是测试报告，还需要写自动化测试代码。

[GuLuDaDuiZhang]

老板觉得没必要，当前质量 ok 不影响营收，那质量这块保障就只好苦一苦研发了

或者找些理由继续劝说老板，让老板相信有测试可以直接或间接的给公司营收带来提升，前期可以小成本先找外包验证效果

我所知有正规测试流程的基本都是 toB 的业务，而且这类业务测试团队规模还都挺大的，主要原因就是这类产品定制版本多迭代多，问题也就多了，光靠研发人力兜不住，而且客户对稳定性要求高，中标签单前客户老是刷到问题没服务好就会丢客户，toB 丢一个客户潜在损失可能就是百万甚至千万，出一次重大事故要赔钱还会把名声搞臭了，所以 toB 业务会倾向建立测试团队，把质量风险降低。

[HappyFox]

个人观点：老板自己搞不清对质量的要求，加再多测试也没用


以下是我个人在不熟悉你们公司业务和人员的情况下，建议的一些通用手段，排序是以少量测试、测试人效高、省钱这仨要求的综合以后的推荐程度，从高到低排的，仅供参考。

0 、流程分割
把提出需求、开发、发布这三部分拆开，保证开发阶段不会出现需求变更。
这个对你们产品和研发的老大要求挺高的，至少需求开发排期这种东西得合理，手底下多少人力心里有数。否则老板基础不牢，小兵地动山摇。
1 、代码门禁
保证代码合并主分支、上线这两个操作可感知、可复现、可优化。拒绝随意上线、夹带上线等事故高发操作。
可感知，指的是运维和研发组长知道手底下的人上了什么需求。
可复现，指的是上线脚本 or 流水线，这个对你们运维要求比较高，至少堡垒机、流水线、上线自动化脚本、回归脚本这些东西都得有。大公司有的自建、有的采购；小公司用云的话可以用配套的流水线；如果是自有服务器，推荐抽时间把脚本写好了一劳永逸。
可优化，指的是后续如果加了别的自动化流程，能结合到这两个流程中，通过代码门禁强制进行一些自动化检查
说句难听的，60%以上的问题都是那种“就稍微改了改”然后随意上线导致的。
2 、静态检查
规则在精不在多，保证每一条规则都执行。代码规则找公司中技术老板出(根据公司平均水平来吧)，直接封禁一些代码里的骚操作（ java 的话推荐阿里的那个规范挑点重点的），编写规则后放到代码门禁里。上线前检查出来问题，代码门禁怼回去不让上（当然，肯定要开发的时候自己多跑几次，千万不能上线的时候才跑第一遍！！！）。
3 、监控
找个时序数据库，代码里关键指标打点，然后自建个 grafana 监控大盘。根据你们的指标特点，最大、最小、波动率，这些基础的报警规则都配置上。平时大家轮流值班，值班的人业务需求少点，但得随时响应这些报警。上线的业务对应开发+值班同学一起跟，等指标平稳以后才算上线结束。
4 、测试+自动化
不同业务天差地别，自动化测试的效果也不一样。确认你们业务的特点
比如滴滴打车这种用户操作空间极少的，流量录制回放效益最高。用户操作界面复杂且经常变的，黑盒测试+操作录制工具效果更好。

[fantathat]

一周一迭代，而且还要改动老旧系统，我感觉是很容易出问题的。但是老板竟然不在乎，这说明一切都尽在他掌握之中。

[ruanimal]

没啥啊，招点贵的人，让他们自测。毕竟鹅厂也没有测试[doge]

[slert]

不用提老板操心，老板觉得靠用户测可以那就这样。