测试万能公式
y1,y2,y3,…,yn= f(x1,x2,x3,…,xn)
须理清“SUT的功能”，“SUT的所有输入”，“每一个输入的取值范围”，“SUT的所有输出”，“根据功能推出每一个输出的预期值”。
想要找齐所有的x和y，就必须要求你对系统非常熟悉，对流程非常熟悉。系统依赖如何？流程调用，系统如何处理、交互？产生哪些反应？
典型的输入有：调用请求，读DB数据，读缓存数据，被依赖系统的返回数据，收到的异步消息等；典型的输出有：写DB，写缓存，写日志，调用依赖系统的请求，发出的异步消息等。所以这个需要你对你的被测系统和流程必须非常非常的熟悉。
一切测试都算黑盒，只是这个“盒子”的大小不同而已。(如果，你扩展到从源码编译到字节码，机器码，到CPU指令集，到OS硬件驱动，到半导体电路的话)
单元测试中“盒子”比较小，就是一个或者若干个方法；接口测试的“盒子”就会扩大到应用级别；集成测试的“盒子”就会扩大到系统级别。
自动化测试
机器可以帮助我们完成几乎任何的单一形态的、重复性的、非智能的测试方面，这样我们才能够将时间和精力集中在多形态的、可变的、智能的测试方面。
自动化测试分层
自动化测试框架
自动化测试框架的出现，根本原因是为了复用代码，提高自动化测试的效率。同时一个设计良好的测试框架，也能通过开放给用户的接口，指导用户编写出风格统一，便于维护扩展的测试代码。
衡量一个自动化框架的品质，就看它在多大程度上起到上面两个作用。
工具平台
实践出真知，多一些倾听、多一些尝试、多一些沟通、多一些思考，多走进业务，多寻求业务的痛点，没有业务支撑的工具平台也许只是空中楼阁。
数据准备服务
基本上每个产品线都有自己的数据准备工具（造数据），如，数据工厂。
Bug
什么是Bug？只要不能满足预期的东西都可以称之为Bug。所以，Bug也是广义的Bug，可以分为功能Bug，性能Bug，安全Bug，甚至流程Bug。对于一个Bug，优秀的测试工程师要能够定位Bug原因，并给出解决方案。
对于功能性Bug，没什么好说的，测试工程师的大部分时间都花在了这里。Bug定位的方法，主要的手段就是看日志，Debug。
对于非功能性Bug，就有点复杂了，不能一概而论，但还是有方法的。如性能测试中，发现程序卡住了，你会猜测是否出现了线程死锁，对于java应用，你需要使用一些jvm工具去查看线程堆栈，根据线程状态做出判断。只要掌握了一些非功能性Bug的定位方法，定位起来也是有迹可循，最后做到游刃有余的。Bug的定位和解决考验的不仅是测试人员的技术深度，更是知识的广度，所以这一点也是判断一个测试工程师能力水平的重要方面。
另外，对于一些流程上面的问题，考验的又是测试工程师的沟通、协调能力。因为真的很难，主导权在PD、开发，作为最后一个环节的测试，有时候真的需要用一些沟通技巧，和修炼出的人格魅力去说服和推进。
