认识达内从这里开始

随着互联网的不断发展，越来越多的关于软件测试方面的技术与经验总结的分享出现在了网络上。今天，我们就一起来了解一下，软件测试方面的性能设计都有哪些特点。

其实性能设计就是以目的出发的。

可以考虑一下几个方面：

测试数据(基础数据、业务数据)不多解释这个文章中有。

测试场景(基础场景、综合场景)场景一定要同业务过，看看是不是真实的，或遗漏了。好是用户，而非业务。

参数化策略(如何参数化、如何取数、数据用完后怎么办等，这个后面的Chat会分享)。

集合点策略(全部虚拟用户都到了在压，还是等到%XX就可以压，还是业务成功达到多少在压)。

检查点(又叫断言，判读事务是否成功)这是很多初学同学容易遗漏的。

环境(网络、服务器配置、防火墙等、中间件配置、定时任务频率、应用配置等)。

负载机情况，需要把负载机的监控纳入监控范围。(很多失败原因都是没有关注负载机情况导致测试走弯路),这也是常见问题。需要特别说明的是“网络”这是也是遇到多的问题。(可能负载机的网络带宽限制，导致无论怎么样压，压力都上不去，一直找不到原因)。

问：经常看到有很多同行或者同事做的性能场景很复杂(非综合场景)，需要很多步骤组成，写的脚本也很长，当然我本人没做过那么复杂的，不知道实际情况，所以我想问一下是不是实际上真的存在这么复杂场景的性能测试，或者这些很复杂的场景是否可以简化成对某个接口的测试?

答：脚本一定不要太长，能抽象一定抽象，太长自己看不到逻辑关系。所有我写脚本都会先写伪代码。建议大家也这么做，先设计表格，依照表格写伪代码。比如刚刚的场景用例设计表格。文字好懂，代码不易懂。然后能抽象出去的就抽象出去。需要加的关键点都在场景设计和用例设计时一表格的形式列出来，专家也好评审。对于接口测试，你的思路是对的，我们可以拆解，但接口测试代替不了页面测试。

提前做接口的，甚至先让研发做单元的性能测试(多线程压一下)。数据从后端到前端，浏览器要渲染等操作会占用这个响应时间，所以接口OK了，还要测

提前做接口的，甚至先让研发做单元的性能测试(多线程压一下)。

数据从后端到前端，浏览器要渲染等操作会占用这个响应时间，所以接口OK了，还要测页面。

另外前端性能也是一个大的方向，比如，js/图片/css，缓存等。其实性能测试还要考虑好缓存到底能不能模拟真实情况。缓存在性能测试中干扰多，又是是需要缓存来模拟真实情况，但有时参数化有会导致不需要的缓存出现。所有参数化，是结合业务的一门学问。静态服务器，就是静态资源下载带来的压力。

问：如果部署环境和测试环境不一致，如何在性能测试过程中的测试结果具有代表性?和可证明性。

答：这个需要一定的换算标准。当然有些土豪公司就是一比一的设备来进行测试。测试的配置是否与生产一致。如果测试的配置与生产一致的话。可以按照乘以它的百分比，咱后再乘以70%。这样的话就建议提服务器的人通常同配置，这样便于你计算。如果没有这种等比例的配置，算起来就比较麻烦。服务器型号不同，没有关系，但CPU的核数，以及CPU的频率以及内存。包括你的中间价，你的网络。建议越接近的配置好。

问：https的手机端，在开发给不出靠谱的接口文档的时候，如何录制或抓取数据流，公司主要用的lr。

答：可以让研发做一些单元压力测试。完善后再做，不建议用lr，可以换jmeter试试。

问：如何快速定位数据库问题?有没有好的实例讲解?用LR如何做到?

答：可以先做一部分，比如说你先解决，性能测试监控指标，回传和展示。数据库的问题和建议进行数据库相关设置。比如说慢sql，比如spitlight工具。慢sql会记录所有系统查询较慢的sql语句，根据语句找到相应代码进行优化。根据语句，找到相应代码进行优化。

作/译者：鲁德

节选：公众号：鲁德

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。