完整的后端性能测试应该包括性能需求获取、性能场景设计、性能测试脚本开发、性能场景实现、性能测试执行、性能结果报告分析、性能优化和再验证

后端性能测试工具主要在性能测试脚本开发、性能场景实现、性能测试执行这三个步骤中发 挥作用，而其他环节都要依靠性能测试工程师的专业知识完成

使用性能测试工具获得性能测试报告只是性能测试过程中的一个必要步骤而已，而得出 报告的目的是让性能测试工程师去做进一步的分析，以得出最终结论，并给出性能优化的措施

性能测试的执行，往往需要同时模拟大 量的并发用户，不仅需要验证业务功能是否成功完成，还要收集各种性能监控指标，会涉及到压力产生 器、并发用户调度控制、实时监控收集等内容

后端性能测试工具会以多线程或多进程的方式并发执行虚拟用户 脚本，来模拟大量并发用户的同时访问，从而对服务器施加测试负载

压力产生器:实际发起测试负载的机器,受限于CPU、内存，以及网络带宽等硬件资源，一台压力产生器能够承载的虚拟用户数量是有限的，当需要发起的并发用户数量超过了单台压力产 生器能够提供的极限时，就需要引入多台压力产生器合作发起需要的测试负载

压力控制器:专门统一管理与协调压力产生器,会根据性能测试场景的设计，来控制和协调多台压力产生器 上的多线程或多进程执行的虚拟用户脚本，最终模拟出性能测试场景中的测试负载

Read More

起源

由14世纪西方活字印刷术的发明人约翰·古腾堡提出,古腾堡图将画面所呈现的内容分成四个象限：

• 第一视觉区(POA)：左上方，用户首先注意到的地方
• 强休息区(SFA)：右上方，较少被注意到
• 弱休息区(WFA)：左下方，最少被注意到
• 终端视觉区(TA)：右下方，视觉流终点

从图中可以看出，用户视线很自然的会从第一视觉区开始，逐渐移动到终端休息区。整个阅读过程视线都会沿着一条方向轴开始从左到右浏览。用户会更容易关注到页面的开始与结束区域，而中间的段落则很少被关注到。古腾堡揭示了一个实用的视觉轨迹规律：阅读引力是从上到下，从左到右

遵循古腾堡原则把关键信息放在左上角、中间和右下角，能够更好的体现元素的重要性。例如：我们平时所看到的页面弹窗、各种证明文件和合同文件等等

古腾堡图通过对设计元素的重量与元素布局和组成方式进行调和，指导眼睛的运动轨迹。让用户迅速获取有价值的信息，同时用户对信息的熟悉程度也是影响眼睛运动轨迹的因素之一

Read More

不同的性能测试方法适用于不同的应用领域去解决不同的问题，这里“不同的应用领域”主要包括能力验证、能力规划、性能调优、缺陷发现这四大方面。每个应用领域可以根据自身特点，选择合适的测试方法

能力验证

能力验证是最常用，也是最容易理解的性能测试的应用领域，主要是验证“某系统能否在A条件下具 有B能力”，通常要求在明确的软硬件环境下，根据明确的系统性能需求设计测试方案和用例

能力验证这个领域最常使用的测试方法，包括后端性能测试、压力测试和可靠性测试

能力规划

能力规划关注的是，如何才能使系统达到要求的性能和容量。通常情况下，我们会采用探索性测试的方 式来了解系统的能力

能力规划解决的问题，主要包括以下几个方面

• 能否支持未来一段时间内的用户增长
• 应该如何调整系统配置，使系统能够满足不断增长的用户数需求
• 应用集群的可扩展性验证，以及寻找集群扩展的瓶颈点
• 数据库集群的可扩展性验证
• 缓存集群的可扩展性验证

能力规划最常使用的测试方法，主要有后端性能测试、压力测试、配置测试和可靠性测试

Read More

常用的性能测试方法分为七大类: 后端性能测试(Back-end Performance Test )、前端性能测试(Front-end Performance Test )、代码级性能测试(Code-level Performance Test )、压力测试(Load/Stress Test )、配置测试(Confguration Test )、并发测试 (Concurrence Test )，以及可靠性测试(Reliability Test )

后端性能测试

平时听到的性能测试，大多数情况下指的是后端性能测试，也就是服务器端性能测试

通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段

性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应该包括各类资源的使用率，比如系统级别的CPU占用率、内存使用率、磁盘I/O和网络I/O等，再比如应用级别以及JVM级别的各类资源使用率指标等

后端性能测试的场景设计主要包括以下两种方式:

• 基于性能需求目标的测试验证
• 探索系统的容量，并验证系统容量的可扩展性

Read More

对于不同类型的系统，软件性能的关注点各不相同，比如:

• Web类应用和手机端应用，一般以终端用户感受到的端到端的响应时间来描述系统的性能;
• 非交互式的应用，比如典型的电信和银行后台处理系统，响应时间关注更多的是事件处理的速度，以及单位时间的事件吞吐量。

从终端用户(也就是软件系统使用者)的维度来讲，软件性能表现为用户进行业务操作时的主观响应时间. 包含了系统响应时间和前端展示时间.

性能测试分为后端(服务器端)的性能测试和前端(通常是浏览器端)的性能测试

Read More

代码级测试方法主要分为两大类:

• 静态方法,在不实际执行代码的基础上发现代码缺陷的方法，又可以进一步细分为人工静态方法和自动静态方法
• 动态方法,通过实际执行代码发现代码中潜在缺陷的方法，同样可以进一步细分为人工动态方法和自动动态方法

人工静态方法

通过人工阅读代码查找代码中潜在的错误方法,存在以下局限

• 过度依赖代码评审者个人能力
• 存在思维惯性
• 完全依赖人工,效率低

自动静态方法

通过词法分析、语法分析、控制流分析等技术，并结合各种预定义和自定义的代码规则，对程序代码进行静态扫描发现语法错误、潜在 语义错误，以及部分动态错误的一种代码分析技术.

常用工具有Sonar、Coverity等

自动静态方法通常能够以极低的成本发现以下问题:

• 使用未初始化的变量;
• 变量在使用前未定义
• 变量声明了但未使用;
• 变量类型不匹配;
• 部分的内存泄漏问题;
• 空指针引用;
• 缓冲区溢出;
• 数组越界;
• 不可达的僵尸代码;
• 过高的代码复杂度;
• 死循环;
• 大量的重复代码块

  Read More

移动应用专项测试的思路和方法
对于移动应用，顺利完成全部业务功能测试往往是不够的。如果你的关注点只是业务功能测试，那么，当你的移动应用被大量用户安装和使用时，就会暴露出很多之前完全没有预料 到的问题，比如:

• 流量使用过多;
• 耗电量过大;
• 在某些设备终端上出现崩溃或者闪退的现象
• 多个移动应用相互切换后，行为异常
• 在某些设备终端上无法顺利安装或卸载
• 弱网络环境下，无法正常使用
• Android环境下，经常出现ANR(Application Not Responding)

叉事件测试、兼容性测试、流量测试、耗电量测试、弱网络测试、边界测试这6个最主要的专项测试

交叉事件测试

交叉事件测试也叫中断测试，是指App执行过程中，有其他事件或者应用中断当前应用执行的测试。

比如，App在前台运行过程中，突然有电话打进来，或者收到短信，再或者是系统闹钟等等情况。所以，在App测试时，就需要把这些常见的中断情况考虑在内，并进行相关的测试。

此类测试目前基本还都是采用手工测试的方式，并且都是在真机上进行，不会使用模拟器

首先，采用手工测试的原因是，此类测试往往场景多，而且很多事件很难通过自动化的方式来模拟，比如呼入电话、接收短信等，这些因素都会造成自动化测试的成本过高，得不偿
失，所以工程实践中，交叉事件测试往往全是基于手工的测试。 其次，之所以采用真机，是因为很多问题只会在真机上才能重现，采用模拟器测试没有意义。

交叉事件测试，需要覆盖的场景主要包括:

• 多个App同时在后台运行，并交替切换至前台是否影响正常功能;
• 要求相同系统资源的多个App前后台交替切换是否影响正常功能，比如两个App都需要播放音乐，那么两者在交替切换的过程中，播放音乐功能是否正常;
• App运行时接听电话;
• App运行时接收信息;
• App运行时提示系统升级;
• App运行时发生系统闹钟事件;
• App运行时进入低电量模式;
• App运行时第三方安全软件弹出告警;
• App运行时发生网络切换，比如，由Wif切换到移动4G网络，或者从4G网络切换到3G网络等;

这些需要覆盖的场景，也是我们今后测试的测试用例集，每一场景都是一个测试用例的集合

Read More

搜索、管理、维护和生成测试数据包含了测试人员30%-60%的时间。这是一个不可否认的证据，数据准备是软件测试的一个耗时的阶段

创建测试数据

创建测试数据的方法主要分为三种:

1. API调用;
2. 数据库操作;
3. 综合运用API调用和数据库操作

对于创建数据的技术手段而言，最佳的选择是利用API来创建数据，只有当API不能满足数据创建的需求时，才会使用数据库操作的手段.(业务内部实现可能相对复杂)

Read More

测试重点应该在接口测试上

1. API测试用例的开发与调试效率比GUI测试要高得多，而且测试用例的代码实现比较规范，通常就是准备测试数据，发起request，验证response这几个标准步骤
2. API测试用例的执行稳定性远远高于GUI测试。 GUI测试执行的稳定性始终是难题，即使你采用了很多技术手段(这些具体的技术手段，我会在讲解GUI测试时再详细展开)，它也 无法做到100%的稳定
   而API测试天生就没有执行稳定性的问题，因为测试执行过程不依赖于任何界面上的操作，而是直接调用后端API，且调用过程比较标准。
3. 单个API测试用例的执行时间往往要比GUI测试短很多。当有大量API测试需要执行时，API测试可以很方便地以并发的方式执行，所以可以在短时间内完成大批量API测试用例 的执行
4. 现在很多互联网产品采用了微服务架构，而对微服务的测试，本质上就是对不同的Web Service的测试，也就是API测试。 在微服务架构下，客户端应用的实现都是基于对后端微服务的调用，如果做好了每个后端服务的测试，你就会对应用的整体质量有充分的信心。所以，互联网产品的API测试非常 重要
5. API接口的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性(Backward Compatibility)。所谓后向兼容性，最基本的要求就是保证原本的API调用方式 维持不变

显然，如果调用方式没有发生变化，那么原本的API测试用例也就不需要做大的改动，这样用例的可重用性就很高，进而可以保证较高的投入产出比(ROI)

Read More

测试工程师核心竞争力

测试工程师要具备的七项核心竞争力，包括:测试策略设计能力、测试用例设计能力、快速学习能力、探索性测试思维、缺陷分析能力、自动化测试技术和良好的沟通能力

测试策略设计能力

测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力

具备出色的测试策略设计能力，你可以非常明确地回答出测试过程中遇到的这些关键问题

1. 测试要具体执行到什么程度
2. 测试需要借助于什么工具;
3. 如何运用自动化测试以及自动化测试框架，以及如何选型;
4. 测试人员资源如何合理分配;
5. 测试进度如何安排
6. 测试风险如何应对

测试策略设计能力一定是需要你在大量实践的基础上潜移默化形成的。
我认为，测试策略设计能力是功能测试工程师最核心的竞争力，也是最难培养的

Read More