软件测试毕业论文Word文件下载.docx
《软件测试毕业论文Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试毕业论文Word文件下载.docx（20页珍藏版）》请在冰豆网上搜索。
本文的主要结果详略恰当地给出了软件测试技术的方法与策略。
进行一次完整的软件测试过程，并完成测试过程的基础上撰写。
其中包括根据所选的系统拟出了测试计划并设计出了一大批的测试用例，测试分析报告。
关键字：
软件测试；
文档；
BUG。
、/.—
前言
随着信息技术全球化的深入发展，我国的软件产业将不可避免地融入全球软件产业。
一方面，更多地大型跨国软件公司加大对中国市场的投入，对产品和服务本地化的需求快速增加。
另一方面，越来越多地国内大型软件公司正加速国际化发展的步伐，它们逐步走出国门，加入全球竞争行列。
软件质量表示软件符合用户使用要求的程度，这种程度不仅表现在软件产品自身的功能性和性能方面，也表现在软件的国际化和本地化能力等方面。
软件企业只有提高软件质量，不断改进质量管理的方法和流程，提供具有符合国际市场和用户要求的高质量软件产品，才能具备进军国际市场的实力。
提高软件测试在软件生命周期中的地位是保证软件质量的关键，做好软件测试工作是解决软件质量问题的根本，为了保证国际化软件的产品质量，进行有效的国际化测试成为必不可少的生产过程。
由于目前我国软件企业的规模普遍较小，而且主要面向国内用户市场，对软件国际化和本地化发展战略和实现技术认识不足，重视不够，特别是在保证国际化软件的质量管理和测试技术方面，与国外同行相比还存在较大差距。
国内软件测试的成熟度不高，特别在国际化软件测试方面的滞后，在一定程度上，影响着我国软件在国际市场上的竞争力，也影响着我们承接软件外包服务的规模。
因此，探讨和研究软件测试技术，成为摆在国内软件界的新课题。
1.1软件测试的必要性
软件测试的意义在于：
（1）发现软件错误；
（2）有效定义和实现软件成分由低层到高层的组装过程；
（3）验证软件是否满足任务书和系统定义文档所规定的技术要求；
（4）为软件质量模型的建立提供依据。
软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。
第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。
第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。
如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。
因此软件测试的第三个目的是保证整个软件开发过程是高质量的。
软件质量是由几个方面来衡量的，在正确的时间用正确的方法把一个工作做正确。
符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。
质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量。
质量也代表着它符合客户的需要。
作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。
只有这些问题都解决了，软件产品的质量才可以说是上去了。
总之，它的目标就是确保软件的质量。
1.2软件测试需求分析
理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。
然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。
在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求（当发生这种情况时，普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。
是的，事实上，资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。
）由于后者涉及需求工程的专门知识，本文略过不做细述；
这里重点讨论前者。
在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW项目建议书等文档中）
细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。
在UML表示方法中，用户需求通常通过UseCase来进行刻画。
接下来，
用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。
这三类需求项就是通常意义上的软件需求项。
管理这三类需求项的矩阵被称为需求矩阵。
理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。
（注意：
为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。
详细论述请参阅拙文《试论软件测试学科架构建设》）然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排
序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。
软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。
对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认），测试需求开发所涉及的工作内容和方法都会略有差异。
例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）；
又如，如果是系统
测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。
再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。
如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。
根据协同工作的结果，开发出对应的测试需求。
最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。
如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。
根据此结果，进一步开发相应的测试需求。
相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。
例如为了保证系统能够长期、安全、稳定、可靠、高效的运行，机票预定系统应该满足以下的性能需求：
耍户信.?
.'
¥
克
图2-1系统功能模块图
（1）系统处理的准确性和及时性
系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。
由于机票预定系统的查询功能对于整个系统的功能和性能完成举足轻重。
作为系统的很多数据来源，而机票数量和时间又影响企业的决策活动，其准确性很大程度上决定了机票预定系统的成败。
在系统开发过程中，必须采用一定的方法保证系统的准确性。
（2）系统的开放性和系统的可扩充性机票预定系统在开发过程中，应该充分考虑以后的可扩充性。
例如订票系统的方式的改变（网上订票），用户查询的需求也会不断的更新和完善。
所有这些，都要求系统提供足够的手段进行功能的调整和扩充。
而要实现这一点，应通过系统的开放性来完成，既系统应是一个开放系统，只要符合一定的规范，可以简单的加入和减少系统的模块，配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
（3）系统的易用性和易维护性机票预定系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。
这就
要求系统能够提供良好的用户接口，易用的人机交互界面。
要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；
针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。
机票预定系统中涉及到的数据是航空公司的相当重要的信息，系统要提供方便的手段供系统维护人员进行数据的备份，日常的安全管理，系统意外崩溃时数据的恢复等工作。
（4）系统的标准性系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。
所有这些都要符合主流
国际、国家和行业标准。
例如在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。
如规范的数据库操纵界面、作为业界标准的TCP/IP网络协议及ISO9002标准所要求的质量规范等；
同时，在自主开发本系统时，要进行良好的设计工作，制订行之有效的软件工程规范，保证代码的易读性、可操作性和可移植性。
（5）系统的先进性目前计算系统的技术发展相当快，作为机票预定系统工程，应该保证系统在下个世纪仍
旧是先进的，在系统的生命周期尽量做到系统的先进，充分完成企业信息处理的要求而不至于落后。
这一方面通过系统的开放性和可扩充性，不断改善系统的功能完成。
另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当前主流先进且有良好发展前途的产品。
（6）系统的响应速度机票预定系统在日常处理中的响应速度为秒级，达到实时要求，以及时反馈信息。
在进行统计分析时，根据所需数据量的不同而从秒级到分钟级，原则是保证操作人员不会因为速度问题而影响工作效率。
服务器端的功能要求是，通过计算机网络将客户端与服务器的数据库相连，将从客户端得到的信息进行处理，实现航班查询，机票生成，销售统计，综合信息查询等子系统。
以计算机成本核算为中心，实现销售业务的计算机自动化，为航空公司降低成本、提高销售额、经营决策提供及时精确的依据。
在客户端系统的功能实现上，可以分为以下几个部分：
（1）接收由旅行社客户端发回的所需机票信息：
通过网络接收机票信息并存入到服务器的数据库中。
（2）生成航班信息：
根据所需机票信息（时间，地点），在数据库中查询并得到正确的航班的信息（价格，时间，等级），分配所需的机票数并在数据库中做出已售出的标记。
（3）传递航班信息到客户端（旅行社）：
把得到的航班信息通过网络传递到旅行社。
（4）接收旅行社的反馈信息：
对旅行社的反馈信息进行分析，把已经售出的机票进行统计，对被旅客所退掉的机票要进行数据库的恢复。
（5）印出机票给已经订票的旅客：
根据旅客的取票通知及帐单，经过确认无误后，接受旅客的付款后把机票印出来交给旅
客。
（6）销售额的分析和管理这一步骤的功能要求包括对销售的机票进行分析，这一工作是在前面的基础上，以计算机为工具，对机票预定系统的功能和目标进行扩充。
它以财务管理学为理论基础，以辅助决策为目标，以机票销售数据为中心，广泛采用统计学、运筹学的分析方法，对销售信息进行深层加工，建立反映不同航班需求的模型，提供管理上所需的各种辅助决策信息和财务信息。
这一要求是机票预定系统的最高目标，将通过系统运行后获得的大量销售历史数据基础上，实现这一目标。
机票预定系统的数据需求包括如下几点：
（1）数据录入和处理的准确性和实时性
数据的输入是否准确是数据处理的前提，错误的输入会导致系统输出的不正确和不可用，从而使系统的工作失去意义。
数据的输入来源是手工输入。
手工输入要通过系统界面上的安排系统具有容错性，并且对操作人员要进行系统的培训。
在系统中，数据的输入往往是大量的，因此系统要有一定的处理能力，以保证迅速的处理数据。
（2）数据的一致性与完整性由于系统的数据是共享的，在不同的旅行社中，机票是共享数据，所以如何保证这些数据的一致性，是系统必须解决的问题。
要解决这一问题，要有一定的人员维护数据的一致性，在数据录入处控制数据的去向，并且要求对数据库的数据完整性进行严格的约束。
对于输入的数据，要为其定义完整性规则，如果不能符合完整性约束，系统应该拒绝该数据。
（3）数据的共享与独立性
整个机票预定系统的数据是共享的。
然而，从系统开发的角度上看，共享会给设计和调试带来困难。
因此，应该提供灵活的配置，使各个分系统能够独立运行，而通过人工干预的手段进行系统数据的交换。
这样，也能提供系统的强壮性。
软件BUG的存在迫使人们进行软件测试。
软件测试实质上是为了发现程序中的错误而执行程序的过程。
软件的内部测试狭义的概念是由软件开发部门自我组织的，在部门内部进行的软件测试；
而广义上的软件的内部测试是指在向用户发布正式版本之前进行的软件测试。
这个过程通常由单元测试，集成测试（系统测试）、验收测试、平行运行测试构成，通常需要设计完整的测试方案。
2.1白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
采用什么方法对软件进行测试呢？
常用的软件测试方法有两大类：
静态测试方法和动态测试方法。
其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；
而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖、程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。
在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
第二，穷举路径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试三步法：
一、根据代码的功能，人工设计测试用例进行基本功能测试；
二、统计白盒覆盖率，为未覆盖的白盒单位设计测试用例，实现完整的白盒覆盖，比较理想的覆盖率是实现100%语句、条件、分支、路径覆盖；
三、自动生成大量的测试用例，捕捉"
程序员
未处理某些特殊输入"
形成的错误。
2.2黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。
1、功能不正确或遗漏；
2、界面错误；
3、数据库访问错误；
4、性能错误；
5、初始化和终止错误等。
从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。
实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。
这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。
黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
第三章软件测试计划
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。
对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。
详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。
它非常有用但是测试项目组之外的人却很少去读它。
测试时间进度
测试阶段
开始时间
完成时间
测试人员
阶段完成标志
制定测试计划
2009-02-05
2009-02-10
刘晓文
总体计划完成
设计测试用例
2009-02-11
2009-02-15
用例的完成
测试开发
2009-02-16
2009-02-20
检测完成
测试环境准备
2009-02-21
2009-02-25
准备完成
测试实施
2009-02-26
2009-02-28
宋厉
完成测试
功能测试
2009-03-01
2009-03-03
完成功能测试
集成测试
2009-03-04
2009-03-06
李元昊
完成集成测试
性能测试
2009-03-07
2009-03-09
完成性能测试
系统测试
2009-03-10
2009-03-13
完成系统测试
验收测试
2009-03-14
2009-03-15
完成验收测试
文档编写
2009-03-16
2009-03-20
陈新群
完成文档
表3-1
以下几节对机票预定系统这个项目做了分析。
3.1机票预定系统的运行要求
机票预定系统中的各个子系统的硬件和软件的配置如下:
1、服务器端子系统的运行要求：
系统软件：
WindowNTServer
数据库管理系统：
SQLServer
硬件要求：
PentiumIII450以上，258MRAM,14GHD
2、客户端子系统的运行要求:
WindowNTWorkstation
Pentium133以上,32MRAM,4.3GHD
3.2建立机票预定系统的约束
1、Client/Server结构总体设计方案对它的约束机票预定系统作为Client/Server结构的一个应用系统，不可避免的要受到
Client/Server结构的约束。
在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。
同时，由于信息的共享，机票预定系统还受到其它系统的信息约束。
2、人力、资金、时间的约束
机票预定工程实施的目标就是要带给航空公司看得出见的效益，其开发过程中也要考虑到人力、资金和时间的约束。
因此，在设计中，重点是销售系统中的方便快捷，能提供给旅客以优质高效的服务，并提高销售的效率和便捷，为航空公司带来良好的效益。
计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。
例如图像和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。
4.1测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的。
但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。
每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。
因为有些因素是客观存在的，无法避
免。
有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来;
一个具体的人工作也受情绪等影响，等等。
如何保障软件测试质量的稳定?
有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。
可以把人为因素的影响减少到最小。
即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
因此测试用例的设计和编制是软件测试活动中最重要的。
测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
4.2什么叫测试用例
测试用例（TestCase）目前没有经典的定义。
比较通常的说法是：
指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。
测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。
对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
4.3编写测试用例
1、测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。
测试用例文档将受制于测试用例管理软件的约束。
升级会员 