1、接口自动化
对已经固化的功能，通过接口自动化定期执行，做回归测试，主要验证后期的迭代是否影响的以前的业务功能，实际项目中，注意力主要集中在当期的版本中，例如：本期只更新了 A 模块的相关功能，但是 B 模块的某个接口或者数据发生错误，因为很多业务有耦合性，底层的数据库结构也是有关联的，这种情况通过脚本去回归可以避免漏测一些逻辑，同时也提高的工作效率，业务比较复杂模块比较多的话，靠手工测试是望尘莫及的；
2、数据监控，
可以写一些 sql 脚本，对系统中，交易类的或者有数据统计类的进行监控，实际场景中，偶尔会有账务不平的情况，那就是哪里出了问题。
例如：已发出红包总金额＝每个人领金额相加，如果不相等，可能有并发问题或者数据丢失或者其他问题，还有一些借贷不平，以及一些库存核销不平等等，
具体看你公司是什么业务，底层原理都一样，思路就是我的数据是要对得上账的，如果不平一定是哪里出了问题，去定位问题和解决问题倒是比较简单了
，很多时候一些隐藏的 bug 不容易发现再加上一些历史遗留问题脏数据等等。
当然做这些的前提，是你需要有比较高的数据权限，数据库表结构非常熟悉，业务也很熟悉，否则你写不出来。我以前都是在生产环境运行这些脚本的，一般测试人员没有访问生产库的权限；
3、做日志监控，
系统没有 bug 是不可能的，总会有你关注不到的点，总有一些你无法预料的异常或者一些开发人员人为的误操作，
发布版本的时候某个配置文件忘记更新或者某个脚本忘记执行，那么就会导致测试环境都没问题的功能上线后却报错了。
所以做这个的目的是生产上或者测试环境的报错日志监控起来，能够及时的预警，及时修正漏洞，在用户没有投诉之前把问题解决降低影响。
以上是我所用过的手段，即使做到这些也无法 100%保证系统没有任何问题，只能说尽可能的去保障系统的质量，偶尔出一些小问题尽快修复就好，避免出现严重 bug 就好。