软件测试实验报告

1、软件质量保证与测试实验报告指导教师刘卫红实验一 用例设计与黑盒测试1、 实验目的a) 能够熟练应用黑盒测试技术进行测试用例设计b) 对测试用例进行优化测试2、 实验设备主流PC机一套，安装有主流的编程工具如MyEclipse、C、Visual C+3、 实验内容（1） 实现一个登陆模块，用户名要求由字母和数字组成且第一个必须是字母，长度为6-10，密码由六位数字组成，请根据黑盒测试的方法设计测试用例。编程工具myeclipse+tomcat+orcal部分代码：用户登陆用已有账号登陆用户ID 密码: if(action.equals(login)int id=Integer.parseInt(

2、request.getParameter(id);if(id.matches(a-zA-Z1,)6,10)request.setAttribute(login_msg, 登陆失败，账号或密码错误);request.getRequestDispatcher(login.jsp).forward(request, response);return；String password=request.getParameter(password);if(password.maches(0-96)request.setAttribute(login_msg, 登陆失败，账号或密码错误);request.ge

3、tRequestDispatcher(login.jsp).forward(request, response);return；userDAO dao=new userDAO();try user u=dao.findByID(id);if(u=null|!u.getUserpwd().equals(password)request.setAttribute(login_msg, 登陆失败，账号或密码错误);request.getRequestDispatcher(login.jsp).forward(request, response);elseout.print(登陆成功); catch

4、(Exception e) e.printStackTrace();测试用例：（2）为QQ的注册账号功能设计测试用例。注册账号功能部分截图如下：Qq注册测试用例详细的界面可打开QQ网站的注册账号链接查看，每个字段的要求点击相应的输入域即可看到。4、 实验要求(1) 实验内容1需要编写相关程序。(2) 撰写实验报告，并给出设计的测试用例对程序进行测试5、 实验思考(1) 在实际的测试中，你的测试用例达到了发现程序缺陷的目的吗？答：基本达到了(2) 在进行程序设计中，你的测试用例是否达到测试的充分性和减少测试用例的冗余性。答：没有，以后会慢慢解决实验二 Web测试1.实验目的掌握用例执行及缺陷报告

5、的书写方法。2.实验设备主流PC机一套，网络通畅。3.实验内容测试NBA英文版网站，或目前使用的一些知名网站，如QQ空间，报告四个缺陷。4.实验要求将所发现的四个缺陷进行详细描述，撰写实验报告，描述缺陷可使用中文，附件若必要，也可使用视频，截取图片或抓取视频时，需要有浏览器的标题栏和地址栏。附：缺陷描述样本：Bug Title: Home-Login link does not work in IE6OS & BS: Windows XP Professional SP3 + IE6Bug Type：FunctionalSeverity Degree: MediumAction Steps:1

6、. Visit NBA Home with IE6: 2. Click LoginExpect Result: Go to the login page.Actual Result: No response. BTW: FF10 and Chrome 17 NO this issue.Bug Attachment: 网址：浏览器：win10 edge浏览器问题描述：图片显示不了网址：浏览器：win10 edge浏览器问题描述：图片加载不了实验三 代码分析与单元测试1.实验目的掌握白盒测试方法，并用白盒测试方法设计测试用例；掌握使用Junit进行单元测试的方法。2.实验设备主流PC机一套，安装有

7、主流的编程工具如MyEclipse、C、Visual C+3.实验内容题目一：折半查找请按要求对下面的Java代码进行测试。代码的功能是：用折半查找法在元素呈升序排列的数组中查找值为key的元素。public int binSearch(int array,int key)int mid,low,high;low=0;high=array.length-1;while(low=high)mid=(low+high)/2;if(key=arraymid)return mid;else if(keyarraymid)high=mid-1;elselow=mid+1;return -1;(1) 用基

8、本路径测试给出测试路径；(2) 为各测试路径设计测试用例。题目二：设计一个加减乘除的计算器程序，利用Junit实施自动测试4.实验要求对于题目一，根据题目要求编写测试用例。对于题目二，给出程序和测试的源代码，并附上测试执行成功与否的截图。撰写实验报告。5.试验思考题目一中使用基本路径测试设计的测试用例，分支覆盖率、条件覆盖率和语句覆盖率是多少？程序的环路复杂性即McCabe复杂性度量，简单的定义为控制流图的区域数。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的最少测试用例数。 通常环路复杂性可用以下三种方法求得。 （1）通过控制流图的

9、边数和节点数计算。设E为控制流图的边数，N为控制流图的节点数，则定义环路复杂性为 V（G）= E N + 2 ； 该图中共有16条边，14个节点，因此 E = 16 ，N = 14 ， V(G)=E-N+2=16-14+2 = 4 ，程序的环路复杂性为4。 （2）通过控制流图中判定节点数计算。若设P为控制流图中的判定节点数，则有V(G) = P + 1 该图中有3个判定节点，因此其环路复杂性为V(G)=P+1=3+1=4，所以该程序的环路复杂性为4。 （3）将环路复杂性定义为控制流图中的区域数。该控制流图中有4个区域：R1、R2、R3、R4，因此其环路复杂性为4。 通过程序的控制流图导出基本路

10、径集，列出程序的独立路径。实验四 性能测试和结果分析1. 实验目的（1）掌握性能测试的原理，及使用LoadRunner进行性能测试的方法；（2）掌握分析测试结果的基本方法。2. 实验设备主流PC机一套， LoadRunner 8.03. 实验内容（1）配置一个用户登陆系统；（2）录制脚本（即创建虚拟用户脚本）；（3）创建场景（设置用户数 0) lr_output_message(登录成功，继续执行.); else lr_error_message(登录失败，退出测试); return -1; 上述代码的意思是说，如果登录失败了，就退出脚本的迭代，那么什么原因可能会导致登录失败呢？就是我们前面参

11、数化的设置，一旦Vuser分配不到正确的登录账号，就可能导致登录失败，从而引起Vuser停止运行。所以，从图5- 7的表现，可以认为参数化是没有问题的。图1- 7运行的并发数图测试脚本中我们还使用了集合点，那么这里还可以看看集合点在场景执行过程中的表现，点击左边的“New Graph”，出现图5- 8，展开“Vusers”前的加号，双击“Rendezvous”，出现集合点的图形后，点击【Close】，关闭添加新图界面。图1- 8添加集合点统计图集合点的图形如图1- 9所示，从图中可以看到，所有用户到达集合点后，立刻就释放了。与之前设定的集合点策略设置“所有运行用户到达后释放“是一致的。假设这样

12、的一种情况，Running的Vusers有10个，集合点策略设置是“所有运行用户到达后释放”，而集合点图形显示的最大释放Vusers是7个，那么就表示有些Vuser超时了，引起超时的原因可能是Vuser得到的响应超时了，可以结合平均事务响应时间再详细分析原因。图1- 9集合点状态图我们本次测试Running Vusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。 响应时间在性能测试要求中我们知道，有一项指标是要求登录、考勤业务操作的页面响应时间不超过3秒，那么本次测试是否达到了这个要求呢？我们先来看“Average Tran

13、saction Response Time（平均事务响应时间图）”（图1- 10），这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。图1- 10平均事务响应时间图从图形下部我们可以看到，登录部分对应的Action是“submit_login”，考勤业务提交对应的Action是“submit_sign”，他们的“Average Time（平均响应时间为）”分别是4.425秒与0.848秒，从这两个数值来看，考勤业务的事务响应时间0.848秒小于预期的3秒，达到了要求，而登录是4.425秒，大于预期的3秒，不符合要求。这样的结果是不正确的，因为在统计的登录业

14、务的时候，我们没有去除思考时间，所以，登录功能的实际事务时间应该是4.425秒-3秒=1.425秒，小于预期的3秒，故登录业务的事务响应时间也达到了我们的要求。在平时的性能测试活动中，统计结果的时候需要去掉思考时间，加上思考时间是为了真实的模拟用户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，两者并不矛盾。看完了“Average Time”，我们再看“90 Percent Time”，这个时间从某种程度来说，更准确衡量了测试过程中各个事务的真实情况，表示90%的事务，服务器的响应都维持在某个值附近，“Average Time”值对于平均事务响应时间变动趋势很大的情况统计就不准

15、确了，比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些。从图5- 10可以看出，所有Action平均事务响应时间的趋势都非常平滑，所以使用“Average Time”与“90 Percent Time”差别不是

16、很大，用哪个都可以。这里是使用最常用的统计方法“90 Percent Time”。登录业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，没有思考时间，那么就是实打实的啦。根据上面的计算，本次测试结果记录如表1所示。测试项目标值实际值是否通过登录业务响应时间=3秒2.298秒Y考勤业务响应时间=3秒1.469秒Y登录业务成功率100%考勤业务成功率100%登录业务总数30分钟完成2000考勤业务总数30分钟完成2000CPU使用率75%内存使用率70%表1测试结果对照表一 每秒点击数“Hits pe

17、r Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。图1- 11显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。如果“Hits per Second”正常，而“Average Throug

18、hput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。具体问题具体分析，这里仅给出一些建议。图1- 11每秒点击数与每秒吞吐量复合图对于本次测试来说，“Hits per Second”与“Average Throughput (bytes/second)”都是正常的，而且整体表现还是不错的。一般情况下，这两种指标用于性能调优，比如给定了几个条件，去检测另外一个条件，用这两个指标衡量，往往

19、起到很好的效果。比如要比较某两种硬件平台的优劣，就可以使用相同的配置方法部署软件系统，然后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。 业务成功率“业务成功率”这个指标在很多系统中都提及到，比如电信的、金融的、企业资源管理的等等。举个例子，我们楼下的建行，假如每天的业务类别是这样的：20个开户，5个销户，300个存款，500取款，100个汇款等，那么在做他们的营业系统测试时就需要考虑业务成功率了，一般不得低于98%。具体的业务成功率是什么意思呢？排除那些复杂的业务，比如异步处理的业务（移动的套卡开通就是异步的），业务成功率就是事务成功率，用户一般把一个Aciton当做一笔

20、业务，在LoadRunner场景执行中一笔交易称为一个事务。所以，说业务成功率其实就是事务成功率、通过率的意思。在“Transaction Summary”中我们可以很明确的看到每个事务的执行状态，如图1- 12所示。图1- 12事务状态统计图从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表2所示。测试项目标值实际值是否通过登录业务响应

21、时间=3秒2.298秒Y考勤业务响应时间=3秒1.469秒Y登录业务成功率100%100%Y考勤业务成功率100%100%Y登录业务总数30分钟完成20002163Y考勤业务总数30分钟完成20002163YCPU使用率75%内存使用率70%表2测试结果对照表二 系统资源系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图1- 13所示。图1- 13测试服务器系统资源监控结果图从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指

22、标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了错误！未找到引用源。的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。获得上述数据后，最新的测试结果记录表如表3所示。测试项目标值实际值是否通过登录业务响应时间=3秒2.298秒Y考勤业务响应时间=3秒1.469秒Y登录业务成功率100%100%Y考勤业务成功率100%100%Y登录业务总数30分钟完成20002163Y考勤业