第一篇：软件测试技术-实验报告内容格式
课程名称：《软件测试技术》
实验名称：《使用LoadRunner 进行性能测试》
实验目标：
1、掌握LR的测试过程；
2、掌握LR中 Visual User Generator（以下简称VuGen）、Controller和Analysis三个组件的具体使用。
实验要求：
采用LR 自带的HP WEBTours应用程序，进行性能测试。
实验过程：
1、录制LR 自带的HP WEBTours应用程序脚本，录制内容包括自动进入到WEB TOURS 网站，进行登录（已经注册成功），登录成功后，再定一张票，定票后，输入信用卡信息，然后退出登录，完成后，点击停止录制；（具体过程自己描述）
2、生成脚本；
（具体过程自己描述）
3、回放脚本；
（具体过程自己描述）
4、插入事件，分别在登录前和登录成功后、订票前和订票成功后四个位置插入一个事件；
（具体过程自己描述）
5、启动Controller，配置场景，选择场景类型为Goal—Oriented Scenario；（具体过程自己描述）
6、生成分析报告。
（具体过程自己描述）
参照《LoadRunner结果分析说明》文档进行分析，了解系统瓶颈在什么地方，需要改进，实验完成。
实验心得：
要求不得少于200字。
第二篇：软件测试实验报告
软件质量保证与测试
2016 ~ 2017学年
第二学期
学
院 计算机科学技术
专
业 软件工程 学
号
140521221 姓
名 蒲凤 指导教师王鹏
目录
一、单元测试.......................................................1 1.1实验目的......................................................1 1.2实验环境......................................................1 1.3实验原理......................................................1 1.4实验内容......................................................1 1.4.1 C#单元测试................................................1 1.4.2 测试用例..................................................4 1.5实验结果......................................................5 1.6实验总结......................................................6 1.6.1插件安装...................................................6 1.6.2心得体会...................................................6 1.6.3单元测试意义...............................................6
二、LOADRUNNER性能测试.............................................7 2.1实验目的......................................................7 2.2实验环境......................................................7 2.3实验原理......................................................7 2.4实验内容......................................................7 2.4.1 HP LoadRunner录制脚本.....................................7 2.4.2 HP LoadRunner脚本测试场景设计及分析......................17 2.5实验结果.....................................................33 2.6实验分析.....................................................34 2.7实验总结.....................................................34
三、反编译........................................................36 3.1实验目的.....................................................36 3.2实验环境.....................................................36 3.3实验原理.....................................................36 3.4实验内容.....................................................36 3.4.1 Net Refelector反编译.....................................36 3.5实验结果.....................................................40 3.6实验总结.....................................................41 3.6.1心得体会..................................................41
I 3.6.2 对软件安全性的看法.......................................41
四、SQL注入.......................................................42 4.1实验目的.....................................................42 4.2实验环境.....................................................42 4.2实验原理.....................................................42 4.3实验内容.....................................................42 4.3.1 sql注入..................................................42 4.4实验结果.....................................................52 4.5实验总结.....................................................54 4.5.1心得体会..................................................54 4.5.2 SQL注入危害..............................................54
五、禅道项目管理的BUG管理模块使用................................55 5.1实验目的.....................................................55 5.2实验环境.....................................................55 5.3实验原理.....................................................55 5.4实验内容.....................................................55 5.4.1禅道项目管理的bug管理模块使用............................55 5.5实验结果.....................................................67 5.6实验总结.....................................................68
II
一、单元测试
1.1实验目的
1.能够使用编程工具进行单元测试。
2.检查代码实现是否符合设计，尽早发现设计和需求中存在的错误。3.发现在编码过程中引入的错误，跟踪需求和设计的实现是否一致。
1.2实验环境
环境：vs2013
1.3实验原理
主要采用白盒技术，检查模块控制结构的某些特殊路径，期望覆盖尽可能多的出错点。
1.4实验内容
1.4.1 C#单元测试
1.新建一个类库项目，并为其中的类为BinaryTree.构建二叉树并添加前序遍历方法。如图1-1所示。
图1-1 2.创建单元测试。在方法名上右击，然后单击“Generate Unit Test”选项，打开对话框。如图1-2所示。
图1-2 3.选择方法，为新建项目命名。如图1-3所示。
图1-3 4.然后在解决方案管理中就多了相应的BinaryTree Tests解决方案。如图1-4所示。
图1-4 打开测试菜单->窗口->测试资源管理器，如图1-5所示。
图1-5 5.在测试试图，右键运行要测试的方法，在测试结果窗口中查看测试结果，运行测试之前。如图1-6所示。
图1-6 1.4.2测试用例
1.设置测试参数。如图1-7，1-8所示。
图1-7
图1-8 2.运行之后。如图1-9所示。
图1-9 1.5实验结果
经过测试，ResultEqualTest1，ResultEqualTest2均未通过测试，调整参数，重新测试,测试结果如下，如图1-10所示。：
图1-10 1.6实验总结
1.6.1插件安装
在vs2013进行单元测试之前，需要按照手动添加插件。选择工具-扩展和更新，搜索并安装Unit Test Generator。1.6.2心得体会
本次测试设计涉及预期测试需求，实验结果符合预期。单元测试帮助开发人员编写代码，提升质量，减少bug；提升反馈速度，减少重复工作，提高开发效率；保证最后的代码不会破坏之前的代码功能，同时让代码维护更容易，有助于改进代码质量和设计。1.6.3单元测试意义
单元测试集中注意力与程序的基本组成部分，首先保证每个单元测试通过，才能使下一步把单元组成部分组装成部件并测试其正确性具有基础。单元是整个软件的构成基础，只有保证零部件一样，这个设备的质量才有基础，单元的质量也是整个软件质量的基础。因此，单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。同时，单元规模较小，复杂性较低，因而发现错误后容易隔离和定位，有利于调试工作。
二、LoadRunner性能测试
2.1实验目的
1.掌握LoadRunner的使用方法。2.能够使用LoadRunner进行负载测试
3.学会用LoadRunner设计场景并尝试，并分析测试结果。
2.2实验环境
环境：HP LoadRunnner
2.3实验原理
LoadRunner进行负载测试通常有五个阶段组成：
计划、脚本创建、场景定义、场景执行和结果分析。
(1)计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需相应时间。
(2)创建Vuser脚本：将最终用户活动捕获到自动脚本中。(3)定义场景:使用LoadRunnerControlller设置负载测试环境。(4)运行场景：通过LoadRunnerControlller驱动、管理和监控负载测试。(5)分析结果：使用LoadRunnerAnalysis创建图和报告并评估性能。
2.4实验内容
2.4.1HP LoadRunner录制脚本
1.启动服务。如图2-1所示。
图2-1 2.登录自带网站WebTours，并注册。如图2-2所示。
图2-2 填写注册信息，如图2-3，2-4所示。
图2-3
图2-4 注册成功，如图2-5所示。
图2-5
3.打开Loadrunner，点击新建脚本打开VuGen。如图2-6所示。
图2-6 新建脚本，如图2-7所示。
图2-7
4.新建脚本，选择协议。如图2-8所示。
图2-8 5.选择浏览器，设置所测web的地址。如图2-9所示。
图2-9 6.点击左下角Options按钮，进入录制环境设置界面。如图2-10，2-11所示。
图2-10
图2-11
7、模拟用户操作开始录制脚本。如图2-12所示。
图2-12 用户操作如下，模拟用户订票。如图2-13所示。
图2-13 8.结束录制，生成脚本。如图2-14所示。
图2-14 9.回放脚本，验证脚本是否正确。如图2-15所示。
图2-15 回放结果，如图2-16所示。
图2-16 10.增加事务，并命名。如图2-17所示。
图2-17 给事务命名，如图2-18所示。
图2-18 查看事务，如图2-19所示。
图2-19 11.参数化。在脚本中找到需要参数化的值，例如登录名和登录密码。如图2-20所示。
图2-20 2.4.2HP LoadRunner脚本测试场景设计及分析
1.导入脚本，打开controller。如图2-21所示。
图2-21 2.选择文件路径。如图2-22所示。
图2-22 3.进入初始界面。如图2-23所示。
图2-23 4.为了设置集合点，取消默认勾选框，添加脚本。如图2-24所示。
图2-24 5.确定，进入场景设置界面。如图2-25所示。
图2-25 6.设置场景，选择初始化。如图2-26所示。
图2-26 7.打开运行时设置，设置迭代次数。如图2-27所示。
图2-27 8.设置迭代参数为2。如图2-28所示。
图2-28 9.点开Miscellaneous,设置Continueon error，使错误发生时可继续执行。如图2-29所示。
图2-29 10.设计集合点。如图2-30所示。
图2-30 设置当所有虚拟用户都到达集合点才释放，模拟多用户同时进行某一操作的情况。选中policy。如图2-31所示。
图2-31 11.设置policy。如图2-32所示。
图2-32 12.点击运行，进入运行时监控界面。如图2-33所示。
图2-33 13.点击运行场景。如图2-34所示。
图2-34 14.观察运行结果。如图2-35，2-36，2-37，2-38，2-39所示。
图2-35
图2-36
图2-37
图2-38
图2-39 15.设置场景运行时Windows资源监控图。如图2-40所示。
图2-40 点击添加。如图2-41，2-42所示。
图2-41
图2-42 运行时Windows资源监控图截图如下。如图2-43所示。
图2-43 16.打开分析器，形成分析结果。如图2-44，2-45所示。
图2-44
图2-45 17.分析器自动形成分析结果。如图2-46，2-47，2-48，2-49，2-50所示。
图2-46
图2-47 18.点开监控的图表，根据需要合并图表以便更好地分析。
图2-48
图2-49
图2-50 19．添加Windows资源监控图表。如图2-51，2-52所示。
图2-51
图2-52 20.添加页面分析结果图表。如图2-53所示。
图2-53 21.生成测试报告。如图2-54所示。
图2-54 生成测试报告中。如图2-55所示。
图2-55 生成测试报告，如图2-56所示。
图2-56 2.5实验结果
回放验证。如图2-57所示。
图2-57
生成测试报告，点击内容，如图2-58所示。
图2-58 2.6实验分析
通过测试报告可以看出，最多能够创建10个vuser，平均吞吐量是14320字节每分，平均每秒点击数量约为10次。同时可以通过以下方式使被测系统所受压力减轻,从如下方面进行综合调解:将测试脚本中think time值加大并在控制台中按比例实现,此处think time指在transaction外部的时间；Controller中Run-Time Setting的Pacing设置值加大；虚拟用户登录时使用递增策略，间隔稍长。
2.7实验总结
LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。学会了使用LoadRunner录制脚本。基本的流程是启动服务器、注册、录制脚本及进行参数化设置。设计涉及场景的搭建和测试，通过Lordrunner进行脚本测试，同时能够生成相应的图表，直观的反应了测试结果。Lordrunner作为专业的性能测试工具,通过模拟成千上万的用户对被测应用进行操作和请求,在实验室环境中精确重现生产环境中任意可能出现的业务压力,然后通过在测试过程中获取的信息和数据来确认和查找软件的性能问题,分析性能瓶颈。
三、反编译
3.1实验目的
1.学会如何使用反编译工具对程序进行反编译。2.能够使用.NetRefelector进行反编译。
3.2实验环境
环境：.Net Refelector,VS2008 3.3实验原理
反编译的主要思想：将特定的机器代码，即我们的“源程序”，先翻译为低级的中间代码，然后再根据特定的高级语言将中间代码翻译为高级程序。反编译器也有前端和后端。前端是一个机器依赖的模块，句法分析二进制程序、分析其指令的语义、并且生成该程序的低级中间表示法和每一子程序的控制流向图。通用的反编译机器是一个与语言和机器无关的模块，分析低级中间代码，将它转换成对任何高级语言都可接受的高级表示法，并且分析控制流向图的结构、把它们转换成用高级控制结构表现的图。最后，后端是一个目标语言依赖的模块，生成目标语言代码。反编译的过程中要使用一些工具：把二进制程序装入内存，对这一程序做句法分析或反汇编，以及反编译或者分析该程序来生成高级语言程序。这个过程借助编译器和库的签名来识别特定的编译器和库子程序。只要在二进制程序中识别出编译器签名，就不去反编译这些编译器启动代码(start-up)和库子程序：对于前者，从最后的目标程序去掉启动代码的那些例程，反编译器从主(main)程序入口点开始分析；对于后者，那些子程序用其库函数名代替。
3.4实验内容
3.4.1Net Refelector反编译
1.启动.NETRefelector(在所有程序中找到RedGate文件夹)找到安装文件，点击运行。如图3-1所示。
图3-1 2.选择文件，打开可执行文件。如图3-2所示。
图3-2 选择文件路径。如图3-3所示。
图3-3
3.导入工程截图如下。如图3-4所示。
图3-4 4.相关函数和类，如图3-5所示。
图3-5 5.选中工程，导出源码。如图3-6所示。
图3-6 6.选择导出文件路径。如图3-7所示。
图3-7 7.选中反编译程序，点击运行。如图3-8所示。
图3-8 3.5实验结果
反编译成功，如图3-9所示。
图3-9
3.6实验总结
3.6.1心得体会
本次实验通过反编译工具进行了反编译，完成了从可执行文件到源码的转换，学会了如何使用.NET Refelector反编译工具。3.6.2 对软件安全性的看法
软件安全（Software Security）就是使软件在收到恶意攻击的情形下依然能够继续正确运行及确保软件被在授权范围内合法使用的思想。软件安全性分析任务包含于软件生存周期的若干活动中，是针对软件的安全性质量，作为这些活动的补充。软件安全性分析作为开发中软件的质量的重要保证，关系到软件的获取、供应、开发、运行和维护，已得到专业人士的高度重视。并且现在，软件安全性分析任务的各项细节执行都写入了国军标，被安全相关软件的需方、供方、开发者、维护者以及独立的评价者使用。规范化将推进软件安全性分析的进程，使更多的开发和评测单位遵循标准化文件，督促开发团队采取相应的技术手段，以软件测试作为辅助。同样，软件安全性分析标准也会在推进的过程中，得到不断地发展。
四、SQL注入
4.1实验目的
1.明白SQL注入原理。2.能够进行简单的SQL注入。
4.2实验环境
环境：VS2013，SQL Server Management Studio 4.2实验原理
SQL注入即是指web应用程序对用户输入数据的合法性没有判断，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
4.3实验内容
4.3.1 sql注入
1.点击SQL SERVERR２。如图4-1所示。
图4-1 登陆数据库，如图4-2所示。
图4-2 ２.创建数据库SQLTEST。如图4-3，4-4所示。
图4-3
图4-4 ３.创建表UserLogin。如图4-5所示。
图4-5 设置主键如下，如图4-6所示。
图4-6 设置成功，截图如下。如图4-7所示。
图4-7 输入表名。如图4-8所示。
图4-8 4.选中表，编辑前200行。如图4-9所示。
图4-9 5.编辑测试数据，如图4-10所示。
图4-10 6.打开VS2013，新建项目。如图4-11所示。
图4-11 选中Asp.net Web应用程序。如图4-12所示。
第三篇：《软件测试技术》课程总结报告
《软件测试技术》课程总结报告
班级：姓名：学号：
一、课程概述
二、课程实训项目
三、课程知识点总结
四、收获和体会
第四篇：软件测试技术面试总结
软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念
+基本知识+软件开发过程-定义-计划-实现-稳定化-部署
+软件开发模型(四种典型的模型)
+瀑布模型
-概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。
-特点：1.阶段的顺序性和依赖性；2.文档驱动； 3.推迟实现的观点；4.质量保证。-缺点：不适合需求模糊的系统
+原型模型-概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。
-特点：1.快速开发工具；2.循环； 3.低成本。
-分类：按照对原型的处理方式，可以分为渐进型和抛弃型。
+增量模型
-概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。
-同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。+螺旋模型
-概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。
-特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；
2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。
-软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。
-测试用例
-三要素：前提条件和操作步骤、预期结果、实际结果。
-必须以需求为依据。
-软件测试分类
-是否关注软件结构和算法
-黑盒测试：基于软件需求的测试方法。
-白盒测试：基于软件内部设计和程序实现的测试方法。
-是否执行被测试软件
-动态测试：在测试过程中执行被测试软件的测试方法。
-静态测试：------------不----------------------。
-基于不同的测试阶段：
-单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。
-集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是
客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。
-系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由
独立的测试
人员完成，通常采用黑盒测试方法。
-验收测试：(α、β)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。
-回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。
-软件测试的三个步骤：
-测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。
-测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动 程序的开发。
-执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。
-测试工程师的能力要求：
+5C
-Controlled /kEn'trEuld/ 接受管理，有条理的-Competent /'kCmpitEnt/了解正确的测试技术
-Critical /'kritikEl/专注于发现问题
-Comprehensive /.kCmpri'hensiv/ 注意细节
-Considerate /kEn'sidErit/能够和开发人员很好的交谈
+职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累 +制定测试计划的五个步骤：-分析和测试软件需求-定义测试策略
-定义测试环境
-定义测试管理
-编写和审核测试计划
如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。——越早测试越好-在需求分析过程中测试人员需要进行如下工作：
1)理解需求，参与审核需求文档；
2)理解项目的目标、限制，了解用户的应用背景；
3)编写测试计划；
4)准备测试资源。
+需求测试
-需求测试测试的对象是主意而不是代码，针对文档进行测试。
+好的需求文档的特征-具有清晰的格式和文档结构-需求的内容正确-需求的内容完整-需求具有可行性需求的必要性
-对不同的需求优先等级进行定义-描述明确-可证性和可测试性-可修改性-可追踪-需求文档被及时更新
+需求测试内容
-需求文档是否符合公司的格式要求
-是否正确
-要保证需求文档中所描述的内容是真实可靠的-这是“真正的”需求吗？描述的产品是否是要开发的产品？
-需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？-需求是否兼容？需求有可能是矛盾的。
-需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？
需求的输入或输出设备要求的分辨率是否要求过高？
-需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。
-需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。+需求测试方法-复查review-走查walkthrough-审查inspection
+测试策略的内容
-确定测试范围 软件是无法被完全测试的-确定测试方法 不同的系统需要不同的测试方法
-定义测试标准 入口标准，暂停和继续的标准，出口标准等
+软件测试结束的标准
-基于测试用例的使用规则
1)构造测试用例（由相关人员进行评审）
2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。
3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。
-基于“测试期缺陷密度”规则
--------------含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则
--------------含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试注：一个阶段的出口标准!=下一个阶段的入口标准
系统测试结束的标准!=软件的发布标准
发布标准!=软件0缺陷
-选择测试工具 是否需要，需要什么工具，怎么获取
-降低软件测试代价是企业普遍关注的问题，可通过
a.减少冗余和无价值的测试；
b.减少测试阶段(万般无奈下)
+测试环境
-基本内容：设备环境、软件环境、数据环境
-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备
-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境 +测试管理 由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理
-选择缺陷管理工具和测试管理工具
-定义工作进度
-建立风险管理计划
+可能遇到的风险
·由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加
·开始测试时所需的硬件、软件没有准备好
·未能完成对测试人员的技术培训
·测试时的人力资源安排不足
·测试过程中，发生了大量的需求变更
·测试过程中，项目的开发计划被大幅度调整
·不能及时准备好测试所需的环境
·不能及时准备好测试数据
+风险管理的过程
·识别风险
·评估风险
·制定对策
·跟踪风险
+测试设计与开发
+总体设计
-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则
-清楚地说明没项测试的目标
-使每项测试的目标单一，可以对应到规格说明书中的一项需求
-只说明测试应该完成什么工作，而不说明如何完成-流程：总体设计-开发测试用例-评审测试用例
I.定义设计目标
II.定义输入说明
III.定义测试环境和配置
IV.测试设计文档
V.开发测试用例
+测试用例
-概念：为特定目标开发的测试输入、执行条件和预期结果的集合。
+好的测试用例：
-容易发现软件的错误
-精确的重复某测试失败的情景，可重复性
-清晰的定义一个或多个期望的结果
-没有冗余
+测试用例的作用
-指导测试的实施
-作为编写测试脚本的“设计规格说明书”
-评估测试标准的度量基准
-分析缺陷的标准
+白盒测试用例设计
+设计方法
+逻辑覆盖法
-语句覆盖
-判定覆盖
-条件覆盖
-判定-条件覆盖
-条件组合覆盖
-路经覆盖
-基本路经法
+辅助模块设计
-驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。
-桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。
+黑盒测试用例设计
-等价类划分法
-边界值法——“缺陷遗漏在角落里，聚集在边界上。”
-因果图法弥补等价类和边界值法的不足
-错误推测法
-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。+常见错误分析
-用户界面问题
·输入无合法性检查和值域检查。
·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。
·表达不清或过于模糊的信息提示。
·要求用户输入多余的本来系统可以自己得到的数据。
·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。·不经用户确认就对系统或数据进行了重大修改。
-形象类问题
·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。
·不够专业，缺乏基本知识。
·界面中英文混杂，甚至拼写错误。
·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。·界面元素参差不齐，文字不能完全显示。
－稳定性问题
·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。
·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。
·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请
不成功、长时间无响应等)有关。
-其他问题
·运行时不检查内存、硬盘空间、数据库等。
·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。·提供的版本带病毒。
·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。
·用户现场开放和修改，又没有记录和保留。
·版本中部分内容或接口倒退，或出现版本管理混乱。
·有些选项永远都是灰的，或有些在该变灰时没变灰。
+测试用例的评审
-测试或测试组件完全针对的是需求中列出的功能吗？
-测试组件是否覆盖了所有的需求？
-有冗余的吗？
-每个测试步骤都有清楚描述的预期结果吗？
+优先级
+3级
优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行
+5级
1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试
第五篇：《软件分析与测试》实验报告范例.doc
《软件分析与测试》实验一：白盒测试实验报告
一、实验目的1、通过简单程序白盒测试，熟悉测试过程，对软件测试行程初步了解，并养成良好的测试习惯。
2、熟练掌握如何运用基路径测试方法进行测试用例设计，进行逻辑覆盖率分析。
二、实验内容<测试内容的描述>
……
三、实验原理
白盒测试原理：分析程序的内部逻辑结构，选择适当的覆盖标准，设计测试用例，对主要路径进行尽可能多的测试。白盒测试测试用例一般采用逻辑覆盖法进行设计。
语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。
判定覆盖：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值。
条件覆盖：执行足够的测试用例，使得所有判定中的每个条件至少都获得一次“真”值和“假”值。
判定/条件覆盖：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。
条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。
路径覆盖：路径覆盖是相当强的逻辑覆盖，它保证程序中每条可能的路径都至少执行一次。
四、实验步骤：
1、测试程序源代码
……
2、测试程序流程图
……
3、测试用例设计
……<要求分别使用语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合测试、路径覆盖（及完全覆盖）方法设计测试用例>
4、测试用例分析
……<比较各种设计方法，给出结论>
五、总结与体会
……
《软件分析与测试》实验二：黑盒测试实验报告
一、实验目的1、系统地学习和理解黑盒测试的基本概念、原理，掌握黑盒测试的基本技术和方法。
2、通过试验和应用，要逐步提高和运用黑盒测试技术解决实际测试问题的能力。
二、实验内容<测试内容的描述>
……
三、实验原理
黑盒测试原理：不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。
等价分类法：根据程序的I/O特性，将程序的定义域划分为有限个等价区段 —“等价类”，从等价类中选择出的用例，具有“代表性”。应按照输入条件（如输入值的范围，值的个数，值的集合，输入条件必须如何）划分为有效等价类和无效等价类。有效等价类，对于程序的规格说明是合理的、有意义的输入数据构成的集合。无效等价类，对于程序的规格说明，是不合理的，是没有意义的输入数据构成的集合。
边值分析法：选择等价类的边缘值作为测试用例，让每个等价类的边界都得到测试，选择测试用例既考虑输入亦考虑输出。
决策表：在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。最适合描述在多逻辑条件取值的组合所构成的复杂情况下，分别执行哪些不同的动作。
因果图法：一些程序的功能可以用判定表（或称决策表）的形式来表示，并根据输入条件的组合情况规定相应的操作。它是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
四、实验步骤：
1、测试用例设计
……<要求分别使用等价分类法、方法边值分析法、因果图法、决策表设计测试用例>
2、测试用例分析
……<比较各种设计方法，给出结论>
五、总结与体会
……
《软件分析与测试》实验三：测试自动化实验报告
一、实验目的1、系统地学习和理解测试自动化的基本概念，掌握测试自动化的基本技术和方法。
2、通过试验和应用，要逐步提高和运用测试自动化工具解决实际测试问题的能力。
二、实验内容<测试内容的描述>
……
三、实验环境
在Eclipse集成开发环境中使用JUnit来作为自动化的功能测试工具。Eclipse本身集成了JUnit相关组件，并对JUnit的运行提供了无缝的支持。
JUnit是一个开放源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。它包括以下特性：
1、用于测试期望结果的断言（Assertion）
2、用于共享共同测试数据的测试工具
3、用于方便的组织和运行测试的测试套件
4、图形和文本的测试运行器
Eclipse 是一个开放源代码的、基于 Java 的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。幸运的是，Eclipse 附带了一个标准的插件集，包括 Java 开发工具（Java Development Tools，JDT）。
四、实验步骤：
1、测试过程
……
2、测试分析
……
五、总结与体会
……
//注释：
1、省略号为自定义部分,需要补充完整；
2、<>中内容为说明文字部分；
3、其他文字要求都写入报告中（包括 注释1中的内容）。
点击咨询 