网站测试流程，要求以及测试报告 - 清泉的个人空间 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园 - Powered by X-Space
如果有好的文章可以随意分享，但请尊重别人的劳动成果，谢谢合作！
网站测试流程，要求以及测试报告
& 15:48:49
&在51testing测试网站上发现了一篇很有参考价值的，虽然我不是做测试的，但是此文章可以为以后奠定一定&的基础知识，所以特意拷贝下来，留在自己空间，供以后参考，非常感谢提供这篇文章的作者&下面是网站流程、要求及测试报告&一个网站基本完工后，需要通过下面三步测试才可以交活。&一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。&a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位；图片上有没有错别字；各连接是否是死连接；各栏目图片与内容是否对应等&b) 功能 达到客户要求；连接正确；各个动态生成连接正确；传递参数格式、内容正确；试填测试内容没有报错；页面显示正确&二、 全面测试 根据交工标准和客户要求，由专人进行全面测试&也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。&三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误&&软件缺陷的原则&软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等&软件未达到产品说明书标明的功能。&软件出现了产品说明书指明不会出现的错误。&软件功能超出产品说明书指明范围。&软件未达到产品说明书虽未指出但应达到的目标。&员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。&测试的主要方面：&一、功能测试&对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。&1、链接测试&　　 链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：&1）测试所有链接是否按指示的那样确实链接到了该链接的页面；&2）测试所链接的页面是否存在；&3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。&链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。&Xenu------主要测试链接的正确性的工具&可惜的是对于动态生成的页面的测试会出现一些错误。&2、表单测试&当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。&要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。&B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员量。&我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。&3、Cookies测试&　　 Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统&&& 时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态的自定义页面或者存储登陆等信息。&如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。&4、设计语言测试&Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如、JavaScript、 ActiveX、VBScript或等也要进行验证。&5、数据库测试&　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用对信息进行处理。&在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。&二、性能测试&网站的对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。&网站的性能测试主要从三个方面进行：连接速度测试、负荷测试(Load)和(Stress),&连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。&1、连接速度测试&　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。&　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。&2、负载测试&　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？&3、压力测试&　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。&　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。&压力测试的区域包括表单、登陆和信息传输页面等。&采用的测试工具：&性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具&ab -----Apache 的测试工具&OpenSTA—开发架构&三、接口测试&在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、&验证数据或提交订单。&1、 服务器接口&第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器&记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。&2、 外部接口&有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行&为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。&3、错误处理&最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错&误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？&订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服&务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果&用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致&电用户进行订单确认。&四、可用性测试&可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。&1、导航测试&　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？&　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。&　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。&Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。&2、图形测试&　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：&　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。&　　（2）验证所有页面字体的风格是否一致。&　　（3）背景颜色应该与字体颜色和前景颜色相搭配。&　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。&3、内容测试&　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。&信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关列表"。&4、整体界面测试&　 整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？&对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。&　 对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。&五、兼容性测试&需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。&1、平台测试&　　市场上有很多不同的操作系统类型，最常见的有、Unix、Macintosh、等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。&因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。&2、浏览器测试&　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。&测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。&采用测试工具：&通过或者导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。&3．视频测试&页面版式在 640x400、600x800 或
的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?&4．Modem/连接速率测试&是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测&试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，&但却不会耐心等待首页的出现。最后，需要确认图片不会太大。&5、打印机测试&用户可能会将网页打印下来。因此网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。&6、组合测试&最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在兼容&机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。&如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，&那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。&(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能&在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，&六、安全测试&Web应用系统的安全性测试区域主要有：&1、 目录设置&Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页&面，这样就不会显示该目录下的所有内容。如果没有执行这条规则。那么选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。但是进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中有些都是已过期页面。如果该公司每个月都要更改产品价格信息，并且保存过期页面。那么只要翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。&2．登录&　 现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。　&3．Session&Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。&4．文件&为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。&5．加密&当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。&6．安全漏洞&服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。&目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，&工具如下&SAINT------- Security Administrator’s Integrated Network Tool&此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。&七、代码合法性测试&代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查。&1、程序代码合法性检查&程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。&2、显示代码合法性检查&显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用&HTML代码检查------采用CSE HTML Validator进行测试&JavaScript、Css也可以在网上下载相应的测试工具。&八、 文档测试&l、产品说明书属性检查清单&1）完整.是否有遗漏和丢失，完全吗？ 单独使用是否包含全部内容&2）准确.既定解决方案正确吗？ 目标明确吗？ 有没有错误？&3）精确、不含糊、清晰.描述是否一清二楚？ 还是自说自话？容易看懂和理解吗？&4）一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突&5）贴切.描述功能的陈述是否必要？有没有多余信息？ 功能是否原来的客户要求？&6）合理.在特定的预算和进度下,以现有人力,物力和资源能否实现？&7）代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码&8）可测试性.特性能否测试？ 测试员建立验证操作的测试程序是否提供足够的信息？&2、 产品说明书用语检查清单&1）说明。 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.&2）总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.&3）当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.&4）某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.&5）等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.&6）良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.&7）已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.&8）如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.&相关的测试工具&OpenSTA&主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。&SAINT&网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。&CSE HTML Validator&一个有用的对于HTML代码进行合法性检查的工具&Ab(Apache Bench)&Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。&Crash-me&Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。&&写得不错，收藏了，以后再看&&&&
&re: web测试总结
写的很好啊，我正要做web测试，多谢啦！&&&&
&re: web测试总结
写得很好，收藏了。呵呵。。。。。&&&&
&re: web测试总结
好文，偶转载一下并作少量补充
强推firefox的firebug，非常好用&&&&
&re: web测试总结
写的好，我现在正在做WEB测试，谢谢啦！&&&&
&re: web测试总结
&re: web测试总结[未登录]
非常好，学习了。&&&&您的位置：&
&MSDS是什么MSDS检测报告
MSDS是什么MSDS检测报告
&广州通测电子科技有限公司
&经济开发区科学城彩频路9号b栋702c
&&&&志趣认证
&日(距今940天)
一、MSDS是什么？
& & &MSDS (Material Safety Data Sheet)即化学品安全说明书，亦可译为化学品安全技术说明书或化学品安全数据说明书。是化学品生产商和进口商用来阐明化学品的理化特性（如PH值，闪点，易燃度，反应活性等）以及对使用者的健康（如致癌，致畸等）可能产生的危害的一份文件。在欧洲国家，MSDS也被称为安全技术/数据说明书 SDS(Safety Data sheet)。 国际标准化组织 （ISO）11014采用SDS术语，然而美国、加拿大，澳洲以及亚洲许多国家则采用MSDS术语。
二、MSDS内容
& & MSDS是化学品生产或销售企业按法律要求向客户提供的有关化学品特征的一份综合性法律文件。它提供化学品的理化参数、燃爆性能、对健康的危害、安全使用贮存、泄漏处置、急救措施以及有关的法律法规等十六项内容。
& & MSDS简要说明了一种化学品对人类健康和环境的危害性并提供如何安全搬运、贮存和使用该化学品的信息。作为提供给用户的一项服务，生产企业应随化学商品向用户提供安全说明书，使用户明了化学品的有关危害，使用时能主动进行防护，起到减少职业危害和预防化学事故的作用。目前美国、日本、欧盟等发达国家已经普遍建立并实行了MSDS制度，要求危险化学品的生产厂家在销售、运输或出口其产品时，同时提供一份该产品的安全说明书。
& & 需要牢记的是，MSDS上所提供的信息对于使用者来说也许是唯一的信息来源，所以，提供规范、正确而且全面的产品安全说明书十分重要。
三、为什么需要找专业机构编写MSDS？
& & 美、欧等发达国家的法律对环境和职业健康的要求极为严格。在化学品的国际贸易中，客户常常在购买化学品前，向供应商索取MSDS。供应商遵照法律的要求，会及时提供符合客户所在国法律法规要求的MSDS。在美国、加拿大及欧洲国家，一些大中型企业都设有危险化学品管理部或职业健康及环境科学管理部们专门审核化学品供应商提供的MSDS，经审核，符合条件者才有资格同采购部门进行下一步的商务接触。
& & 编制符合法律法规要求、高水准的MSDS的难点在于：一是除了测试化学品的理化特性外，测试化学品的毒理数据费用太高。如果化学品是复合品或掺有添加剂或存在反应副产品，那么编制者就很难对该产品毒理性能做出正确的评估。如果供应商提供的MSDS存在错误或失实，或故意隐瞒有害信息，造成用户的人员伤亡或环境污染，用户往往要求MSDS的提供单位承担相应的法律责任。二是编制的MSDS必须符合买方所在国家和地区的有关危险化学品的法律法规。然而不同的国家，甚至同一个国家不同的州（例如：美国）都有自己对MSDS的不同要求。同时一些数据或名录也会经常变化（例如，ACGIH每年一次公布新的接触阈值，NTP每两年一次公布新的致癌物质名录），所以使得编制符合要求的MSDS更为困难。
& & MSDS编写质量是衡量公司实力，形象以及管理水平重要标志，化工产品没有一份完整的MSDS出口过程很容易被国外客人误解为我们企业是一个没有信誉的小企业遭到拒绝。
广州通测检测科技有限公司拥有国内专业化学分析评估工程师队伍，在短时间为各类材料提供权威MSDS评估报告，将对出具每一份准确性负责。目前，我公司推出MSDS的优惠活动，并且在2个工作日向你提供权威的MSDS报告，好机不容错过！欢迎前来咨询洽谈
联系我时请说明来自志趣网，谢谢!
关键字：&&&&&&
给我留言，我会立即联系您，谢谢!
电话(格式：区号-号码（分机） 如 010-8))
邮箱(强烈建议填写，可跟踪信息！)
留言(1000字内)
免责申明：志趣网所展示的信息由用户自行提供，其真实性、合法性、准确性由信息发布人负责。使用本网站的所有用户须接受并遵守法律法规。志趣网不提供任何保证，并不承担任何法律责任。 志趣网建议您交易小心谨慎。
Copyright &
志趣网 版权所有性能测试总结_测试总结_领测软件测试网
性能 测试总结 概述 对于目前以 B/S 结构为主的产品来说，性能是一项必测的内容。 关于性能方面的测试，在很多地方又被细分为： 负载测试 、强度测试、 容量测试 、 压力测试 等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单" name="description" />
性能测试总结
发表于：来源：作者：点击数：
MI LY: 黑体">性能 测试总结 概述 对于目前以 B/S 结构为主的产品来说，性能是一项必测的内容。 关于性能方面的测试，在很多地方又被细分为： 负载测试 、强度测试、 容量测试 、 压力测试 等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单
<SPAN style="FONT-FALY: 黑体">
对于目前以 B/S 结构为主的产品来说，性能是一项必测的内容。
关于性能方面的，在很多地方又被细分为：、强度测试、、等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单独的进行其中的某一项测试，实际测试基本上都是交叉性的。我们这里把所有与性能相关的测试统称为，不做具体区别。
& 我们在这里所说的性能测试，指的是对系统整体性能的测试，不涉及单元模块的性能检测。
& 我们在这里讨论的内容主要是基于 B/S 架构的应用。
& 要讨论性能测试，很难不涉及，我们在这里以 MI 公司的
为默认的。
性能测试的介入时机
性能测试应该在什么时候开始？对来说，在产品的功能稳定下来后，就应该尽早开始对产品进行性能测试。一般建议在产品的 3 轮完整后开始。
性能测试的整体测试过程如下：
&&& 1.3.1制定性能
&&& 1.3.2搭建
&&& 1.3.3编写测试程序/脚本
&&& 1.3.4测试执行和分析
&& &1.3.5编写测试报告，结束测试
1.4过程说明
各个子过程的具体说明：
1.4.1制定性能测试计划
分析被测试系统的情况，收集性能测试。制定测试计划，形成文档。测试计划应考虑以下内容：
& 测试对象和场景。即我们要测试的内容是什么。系统最后对外提供的功能有很多，我们不可能也没有必要对系统所有的功能点都进行性能测试。挑选性能测试对象的一般原则是：选取那些在系统实际投入使用后，并发访问量较大的、算法比较复杂的、占用系统资源较多的功能点，也就是压力点。设定好要测试的压力点后，需要详细的描述出具体的操作过程，以及预期应该达到的。
注：在制定测试计划时，对于系统预期应该达到的性能指标，常常是不能获得一个准确的数字。但即使是在没有任何参考数据的情况下，也应该和人员一起，设定一个初步的性能指标，作为后面测试的一个参照。有一个初步指标，也比没有任何指标要好。
& 测试环境。具体包括：选用什么样的硬件环境（计算机配置，结构）；什么样的软件环境（操作系统，，应用，
）；多大的数据量（，文件系统）。
& 需要监控的资源。进行性能测试时，需要监控的系统软硬件资源的占用情况。这和产品的具体情况有关，一般可以考虑的因素包括： CPU 使用情况、 Memory 的使用情况、磁盘的 I/O 、网络的占用情况、数据库运行状况、 Web/ 应用服务器运行状况等。
& 测试工具。选用什么工具进行性能测试，是自己，还是选用第三方的测试工具。
& 进度安排。各阶段的工作内容、时间安排。
&1.4.2搭建测试环境
依照测试计划中的测试环境要求，搭建实际的测试环境，安装配置还好硬件、软件，准备好测试数据。
&1.4.3编写测试程序/脚本
编写实际的测试程序或脚本。如果能够使用现有的成熟测试工具则尽量选用，如果现有工具不能满足测试要求，则需要编写定制的测试程序。
同时，要为脚本编写说明文档，文档的内容主要是脚本的名称，以及其对应的测试内容。
&1.4.4测试执行和分析
设定多种测试场景组合，反复运行测试，记录结果数据，逐步优化系统，最后达到一个可接受的性能结果。测试执行过程中，注意每次测试后下次测试开始前的测试环境恢复工作。性能测试和一样，也有测试迭代的过程，也会有产品版本的更新。在性能测试过程中，需要和开发人员协同工作，一起调优系统。
&1.4.5编写测试报告，结束测试
整理测试数据，总结测试结果，编写测试报告，结束测试。
附录 1 保证LoadRunner的正确性
在用 LoadRunner 编写完测试脚本后，要保证脚本在以下情况下能够正确运行：
在脚本编辑器中：单用户单循环运行脚本；单用户多循环运行脚本。
在 controller 中：多用户单循环运行脚本；多用户多循环运行脚本。
附录 2 性能测试术语解释
测试场景：包含一个或多个脚本，设定并发数量，运行方式，模拟系统在现实中的一个情景。
事务：是指一组相关的操作，是性能测试中的计时单位。比如‘登录应用系统’就可以作为一个事务。
集合点：设置集合点后，先到达的请求会等待，直到所有的请求都到达，然后一起发送请求。设置集合点，是为了进行更严格和精确的并发测试。
checkpoint ：也叫检查点。和功能测试一样，性能测试也需要检验结果的正确性。 当返回标准的 HTTP 错误时（状态码不是 200 +时），Loadrunner能够识别出来，但如果返回的不是标准HTTP错误，Loadrunner则无法识别，这时只能通过我们设置的check point来发现错误。
参数化：为了更真实的模拟现实操作，我们经常需要对测试输入进行参数化。比如登录时的用户名。
关联：对于脚本中动态变化的部分，需要对其进行参数化， Loadrunner 提供了对这种变量进行参数化的功能，叫做关联。比如下面这种情况： 在一个基于 WEB 的应用中，用户每次登录时会被服务端赋予了一个 SessionID ，该用户的后续操作都必须给出这个 SessionID 。在这种情况下，由于被赋予的 SessionID 是由服务端给出的，每次执行脚本时，获得的 SessionID 都会不同，因此就需要在脚本中取得用户每次登录，服务端返回的 SessionID ，在后续步骤中使用。这时我们就需要对 SessionID 进行参数化。即 Loadrunner 提供的关联功能。
迭代次数：在性能测试中，对于一个场景，我们需要运行多次取其平均值，即迭代运行多次。目的是为了避免意外因素对测试结果的影响。
think time ：思考时间。在进行长时间的时，要考虑在脚本中加入适当的 think time ，来更好的模拟现实中的情况。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）}