《软件分析与测试》实验报告范例.doc

第一篇：《软件分析与测试》实验报告范例.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中的内容）。

第二篇：软件测试实验报告

软件质量保证与测试

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所示。

第三篇：软件测试技术-实验报告内容格式

课程名称：《软件测试技术》

实验名称：《使用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字。

第四篇：《实用会计软件》课程实验报告分析

2015-2016学年第二学期 《实用会计软件》课程实验报告

实验一 应收应付系统初始化

一、实验内容 设置系统参数 设置基础资料 输入初始数据 与总账系统对账 结束初始化

(应收、应付系统是两个系统，要分别进行操作）

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

财务部、往来账会计马秀伟（XXX5)

四、实验主要步骤：

系统设置—初始化—应收款管理--期初数据录入（1）应收帐款（发票、预收单、其他应收款）（2）应收票据 业务

财务会计—应收款管理—选择单据类型—选择业务类型

2、单据生成凭证

（1）财务会计—应收款管理--凭证处理

（2）单据保存和审核后直接在单据的界面上生成凭证

3、核销

（1）财务会计—应收款管理--结算--核销管理（2）收款单保存和审核以后在单据中直接核销 用户管理

初始余额录入

系统参数设置

科目设置

客户设置

部门设置

职员设置

物料设置

供应商设置

应收款汇总

应付款汇总

实验二

供应链初始化

一、实验内容

设置供应链系统核算参数

设置供应链系统相关的公用基础资料 设置系统参数 初始存货余额录入

输入启用前未处理完单据 与总账系统对账 结束初始化

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

财务部张婷(XXX1)：基础资料 存货初始余额录入，结束初始化 仓库管理员曹敏(XXX9)输入库存类单据 仓库主管 赵力(XXX8)审核曹敏输入的单据

四、实验主要步骤：

系统设置—初始化—供应链--参数设置

系统设置—初始化—供应链--初始存货余额录入

实验三

供应商管理

一、实验内容

设置供应商供货信息 采购价格设置 采购报价的审核

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

采购资料、单据由采购员胡开林录入

资料、单据审核由采购部经理李大勇（XXX6）审核

四、实验主要步骤：

实验四

采购业务流程定义

一、实验内容 业务流程的设置

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员 采购部经理李大勇

四、实验主要步骤：

供应链--→采购管理--→采购订单----→保存--→审核

供应链--→采购管理--→采购订单----→保存--→审核

供应链--→采购管理--→外购入库----→保存--→审核

供应链--→采购管理--→费用发票----→保存--→审核

供应链--→采购管理--→采购发票----→确定--→钩稽--→全部退出

供应链--→入库核算--→外购入库核算--→确定--→核算 供应链--→凭证管理--→生成凭证--

供应链--→仓储管理--→领料发货----→审核

实验五

采购申请

一、实验内容 采购申请单的输入 采购申请单的审核

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

采购申请 车间工人胡兵、赵武 审核 车间主任张二柱、朱铁

四、实验主要步骤： 采购申请单

实验六

采购订货

一、实验内容

采购订单的多级审核设置 采购订单的录入 采购订单的审核

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

采购订单（合同）整理 胡开林

限额内采购订单由采购部经理李大勇审核 超出限额，还需由财务部经理许静审核 采购订单的审核规范由财务部经理许静确定

四、实验主要步骤：

【实验七】仓库收货

一、实验内容 外购入库单的输入 外购入库单的审核

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

原材料的采购入库

仓库管理员

曹敏(XXX8)负责 进出库业务单据 审核 仓储部 赵力(XXX9)

四、实验主要步骤：

【实验八】财务记账

一、实验内容 采购发票的输入 采购发票的审核

采购发票和外购入库单的勾稽

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

原材料的采购入库

仓库管理员

曹敏(XXX8)负责 进出库业务单据 审核 仓储部 赵力(XXX9)

四、实验主要步骤：

【实验九】采购退货

一、实验内容

采购退货单的输入及审核 红字发票的输入及审核

红字发票和采购退货单的勾稽

二、实验条件：

微机一台； 软件环境：金蝶K3 WISE v13.1

三、操作部门及人员

采购退货的处理由仓库管理员曹敏负责 进出库业务单据 审核 仓储部经理 赵力 红字发票由往来账会计马秀伟处理

采购发票的审核、勾稽由财务部经理许静负责。

四、实验主要步骤： 打开【采购入库单】

单击工具栏上的【红字】按钮，依次键入【供应商】、【日期】信息

单击选中【源单类型】为外购入库，在【选单号】过滤窗口中单击选中已经收货的蓝字外购入库单

键入退货的数量，单击【保存】保存退货单

第五篇：软件测试需求分析与定义方法

软件测试需求分析与定义方法

如何确定测试工作的范围？

对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。那么到底该如何确定每次迭代是测试工作的范围呢？在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。

不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？一个实际的做法就是实现软件需求的版本化控制。（用软件需求的版本化控制来解决软件需求的频繁变更）既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。如何整理测试需求？一旦当前阶段测试工作的范围确定下来，我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。整理测试需求的第一步，就是要“测试需求”。测试需求？对，不知道您是否想到，这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。

啊？这不是已经超出了测试工作的范围了吗？测试人员不是应该只关心软件的实现同需求是否相符吗？这样对测试人员要求未免太高了。——这是笔者过去同一些朋友谈到测试人员必须对需求进行检查时听到的一些不同的声音。在这里，首先要明确一个问题，就是软件测试的工作到底做什么？

在《软件测试》（Ron Patton〔美〕，中文版由机械工业出版社出版，这本书是测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。

瞧！这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时候呢？

不知道大家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不同版本的软件工程方面的书中，对于软件缺陷都会有一段类似的描述：缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见下图）。这样看来，上面问题的答案自然就变成了“秃子头上的虱子”：从需求阶段开始！从“测试需求”开始！

注意，笔者这里的观点并不是说可以取消团队中的“需求评审会议”，这里并不存在冲突。笔者所希望讲述的，是测试人员应该如何看待软件需求，而并不是把“需求评审会议”所承担的责任揽到自己身上。?在论坛上也偶尔看到有的朋友问：如何测试需求呢？每次看到这样的提问，笔者内心就禁不住的一阵激动，因为一直以来，讨论这方面问题的朋友的确少之又少。

在笔者的实际工作中，对软件需求的检查包括两个方面的内容。

一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。

二是要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。当然，对于如何提高软件需求的质量，在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法，如果有兴趣，大家也可以找来参考。不过，如果您是一位测试者，那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试，慢慢的体会，一定会发现这种方法给您带来的好处。?现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约（以下简称SRS）和用例（以下简称UC）——当然，也可能是一份包含UC的SRS。通过对SRS和UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测试需求中最基本的一部分。

至于测试需求的表现形式，笔者认为大家都可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需求中，用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。

另外，大家也可能注意到了，在软件开发过程的这个阶段，通常是没有用户界面（以下简称UI）可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分，但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求，将是完全基于业务的，而并不包括基于UI的那部分规则，是同软件的最终具体实现相独立的。

随着开发工作的继续，开发部门的架构设计文档和详细设计文档也将陆续提交，这时候，我们可以根据设计文档来对已有的测试需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有同SRS或UC中已经定义的部分相符的内容，才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一方作为基准，决定是否需要调整软件需求，然后对测试需求进行相应的增补或者调整。比如对于一些算法，需要考虑设计文档中定义的，同系统实现相关的那些计算公式，是否同软件需求中描述的算法表达的是否是同一个意思？而对于一些约束或者业务规则，设计文档中描述的是否同需求中的相应部分一致？呵呵，看完上面这部分内容，恐怕又有一部分朋友晕倒在地了，而没有晕倒的那部分朋友也要提出异议：啊？！你这不是又包含了对开发人员所作的设计工作的检查吗？！刚刚让我们检查需求，现在又让我们检查设计，真的把我们当成全才了！没办法，为了让软件交到我们手上的时候只包含尽量少的缺陷，大家只能再辛苦一下了。我们的工作不应当仅仅限制在软件交付后尽力找到存在的缺陷，而更应该努力及早发现软件缺陷出现的苗头，尽量预防缺陷的出现。虽然并不是说在所有的团队中都应该由测试人员承担“测试需求”和“测试设计”的工作，但是测试人员对这些工作起到的作用，是其他团队中的其他角色所无法替代的。开发部门完成编码实现工作，提交供内部测试的应用程序时，测试人员手头上应该已经准备好了绝大部分测试用例和测试数据，测试部门将开始执行测试。通常在我们执行测试的过程中，即使我们已经从“通过测试”和“失败测试”两个不同的角度准备了非常充分的测试用例和测试数据，但总是有些缺陷的出现是出乎我们意料的，或者说是已有的测试需求和测试用例未能覆盖的。那么，对于这部分缺陷，也应当添加到测试需求中，并设计相应的测试用例，以便于下次版本迭代时进行参考。OK，相信说到这里，各位看客也应该可以理解我的观点了：对于一个长期发展的团队或者持续开发的产品，它的所有东西都是要不断积累的、不断迭代的。无论对于软件需求还是测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间，也是不断迭代和积累的。