helm是做什么用的，在这里就不做解释了，有兴趣的可以看我之前的文章：https://www.jianshu.com/p/e14ab6763e52
首先我们来理解下helm test的设计初衷是：
执行发布版本的测试
helm test [RELEASE] [flags]
可选参数
--filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2)
-h, --help help for test
--logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup)
--timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)
也就是说，可以用来验证发布的chart的功能，比如service是否ok。怎么使用的呢？在你写的job或者pod里加个注解：
annotations:
"helm.sh/hook": test
它会随着业务代码一起打包，在执行helm install/upgrade的时候不会进行test资源创建。但是相当于储备在产品里。一旦有需要说检测系统服务或者测试功能，可以随时多次的进行检验。
启动的命令也很简单，区别于安装和升级的生命周期，测试是一个独立的周期。你可以把它理解为编程世界里的切面。无需关注各个子chart是否测试，只要注解了，都会被拉起执行。当然我们也可以根据需求，指定某些或者哪些case不运行。
helm test 还提供了查看logs的方式。
从logs可以进一步看出，case 失败的原因。根据test的result，我们也可以进一步解析出case的失败或者成功，以及耗时情况。这里值得一提的是，helm test和helm install/upgrade 都是比较关注helm创建资源的状态的。但是他们之间没有直接联系。
下面再来说说helm的其他hook。
hook 作用
pre-install 在渲染模板之后，在Kubernetes中创建任何资源之前执行
post-install 将所有资源加载到Kubernetes之后执行
pre-delete 在从Kubernetes删除任何资源之前对删除请求执行
post-delete 删除所有发行版资源后，对删除请求执行
pre-upgrade 在呈现模板之后但在更新任何资源之前，对升级请求执行
post-upgrade 升级所有资源后执行升级
pre-rollback 在呈现模板之后但在回滚任何资源之前，对回滚请求执行
post-rollback 修改所有资源后，对回滚请求执行
根据名字可以清晰的得知，这些hook的使用场景。比如，我需要在升级之前检查环境是否具备升级的条件，那么我可以加入hook：pre-upgrade，将一些检查的任务脚本放在这阶段执行。抑或是安装升级完成了，我需要自动化的检查下关键路径的功能是否都是正常的。那么我也可以在最后加上post-install或者post-upgrade里做一些事情。
常见的用法就是：
annotations:
"helm.sh/hook": post-install,post-upgrade
搭配着用的也是pod、job，那种一次性的任务会比较容易执行。但是我们在日常使用中，会遇到比如我的升级的时候，需要预先创建数据库（这里有个前提，我们的schema是可以多次执行，反复执行），但是我们使用job的时候，有些字段是immutable的，比如不让你改image tag。解决的办法是再加个注解：
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": hook-succeeded，before-hook-creation
当我们使用before-hook-creation的时候，job资源会在存在的情况下先删除，再次创建。避免因为不能修改而中断。
hook-weight可以用来进行排序，当任务需要有先后顺序的时候，可以用weight来进行标记。
总而言之，test和其他hook，本质上没有啥区别，但是test个人感觉更加灵活，独立可控的运行时态，可以帮助开发者和运维人员更好的捕捉系统应用的信息。且不受产品限制。
