打印 保存
检测文献 基于Web 的企信通软件系统测试方案的研究与实现 作 者
检测范围
中国学术期刊网络出版总库
中国博士学位论文全文数据库/中国优秀硕士学位论文全文数据库 中国重要会议论文全文数据库 中国重要报纸全文数据库 中国专利全文数据库 大学生论文联合比对库 互联网资源
英文数据库(涵盖期刊、博硕、会议的英文数据以及德国Springer 、英国Taylor&Francis 期刊数据库等) 港澳台学术文献库 优先出版文献库
时间范围 1900-01-01 至 2013-04-19 检测时间
2013-04-19 22:27:40
总文字复制比：1.1%
( 表格 )
( 观点 )
去除引用：1.1%
去除本人：1.1%
重合字数：154
文献总字数：13417
( 注释： 无问题部分
文字复制比部
分
引用部分 ) 基于Web 的企信通软件系统测试方案的研究与实现 总文字复制比：1.1%（154） 总字数：13417
1 ·软件测试及其在物流服务操作系统测试中的应用
吴亚平(导师：薛志东) - 《华中科技大学硕士论文》- 2010-05-01
1.1% 是否引用：否
毕业论文
基于Web 的企信通软件系统测试方案的研究与实现 The Study of
Software Testing Case Programm Based on Web application of EMIP 完成日期 2013 年 4 月 3 日
吉林大学珠海学院本科毕业论文开题报告
基于Web 的企信通软件系统测试方案的研究与实现
摘要
目前，软件产品种类越来越多，因此
质量更受到大众的关注。无论是客户端产品还是web端产品都越来越注重
软件产品测试。软件测试是软件产品的质量保证，贯穿软件开发的整个过程，是企业和客户利益的保证。
而基于web环境的软件产品，由于环境系统的复杂性，更容易产生问题。
“企信通”是一个通用移动信息平台，该平台利用现有飞速发展的INTERNET和移动网络资源，向各机关、企业提供全面的内外信息服务。本文以基于web的企信通产品为例，阐述了软件产品的测试过程，包括软件产品的功能测试、性能测试、软件缺陷管理等内容。通过对软件产品实施测试，找出潜藏的缺陷，加以修复，最终提高软件产品的质量。
关键词: ?企信通信息平台；功能测试；自动化性能测试；缺陷流程管理
The Study of Software Testing Case Programm Based on Web application of EMIP
Abstract
At present, more and more types of software product, and more by the quality of public concern. Both client pro ducts and web products are increasingly focused on software product testing. Software testing, which is a software prod uct quality guarantee, runs through the whole process of software development and guarantees the interests of the enter prises and customers. The software products based on web environment, because of the complexity of the environmental system, easily cause various problems to some extents.
MEIP is an universal mobile information platform, the platform using the current rapid development of INTERNE T and mobile network resources, in order to provide inside and outside of information services for the various agencies and enterprises. Using the software that MEIP based on Web software system as an example, this paper expounds the software testing process, including functional testing, performance testing of software products, software defect manage ment, etc. Through the test for software product, the quality of software products is improved eventually by finding out latent defects and repairing.
Key words：EMIP information platform；functional test；automation process；management of defects
目录
1 绪论 (1)
1.1 研究背景 (1)
1.2 产品简述 (1)
2功能测试 (3)
2.1 什么是功能测试 (3)
2.2 测试方法 (3)
2.3 测试用例 (4)
2.4 测试大纲 (6)
2.5测试流程 (7)
3 自动化性能测试 (10)
3.1 为什么要进行自动化性能测试 (10)
3.2 性能测试目的和内容 (10)
3.3 自动化测试过程 (11)
3.3.1 负载计划 (11)
3.3.2 创建脚本 (11)
3.3.3 场景定义及执行 (15)
3.3.4 测试策略 (15)
3.3.5 结果分析 (15)
3.3.6 总结 (18)
4 缺陷的概述 (19)
4.1Bug的定义 (19)
4.2 Bug产生的原因 (19)
4.3 Bug类型 (19)
4.4 Bug优先级 (20)
4.5 Bug的状态 (20)
4.6 Bug的生命周期 (21)
5 缺陷管理工具的使用 (22)
5.1 问题类型（Issue Type） (22)
5.2 优先级（Priority Levels） (22)
5.3 状态（Status） (22)
5.4 解决（Resolutions） (22)
5.5 bug描述 (23)
6 结束语 (25)
参考文献 (26)
致谢 (27)
1 绪论
1.1 研究背景
当今随着经济的发展，互联网发展也越来越迅速，基于web的软件产品也层出不穷。基于web的软件产品之所以受人欢迎是因为其方便性，无论何时何地，只要有网络就可以上网，不需要安装就可以直接使用。企信通产品就是为了方便用户无论何时何地的进行及时的信息传递，通过短彩信的方式跟客户进行信息交流。但是由于Web环境的复杂性，涉及到前台、数据库、网关等，所以Web软件很容易出现问题。为了保证客户的放心使用，必须对企信通进行严格测试，尽早尽快地发现产品中存在的问题，并及时修复，保证软件产品的质量水平。软件的质量代表着企业和用户双方的利益，而软件测试是质量的有力保障。
由于用手机发送短彩信，编辑信息，管理通讯录、查看收发记录等操作的不方便，且只适用于少量用户的收发信息。针对这种情况，企信通在Web环境中产生，一款适用于企业大量用户使用的信息发送平台。企信通让用户更加方便快捷的进行短信操作，融合其他特别功能，能对短彩信进行白名单、敏感字审批和检查，有效防范垃圾信息的发送，节约资源。用户对企信通的信赖不仅是取决于产品的功能，而是对企信通产品质量的放心。这要取决于公司对企信通产品测试的看重，每次产品的发布升级，前都必须经过大量测试，先把问题解决了才允许上线，从而是产品得到质量的保证。
1.2 产品简述
测试产品：企信通信息发送平台Web版
广东省企信通产品正式平台链接地址：https://www.doczj.com/doc/0a18933675.html,/mp/；
产品简介：企信通信息发送平台是集短信群发、收发记录箱、通讯录管理、短语模版、白名单维护、活动短信、报表等功能于一体的软件产品。企信通融合了移动网和互联网的企业级信息交互及综合信息管理平台，让企业拥有高效的企业沟通、协同工作、移动营销的平台，提高企业信息技术水平和办公效率[7]。具体功能界面如图1-1所示：图1-1 企信通功能界面
企信通还包括多类产品，如企信通、动力100、企业彩云，各企业根据需要可以使用单产品、多产品，发送号码地市限制等分类。每类产品都有各自不同的特点，丰富多元化，满足客户不同的需求。适用于公共基础行业、旅游娱乐行业、房地产销售行业、汽车行业、政企单位等。
2功能测试
2.1 什么是功能测试
功能就是为了实现某一个操作，比如一个提交按钮，提交就是把输入的信息提交到指定的地方。功能测试就是对产品的功能进行测试，检验产品的功能是否能正常使用，有没有达到预想需要的效果。一个产品包含很多功能，小到一个按钮，大到需要很多功能配合才能完成。企信通主要的功能有：短彩信常规群发、文件群发、收发记录、精彩短语、活
动短信、白名单、个人设置、系统设置、报表统计、下载客户端和使用手册等。
功能测试可以根据功能的测试用例，按每个功能逐条测试，验证产品的每个功能是否可用，是否存在缺陷，是否达到用户对功能的需求。功能测试不只是要验证单个功能是否可用，还要验证许多功能组合起来是否有用，因此功能测试需要考虑的地方很多，而且要覆盖到尽可能多的测试路径。
2.2
测试方法
功能测试方法有很多，以下是常用的测试方法：等价类划分法、边界值分析法、错误推测法、因果图法、功能图法、正交表法、判定表法。这些都是黑盒测试方法，黑盒测试方法主要是针对功能测试而言的，不涉及产品内部结构，从用户的角度测试并验证软件功能[1-1]。
1)等价类划分法可以分为有效等价类和无效等价类，有效等价类相当于是合理的、有意义的数据集，无效等价类相当于不合理的、没有意义的数据集[1-2]。
2)边界值法就是在边界的范围中，在最小值、略小于或大于最小值、正常值、最大值、略小于或大于最大值中取输入变量值[1-3]。
3)错误推测法是根据测试经验、知识和直觉来推测软件产品中可能出现的问题，从而有针对性的进行测试[1-4]。
4)因果图用于描述系统之间的输入输出，输入输出之间的约束和因果关系。通常因果图与判定表往往结合使用，使用因果图可以得到判定表[1-5]。
5)功能图可以形式化地表示程序的功能说明，把各个功能以图的形式表现出来[1-6]。
6)判定表方法主要用于处理程序输入条件的不同组合，但是要求条件的组合必须是布尔类型，而且条件和预期的结果都是可以分析出来的[1-7]。
7)正交表法要考虑到各个功能点，根据功能点的状态或因素，制作成正交表，根据不同的条件会得到不同的测试结果[1-8]。表2-1是短信发送功能的正交表，具体如下图所示：
表2-1 短信发送功能正交表
2.3 测试用例
测试用例是为了测试某个功能而编制的一组包含编号、测试目的、预设条件、操作步骤以及输出预期结果、实际结果，用来测试和验证该功能与实际需求是否保持一致的依据，要求遍历每个功能点。通常测试用例需要结合测试方法和具体功能来编制。
表2-2是企信通彩信群发功能的部分测试用例：
表2-2 测试用例表
2.4 测试大纲
测试大纲是为了理清测试思路而把要测试功能的各个主干功能点及涉及到的相关内容罗列出来，确保测试时不会遗漏某些功能，也可以为编写测试用例做铺垫。测试大纲通常包括五个方面：入口测试，界面测试，功能测试，组合功能测试，兼容性测试。即是相对于我们常说的“这个功能在哪里？长啥样？什么时候操作，对谁操作？能做什么？会造成什么结果？”。现以企信通单产品短信群发功能为例编写一个测试大纲如下图2-3所示：
图2-3 短信群发测试大纲
2.5测试流程
软件测试的基本流程：测试需求分析阶段->测试设计阶段->测试准备阶段->测试执行阶段->回归测试->性能测试->测试报告编写。
测试需求分析阶段：
需求分析阶段主要工作是为产品的设计而获取测试项目的客户需求和软件的规格。
输出产物：软件需求规格说明书
测试设计阶段：
根据测试需求规格说明书，制定软件产品的总体测试计划，根据项目特点和实际情况来编制，用来描述测试的目的，把握测试的强度、周期、范围和进度。
输出产物：测试计划
测试准备阶段：
本阶段根据测试需求规格说明书，编写各个功能的测试用例，尽量考虑到每个细小的功能点，并进行客户场景分析；准备测试所需要的数据做成测试样张。
输出产物：测试用例、测试样张
测试执行阶段：
本阶段主要是根据测试计划、测试用例展开测试，把隐藏在产品中的缺陷查找出来，创建并提交bug，等待开发修复后，再进行验证和回归。
输入产物：进入bug管理流程
回归测试：
对之前测试并已经修复的bug进行回归验证，验证bug是否已经修复，修改后会不会对其他功能造成影响，会不会产生其他新的问题。
输出产物：回归测试报告
性能测试阶段：
利用Loadrunner自动化工具对软件产品进行压力性能测试，验证产品的性能是否符合需求，并查找影响性能的因素。
输出产物：性能测试报告
测试报告编写：
对本次软件产品的测试做出总结，包括测试需求、测试过程和测试结果。
输出产物：测试报告
测试流程图如图2-4所示：
图2-4 测试流程图
3 自动化性能测试
3.1 为什么要进行自动化性能测试
产品的研发不仅仅是为了个人的需求，更是为了广大的用户市场，良好性能的产品往往会得到更多客户的信赖。进行自动化性能测试是为了检验该软件在大量用户的使用下，能否处理满足需求所要的事务量，超负荷业务量的处理，系统是否稳定；检验该产品的响应速率会不会影响到客户的使用。主要影响因素有响应时间、内存、磁盘、CPU、处理器等。
3.2 性能测试目的和内容
测试目的：
应用性能测试工具Loadrunner对系统产生模拟真实使用环境的压力负载，并且监控客户端和服务器端的性能指标，查看是否出现系统性能瓶颈或缺陷。并且查看不通过的事务是什么原因造成的，根据error的内容进行找错。
测试内容：
企信通平台日常使用频繁且业务量大的功能主要有登录、发送短信、通讯录操作，这次测试以西藏企信通版本的登录功能为例做性能测试，登录界面如图3-1所示。
测试地址：
公司搭建的测试环境：http://192.168.20.52:9081/meip_xz_final/。
图3-1 登录界面
3.3 自动化测试过程
3.3.1 负载计划
录制性能测试脚本，参数化登录账号、密码，循环遍历N遍达到并发用户数量，将登录成功后进入短信群发界面作为一个事件，设置集合点，并发三百个用户同时在线进行登录、退出登录操作，用户加载方式以15秒加载5个用户，退出操作以15秒5个用户退出。
3.3.2 创建脚本
vuser_init() /*开始*/
{
web_add_cookie("SAVE_EID=; DOMAIN=192.168.20.52");
web_add_cookie("SAVE_UID=; DOMAIN=192.168.20.52");
web_add_cookie("qxt.conglomerate.cookie=; DOMAIN=192.168.20.52");
web_url("meip_xz_final",
"URL=http://192.168.20.52:9081/meip_xz_final/",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
EXTRARES,
"Url=index/images/login_button_2.gif", ENDITEM,
LAST);
return 0;
}
login() /*登录*/
{
lr_think_time(64);
web_custom_request("login.do",
"URL=http://192.168.20.52:9081/meip_xz_final/login.do?ajax=1&eid={ID1}&uid={ID2}&password={key}&validateCod e=0980&localvalue=&SAVE_LOGINIDON&rn=0.9290206934205811",
"Method=POST",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=http://192.168.20.52:9081/meip_xz_final/",
"Snapshot=t2.inf",
"Mode=HTML",
"EncType=",
LAST);
lr_rendezvous("login"); /*插入集合点-当300聚集时，才开始登录*/
lr_start_transaction("login"); /*插入开始事务点*/
web_url("mq*index.do",
"URL=http://192.168.20.52:9081/meip_xz_final/mq*index.do",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t3.inf",
"Mode=HTML",
EXTRARES,
"URL=css/newIndexCss.css", ENDITEM,
"URL=2012/plugins/dialog/css/basic_ie.css", ENDITEM,
"URL=images/icons/navigate_down_10.gif", ENDITEM,
"URL=2012/images/proIcon.gif", ENDITEM,
"URL=2012/images/contactsTag.png", ENDITEM,
"URL=2012/images/contactsTag_bg.png", ENDITEM,
"URL=2012/images/search_02.gif", ENDITEM,
"URL=images/icons/bullet_creme.gif", ENDITEM,
"URL=2012/images/sel_topBg.png", ENDITEM,
"URL=2012/images/titleBanner.png", ENDITEM,
"URL=2012/images/clear_Btn.png", ENDITEM,
"URL=2012/images/sendButton.gif", ENDITEM,
"URL=advancejs/jsimages/cluetip/wait.gif", ENDITEM,
"URL=2012/images/left_round.gif", ENDITEM,
"URL=2012/images/right_round.gif", ENDITEM,
"URL=2012/images/search_btn.gif", ENDITEM,
"URL=2012/plugins/zTreev3.0/css/zTreeStyle/img/zTreeStandard.gif", ENDITEM, LAST);
lr_end_transaction("login", LR_AUTO); /*插入结束事务点*/
web_submit_data("ms*eaddressAlllist.do",
"Action=http://192.168.20.52:9081/meip_xz_final/ms*eaddressAlllist.do", "Method=POST",
"TargetFrame=",
"RecContentType=application/json",
"Referer=http://192.168.20.52:9081/meip_xz_final/mq*index.do",
"Snapshot=t4.inf",
"Mode=HTML",
ITEMDATA,
"Name=id", "Value=0", ENDITEM,
"Name=stype", "Value=ajaxSelectGroup", ENDITEM,
"Name=keyValue", "Value=", ENDITEM,
LAST);
web_submit_data("ms*eaddressAlllistShare.do",
"Action=http://192.168.20.52:9081/meip_xz_final/ms*eaddressAlllistShare.do", "Method=POST",
"TargetFrame=",
"RecContentType=application/json",
"Referer=http://192.168.20.52:9081/meip_xz_final/mq*index.do",
"Snapshot=t5.inf",
"Mode=HTML",
ITEMDATA,
"Name=id", "Value=0", ENDITEM,
"Name=stype", "Value=ajaxSelectGroupShare", ENDITEM,
"Name=keyValue", "Value=", ENDITEM,
LAST);
return 0;
}
vuser_end() /*退出*/
{
lr_think_time(19);
web_url("logoff.do",
"URL=http://192.168.20.52:9081/meip_xz_final/logoff.do",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=http://192.168.20.52:9081/meip_xz_final/mq*index.do",
"Snapshot=t6.inf",
"Mode=HTML",
LAST);
return 0;
}
3.3.3 场景定义及执行
表3-2 场景表
运行场景如图3-2时收集的数据：
服务器和客户端的资源使用情况，例如：CPU和内存的使用率；Load Runner 运行场景时用户各个事件的状态，相关的点击率和响应时间。
3.3.4 测试策略
通过压力测试工具LoadRunner 模拟大量的虚拟用户对服务器进行并发访问，从而检测和收集服务器的响应和资源使用情况。
测试过程中，记录虚拟用户执行的有关数据（如点击率、响应时间等测试结果），获取系统性能的相关数据，同时，找出系统存在的瓶颈，并进行解决或者优化。
3.3.5 结果分析
1）用户登录时的响应时间如下：
表3-3 相应时间表
具体请参考图3-4 登录的每个事件的响应时间：
图3-4 事件响应时间
2）从图3-5中可以看到，服务器每秒通过事务数（Transactions per Second），从中可以看到服务器在压力加大时，响应的事务数随之增加，所以服务器的响应是正常。图3-5与图3-6网络吞吐量的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。
图3-5 服务器每秒通过事务数
图3-6 网络吞吐量
3）服务器资源的使用情况
在整个测试的过程中，服务器的CPU和内存使用都是比较稳定的，CPU一般都是维持在10%左右，登录时最高峰值达到70%，不过很快就恢复到正常水平；内存一般占用在800MB左右，登录时最高峰达到900多MB，但也很快恢复到800MB。具体可以参考图3-7服务器资源使用情况图。
图3-7 服务器资源使用情况图
3.3.6 总结
根据测试结果可以得出，系统平台能够支持300个用户同时在线登录，并发300个用户时事务的响应时间正常，并且系统资源使用正常，没有出现瓶颈。
由于测试时是在客户端加载了大量的虚拟用户，所以客户端资源的消耗比较大，而且也导致大部分的时间消耗在网
络资源上，所以用户的登录完成时间一般在12秒左右，但如果在正式平台和实际的用户使用情况，是不会有这样的情况出现的，而且正式平台的服务器配置使用负载均衡，所以如果正式用户登录的时间可以快很多，应该可以在5秒之内就可以登录成功。
4 缺陷的概述
4.1Bug的定义
软件缺陷，又被叫做Bug，即软件产品中存在一些问题或错误会导致软件产品不能正常运行，或导致用户使用不方便。
必须满足下列规则之一才称为软件缺陷：
1）软件未达到软件需求说明书标明的功能。
2）不允许出现软件需求规格说明书中已经明确的错误。
3）出现需求规格说明说没有的功能，或不在说明书的范围的。
4）虽然软件需求说明书没有提及，但应该实现的功能。
5）软件测试人员认为很难明白或理解、不便于操作、影响运行、会影响用户使用的的功能。
4.2 Bug产生的原因
因为环境或者软件产品的复杂度，所以导致bug产生的原因有很多，如系统的复杂性、环境的影响、需求不准确等，具体可以归纳为图4-1中的几种情况。
图4-1 bug原因
4.3 Bug类型
为了方便测试人员对缺陷的理解和辨别，根据实际情况和缺陷特性，可以把bug按类别分为功能、赋值、接口、联编打包、文档、用户接口、性能、标准、环境等，具体可以参照图4-2所示。
图4-2 bug类型
4.4 Bug优先级
根据发现的bug的严重程度，测试人员需要判别bug的优先级，通常bug对软件产品的危害较大，严重程度就越大，优先级也越高。相反对软件产品危害较小，优先级也越低。具体可以参照图4-3所示。
图4-3 bug优先级
4.5 Bug的状态
Bug被发现后，测试人员或开发人员要对bug做相关处理，每个阶段bug被赋予不同的状态，如bug需要被提交、打开、拒绝或修复、关闭或重新打开。Bug状态可以参照bug生命周期，具体如图4-4所示。
图4-4 bug状态
4.6 Bug的生命周期
Bug状态主要包括:new、fixed、open、reopened、rejected、defer、closed
检查新缺陷
1) 开发负责人检查是否有new(新发现)的缺陷，如果经过验证确认是bug，将它设置为为open（开放）状态，如果发现这条bug不是bug时，应该设置为Rejected（拒绝），对于重复的问题也应该Rejected并标明备注，在bug评审会上可以对Rejected状态的bug判定是closed（关闭）还是open（开放）状态。如果开发人员对Rejected bug的原因是bug 描述不清，请在回执备注中注明；如果是其他的原因，也请在回执备注中注明清楚。
2）如果开发人员确认是bug，但目前没时间改或者不影响大局的可以将状态置为defer（延迟）。
修改开放缺陷。
1）开发人员确认是bug并对其进行修改，也可直接修改new状态的bug，修改完成后将bug状态改为fixed（已修复）状态。
验证缺陷
验证状态时请注意实际fixed时间和历史记录中的时间是否一致，要求只检查版本发布时间以前fixed的bug。
1）测试人员需要对fixed状态的bug在新版本中进行回归测试，如果回归验证通过，将bug状态设置为closed（关闭）状态；
2）如果验证不通过，将bug状态改为reopened（重新打开）状态,开发人员需要重新修改。
3）测试人员在每个新版本都应检查rejected的bug，注意是否有备注，如果有，请根据备注分析所提交的bug是否真正属于缺陷，如果是则将bug置为reopened，同时给予合理的reopened原因，如果不是缺陷请测试人员给予明确的备注并closed该bug。反之，没有备注的rejected的bug应更加仔细检查，操作如同有备注的rejected的bug,看看bug是否重现。
5 缺陷管理工具的使用
JIRA 是目前比较流行的基于Java架构的过程管理工具，主要包括项目管理、任务管理和缺陷管理，能够跟踪并有效的管理项目开发、测试和维护过程中出现的问题（如项目、缺陷和任务管理等）[8]。
5.1 问题类型（Issue Type）
JIRA系统也可以对多种类型的问题进行管理，自定义添加想要的问题类型。JIRA系统提供的问题类型有Bug（缺陷）、New Feature（新功能）、Task（需求任务）、Improvement（需要改进的功能）等。因为bug数量较多，所以一般较长用于缺陷管理。
5.2 优先级（Priority Levels）
对应于bug的严重性，在JIRA 系统中用优先级的高低来表示，优先级较高，严重性就较高，反之亦然。系统管理员可以在JIRA 系统中添加严重优先级，一般有：Blocker、Critical、Major、Minor、Trivial，具体如下：
1)Blocker（P1级）即致命的错误，阻碍产品的开发进度，导致软件系统无法运行等；
2)Critical（P1级）即
软件系统系统崩溃、死机、数据丢失、系统悬挂、环境问题、内存溢出等严重错误、或者功能和特性没有实现；
3)Major（P2级）即不太严重的错误，主要的功能没有很好的实现、新增功能建议，不影响正常使用；
4)Minor（P3级）即一些小错误，功能操作不便或对现有系统的改进；
5)Trivial（P3级）即界面错误，如拼写错误错别字、格式对齐等；
5.3 状态（Status）
每个bug所处的阶段不同，所以每个bug都要赋予一个状态。bug通过开始于open 状态，然后开始处理问题In P rogress，再到解决问题Resolved，最后问题被关闭Closed或是问题被重新打开Reopened。可以根据实际项目的需求来定制bug的相应状态。
5.4 解决（Resolutions）
系统管理员可以根据项目的实际情况和需求在系统中定制相应的解决方式。JIRA系统默认的解决方式有已经解决的问题（Fixed）、将不会解决问题（Won’t Fix）、重复的问题（Duplicate）、问题描述的不精准或不完全、问题不能够重现（Cannot Reproduce）。
5.5 bug描述
1、对于bug的描述需要简洁易懂；
2、bug描述必须描述清晰，步骤明了，让任何人都能看懂包括没有使用过的普通用户也能将bug重现出来；
3、每个bug有唯一的标识（即每个bug的KeyID）；
图5-5 BUG记录
综上所述，上几节中主要讲述对bug进行编写时需要的因素，只有在提交了bug后才能对bug进行管理。JIRA可以对bug进行跟踪及管理，如创建、汇总、分类和查询。此外JIRA还具有问题跟进情况的分析报告、项目类别管理功能、组件/模块管理功能等。缺陷管理工具能高效的对bug进行管理，也是测试人员和开发人员重要的交流工具。开发人员通过JIRA把修改的结果、缺陷原因、修改影响的范围等标注在上面。测试人员通过JIRA可以提交问题，对开发修复完的问题状态、原因、影响范围加以了解，阅读开发备注后才可以回归问题，并对问题打上相应的状态。当然如果遇到开发备注不明的地方，应当找开发了解清楚，再进行回归。
6 结束语
在这次论文中，通过结合课本中的理论知识、实习中学到的实际经验，对软件测试整个过程进行了系统性的归纳。论文包含了在实习中掌握测试的知识和技巧，学习到的新知识，如自动化测试、配置管理等。还归纳了实践中积累的宝贵的经验，这些经验会让我们的技术更成熟。论文的完成，让我对整个测试的工作有了新的体会，清楚的认识到哪里还
存在不足，哪里还需要加强，并对软件测试有了重新的认识和理解，总结如下：
1.作为一个软件测试新人，在开展测试工作之前应该先阅读该软件产品的需求规格说明书，学习该系统的相关的概念，清楚该产品业务功能的设计思想、使用方法和这些功能逻辑之间的关联。应该从用户的角度去考虑这些业务，假设用户的使用场景，这样才能够准确的把握测试结果。
2.按照测试用例来执行测试，测试应该尽早的进行，因为BUG发现越早，各方面损失也越小。
3.做回归测试的时候，测试人员应该先查看开发修改备注，再及时向开发人员了解可能影响到的模块，测试人员根据具体情况在回归bug的同时，要注意受影响模块是否产生新问题，避免有漏网之鱼的情况。
4.团队合作精神。项目测试组里往往每个人负责不同功能模块，而各模块之间又有一些共同的东西。积极主动地与组里各成员沟通，既可以避免重复报BUG,又可以使彼此更加熟悉整个项目各模块的联系，使测试工作更加高效顺利进行。
参考文献
[1] 朱少民.软件测试方法与技术（第2版）.清华大学出版社，2005
[2]
柳胜.性能测试从零开始——LoadRunner入门与提升.电子工业出版社2011
[3]
陈邵英等编.loadRunner性能测试实战.电子工业出版社2007
[4]
刘德宝.Web项目测试实战.北京科海电子出版社，科学出版社2009
[5]
Loadrunner使用教程百度文库
[6] Loadrunner操作手册百度文库
[7]企信通操作手册
[8]Jira缺陷管理工具Jira从入门到精髓豆丁网
[9]巴顿（RonPatton）.软件测试（英文版）（第二版）. 机械工业出版社，2006
致谢
在这次论文中，首先要感谢我的导师，给予我毕业论文上的指导。在我毕业论文过程中，给了我很好意见和指导，对于我的论文有很大的帮助。其次要感谢实习工作中的指导师傅和组长，帮助我解决在工作上的问题。让我学习到很多工作上的知识，教我怎么去融入工作中。还要感谢很多同事，因为他们给了我很多宝贵的建议，并借一些书籍和资料给我做参考。这次论文的顺利完成，离不开老师、同学和同事的指导和建议，更离不开实习单位提供的良好环境和氛围。而且要感谢和我一个项目团队的伙伴，在完成项目任务的过程中对我的帮助和教导，让我在工作中吸取宝贵的经验。以上的所有因素，都对我的论文撰写有很大的帮助，让我顺利的完成从选题到论文的编写。
剽窃文字表述
1. 一个软件测试新人，在开展测试工作之前应该先阅读该软件产品的需求规格说明书，学习该系统的相关的概念，清
楚该产品业务功能的设计思想、使用方法和这些功能逻辑之间的关联。应该从用户的角度去考虑这些业务，假设用户的使用场景，这样才能够准确的把握测试结果
表格检测结果
检测文献包括表格：
表格1：
相似
表3对象1的相关约简
表格
1：
79.41%
相似
度：
基于相异关系的粗糙集理论-曾剑锋,吴根秀-《江西师范大学学报(自然科学
版)》-2004-10-30
相似表格2：表1九点两类模式编码
相似度：82.35%
用线性多步法训练神经网络-许少华,梁久祯,何新贵-《计算机研究与发展》
-2001-12-15
红色黄色文字表示引用部分)
打印保存https://www.doczj.com/doc/0a18933675.html,
返回顶部