软件性能测试规范

软件性能测试规范篇一：性能测试流程规范目录 1 2 3 4 前言.2 文档目的 . 2 适用对象 . 2 性能测试目的 . 2 性能测试所处的位置及相关人员 .3 性能测试所处的位置及其基本流程 .3 性能测试工作内容 .4 性能测试涉及的人员角色 .5 性能测试实施规范 . 5 确定性能测试需求 .5 分析应用系统，剥离出需测试的性能点 .5 分析需求点制定单元测试用例 .6 性能测试需求评审 .6 性能测试需求归档 .6 性能测试具体实施规范 .6 性能测试起始时间 .6 制定和编写性能测试计划、方案以及测试用例 . 7 测试环境搭建 .7 验证测试环境 .8 编写测试用例脚本 .8 调试测试用例脚本 .8 预测试 . 9 正式测试 . 9 测试数据分析 .9 调整系统环境和修改程序 .10 回归测试 .10 测试评估报告 .10 测试分析报告 .10 5 6 7 8 测试脚本和测试用例管理 .11 性能测试归档管理 .11 性能测试工作总结 .11 附录：.错误！未定义书签。 1 前言文档目的 本文档的目的在于明确性能测试流程规范，以便于相关人员的使用，保证性能测试脚本的可用性和可维护性，提高测试工作的自动化程度，增加测试的可靠性、重用性和客观性。 适用对象 本文档适用于部门内测试组成员、项目相关人员、QA及高级经理阅读。 2 性能测试目的 性能测试到底能做些什么，能解决哪些问题呢？系统开发人员，维护人员及测试人员在工作中都可能遇到如下的问题 1. 硬件选型，我们的系统快上线了，我们应该购置什么样硬件配置的电脑作为服务器呢？ 2. 我们的系统刚上线，正处在试运行阶段，用户要求提供符合当初提出性能要求的报告才能验收通过，我们该如何做？ 3. 我们的系统已经运行了一段时间，为了保证系统在运行过程中一直能够提供给用户良好的体验（良好的性能） ，我们该怎么办？ 4. 明年这个系统的用户数将会大幅度增加，到时我们的系统是否还能支持这么多的用户访问，是否通过调整软件可以实现，是增加硬件还是软件，哪种方式最有效？ 5. 我们的系统存在问题，达不到预期的性能要求，这是什么原因引起的，我们应该进行怎样的调整？ 6. 在测试或者系统试点试运行阶段我们的系统一直表现得很好，但产品正式上线后，在用户实际环境下，总是会出现这样那样莫名其妙的问题，例如系统运行一段时间后变慢，某些应用自动退出，出现应用挂死现象，导致用户对我们的产品不满意，这些问题是否能避免，提早发现？ 7. 系统即将上线，应该如何部署效果会更好呢？ 并发性能测试的目的注要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。3 性能测试所处的位置及相关人员性能测试所处的位置及其基本流程 下面就性能测试的基本流程给予图示说明： 性能测试的具体流程： 性能测试工作内容 ? 软件需求分析阶段： 分析软件需求，提取出待实现的功能点，此时根据需求功能点选取必要的性能测试点，并组织起有效的测试用例。 ? 软件单元测试阶段： 单元测试在软件开发周期贯穿，针对已经开发的功能做单元测试，保证组件功能可正常使用，此阶段功能测试占主要的测试比例，性能测试部分主要是了解、分析业务结构及进行数据准备。 ? 软件系统集成测试阶段： 软件的功能已经基本实现，此时可以针对稳定的功能点在公司内部部署并实 施小规模的性能测试。? 软件升级及维护阶段： 维护期占整个软件的使用时间，由于日益变更的需求让我们的程序不断升级，为了降低升级过程中出现对已有软件功能的影响。性能测试通常采用 2 个必要步骤： a) 补丁升级测试，在数据结构变更处加上时间点，检验每个操作的时间效 率是否可接受，并为用户升级程序提供一个参考时间。b) 补丁升级成功后，对系统改动功能点做性能测试，并验证一些常规功能 的效率是否受到升级影响，最后提供升级后系统的性能测试评估报告。 ? 历次性能测试数据归档 对历次的性能测试进行归档处理，为预测软件未来的发展状况提供必要的数据基础。 性能测试涉及的人员角色 4 性能测试实施规范确定性能测试需求 分析应用系统，剥离出需测试的性能点 工作内容：性能测试人员，系统开发人员，客户从不同的角度提出性能测试点。性能测试人员主要关注功能测试期反映的测试点；系统开发人员着重从程序角度出发考虑，分析哪些点可能存在性能问题；客户主要从业务角度出发发，抽取使用频率较高，较重要的业务功能作为测试点。 参与人员：测试负责人，系统开发人员，客户 确认要素： 1、并发用户数 2、预期系统响应时间 3、生产环境基础数据量 篇二：性能测试常用分析及标准服务响应的时间标准 参考了业内比较通行的“2-5-10 原则”当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10 原则” ，简单说，就是当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；当用户在 5-10 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过 10 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个 Web 站点，或者发起第二次请求。 针对基础数据库添加企业信息： 添加 10 家企业，9 家成功，1 家失败，失败详细信息 (62): Error -26612: HTTP Status-Code=500 (Internal Server Error) for “PSInfo/IndustryFact/? PSClassCode=1 / 变量 x 与 X 容易混淆 ? 【规则 2-1-3】程序中不要出现完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但会使人误解。 ? 【规则 2-1-4】变量的名字应当使用“名词”或者“形容词名词” 。另外，对于大家常用的、习惯成俗的形容词，可以采用缩写。 例如： uint32 uint32 value; n_val; /名词 /形容词+名词，n 是 new 的缩写 ? 【规则 2-1-5】尽量避免名字中出现数字编号，如val1,val2 等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事） 。 ? 【规则 2-1-6】全局变量加前缀 g_（表示 global）修饰，单词之间采用下划线分割。 例如： Char *g_msg_pool; ? 【规则 2-1-7】函数名尽量采用“模块名+动词+名词” （动宾词组）或者“模块名+名词+动词”的方式命名，尽量做到根据函数名能大概明确函数所完成的功能。 例如： bool comm_hash_create(?) /模块+名词+动词 ? 【规则 2-1-8】宏常量名必须全部采用大写的字母，单词之间使用下划线分隔。 例如： #define DEF_BUF_LEN 150 /宏常量 格式化代码? 【规则 2-2-1】脚本应采用缩进风格编写，每层缩进使用一个制表位（TAB） ，类定义、方法都应顶格书写； ? 【规则 2-2-1】左花括号要另起一行，不能跟在上一行的行末；? 【规则 2-2-2】一个变量定义占一行，一个语句占一行； ? 【规则 2-2-3】对独立的程序块之间、变量说明之后必须加空行； ? 【规则 2-2-4】对于较长的语句（80 字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读； ? 【规则 2-2-5】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分； ? 【规则 2-2-6】在结构成员赋值等情况，等号对齐，最少留一个空格； ? 【规则 2-2-7】若函数或过程中的参数较长，则要进行适当的划分。 ? 【规则 2-2-8】形参的排序风格： 最常使用的参数放在第一位； 输入参数列表应放在输出参数列表的左边； 将通用的参数放在特殊的参数的左边 Vuser ? 【规则 2-3-1】脚本越小越好。就像写 code 一样，不要太长，这样易于维护也易懂。尽量做到一个功能写一个脚本。如果那些功能是连续有序的，必须先做上一个，下一个动作才能进行，就只能放在一起了。 ? 【规则 2-3-2】对于在脚本中常用的函数，需要进行抽取，放到专门的.h 中进行定义实现。 ? 【规则 2-3-3】能用到高级协议的，不要使用底层协议。 ? 【规则 2-3-4】通常将登陆业务放到 init 里面；业务放到 action 里