LoadRunner知识总结.docxVIP

LoadRunner知识总结需求分析正规：分析需求，需求方面的测试（功能有无重复，有没有遗漏，有没有二义性，有没有不同的），提取需求点，不正规：产品，项目。绿色通道？经常调用的模块；关键业务；业务量大的模块；问下开发，测试组长，自己模拟客户习惯自己画出功能结构图（上网查，询问需求人员，然后把思路写出来，根据自己的理解画出来）看实际效果和他们确认是不是这样的指标提取并发数：如果没有要求，根据业务量和时间段去算。业务量可以问一下客户，也可以问问开发或者凭自己的经验，时间段可以询问客户，或者查看系统日志，但是前提是有系统日志。如果什么都没有的话可以用2，8原则。响应时间：响应时间不包括思考时间，仅仅是服务器的响应时间，一般遵循2，5，8，10的原则，并且大多数情况下要求响应时间在5S之内。业务成功率：一般要求100%系统资源占用：包括CPU，内存，网络，硬盘，其它。一般都要在75%以下，这是经验值。但是网络带宽一般是50%以下。最后形成这样的一张表格：测试点并发数响应时间业务成功率CPU内存5s100%75%75%建立模型深入分析系统业务流程，考虑以下几个方面：有没有约束条件业务逻辑方面：系统中对数据有没有唯一性系统中有没有消耗性数据（用完数据就丢了）有没有需要特殊说明的在注释中写出来需要做关联，文本检查点和集合点的地方设计用例约束条件，操作步骤，期望值，测试项。测试数据，如果是参数化了的，写一个数据，后面括号，参数化。尽量在这里考虑全录制脚本录制脚本的时候最重要的是选择协议数据库ODBC选择协议出错代码为空的首先知道什么协议（问程序员），划分Action编译，回放脚本LR可以随机链接其他页面，做参数化即可优化脚本做完以后进行语法检查进行回放——看是否需要参数化和关联系统对客户端输入的东西有唯一性要求：做参数化（Log中的参数替换勾上，看参数化是否正确）服务器给客户端的东西不同：做关联文本检查点成功标志位树视图下界面上面，右键添加文本检查点Server下找相应的字段到界面的源代码下去找调优比较测试事务点：分析结果的时候可以确定响应的结果，确定代码在哪一块有问题，比Action更细化，反应响应时间。集合点：并发函数：手写，帮助，包括思考时间等思考时间：凭经验关联：手动，自动参数化：9种文本检查点：功能是否正确，返回标志位注释回放脚本迭代次数和唯一数场景设计场景执行计划三个1）不断加压：考验系统接受请求的响应的性能2）在一定的压力下持续运行3）有没有内存方面的Runtimesetting设置思考时间检查点Continue on error集合点的策略，三个选项超时的设置负载生成器：一定要开启服务IP欺骗：系统对IP登录有限制的时候场景执行设计几个场景？单独的加一个综合场景综合场景的并发数：收集结果一些概念性能：表现（相应时间，系统资源的占用，多用户情况下能支持多少人使用）系统用户注册用户在线用户正在使用中的，是存在时间的（session）并发用户点的概念，所有用户同时操作PVPageview。比如：日均200万的PV页面访问，指的是业务量，而不是并发。响应时间用户发出的请求经过服务器的处理再返回结果的时间考虑的主要是数据库的而不是网络的，网络的延迟一般可以忽略业务成功率吞吐量服务器接收了多少数据量，返回了多少数据量使用在系统资源耗用性能测试负载测试负载测试就是通过逐步增加系统负载，测试性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。压力测试负载测试就是通过逐步增加系统负载，测试性能的变化，并最终确定在什么负载条件下系统性能处于失效状态。容量测试一些问题：你遇到过什么性能问题？（什么时候碰到的？）Alex排名页面打不开奥运会订票的服务器曾经因为访问的人数多被挤垮春节短信发布出去等电梯什么对象存在性能问题？性能问题通常的情况有哪几类？对用户的影响有哪些？如何避免这些问题？（面）功能测试怎么测？所有的内容都要往项目上靠e.g.这个问题我们公司是这么做的：比如我们拿到的某某项目，组长看了需求，进行小组分配，我当时负责某某模块，我看相关的需求和帮助文档，根据小组的需求写用例，我们当时用的是某某工具。Tips：先看一下公司的情况，如果公司很小，说明不正规，就不要说太正规的东西。给一个网站，比如163，怎么测？分成两块：静态和动态响应时间界面布局。不同的分辨率能不能正常显示。有没有图片无法显示。CSS有没有问题。Title能不能概要的说明网站的主要内容。目的：标题的描述和当前页面所要实现的功能是否一致。页脚有没有“脚本错误”。目的：不同的浏览器支持的脚本语言是不一样的，看看有没有脚本错误。脚本错误有两种，确定后正常，确定后有死循环或者其他错误。body有没有错别字，字体设计是不是一致。比方说用户名后面的冒号是半角，密码后