软件测试-软件测试总结

功能测试

测试的目的

• 降低软件开发成本和维护成本
• 寻找错误，尽最大可能找出最多的错误。
• 核实软件的所有构件是否正确集成
• 核实所有需求是否已经正确实施
• 确定缺陷幵确保在部署软件前将缺陷解决
• 提高软件产品的质量

软件测试的原则

• 尽早的和不断的进行软件测试
• 测试用例应该由输入和与之不对应的预期输出组成
• 程序员应避免测试自己的程序
• 在设计测试用例时，应包含合理输入和不合理输入
• 充分注意测试中的群集现象
• 严格执行测试计划，排除测试的随意性
• 对每一个测试结果做全面检查
• 妥善保存测试计划、测试用例、出错统计和最终分析报告

软件的安全性应从哪几个方面去测试

• 软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
• 用户认证安全的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入 系统 、系统网络安全的测试要考虑问题 、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击，看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞。
• 数据库安全考虑问题： 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据 的不完整，对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独立性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

软件测试的策略

在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

测试人员在软件开发过程中的任务

• 尽可能早的找出系统中的Bug；
• 避免软件开发过程中缺陷的出现；
• 衡量软件的品质，保证系统的质量；
• 关注用户的需求，并保证系统符合用户需求。
• 总的目标是：确保软件的质量。

你认为测试人员需要具备哪些素质

好的测试基础理论；首先要有一定的沟通协调能力，因为测试人员经常会与开发人员接触处理一些问题，需要心平气和地沟通。还需要有一定的耐心，不能放过每一个错误；要有责任感，要尽自己最大的能力，保证产品的质量。要有好奇心，保持一种怀疑的态度，测试人员的任务是找出缺陷，不是证明没有缺陷，所以需要保持怀疑。要细心；乐观；

测试的阶段

测试尽早进行。越早就可以花越少的消耗得到越大的回报。

• 单元测试(Unit Testing)
  　　单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。Findyou又称为模块测试
  测试阶段：编码后
  测试对象：最小模块
  测试人员：白盒测试工程师或开发工程师
  测试依据：代码和注释+详细设计文档
  测试方法：白盒测试
  测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
• 集成测试(Integration Testing)
  　　集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。阿旺主要目的是检查软件单位之间的接口是否正确。
  测试阶段：一般单元测试之后进行
  测试对象：模块间的接口
  测试人员：白盒测试工程师或开发工程师
  测试依据：单元测试的模块+概要设计文档
  测试方法：黑盒测试与白盒测试相结合
  测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
• 系统测试(System Testing)
  　　将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段
  测试阶段：集成测试通过之后
  测试对象：整个系统（软、硬件）
  测试人员：黑盒测试工程师
  测试依据：需求规格说明文档
  测试方法：黑盒测试
  测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
• 验收测试(Acceptance Testing)
  　　验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。阿旺总结验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
  测试阶段：系统测试通过之后
  测试对象：整个系统（包括软硬件）。
  测试人员：主要是最终用户或者需求方。
  测试依据：用户需求、验收标准
  测试方法：黑盒测试
  测试内容：同系统测试(功能…各类文档等)
• 集成测试和系统测试之间的比较：
  1、测试内容：集成测试是测试各个单元模块之间的接口，系统测试是测试整个系统的功能和性能；
  2、测试角度：集成测试偏重于技术的角度进行测试，系统测试是偏重于业务的角度进行测试。

测试的类型

• 功能测试：关注功能正常（包含兼容性测试），除了下面分类都测；
• 性能测试：关注（比如前端性能、后端性能）,APP性能，服务器性能，数据库性能，网络性能等；
• 安全测试：关注传输、存储等安全；
• 特性测试：特性指平台差异(即部分兼容性测试)，如PC端鼠标，键盘操作特性(Tab键等)；如手机触屏操作，横竖屏，中断恢复(来电)等

Linux常用命令

Linux命令有哪些，分别都有什么作用？

• 系统管理命令：
  su 切换账户
  Ifconfig 查看IP地址
  Ping 检查网络是否连接
  Kill 杀死进程
  Kill -9 强制杀死
• 系统资源查询命令：
  ps 查看进程：
  Ps -ef 查看所有的进程
  Netstat 查看网络状况
  Netstat -apn 查看所有的端口
• 管道命令：
  Ps -ef | grep tomcat 查看所有进程，通过管道找到相应的进程包名
  Kill -9 杀死进程
  Chmod 赋权命令 chmod -R 777 XIAOBAI
• 目录操作命令：
  cd tomcat 进入目录里面
  cd / 根目录
  pwd当前目录
  mkdir 创建目录
  rmdir 删除目录
  ls ll 查看所有的目录
• 文件编辑就命令：
  vi a.txt 编辑文件
  Cat a.txt 查看文件
  rm -rf 强制删除
  find / -name .txt 在根目录下面查找txt文件
• 文件解压压缩命令：
  压缩 tar -czvf test.tar.gz.test 将文件压缩成.test.tar.gz
  解压 tar -xzvf test.tar.gz.test将文件解压成.test.tar.gz

post请求的四种参数形式是什么

• application/x-www-form-urlencoded
• multipart/form-data
• application/json
• text/xml

http状态码302, 403, 503分别代表什么

• 302 临时性重定向，该状态码表示请求的资源已经分配了新的URL，希望用户本次能使用新的URL
• 403 服务器理解请求客户端的请求，但是拒绝执行此请求
• 503 服务器目前无法使用

公司有用到第三方服务，出了问题，打电话给第三方，第三方不承认，这时候日志又显示不到错误，应该怎么处理

• 单独调用第三方服务，查看返回结果；
• 引入mock机制，假如正常返回的情况下，测试我们的系统是否存在问题；
• 建议开发增加日志，详细记录调用第三方接口的过程，记录调用前接口入参，返参等信息；

get和post的区别

• GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
• GET书签可收藏，POST为书签不可收藏。
• GET能被缓存，POST不能缓存 。
• GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
• GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
• GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
• GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！
• POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。GET的数据在 URL 中对所有人都是可见的。
• POST的数据不会显示在 URL 中。

做接口测试时，为什么选择Jmeter而不选择Postman？原因是什么？

• 从功能上：
  Jmeter：最为强大，可以测试各种类型的接口，不支持的也可以通过网上或自己编写的插件进行扩展。Postman：更是轻量级，定位也不同，可用来测试Rest接口。
  Jmeter：可以在线程组里添加HTTP、TCP或WebSocket的Sampler。
  Postman：仅支持Rest接口。
• 从流程控制上：
  Jmeter：由Switch控制器、If控制器、随机控制器等一系列控制器实现流程控制，以及Beanshell脚本
  Postman：通过JavaScript脚本控制
• 从数据业务分析上：
  Jmeter：有各种监听器，统一的Jmeter log，监听器可导出到文件，并可导出JTL、CSV文件、通过插件可导出HTML
• 在断言上：
  Jmeter：TestPlan、Threads Group、Sampler均可添加断言
  Postman：请求的Tests中可添加断言
• 从脚本扩展能力上：
  Jmeter：Bean shell（Java）
  Postman：JavaScript
• 从团队协作上：
  Jmeter：一个TestPlan也是一个jmx（xml）文件，无法分割，但Jmeter有一个合并的功能，允许将多个文件合并在一起。只能每个团队成员自己建立一个TestPlan，分功能块进行测试。最后整理合并。
  Postman：有团队协作的功能，需要付费。

在以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

一条Bug记录最基本应包含：

• bug编号；
• bug严重级别，优先级；
• bug产生的模块；
• 首先要有bug摘要，阐述bug大体的内容；
• bug对应的版本；
• bug详细现象描述，包括一些截图、录像…等等；
• bug出现时的测试环境，产生的条件即对应操作步骤；

高质量的Bug记录

• 通用UI要统一、准确
  缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
• 尽量使用业界惯用的表达术语和表达方法
  使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
• 每条缺陷报告只包括一个缺陷
  每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
• 不可重现的缺陷也要报告
  首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
• 明确指明缺陷类型
  根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
• 明确指明缺陷严重等级和优先等级
  时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
• 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
  描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
• 短行之间使用自动数字序号，使用相同的字体、字号、行间距
  短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
• 每一个步骤尽量只记录一个操作
  保证简洁、条理井然，容易重复操作步骤。
• 确认步骤完整，准确，简短
  保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
• 根据缺陷，可选择是否进行图象捕捉
  为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
  附加必要的特殊文档和个人建议和注解
  如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
• 检查拼写和语法缺陷
  在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
• 尽量使用短语和短句，避免复杂句型句式
  软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。 以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
• 缺陷描述内容 缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？

• 软件测试计划是指导测试过程的纲领性文件：
• 领导能够根据测试计划进行宏观调控，进行相应资源配置等
• 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等
• 便于其他人员了解测试人员的工作内容，进行有关配合工作
• 包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
• 测试计划编写6要素（5W1H）：
  why——为什么要进行这些测试；
  what—测试哪些方面，不同阶段的工作内容；
  when—测试不同阶段的起止时间；
  where—相应文档，缺陷的存放位置，测试环境等；
  who—项目有关人员组成，安排哪些测试人员进行测试；
  how—如何去做，使用哪些测试工具以及测试方法进行测试
• 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

系统测试的策略

性能测试、负载测试、强度测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、恢复测试、分布测试、可用性测试。

当开发人员说不是BUG时，你如何应付

开发人员说不是bug，有2种情况

• 一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
• 二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

一份测试计划应该包括哪些内容

背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、常用术语、提交文档、风险分析。

黑盒测试的测试用例常见设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

• 等价类划分： 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。
• 边界值分析法：是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
  使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
• 错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
  错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
• 因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
• 正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
• 场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
• 状态图法：通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。
• 大纲法：大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

自动化测试

Python接口自动化中的关联怎么处理

• 将请求返回的结果反射到类属性中，使用setattr()函数，下个请求调用这个类

自动化测试怎么校验结果

• 使用断言，预期结果值和实际结果值进行对比；

自动化使用的测试框架是什么？简述自动化框架的设计、维护

• 自动化使用的测试框架:
  语言：python
  测试框架：unittest（assertEqual，assertTure，assertFalse）
  接口调用：requests（API非常简洁）
  数据驱动：ddt（装饰器：ddt类，unpack测试方法装饰器解包时候，data测试方法装饰器，可迭代的数据类型）
  注：普通用户，管理用户，数据库，配置文件—基础数据
  数据管理：openpyxl（excel，CSV，json，yaml，txt）
  数据库交互：pymysql —根据数据库选择相应的第三方模块来完成
  数据格式的转换：eval，json
  日志处理：logging —清晰的执行过程，快速定位问题
  持续集成：Jenkins（通过插件HTML Publisher/git/Email Extension）进行自动构建，生成HTML，发送邮件

• 自动化框架的设计、维护:
  ①、数据与代码分离，（数据驱动）数据驱动框架
  例如：参数不一样，响应不一样
  ②、结构分层（数据层，用例层，逻辑性）
  逻辑层：公用的方法，封装起来，避免用例层的代码冗余
  数据层：例如，设计Excel，excel读取，参数化替换等
  用例层：存放测试用例

具体的在这个项目中自动化怎么应用到实际的，您对自动化结果的分析

• 配置定时执行，快速结果的反馈，将测试结果反馈给开发；
• 执行测试用例，配合使用HTML报表，发送邮件至责任人处；
• 根据多次调用的自动化分析，来进行定位失败的原因，分析每一次执行的通过率，确定系统的缺陷，来进行改进；

性能测试

性能测试流程

• 性能需求分析
  性能需求分析是整个性能测试工作开展的基础
• 性能测试计划
  项目的简单背景描述；
  本次性能测试的需求与目的；
  性能需求分析的结果是什么；
  测试环境的准备，需要什么样的软硬件配置，网络状况登录；
  测试数据的准备，对于某些性能测试是需要事先准备测试数据的；
  测试的策略，前面进行需求分析的目的是制定测试策略，也就是设计符合需求的测试场景，需要对系统的哪些业务模块进行测试，如何进行？需要设计哪些场景以及设计这些场景的目的；
  最后会明确一下人员配备，比如需要开发、DBA、运维都人员的参与协助，性能测试的时间安排。
• 测试环境搭建
  分硬件环境与软件环境，硬件环境主要是向上级审批硬件配备，在某些大型性能测试，可能需要公司购置或租用硬件设备来进行。或者是将来原有设置进行调配与重组，这个时候就需要网络工程师的参与或协助；
  软件环境的搭建对于开发人员来说应该毫无压力；
  当然身为性能测试人员，不仅也需要会搭建软件平台，更需要对每个平台中的部分有比较深入的了解。因为性能测试的分析并不是死盯着系统应用那一层。中间件、数据库、系统、硬件都有可能成为系统的瓶颈。
• 测试工具选择
  我们在日常的工作中往往是先选定好测试工具然后再分析需求，制定计划进行测试。这样我们在做性能需求分析的时候往往会往往会考虑所选的工具是否能实现，无法实现可能就放弃这个需求或改变这个需求。这样以某一工具为基础点做出的性能测试结果可能是不准确的。
• 测试执行
  用户行为生成–>压力产生器–>用户代理–>测试调度–>系统监控等；
  我们所选择的工具如何来实现我们的需求，这个性能测试工程师对引入的有足够的了解；
  对协议的了解，可能需要编程的能力等。
• 测试结果分析
  测试工具只是提供多种不同的数据揭示和呈现方法而已；
  工具本身并不能帮我们进行性能结果的分析；
  对于性能测试结果的分析，这个需要性能测试工程师对整个被测环境的各种软硬件都要有深入的了解；
  当然，在这个过程中我们往往需要各个岗位人员的协助，开发人员、DBA、运维等。
• 软硬件配置调整与优化
  对于我们测试人员来说，发现了缺陷之后是需要对缺陷进行跟踪和修复的，并不是把发现的缺陷写在报告里就完事的。当然，功能缺陷与性能缺陷存在着本质的缺陷。如果在性能测试过程中发现不满足需求的缺陷，进行调优是一个不可缺少的过程；
  如果要对系统进行调优的话，测试执行、结果分析、系统调优将会形成一个循环持续的过程。直到满足客户的需求为止。

性能测试的Check List

• 开发人员是否提交了测试申请？
• 测试对象是否已经明确？
• 测试范围是否已经明确？
• 本次不被测试的范围是否已经明确？
• 测试目标是否已经明确？
• 何时开始性能测试？
• 何时终止一轮性能测试？
• 性能测试需要做几轮？
• 所需的测试环境是什么？是否已经到位并配置完成？（包括硬件、软件、网络等）
• 所需的测试工具是什么？是否已经到位并保证可以正常使用？
• 被测系统的版本是否已经明确？是否已发布？从哪里可以获得？是否已经部署成功？
• 被测系统的相关功能是否已经正确实现？
• 压力点是否已经明确？响应时间的计算方式是否已经明确？
• 本次测试工作参考的文档有哪些？
• 场景是否已经设计完成并记录在场景管理文档中？
• 每个场景是否有明确的测试意图、前置条件和详细的设置？
• 脚本是否已经录制并调试通过？
• 是否已经明确了哪些地方需要参数化？
• 是否已经明确了各个参数的取值方式？
• 是否已经为参数化的部分准备了必须的数据？
• 是否已经准备了相应历史数据量？
• 是否已经准备了相应的数据恢复方法？（例如准备一个SQL语句用来恢复数据环境）
• 在Controller中对多VU、多次迭代的情况是否已经调试通过？
• 在Controller中Result的路径设置是否正确？
• 在Controller中检查脚本选择是否正确？
• 在Controller中检查VU数量设置是否正确？
• 在Controller中检查集合点是否禁用/启用?
• 在Controller中检查VU加载策略是否设置正确？
• 在Controller中检查迭代次数是否设置正确？
• 在Controller中检查迭代间隔设置是否正确？
• 在Controller中检查日志是否禁用/启用？
• 在Controller中检查Think_Time是否回放？
• 在Controller中检查是否为UNIX服务器和Load Generator机添加了资源监视器并确认可以收到性能数据？
• 在Controller中检查是否为其他必要的资源添加了资源监视器，并确认可以收到性能数据（例如Oracle，WebSphere）？
• 在Controller中检查Load Generator机是否可以连上？
• 检查场景管理文档中是否添加了新的“场景执行情况”，并记录了运行前的数据？
• 在Controller中执行场景前，检查是否在Linux客户端中运行了vmstat和top，监视执行过程中的Linux服务器资源消耗情况？
• 在Controller中执行场景完毕后是否马上去系统中进行检查数据的一致性，并填写“场景执行情况”中的运行后情况？
• 场景完执行完后是否将vmstat和top的数据copy到记事本中，并保存到相应的结果目录下？
• 整个系统的测试工作执行完毕后，是否进行了性能图表的分析和测试报告的提交？

什么是负载测试

负载测试是测试应用程序是否能够很好地处理大量并发用户、事务导致的负载，并确定它是否能够处理高峰使用期。

什么是性能测试

应收集读取和更新事务的时间，以确定系统功能是否在可接受的时间范围内执行。这应该独立完成，然后在多用户环境中确定多个事务对单个事务计时的影响。

解释负载测试过程

• 步骤1:计划测试。
  在这里，我们开发了一个清晰定义的测试计划，以确保我们开发的测试场景将完成负载测试目标。
• 步骤2:创建Vusers。
  在这里，我们创建Vuser脚本，其中包含每个Vuser执行的任务、Vuser执行的任务以及作为事务度量的任务。
• 步骤3:创建场景。
  场景描述测试会话期间发生的事件。它包括在场景中运行的机器、脚本和Vusers的列表。我们使用LoadRunner控制器创建场景。我们可以创建手动场景和面向目标的场景。在手动场景中，我们定义了要分配给每个脚本的vuser的数量、负载生成器和vuser的百分比。对于web测试，我们可以创建一个面向目标的场景，在这个场景中定义测试必须实现的目标。LoadRunner自动为我们构建一个场景。
• 步骤4:运行场景。
  我们通过指示多个vuser同时执行任务来模拟服务器上的负载。在测试之前，我们设置场景配置和调度。我们可以运行整个场景、Vuser组或单个Vuser。
• 步骤5:监视场景。
  我们使用LoadRunner在线运行时、事务、系统资源、Web资源、Web服务器资源、Web应用服务器资源、数据库服务器资源、网络延迟、流媒体资源、防火墙服务器资源、ERP服务器资源和Java性能监视器监视场景执行。
• 步骤6:分析测试结果。
  在场景执行期间，LoadRunner记录应用程序在不同负载下的性能。我们使用LoadRunner的图表和报告来分析应用程序的性能。

什么时候进行负载和性能测试

一旦完成了接口(GUI)测试，我们就执行负载测试。现代系统架构庞大而复杂。单个用户测试主要关注系统组件的功能和用户界面，而应用程序测试则关注整个系统的性能和可靠性。
例如，一个典型的应用程序测试场景可能描述1000个用户同时登录到一个系统。这就产生了一些问题，比如系统的响应时间是多少，它会崩溃吗，它会与不同的软件应用程序和平台兼容吗，它能容纳成千上万的用户吗，等等。这是我们做负载和性能测试的时候需要考虑的。

什么是集合点

• 将集合点插入Vuser脚本，以模拟服务器上的高用户负载。
• 集合点指示vuser在测试执行期间等待多个vuser到达某个点，以便它们可以同时执行一个任务。
• 例如，要模拟银行服务器上的峰值负载，可以插入一个集合点，指示100个vuser同时将现金存入他们的帐户。

什么是场景

• 一个场景定义了在每个测试会话中发生的事件。例如，场景定义并控制要模拟的用户数量、要执行的操作以及虚拟用户在其上运行模拟的机器。

为什么要创建参数

• 参数就像脚本变量。它们用于改变服务器的输入，并模拟真实的用户。每次运行脚本时，都会向服务器发送不同的数据集。更好地模拟使用模型，以便从控制器进行更精确的测试;一个脚本可以模拟系统上的许多不同用户。

您如何在负载下执行功能测试

负载下的功能可以通过同时运行多个Vuser来测试。通过增加Vusers的数量，我们可以确定服务器可以承受多少负载。

响应时间和吞吐量之间的关系

吞吐量图显示每秒从服务器接收到的数据量(以字节为单位/TPS)。当我们将其与事务响应时间进行比较时，我们会注意到，随着吞吐量的降低，响应时间也会减少。类似地，峰值吞吐量和最高响应时间将大约同时出现。

如何确定性能瓶颈

• 使用监视器可以检测性能瓶颈。
• 这些监视器可以是应用服务器监视器、web服务器监视器、数据库服务器监视器和网络监视器。它们有助于找出我们场景中导致响应时间增加的问题区域。
• 所做的度量通常是性能响应时间、吞吐量、点击率/秒、网络延迟图等。

如何发现与web服务器相关的问题

使用网络资源监视器，我们可以发现网络服务器的性能。使用这些监视器，我们可以分析web服务器上的吞吐量，每秒的点击率发生在场景期间，每秒http响应的数量，每秒下载页面的数量。

如何发现与数据库相关的问题

通过运行“数据库”监视器和“数据资源图”的帮助，我们可以发现数据库相关的问题。你可以在运行控制器之前指定你想测量的资源，然后你就可以看到数据库相关的问题。

"不成文"的性能需求指标

• 响应时间：
  根据国外的一些资料，一般操作的响应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。
• 第三方研究表明，如果网页是逐步加载的，先出现横幅，再出现文字，最后出现图像。在这样的条件下，用户会忍受更长的等待时间，用户会把延迟在39秒内的也标识为“good”，超过56秒的才认为是“poor”的。
• 80/20原则
  又称帕累托效应，比如，某一些系统一天中80%的访问量集中在20%的时间内。

常见性能需求

• WEB首页打开速度5s以下，web登陆速度 15s以下。
• 邮件服务支持50万个在线用户
• 计费话单成功率达到99.999%以上。
• 在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS
• 系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时
• 这个系统能否支撑200万的vu（每天登录系统的人次）
• 注： vu----代表Virtual user(虚拟用户)

如何获得有效的需求

• 客户方提出
  客户方能提出明确的性能需求，说明对方很重视性能测试，这样的企业一般是金融、电信、银行、医疗器械等；他们一般对系统的性能要求非常高，对性能也非常了解,提出需求也比较明确。
  前期的性能测试为单元性能测试、接口性能测试，有别系统性能测试。
• 根据历史数据分析
  对于一些面向用户的独特产品，比较难定位市场的大小，可以先上一运营一段时间，通过运营可以搜集客户资料，比如，每月、每星期、每天的峰值业务量是多少。用户以什么样的速度在递增中。用户对系统的哪些功能模块使用的最多，他们所点的比例等等。
  收集到这些数据之后，我们就可评估系统的系统需求指标，从而进行性能测试。
• 需求分析与定位
  这里根据前期的需求分析与定位，来分析确定系统性能指标。
• 参考历史项目或其它同行业的项目
  如果公司之前有类似的项目经验，根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制定出相应的性能指标。
• 参考其它资料数据
  从与产品相关的资料中寻找痕迹。