1、覆盖主要功能；
冒烟测试不是系统测试或集成测试，所以不需要面面俱到，重点放在保证主要功能或主要业务路径执行正常；
2、易用性；
既然是自动化测试脚本，那么最好的状况是只输入一个命令可以就搞定，不要再让执行人员做各种配置；为了达到这个目的，可能会导致一定的冗余，但是值得，这会降低在冒烟测试阶段的成本。此外，测试结果要清晰明了，成功多少用例，失败多少用例，用例失败的原因，以及出现的异常信息，最好都可以一目了然。
3、引入工程的概念；
独立的测试脚本，如果没有统一的调用管理，则不可能满足易用性的需求；所以，应当引入工程的概念，使用类似TestSuite的概念以管理测试脚本的执行；
4、测试脚本要独立；
也就是经常说到的“高内聚，低耦合”的思想，每个测试脚本要尽可能的独立，执行过程不需要依赖其它测试脚本（lib除外）。此外，每个测试脚本（用例函数）覆盖的测试点要尽可能的单一，不要将多个测试点放到同一个脚本（用例函数）中执行；这样的好处是在功能变更后，修改相应的测试脚本时，对其它测试点的测试执行没有影响，同时，也可以保证在执行冒烟测试过程中，不会因某一个用例没有通过，而导致之后的用例无法继续执行；
5、测试脚本要简单
测试脚本编码要尽可能的简单，如果说测试脚本写的很复杂，那么就需要先测试自己的测试脚本的正确性了，否则，无法保证当冒烟测试过程出现问题后就肯定是被测产品的问题。而对测试脚本的测试是要耗费多余的成本的，不太现实，因此测试脚本要尽可能的简单，从复杂程度上避免测试脚本出现bug。
6、维护必要的文档
一整套的自动化冒烟测试脚本本身也是一个产品，尤其当其以工程的方式管理时，所以必要的文档是必不可少的，要有简单的设计、架构文档，更新日志。如果没有这些文档的话，发生测试人员变更时，新的测试工程师就惨了，只有两条路可选，一是一点一点的看测试代码以搞清测试脚本是如何执行的；二是重新做一个新的测试脚本框架出来；这两种方式成本好像都很高啊。
7、测试结果收集
每一次的测试结果都要留存，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行review，及可能存在更大的隐患。
上面说的原则不只适用于冒烟测试，其实对自动化的回归测试脚本开发也同样适用。
相信有人会说，为什么一个自动化测试还要搞得这么麻烦，还整出些原则来。其实，作为一名测试管理者来说，一方面要考虑提高测试质量，另一方面也要考虑测试成本，像冒烟测试和回归测试这样重复性较强的工作，若没有一个高效合理的自动化测试框架来执行，单靠手工来完成，成本是相当高的，尤其是对一些发布较频繁的产品；同理，如果自动化测试框架不是很合理，执行过程总是需要过多的人工参与，成本同样会很高。测试成本若是降下来了，那么我们就有更多的人力去做其它的事情，生产力就提上去了^_^。
文章来源于领测软件测试网 https://www.ltesting.net/
