我们在进行性测试过程中，需要注意系统架构的哪些关注点呢？常见的有如下几个，系统资源，操作系统，数据库存储，中间件，应用程序，web服务等。

如果停止的事务增多，则停下来线程也会增多，处于运行状态的线程会减少，最后导致服务器负载不够（若服务器负载不够，测试结果将不具有参考性），因此一般不会勾选此项。就绪状态，线程对象创建后，其他线程调用了该对象的start()方法，该状态的线程位于可运行线程池中，已经准备好。从当前延迟多长时间开始运行测试，单机执行按钮后，仅初始化场景，不运行测试，等待延迟到达后开始测试，运行时长为“持续时间”中设置的时

比如企业A在理论基础及流程规范上已经非常完善，同时已经开始给其他内部和外部的团队进行赋能，但在工具使用上尚未达到平台化的能力，此时认定A企业在性能成熟度模型中只达到了规范型的等级，而非赋能型。在团队方面，有全职的性能测试工程师，并且有性能团队这个组织，性能测试项目的实施都是由该团队完成，不再是由开发工程师进行，他们会产出专业的性能测试实施方案和使用专业工具开展实施工作。处于规范型性能测试等级的企业

在我们的测试工作中，为了提升回归测试效率等会使用到自动化测试，UI自动化测试也会使用到，在使用的过程中会出现测试稳定性问题，最典型要数同样的测试用例在同样的环境上，时而测试通过，时而测试失败，很是让人头大，严重降低UI自动化测试的可信度。

规范的测试实施流程是性能团队不可或缺的一部分，有了规范的实施流程才能保证整个团队的测试目标的合理性、测试数据的准确性、测试结论的正确性。

时序问题可能涉及缓存和数据库的数据同步，比如先更新数据库再删缓存，如果顺序反了会导致脏数据。并发场景下，多个请求同时操作缓存，容易引发数据竞争，比如缓存击穿或雪崩。状态变化则关注缓存生命周期的各个阶段，比如失效、更新时的行为是否正确。还要分析缓存的不同存储策略，比如旁路缓存和读写穿透，因为不同策略的测试重点会不一样。比如旁路缓存更依赖应用层逻辑，容易出现时序问题，而读写穿透由缓存自身处理，可能更需

项目中的开发团队对接口进行重构后，涉及到的自动化测试用例出现大面积“报红”，测试团队需要花费大量时间进行更新。参数化不足导致每次业务规则微调整修改几十个脚本。从技术角度看，维护成本确实是个系统工程问题。最表层的是用例失效现象（如报错），中层是架构设计缺陷（如硬编码），深层则是流程协作问题（如开发不通知变更）。一定要摆脱用例越多越好这种观念（低价值用例反而增加维护负担），断言不是越详细越好（过度断言

对接口实施压力测试，主要是为了评估系统在高负载下的表现，比如响应时间、吞吐量、资源使用情况，比如找到最大并发用户数或处理能力等。确定测试目标，比如并发用户数、持续时间、性能指标。然后选择合适的工具，比如JMeter、LoadRunner、Gatling这些常见的工具。接下来是设计测试场景，模拟真实用户行为，比如登录、搜索、下单这些操作。然后配置测试环境，确保和实际环境一致，避免环境差异影响结果。执

目录一、断言设计原则1.1精准性1.2可维护性1.3容错性二、常见断言类型及实现2.1基础验证2.2响应体验证2.3业务逻辑验证2.4异常场景验证2.5数据库断言三、断言策略3.1 精准断言 vs 模糊断言3.2关键字段优先3.3数据动态处理四、多断言处理4.1单用例多断言4.2软断言（Soft Assertion）五、工具与框架支持5.1 断言库5.2 JSON Schema验证5.3 Post

接口自动化测试会分为几个层次，每个层次有不同的关注点，主要包括用例层、协议及接口层，业务逻辑层、数据驱动层、工具层，还有框架层等。其中用例层应该是最上层的，是用户直接编写测试用例的地方，用自然语言或者特定语法来描述测试场景。例如使用Gherkin语法，或者使用一些测试框架的DSL。比如Postman的Collection或者JMeter的测试计划。业务逻辑层可能需要封装具体的接口调用和断言。例如创