事实上写出好的测试和写出好的生产代码一样难，需要精心练习和深思熟虑。然而我太多次看到测试代码被当作二等公民。这种情况往往意味着我们没有从测试中得到应有的益处，到头来测试集更像个累赘而非资产。
好的测试集：
一、信心
当修改代码后，运行了测试就足以放心提交代码么？直接上线呢？
我的经验是单元测试是不够的，我们需要一些全栈测试，BDD以及集成测试来增加信心。
需要注意的是对于同一个功能点如果有两个测试给你信心，那么有一个测试是多余的。
另外，如果你真的对测试集很有信心，但是你发布的产品中bug仍然持续增加，你的信心可能放错了地方。
二、抓到bug
如果你有个永远不会红灯的测试，它毫无价值因为它不会抓住任何bug，而这是测试存在的主要原因。
三、易于打理
如果你在重构代码的时候花了大量的时间修改测试或者重写测试，你的测试集就没有值回票价。如果你使用了大量的mock对象的话，我发现更是如此。很多情况下最终得到的是过分规格化的软件。
四、描述系统
测试用例应该告诉我们系统做了什么，最好还能告诉我们为什么做这些事。
只有很少的测试应该用来告诉我们它是怎么做的，而且我们知道如果进行大的重构时会扔掉这些测试。
五、本身没有bug
知道测试确实在测它的目标代码，也就是说测试本身没有bug的最好办法，就是在改了生产代码后，看着测试从红灯变为绿灯。
这就是为什么应该在写生产代码之前写测试。
另外考虑使用变异测试来找到测试集的盲点。
六、结实
如果你的测试集里有个反复无常的测试，莫名其妙的失败。它将危害整个测试集因为大家将不再把测试失败当回事。
删掉这种测试。
七、被人运行
也许这听起来有点傻，但是我确实看到过也写过很多测试却没人去跑。包括：
- 被注释掉的或打上@Ignored标签的测试。
- 非常慢的测试。
- 需要一些手工步骤的测试，比如安装数据库，应用程序容器或者消息中间件。
- 无法从IDE运行或者调试的测试。
总而言之，好的测试集将会支撑我们对系统进行演进。
测试应该支持改变，而非阻碍改变。
毕竟，正如Dave Thomas和Andy Hunt所言，我们总是在改变现有系统。
所有的编程都是维护性的工作，因为我们极少写全新的代码。
只有在你刚刚敲进去那10分钟里代码是全新的。
推荐好文：
10分钟玩转Python+Selenium自动化测试，教你快速入门！
最后： 欢迎关注小编领取一份300页pdf文档的Python自动化测试工程师核心知识点总结！软件测试技术交流群：（313782132） 这些资料的内容都是面试时面试官必问的知识点，篇章包括了很多知识点，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。