对一个开发人员来说，除了保质保量按时完成功能需求外，非功能也不可忽视。
决定一个软件的成败往往是非功能性需求比如性能，若是用户体验不好那么必定是个失败的作品。
那么一个开发人员如何去做关于自己模块又或者整体的基准性能测试呢？以下将从测试的切入点和具体测试的指标来说明。
切入点：
通常，基准性能测试有两个切入点，一方面可以通过从整体系统的角度做一个全栈式(即打通上下各层)的性能测试用于发现整体系统的性能瓶颈点，另一方面又可以具体到某个层或者模块进一步分析性能问题。
测试目标：
从定量工具的角度来说性能测试一般关注以下3点：
1. 单位时间内系统处理请求、事务的次数：比如测试模块的接口性能，可以针对一个接口调用N次并求平均值。
2. 响应时间（延迟）：目的是求出最大响应时间和最小响应时间，并对响应性能做一个预估用百分法来表示。比如对一个接口或协议发起请求10次，若有一次响应时间大于10ms，其他都小于10ms，那么可以说针对该接口有90%的概率系统响应时间小于10ms，当然要求准确的话需要更多地测试。
3. 吞吐量：这里的指标常有如IOPS，常见于测试存储系统的性能测试用于发现系统最大流量。
从测试价值的角度来说性能测试还需要以下2点：
1. 可伸缩性
可伸缩性需要和单纯的性能测试区别开，当系统只有一个访问者无其他负载的情况下为单纯的性能测试，若有性能问题可从代码、设计上分析研究。而伸缩性指得是在整个系统负载变化的情况下（比如增加访问者并发量），要求系统保持一定的性能（响应时间、吞吐量）。测试过程中可以尝试对测试环境的硬件进行扩展（垂直、横向扩展都行），看性能是否能够在持续增压的条件下满足性能需求。在持续对系统增加并发访问量的情况下通过查看系统的持续响应时间基准测试结果发现系统的设计缺陷。从一定层度上来讲，系统的伸缩性在设计上就已决定。
2. 并发性
对于并发通常有各种理解，但是对于系统性能测试领域来说，更准确地评判服务器的并发性指得是高峰时期单位时间内的请求数。对我们来说更多应该关注的是工作的并发量，比如同时处理请求的线程数或连接数。并发测试更多地是以一种辅助的手段配合性能测试，比如通过并发的手段持续加压达到测试系统伸缩性的目的。
最新内容请见作者的GitHub页：http://qaseven.github.io/
