论坛系统的测试.docx
《论坛系统的测试.docx》由会员分享，可在线阅读，更多相关《论坛系统的测试.docx（25页珍藏版）》请在冰豆网上搜索。
论坛系统的测试
河南理工大学
计算机科学与技术学院
实训报告设计
2016 — 2017学年 第一学期
课程名称：
软件测试技术
设计题目：
论坛系统软件测试
学生姓名：
田树浩
学号：
4
专业班级：
计软1501
指导老师：
鲁保云
2017年12月29号
第一节编写的目的及意义
论坛系统为人民的交流提供了一个很好的平台，用户可以在这里发表自己的观点，与人分享自己的想法，同时可以对别人的主题发表自己的意见，用户之间可以公开的交流，也可以通过站内信箱的方式与全球各的的用户沟通。
为了是论坛系统能够胜任更多的工作，提供服务质量，本设计对论坛系统进行全面的功能测试和性能测试，并对的到的测试结果进行分析，发现系统存在的漏洞以及性能瓶颈，并对其提出修改意见。
其中的功能测试主要对系统的后台已经前台的的操作进行检查。
后台主要就是论坛系统的管理，包括用户管理的论坛的管理等。
前台主要就是用户登录功能，发帖，回复，撰写日志等等。
性能测试主要借助测试工具，模拟不同的用户环境下，系统的性能表现，包括系统的相应时间，事物成功率等。
出此之外还对系统的链接，界面等进行简单的测试。
系统的测试不仅要检验系统是否实现了相应的功能，还需要检查系统的功能是否存在缺陷[12]。
在执行测试之前，根据系统的整体情况，拟定测试计划，并严格按照计划来进行测试。
为更加真实的模拟实际环境，对测试用例的设计力求完美。
不仅要考虑到正确的输入输出，同时也要对系统处理错误信息的能力进行检查。
在性能方面，通过场景的设置，模拟真实环境下，系统对用户请求的响应情况，以此来发现系统存在的性能瓶颈，提出相应的修改意见。
选择论坛测试的目的是为了对web系统测试有更多的了解。
因为web系统与其他系统存在很大的不同，他与互联网紧密相连，除了要考虑系统本身的设计之外，网络环境的影响也是很重要的。
对这样的系统进行测试，也存在一定的复杂性，需要考虑到各种复杂的情况，并为每种情况设置相应的场景。
这里根据web工程[14]的概念，对系统进行全面的测试。
第二节软件测试方法
1.功能测试
功能测试从用户的角度出发，对系统提供的各种功能进行测试，主要是黑盒测试。
它把系统看作一个黑盒子，不考虑系统内部结构以及系统的具体实现方法[3]。
通过逐项测试，来检查系统的各个功能是否完善，输入正确的数据能否得到期望的输出结果，输入错误的信息时系统能否进行相应的处理。
针对论坛系统采用的功能测试主要有论坛后台管理模块的测试，包括论坛管理和用户管理等模块，前台主要包括用户登录模块，发帖回复模块，以及用户空间管理模块。
采用的功能测试方法是等价类划分和边界值测试。
这样既可以测试正确情况下系统的相应，又可以测试系统对错误的处理能力。
2.性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试[11]。
对论坛系统采用的也主要是系统负载测试和压力测试。
期望通过使用自动化测试工具的模拟，实现在虚拟环境下获得系统的性能指数[12]。
根据测试结果对系统的性能进行评估，并提出改进意见。
3.链接测试
链接测试可分为三个方面。
首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面[7]。
采用的方法同样的通过自动化工具来实现。
本次论坛的链接测试主要使用的链接测试工具是XenuLinkSleuth。
它可以检测到网页中各种类型的链接。
它可以分别列出网站的活链接以及死链接，并可把检查结果存储成文本文件或网页文件。
4.界面测试
整体界面测试反映浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方整个Web应用系统的设计风格是否一致[9]。
通过对网页界面的易用性、美观性等进行测试，对网页的布局，排版等提出修改意见，以获得更好的用户体验。
5.测试工具
QuickTestProfessional
QuickTestProfessional简称QTP，是一种自动测试工具。
使用QTP的目的是想用它来执行重复的手动测试。
在测试前要考虑好如何对系统进行测试，例如要测试哪些功能、操作步骤、输入数据和期望的输出数据等。
它让用户可以直接录制屏幕上的操作流程，自动生成功能测试或者回归测试用例。
专业的测试者也可以通过提供的内置脚本和调试环境来取得对测试和对象属性的完全控制。
QTP可以使测试人员在几分钟内提高效率,只需通过按“记录”按钮，并使用执行典型业务流程的应用程序即可创建测试脚本。
系统使用简明的英文语句和屏幕抓图来自动记录业务流程中的每个步骤。
QTP可以自动引入检查点，以验证应用程序的属性和功能，例如验证输出或检查链接有效性。
对于关键字视图中的每个步骤，活动屏幕均准确显示测试中应用程序处理此步骤的方式。
也可以为任何对象添加几种类型的检查点，以便验证组件是否按预期运行。
在测试结束之后，用户的可以的到系统自动生成的详细测试结果。
LoadRunner
LoadRunner是一种预测系统行为和性能的负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。
LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。
LoadRunner的测试对象是整个系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助更快的查找和发现问题。
使用LoadRunner的VirtualUserGenerator，您能很简便地创立起系统负载。
该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。
它先记录下业务流程（如下订单或机票预定），然后将其转化为测试脚本。
建立测试脚本后，可以对其进行参数化操作，这一操作能让测试人员利用几套不同的实际发生数据来测试系统，从而反映出本系统的负载能力。
测试完成之后，LoadRunner会提供系统的性能测试结果，包括事物的最大响应时间、平均响应时间和事物成功率等信息。
通过对这些信息的分析，测试人员就可以找出系统存在的性能瓶颈，对系统提出改进意见。
第三节系统测试计划
根据系统的测试需求，计划对系统实施的测试主要包括后台和前台的功能测试，以及前台的性能测试。
因为在后台管理模块中的用户量不是很大，操作频率也不是很高，所以就不对其进行性能方面的测试。
1.系统功能测试计划
因为系统分为后台管理模块和前台模块，所以在进行功能测试的时候，需要分开进行。
后台的功能测试主要包括后台登陆测试，用户管理模块，论坛管理模块等。
后台登路的测试主要针对不同输入情况下，检查系统是否能够正确的处理，包括输入正确的用户名和密码，输入正确的用户名错误的密码，输入错误的用户名等情况。
用户管理模块的功能测试则按照逐项测试的原则，根据系统提供的所有功能，进行深度测试。
论坛管理模块同样采用深度测试的方法，测试每个系统功能。
用户登录主要采用自动测试的方法，其他的模块功能测试则采用手工测试。
前台的功能测试则根据系统划分的模块，对核心模块进行测试，包括登录模块的测试，用户发帖、回复模块的测试，用户发送短信的测试等。
和后台模块类似，登录的测试主要采用自动测试，通过测试用例的设计，来模拟不同的输入情况。
其他模块的测试主要采用手工的方法，进行深度的测试。
期望通过全面的功能测试，找出系统存在的问题，并对系统的改进提出意见。
2.系统性能测试计划
系统的性能测试主要针对前台模块，因为该模块的使用频率比较高，大部分的用户活动都集中在这个模块中。
用户在前台进行的操作包括系统的登录、发表帖子、发表回复、上传附件、撰写博客等等。
因为用户的数量可能会越来越多，同时发生的系统操作也会越来越多，为了获得系统在复杂情况下的性能表现，将对这些情况进行模拟，并的到系统的性能参数，以作为系统的改进参考。
在性能测试中要模拟的用户情况有多用户同时登录系统，多用户同时发布帖子或回复以及用户上传不同大小的附件等。
性能测试将通过测试工具来设置这些用户环境。
因为进行的是本地测试，所以在进行结果分析的时候，需要考虑网络的传输情况，以尽可能真实的反映系统性能[10]。
3.其他测试
其他测试包括链接测试，界面测试以及兼容性测试。
其中链接测试主要采用自动测试的方法，找出系统的链接存在的问题。
界面测试则主要针对系统界面的易用性、合理性进行测试。
兼容性测试通过在不同的平台下运行系统，查看系统是否能够正常工作。
这里主要通过在不同的浏览器下登录系统并进行一系列的操作，查看系统的功能是否完整，网页的显示是否正常等。
第四节系统测试准侧
1.系统缺陷级别定义
级别1：
微小，系统的友好性等存在不足。
像文字的美化不好、色彩搭配不恰当、系统界面布局不合理等。
级别2：
一般，系统的易用性不会，给用户带来不便等。
像文字显示不规范，图片显示不正确，提示消息不恰当等。
级别3：
较严重，影响到系统的基本功能。
像链接错误，页面跳转失败，附件显示不正确等。
级别4：
严重，系统的功能存在重大缺陷，导致系统部分功能不能正常使用。
像由于程序所引起的死机，非法退出，死循环，数据库发生死锁，错误操作导致的程序中断，严重的计算错误，与数据库连接错误，数据通讯错误等。
级别5：
致命，因为系统存在严重缺陷，导致系统死机、蓝屏，系统的无法运行甚至崩溃等。
2.系统性能指标
（1）单个事物操作时用户的等待时间不超过10秒；
（2）多个事物操作时，没有任何事物失败；
（3）10个用户并发操作时，8个以上用户的事物平均响应时间不超过5秒；
（4）50个用户并发操作时，90%的事务平均响应时间不超过10秒；
（5）100个用户发操作时，90%的事务平均响应时间不超过15秒；
第五节功能测试
1.后台管理测试
管理员登录界面如图4-1-1所示，管理员需要输入正确的用户名和密码才能登录系统。
不同权限的管理员可以进入系统之后，将有不同的操作。
这部分将使用Quick进行测试，在测试之前将进行脚本的录制，然后通过对脚本的增强，完成登录场景的模拟。
图4-1-1管理员登录界面
因为登录时输入的情况可能存在差异，有可能用户输入了错误的用户名和密码，或者正确的用户名和错误的密码等，所有在设计测试用例时，主要采用等价类划分和边界值测试的方法。
测试用例如表4-1-1所示。
表4-1-1（a）管理员登录模块测试用例表头
项目名称
管理员登录模块测试
开发人员
XXX
模块名称
管理员登录模块
用例作者
王靖
参考信息
需求规格说明书、设计说明书
测试类型
功能测试
设计日期
2010-03-29
测试人员
王靖
测试方法
手动测试+自动测试
测试日期
2010-03-30
优先级
1
测试对象
测试管理员能否正常登录
前置条件
正确的用户名admin和密码123456
表4-3（b）管理员登录模块测试用例
用例编号
操作
输入数据
预期结果
实际结果
测试状态（P/F）
1-1
输入正确的用户名和密码，点击“登录”按钮
用户名：
admin
密码：
123456
成功登录
成功登录，进入系统管理主页
P
1-2
输入正确的用户名、正确的密码，点击键盘的“确定”键
用户名：
ben
密码：
123456
成功登录
成功登录，进入系统管理主页
P
1-3
输入正确的用户名和密码，将字符的大小写改变，点击“登录”按钮
用户名：
Admin
密码：
123
不能正常登录，提示“用户名不存在或错误”
不能成功登录，提示为“您的密码不正确”
F
1-4
输入错误的用户，点击“登录”按钮
用户名：
jjj
密码：
123
显示提示信息“用户名不正确”
显示提示信息“用户名不正确”
P
1-5
反复输入正确的用户名和错误的密码
用户名：
admin
密码：
123
显示提示信息“密码不正确”当三次输入错误的密码之后，显示验证码输入框
显示提示“密码不正确”当三次输入错误的密码后，显示验证码输入框
P
1-6
用户名和密码为空，点击“登录”按钮
用户名：
密码：
显示提示信息“请填写登录用户名”
显示提示信息“请填写登录用户名”
P
1-7
用户名为空，密码不为空，点击“登录”按钮
用户名：
密码：
123
显示提示信息“请填写登录用户名”
显示提示信息“请填写登录用户名”
P
1-8
用户名不为空，密码为空，点击“登录”按钮
用户名：
admin
密码：
显示提示信息“请填写登录密码”
显示提示信息“请填写登录密码”
P
注：
实际结果和输出状态在测试完成之后填写。
2.录制脚本
运行Quick，在URL框输入“，然后使用户名“admin”和密码“123”登录系统。
成功登录之后，退出。
得到的脚本如图4-1-2所示。
图4-1-2管理员登录模块测试脚本
脚本录制完成之后，为了模拟不同的登录情况，需要对脚本进行增强。
使用参数化的方法，将设计的测试用例通过数据表的方式导入测试脚本之中。
为了测试用户登录是否成功，还将在页面中插入文本检查点和图像检查点。
参数化之后的测试脚本如图4-1-3所示。
图4-1-2参数化之后的登录模块测试脚本
3.执行测试
完成测试脚本的增强之后，运行脚本，就开始测试了。
因为之前设计了8个测试用例，所以将运行8次测试脚本。
在执行过程中，因为当输入错误是，不能回到之前录制的界面，所以还需要手动回到脚本录制时的页面。
4.测试结果
从测试的结果来看，登录模块只存在一个提示错误，就是在将正确的用户名大小写改变的时候，系统提示不合理，属于级别1的错误。
第六节性能测试
1.系统分析
论坛主要分为前台和后台两大块。
后台主要提供给管理员，用于论坛的日常管理。
因为管理员的数量相对于普通用户来说很少，进行管理操作的频率也不是很高，所有对系统的性能测试主要集中在前台模块。
普通用户在前台可以登录论坛，浏览论坛帖子，发表主题，上传图片，发送短信等等。
2.系统压力估算
系统注册用户数大约在5000人左右。
白天同时在线的人数占总人数的5%，大约250人，并发操作用户占在线人数的15%，约37人。
晚上同时在线的人数占总人数的15%，约750人，进行并发操作用户数占在线人数的30%，约225人。
3.性能测试模块
因为环境和条件的限制，对论坛系统的性能测试不能全部进行，这里主要选取系统的核心模块和业务进行测试。
包括一下业务：
（1）用户登录；
（2）发表帖子；
（3）上传图片；
（4）综合业务。
4.测试场景设计
（1）用户登录模块
取并发登录系统的人数为10、20、50、100、200。
通过逐渐增加并发用户数，获得系统的响应时间等参数。
具体场景设置如表4-2-1所示。
表4-2-1用户登录场景设置
编号
并发用户数
操作描述
持续时间（min）
场景1
10
同时登录
10
场景2
20
同时登录
10
场景3
50
同时登录
5
场景4
100
每10秒登录5人
10
场景5
200
每10秒登录10人
10
（2）用户发帖模块
用户发帖的时候可以选择是否上传附件，这两种情况下，系统的响应情况会有所不同，为了更准确的表现系统的真实情况，将对上传附件和不上传附件的情况分别设计，附件的大小选择为100k。
具体设置如表4-2-2所示。
表4-2-2用户发帖模块场景设置
编号
并发用户数
操作描述
持续时间（min）
场景1
10
同时发帖（不带附件）
10
场景2
20
同时发帖（不带附件）
10
场景3
50
同时发帖（不带附件）
5
场景4
100
每10秒登录5人，同时发帖（不带附件）
10
场景5
200
每10秒登录10人，同时发帖（不带附件）
10
场景6
10
同时发帖（带附件）
10
场景7
20
同时发帖（带附件）
10
场景8
50
同时发帖（带附件）
5
场景9
100
每10秒登录5人，同时发帖（带附件）
10
场景10
200
每10秒登录10人，同时发帖（带附件）
10
（3）上传图片
系统处理图片上传的时间受并发用户数以及图片大小的影响。
但是系统设置的上传大小限制为200k，在具体操作过程中，大小的影响不是很大，为简化测试环境，真实模拟用户操作，上传的图片大小统一为100k。
具体的场景设置如表4-2-3所示。
表4-2-3图片上传模块场景设置
编号
并发用户数
操作描述
持续时间（min）
场景1
10
同时上传图片
10
场景2
20
同时上传图片
10
场景3
50
同时上传图片
5
场景4
100
每10秒登录5人，同时上传图片
10
场景5
200
每10秒登录10人，同时上传图片
10
（4）综合业务
用户登录系统之后不会总是进行相同的操作。
为了模拟这种情况，选择不同用户数量情况下，不同比例的用户进行不同的操作。
这里主要的操作有用户登录，发帖和上传图片。
发帖不不带附件，图片的大小为200k。
具体场景设置如表4-2-4所示。
表4-2-4综合业务场景设置
编号
并发用户数
操作描述
持续时间（min）
场景1
10
3个用户同时登录系统；4个用户同时登录系统并同时发帖；3个用户同时登录并同时上传图片
10
场景2
20
3个用户同时登录系统；8个用户同时登录系统并同时发帖；6个用户同时登录并同时上传图片
10
场景3
50
15个用户同时登录系统；20个用户同时登录系统并同时发帖；15个用户同时登录并同时上传图片
10
场景4
100
30个用户逐个登录系统，每隔10秒登录5人；40个用户逐个登录并同时发帖，每10秒登录5人；30个用户逐个登录并同时上传图片，每10秒登录5人
10
场景5
200
60个用户逐个登录系统，每隔10秒登录5人；80个用户逐个登录并同时发帖，每10秒登录5人；60个用户逐个登录并同时上传图片，每10秒登录5人
10
5.编写测试脚本
LoadRunner提供了脚步录制的功能，为了更真实的模拟用户操作以及系统环境，需要对录制的脚步进行修改。
以用户登录模块为例，使用LoadRunner录制好用户成功登录，然后退出的脚本。
在录制选项的地址栏输入登录页面地址，开始录制。
登录之前的操作放在vuser_init部分，用户输入用户名和密码，然后选择新建Actionuser_login，点击登录，然后退出论坛。
完成录制之后，为了模拟多用户并发登录的情况，需要对脚本进行修改。
在用户进行操作的的user_login中，插入登录操作的集合点login_rendezvous。
为了验证用户是否成功登录，在页面插入检查函数confirmlogin。
修改后的脚步如文本框4-2-1所示。
user_login（）
{
lr_rendezvous（"login_rendezvous"）;/*登录操作的集合点*/
web_submit_data（"",
"Action=",
"Method=POST",
"RecContentType=text/html",
"Referer=",
"Snapshot=",
"Mode=HTML",
ITEMDATA,
"Name=bbsuser","Value=johan",ENDITEM,
"Name=password","Value=123",ENDITEM,
"Name=ckies","Value=0",ENDITEM,
"Name=reurl","Value=",ENDITEM,
"Name=act","Value=y",ENDITEM,
"Name=Input","Value=登录",ENDITEM,
LAST）;
lr_start_transaction（"confirmlogin"）;/*验证是否成功登录*/
web_url（"",
"URL=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=",
"Mode=HTML",
LAST）;
lr_end_transaction（"confirmlogin",LR_AUTO）;
return0;
}
用户发帖的脚本需要考虑带附件和不带附件的情况，所有需要录制两个脚本。
上传图片的脚本录制和登录模块类似，选择上传的图片大小不超过200k。
综合业务的脚步需要组合前面的登录模块、发帖模块和上传图片模块的所有测试脚本，这可以通过场景设置来实现。
6.测试环境配置
执行测试是，需要手工配置测试环境。
LoadRunner采用了图形化的用户界面，方便用户的配置。
以登录模块为例，进入LoadRunnerController之后，选择添加录制好的脚本user_login，然后选择行程编辑。
设置用户登录的方式，如按照每5秒钟登录3人的方式，一共10个用户，持续时间为10分钟，退出系统的方式也是每秒钟3个用户。
完成环境配置之后，进入脚步运行模式，开始测试。
在测试过程中，可以实时监控系统性能指标，为了减少误差，在测试过程中，不进行其他任何操作。
完成一个场景之后，可以得到系统的请求响应时间，每秒的点击数等性能参数报告。
通过在不同环境下的到的参数，对系统的性能作出评估。
7.测试执行及结果
（1）用户登录模块
根据设计好的测试用例以及准备的测试脚本，运行测试，得到用户登录的测试结果如表4-2-5所示。
表4-2-5用户登录性能测试结果
用户登录测试结果
并发用户数
事务平均响应时间
事务最大响应时间
事务成功率
平均每秒点击率
平均流量
（字节/秒）
10
100%
47,
20
100%
257,
50
100%
284,
100
100%
311,
200
100%
275,
（2）用户发帖模块
用户发帖模块的性能测试与登录模块类似，编写好脚本之后，在场景生成器里面加载，然后根据设计的测试用例，配置场景。
因为发帖模块分为带附件发帖和不带附件发帖，所以需要录制两个脚本。
分别记录不同脚本下的性能数据。
完成测试之后得到的数据如表4-2-6所示。
表4-2-6（a）用户发帖（不带附件）性能测试结果
用户发帖（不带附件）测试结果
并发用户数
事务平均响应时间
事务最大响应时间
事务成功率
平均每秒点击率
平均流量
（字节/秒）
10
100%
180,
20
100%
207,
50
100%
228,
100
100%
256,
200
%
319,
表4-2-6（b）用户发帖（带附件）性能测试结果
用户发帖（带附件）测试结果
并发用户
升级会员 