然而，随之而来的是软件Bug和崩溃问题，这些问题时常让用户感到困扰。就比如国庆假期之前，有网友反映国内火车票订购网站12306的软件出现崩溃问题，这不仅给乘客带来不便，也再次引发了对软件性能测试的关注。
多家企业性能测试面试题目
在当前“金九银十”的职业招聘季，很多企业面试时性能测试的问题更是必不可少，虽然，各企业性能面试题目略有差异，但很多题目的答案都是一样的，这种类型的性能测试题目搜集如下：
（来自网络）
性能测试面试题目解答
针对以上题目，可以用同一个答案，完整的性能测试过程如下：
其中，“分析性能需求”需要详细说明，详细内容如下。
性能需求从3个方面进行分析：
性能测试内容
性能测试内容包含如下6个内容：
（1）涉及哪些子系统；
（2）软件主干功能；
（3）访问量较大的功能；
（4）业务逻辑复杂的功能；
（5）数据量较大的功能；
（6）特殊场景。
性能测试类型
性能测试类型分为两大类型，具体如下：
（1）后端服务器性能测试（使用工具JMeter）
该类性能测试包括：
并发量性能测试，包括：基准测试、负载测试、压力测试、稳定性测试；
数据处理能力的性能测试，包括：基准测试、负载测试、压力测试、稳定性测试。
（2）客户端性能测试(使用工具adb、solopi、monkey)
性能测试指标和预期结果
性能测试指标和预期结果，根据性能测试类型不同，分为如下：
（1）后端服务器性能测试
聚合报告里的指标：
并发量(并发量性能测试指标)：根据具体项目估算预期结果，没有统一标准；
响应时间：符合1-3-5或2-5-8s规则(根据具体项目要求选择)；
吞吐率(数据处理能力的性能测试指标)：使用2-8原则(80%的业务数据在20%的时间内处理完成)计算得出预期结果(根据软件具体业务计算)；
事务成功率：一般95%以上，支付功能：大于99%；注册功能：100%；特殊主流程功能：99%以上等等。
资源监控报告的指标：
CPU：不超过80%(上下浮动5%)；
内存：不超过80%(上下浮动5%)；
网络：不超过80%；
磁盘：不超过90%。
（2）客户端性能测试指标
冷热启动时间：预期结果：2-3-5s；
fps：帧率标准：每帧低于16ms，每秒60帧左右；
gpu：
1、控制过度绘制为2x；
2、非强制gpu的情况下，无红书区域，即，无4x过度绘制情况；
3、浅红色区域总面积不超过屏幕的1/4或1/3。
安装包物理内存：36MB左右；
CPU：
1、空闲，CPU占有率：0%；
2、模拟用户常用功能运行，CPU不超过：30%；
3、长时间运行应用，CPU不超过：50%；
4、高负荷运行时，CPU不超过：75%。
耗电量：一般不超过：10MB/小时；
流量：不超过10M；
页面切换时间：遵循3-5-8s原则；
稳定性测试：monkey+solopi，以上指标都在预期结果之内。
备注：以上性能指标及预期结果只是性能测试行业的一般规则，根据项目具体要求可做相应的调整。
做好以上性能测试软件就不会出现性能问题了吗？答案是否定的，比如，最近出现的12306系统崩溃事件。
12306系统崩溃
中秋国庆火车票开售，12306订票系统崩溃：
那么12306系统崩溃的原因是什么？我们测试工程师如何在性能测试过程中加强性能测试将如上问题“扼杀在摇篮里”？开发工程师需要如何优化以上的问题呢？
12306系统崩溃的原因
12306系统崩溃的原因揭晓：瞬间访问量过大或因第三方脚本。
根据最新数据显示，是因为瞬间访问用户量过大，系统无法正常响应。这可能是由于未经授权的第三方应用程序或脚本导致，他们通过利用某些特定时间窗口的规则来批量获取车票，而这时12306系统的访问量达到了峰值，最终导致了系统的崩溃。
分析以上原因可得出12306系统崩溃的具体问题如下：
服务器负载过重
针对瞬间访问量过大问题，12306可以在系统架构和算法上进行优化，比如采用分布式架构、负载均衡、限流等技术手段来提升系统的可扩展性和稳定性。
同时，也可以引入缓存技术来减轻数据库等核心组件的负载，缩短响应时间，提高并发处理能力。
代码Bug
软件Bug是导致系统崩溃的常见原因之一。这些Bug可能包括代码中的逻辑错误、未处理的异常情况、内存泄漏等。
安全问题
针对第三方应用程序和脚本的问题，12306可以通过加强系统的安全性和防护措施来防止未经授权的访问和恶意攻击。例如增加验证码、IP限制、封禁脚本等手段，维护购票秩序和公平性。
网络问题
12306系统依赖互联网来处理用户的请求和数据传输，在购票高峰期，由于网络流量过大，网络拥堵可能导致用户无法正常访问系统或者系统无法正常处理用户请求，从而引发系统崩溃。
可采用：负载均衡、WAN优化和SD-WAN、虚拟端口通道(vPC)或叶脊架构等方法解决网络拥堵拥塞问题。
12306系统崩溃原因找到了，可是我们测试工程师怎样才能在软件测试阶段将问题暴漏出来，而不是待系统上线并发生崩溃后“事后诸葛亮”式的去排除问题、分析问题？
小编认为：对于12306系统崩溃的问题，性能测试过程中一般的测试场景很难将问题暴漏，需要模拟系统特殊场景(第三方应用程序或脚本)。
即根据真实场景，在负载测试、压力测试和稳定性测试过程中，模拟第三方应用程序、自动化脚本和虚拟用户同时并发的场景。
启示
这次事件提醒我们：在互联网时代，用户对于软件的要求越来越高，对软件的操作方式越来越多，我们软件测试工程师的角色至关重要，我们不仅需要持续学习和跟踪新的测试方法和工具，还需要深入了解用户实际的操作场景。
只有这样，性能测试时，才能模拟到用户的真实场景(第三方应用程序或脚本)，性能场景模拟越真实，性能测试的效果越明显。
也只有通过这样的不懈的努力和严格的测试，我们才能构建更加稳定和可靠的软件，为用户提供更好的体验。
以上是小编的个人见解共大家参考，如果有不同思路可共同探讨。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
