LoadRunner

软件测试面试题（一） 软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne） 测试用例 用例编号 　测试项目 　测试标题 　重要级别 　预置条件　 输入数据 　执行步骤　　 预期结果 1 、问：你在测试中发现了一个bug ，但是开发经理认为这不是一个bug ，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试

一、首先明白接口是什么 软件接口是指程序中具体负责在不同模块之间传输或接受数据的并做处理的类或者函数。（而不是指传输的数据！！） 二、什么是接口测试 接口测试就是通过向接口传递数据来测试这个接口是否正确。比如：一个QQ登录功能接口，就需要我们传递QQ号和密码去验证这个登录接口是否正确，能否使用。 三、进行接口测试需要掌握哪些知识 1、了解系统及内部各个组件之间的业务逻辑交互； 2、了解接口的I/O（input/output：输入输出）； 3、了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等； 4、常用的接口测试工具，比如：apipost、jmeter、loadrunner、soapUI等； 5、数据库基础操作命令（检查数据入库、提取测试数据等）； 6、常见的字符类型，比如：char、varchar、text、int、float、datatime、string等； 四、如何学这些技能？ 1、系统间业务交互逻辑：通过需求文档、流程图、思维导图、沟通等很多渠道和方式； 2、协议：推荐《图解http》这本书，内容生动，相对算是入门级的书籍，其他的还有《图解tcp、IP》等； 3、接口测试工具：百度这些工具，然后你会发现，好多的教学博客、相关问题解决方案、以及一些基于工具的书籍，当然，选择合适的书很重要； 4、数据库操作命令

一、首先明白接口是什么 软件接口是指程序中具体负责在不同模块之间传输或接受数据的并做处理的类或者函数。（而不是指传输的数据！！） 二、什么是接口测试 接口测试就是通过向接口传递数据来测试这个接口是否正确。比如：一个QQ登录功能接口，就需要我们传递QQ号和密码去验证这个登录接口是否正确，能否使用。 三、进行接口测试需要掌握哪些知识 1、了解系统及内部各个组件之间的业务逻辑交互； 2、了解接口的I/O（input/output：输入输出）； 3、了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等； 4、常用的接口测试工具，比如：apipost、jmeter、loadrunner、soapUI等； 5、数据库基础操作命令（检查数据入库、提取测试数据等）； 6、常见的字符类型，比如：char、varchar、text、int、float、datatime、string等； 四、如何学这些技能？ 1、系统间业务交互逻辑：通过需求文档、流程图、思维导图、沟通等很多渠道和方式； 2、协议：推荐《图解http》这本书，内容生动，相对算是入门级的书籍，其他的还有《图解tcp、IP》等； 3、接口测试工具：百度这些工具，然后你会发现，好多的教学博客、相关问题解决方案、以及一些基于工具的书籍，当然，选择合适的书很重要； 4、数据库操作命令

一、首先明白接口是什么 软件接口是指程序中具体负责在不同模块之间传输或接受数据的并做处理的类或者函数。（而不是指传输的数据！！） 二、什么是接口测试 接口测试就是通过向接口传递数据来测试这个接口是否正确。比如：一个QQ登录功能接口，就需要我们传递QQ号和密码去验证这个登录接口是否正确，能否使用。 三、进行接口测试需要掌握哪些知识 1、了解系统及内部各个组件之间的业务逻辑交互； 2、了解接口的I/O（input/output：输入输出）； 3、了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等； 4、常用的接口测试工具，比如：apipost、jmeter、loadrunner、soapUI等； 5、数据库基础操作命令（检查数据入库、提取测试数据等）； 6、常见的字符类型，比如：char、varchar、text、int、float、datatime、string等； 四、如何学这些技能？ 1、系统间业务交互逻辑：通过需求文档、流程图、思维导图、沟通等很多渠道和方式； 2、协议：推荐《图解http》这本书，内容生动，相对算是入门级的书籍，其他的还有《图解tcp、IP》等； 3、接口测试工具：百度这些工具，然后你会发现，好多的教学博客、相关问题解决方案、以及一些基于工具的书籍，当然，选择合适的书很重要； 4、数据库操作命令

文章首发于公众号：程序员一凡 企业中如何实施自动化测试 在我们读高中的时候， 是不是经常听老师说： 学好数理化，走遍天下都不怕。 作为软件测试这个行业，在当下， 你学好自动化，你去哪面试都不怕。 说是这么说，但是你想提前下班，自动化测试解放劳动力、提高效率，让程序脚本在不需要看守的情况下“起飞”如果你的代码、脚本掉到了坑里，你觉得你还能提前下班吗？ 有可能，你甚至不如别人做功能测试的。别人一个功能都测试完好久了，你的自动化脚本报了一堆错，还不知道找这个错误的原因。自然你的自动化做不起来，自动化的价值体现不出来。 所以，我针对我们Python自动化测试中基础容易遇到的一些坑，进行一些 实战的案例讲解 。 在讲这一些坑之前，先给大家分享一下我对自动化测试概念的理解。 在做自动化测试之前，我们要思考一个问题。自动化不是说你会写一点简单的自动化脚本，你就能来实施。你要有一个规划，再去慢慢的推进落地。 我总结了几点： 1.根据业务特点，选择自动化测试方案。 ⒉.根据业务侧重点确认自动化覆盖范围和粒度。 3.根据自动化测试用例范围，选择实现框架和语言。 4.根据用例用途，选择执行策略。 （1）你在一个公司，你的产品是什么样子的，根据你产品的业务特点，你去选择确定一个自动化测试方案，这个很重要。比如说你们公司主要注重业务特点是数据库或者后端的一些内容（有些产品注重前端的界面）

引言 在做学习性能测试之前，有必要先了解一些性能测试的理论基础知识，为后期的性能测试做准备。需要了解什么是软件性能，性能测试需要关注的内容；了解在性能测试过程中常用的相关术语以及性能测试过程中需要关注的指标；了解性能测试的划分和应用领域，这样可以更好的确定需要进行那些性能测试。 性能测试相关术语 了解了什么叫系统性能之后，需要对性能测试过程中常用的术语有一个详细的了解，为后面的性能测试做准备。下面介绍性能测试过程中的一些常用术语，性能测试过程中的常用术语有：响应时间、并发用户数、事务响应时间、吞吐量、吞吐率、TPS（每秒事务响应数）、性能计数器等。 响应时间 响应时间是指应用系统从发出请求开始到客户端接收到所有数据所消耗的时间。该定义强调所有数据都已经被呈现到客户端所花费的时间，为什么说是所有数据呢？因为用户体验的响应时间带有主观性，用户认为从提交请求到服务器开始返回数据到客户端的这一段时间为响应时间。以一个Web应用的页面响应时间为例，从客户端发送请求到服务处理完成的整个过程如图1-3所示。从图中可以看到，页面的响应时间可分解为“网络传输时间”（N1+N2+N3+N4）和“应用服务器处理的时间”为（A1+A3），“数据库处理的时间”为（A2），所以整个Web页面请求的响应时间为（N1+N2+N3+N4+A1+A2+A3）。 并发数用户数

背景 随着业务不断发展，用户量不断增加，系统负载越来越高。为了解决系统负载问题，我们是不是直接大量增加机器就可以了？ 同时，公司业务开展需要，可能需要开展各种营销活动，目前系统是否能够支持那么多用户也是个未知数，如何解决呢？ 答案就是今天要讲的压测。 目的 验证单个业务及整个的处理能力及响应时间等 验证系统的性能瓶颈 合理的容量规划，而不是大量增加 分类 单接口压测 全链路压测 性能测试指标 业务类 TPS 相应时间 - 平均响应时间、最小响应时间、最大响应时间、90%响应时间等 - 百分位数是一个统计学名词。99% 的百分位响应时间，指的是 99% 的请求响应时间都处在这个值以下。 - 如果99%响应时间跟平均响应时间相差很大，那么说明是抗不住这么大量的，需要做相应调整及优化 业务成功率 - 压测前要确定压测的业务成功率，不能把报错的数据当做压测结果，一般可以定业务成功率最少为1% 系统资源指标 CPU使用率 内存使用率 磁盘繁忙率 网络IO 全链路压测 目的 只做单系统压测是不够的，因为在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。 为什么选择线上环境做全链路压测

性能测试中最容易被误解的部分之一就是 负载测试 。大多数人认为所有性能测试就是负载测试，但这是不准确的。有许多类型的测试组成 性能测试 。在进行负载测试之前要考虑的问题之前，让我们仔细研究一下负载测试的基本信息。 LoadRunner 的基本一种定义： 负载测试是许多并发用户运行同一程序，以查看系统基础结构是否在不影响功能或性能的情况下处理了负载。 还有一种说法将 负载测试 解释为： 负载测试是性能测试的子集。比如说性能测试相当于 Microsoft Office ，而负载测试就是 Word 。 Word 只是 Office 的一个组成部分。 Word 与 Excel 一起被大量使用。它们可能是 Office 使用最频繁的两个组件。 以下是准备进行负载测试时要考虑的N种策略。 针对正确的测试量 首先，不要在没有实际需要的情况下进行大规模测试。无需向软件施加超出实际预期的压力。 当然产生环境比预期拥有更高的流量负载始终是一件好事，但要保持现实和高效，应该专注于评估应用程序在生产中将遇到的正确工作负载。 以方便取决于周期性性事件，网站或APP可能会在一个以上高峰或高峰负载时间内遇到流量峰值。但是建议在着重负载测试之前首先通过模拟或者监控正常一天的吞吐量来开始负载测试。 这里的关键词是 吞吐量 ，这是另一个经常被误解的性能测试。系统吞吐量是指系统在单位时间内所处理的信息量

LoadRunner性能测试Analysis分析器的Analysis分析器摘要报告，这期我们来讲讲，Analysis常见图分析。 在分析视图时通常会先分析一些常用的视图，之后才会分析其它的一些相关数据，通常分析的视图有：Vuser图、点击率视图、平均事务响应时间视图和吞吐量视图。在LoadRunner分析器中对资源使用的情况分析的很少，因为通常在性能测试过程中很少使用LoadRunner来监控系统资源的使用，特别是Linux、Unix和AIX操作系统，几乎不使用LoadRunner来监控，更多的是借助第三方式工具来监控，当然如果服务器是Windows操作系统，那么使用LoadRunner进行监控比较简单。 Vuser图 在方案执行过程中，Vuser在执行事务时生成数据。使用Vusers图可以确定方案执行期间Vuser的整体行为。它显示Vuser状态和完成脚本的Vuser的数量。将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。 这里包含两种图：正在运行的Vuser图和Vuser摘要图。 正在运行的Vuser图显示在测试期间的每一秒内执行Vuser脚本的Vuser数量及它们的状态。可以帮助确定任何给定环境中服务器上的Vuser负载。默认情况下，此图仅显示状态为Running的Vuser。当然可以更改筛选条件来查看其他状态的Vuser情况。

上期讲到LoadRunner性能测试脚本编写检查函数，这期我们来讲讲Block(块)技术和参数化。 Block（块）技术 在使用LoadRunner时经常遇到这样一个问题，如果对不同的事务进行不同次数的循环该怎么处理？默认情况下LoadRunner对所有的事务都是统一执行的，即虽然有多个事务，但它们被执行的循环次数都是一样的，那么LoadRunner如何在一个脚本中实现不同事务不同次数的循环或不同百分比的循环呢？ 案例：假设在一个脚本中，想实现注册执行3次，登录执行1次，查询执行2次，怎么办？录3个脚本？每个事务分别在脚本中复制N次？这样是可以解决问题，但不是最好的解决办法，LoadRunner提供了对业务流程的处理方法，即Block（块）技术。 首先，借用LoadRunner自带的订票系统，录制好这三个脚本，录制结束后，脚本如图所示，包含三个业务：注册，登录和查询。接着，对脚本中的三个业务的迭代次数进行设置，这里使用到的是Block（块）技术。 1.进入菜单Vuser→Run-timeSettings，弹出Run-timeSettings对话框，选择General→RunLogic选项卡. 2.选择Run，插入一个Block块，如图所示。 3.选择Block0，点击InsertAction按钮，弹出SelectActions对话框，如图所示，选中要添加的Action