功能测试在查什么
你让开发做个登录功能，输入账号密码能进去就算完事？没这么简单。功能测试就是盯着这一步一步来：输错密码有没有提示，点‘忘记密码’跳不跳转，验证码刷不出来算不算bug。它关心的是‘能不能用’。
比如你做电商网站，用户下单流程从加购物车到支付成功，中间每一步点击、跳转、数据展示都得验证。这个过程就像过安检，每个环节都要盖章确认没问题。
性能测试盯的是另一回事
系统能用是一回事，扛不扛得住人多是另一码事。双十一秒杀时，一百万人同时点购买，服务器直接罢工，页面卡成PPT——这就是性能问题。性能测试不看你功能对不对，而是问：系统快不快、稳不稳、撑不撑得住。
举个例子，一个API接口返回商品列表，功能测试只管它返回的数据准不准；但性能测试会模拟几千并发请求，看响应时间是不是超过2秒，内存会不会爆掉，数据库连接会不会被打满。
两类测试的关注点差异
功能测试像质检员，拿着清单一条条核对。它的依据是需求文档，目标是发现逻辑错误、交互异常或者数据处理偏差。常见手段是手工点击或自动化脚本模拟用户操作。
性能测试更像压力教练，专门给系统“加负重”。它关注响应时间、吞吐量、资源利用率（CPU、内存）、并发能力。工具常用JMeter、LoadRunner这类，跑完出报告，一看哪里成了瓶颈。
实际场景中的配合
新版本上线前，团队先跑一轮功能回归，确保改代码没把登录搞坏。接着上性能测试，模拟高峰流量，看看系统表现。如果这时候发现登录接口延迟飙升，虽然功能没错，但用户体验已经崩了。
有时候问题藏得很深。比如某个查询没加索引，单次请求看不出问题，但一并发就拖垮整个数据库。这种case功能测试根本测不出来，非得靠性能压测才能暴露。
要不要写代码
功能自动化常需要写脚本，比如用Selenium控制浏览器点击按钮：
driver.find_element_by_id("login-btn").click();性能测试的脚本则侧重请求构造和指标收集。拿JMeter举例，定义线程组模拟多少人，设置循环次数，添加监听器看结果树和聚合报告。虽然也有可视化界面，但复杂场景还是得调参数甚至写BeanShell脚本。
谁该关心这两者
产品经理可能只问“功能做完了没”，但技术负责人必须知道“上线后会不会挂”。开发要懂基本的功能验证逻辑，避免低级错误；运维更在意性能基线，怕半夜被报警叫醒。测试人员则得两边兼顾，既不能漏掉功能漏洞，也不能放过潜在的性能雷区。
说白了，功能测试保正确性，性能测试保可用性。两者都不是可选项，而是保障线上稳定的一体两面。