小区物业管理系统 软件工程毕业论文.docx

小区物业管理系统 软件工程毕业论文.docx

《小区物业管理系统 软件工程毕业论文.docx》由会员分享，可在线阅读，更多相关《小区物业管理系统 软件工程毕业论文.docx（35页珍藏版）》请在冰豆网上搜索。

小区物业管理系统软件工程毕业论文

三江学院

本科毕业设计（论文）

题目小区物业管理系统--

计算机科学与工程院（系）软件工程专业

学生姓名魏宗斌学号12009054022

指导教师彭雅琴职称讲师

指导教师工作单位三江学院

起讫日期2013.2.20～2012.5.17

摘要

软件测试随着软件产品的发展应运而生，现今的软件测试已不再只是为发现软件的缺陷和错误而存在，它已成为对软件的质量进行度量和评估的标准。

功能测试是软件测试中最基本的测试，所以对功能测试的研究非常重要。

本文首先介绍了TestLink和BugFree测试工具，描述了DG产品的基本功能，并且从单功能测试和业务场景测试两个方面入手，编写适合功能特点的测试用例，最后验证了产品功能是否符合用户需求，体现了测试的意义。

关键词：

功能测试；加密；黑盒测试；测试用例

ABSTRACT

Softwaretestingemergedwiththedevelopmentofsoftwareproducts.Nowadays,softwaretestingisnolongerjustforthediscoveryofsoftwarebugsanderrors，ithasbecomeastandardofmeasurementandevaluationofthequality.Functionaltestingisthemostbasictestinsoftwaretesting.Therefore,thestudyoffunctionaltestingisveryimportant.

ThepaperfirstintroducesTestLinkandBugFreetool,andthenitdescribesthefunctionsofDG.Thestudystartswiththetwoaspectsofthesingle-functiontestingandbusinessscenariotesting.Accordingtothecharacterofthefunction,thepaperchoosesappropriatemethodtowritetestcases,finallyitverifiestheproductfunctionsmeettotheuser’sneedsandreflectsthesignificanceofthetest.

Keywords:

Functionaltest;Encryption;Black-boxtesting;Testcase

第一章引言

1.1课题研究背景

毫无疑问，从20世纪60年代到现在，计算机主宰了世界的眼球，而它的灵魂体现----软件，也承载了一代又一代渴望改变世界的人们的热忱，它变的完备，性感，包罗万象。

软件是从早期以个人活动为主的手工作坊开发方式，逐步转变成了以程序员小组为代表的集体开发方式，而这伟大的蜕变过程，并不是一蹴而就的，它伴随着苦痛，这段历程一直走到了现在。

那些凝聚了前辈们智慧的软件系统，有些最终失败，烟消云散；有些虽经过不懈的努力诞生于世界，但它的晚来与预算的超出也让人心存遗憾，；还有些却迟迟不能达到人们对它期望的高度；甚至有的干脆无法被修改和维护，而这些，还将继续上演。

软件测试是这些苦难中开出的百合，它应运而生。

早期的百合显得黯淡，不美丽，只是为了纠正软件中已经知道的故障，常常由开发人员自己完成这部分工作，并且没有得到悉心的照料，而现在，它已成为一种艺术。

它重新诠释自己是在20世纪80年代，检验软件系统是否满足需求成了它新生的意义，它不再孤独，一次性的存在，它与改变世界的开发流程深深融为一体。

1.2课题发展现状与未来

就像所有伟大的学科一样，发展到一定程度时，其细微的地方也会相继蜕变为专业，而如今的软件测试也走到了这一步。

它成为了由专门人才和专家承担，运用专门的方法和手段，对软件进行严密测试发现其存在问题并加以纠正的方法。

它主要分为白盒测试和黑盒测试，测试初始，就需要建立详细的测试计划，而后续的操作也必须严格按照测试计划执行，这些将有利于减少测试的随意性。

它并不是一个轻松的工作，它严密，复杂，工作量往往就占了软件开发总量的40%以上，而它的成本有时甚至高于软件工程其他步骤成本总和的三至五倍。

但这些都是值得的，因为它通过软件开发过程中的质量控制，保证了其最终质量，好处显而易见，它回避了软件发布后由于其潜在的缺陷和错误所带来的商业风险，并且它是以最少的时间，人力和物力来完成这点的。

它现阶段只能由人来完成，所以显得不是那么完美，人们通过它发现尽可能多的产品缺陷并加以纠正，这提高了软件的质量。

随着时代的发展和科技的进步，软件测试被注入了新的活力，它再也不是狭义的为发现软件的缺陷和错误而存在了，它如今对软件的度量和评估，显得尤为重要，这早已成为了客户选择和接受软件的有力参考，保证了其对产品的满意度。

1.3本文的主要内容

本文主要研究软件测试中的功能测试，第一章简述软件测试的发展状况及其重要性；第二章介绍测试工具BugFree，TestLink的使用，并对一些测试方法进行概述；第三章简要介绍本次研究的软件产品DG，对DG产品进行测试需求分析，并从中挑选部分功能展开具体研究，验证产品功能是否符合客户需求，测试的实际结果与预期结果是否吻合，并将出现的bug填写到BugFree中。

第四章总结本次课题研究的收获以及对未来的展望。

第二章技术平台

本章分别对TestLink，BugFree两个工具进行介绍，并对软件测试方法进行概述，为后期的测试工作奠定基础，做好准备。

2.1TestLink工具介绍

TestLink是一种基于web的测试用例管理系统，主要用于测试用例的创建、管理和执行，另外还提供了一些简单的统计功能。

2.1.1简介

TestLink用于对测试过程进行管理，使用TestLink可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来，同时，它还提供了好多种测试结果的统计和分析，使我们能够简单的开始测试工作和分析测试结果。

TestLink主要功能包括：

测试需求管理，测试计划的制定，测试用例管理，测试用例的执行，测试用例对测试需求的覆盖率，基于角色的用户管理，以及大量测试数据的度量和统计功能。

2.1.2实现功能

1）根据不同的项目，制定不同的测试计划、测试用例，并进行管理；

2）可以使用关键字搜索测试用例；

3）同一项目可以制定不同的测试计划，将编写的测试用例分配给各测试计划，实现测试用例的可复用性；

4）可以将现有测试用例简要修改后进行复用；

5）可以设定和记录测试执行的状态，执行测试用例时，可以做相应的说明；

6）按照用户需求、测试计划、测试用例状态、版本等统计测试结果，进行测试结果分析；

7）为不同用户定义不同的角色，通过角色控制用户权限；

8）将测试用例和测试需求相对应，划分测试用例的优先级，然后根据优先级指派给测试员进行测试。

2.1.3测试用例管理

TestLink对测试用例的管理包含三层，分别为：

Component、Category、Testcase。

Component对应于项目的功能模块，Category与每个模块的功能对应，而Testcase就是写在这些Category里的测试用例。

测试人员可以使用关键字搜索功能从不同项目、不同版本的测试用例中查到所需要的测试用例，甚至可以直接将其他项目里编写的测试用例复制进来，解决了测试用例的管理和复用性问题。

在测试管理中，测试用例对测试需求的覆盖率也很重要，根据需求规格说明书提取出测试需求之后，可以使用Testlink管理测试需求与测试用例的对应关系。

2.1.4创建测试用例

选择创建好的Category，点击“创建测试用例”按钮，可以新建测试用例。

测试用例的要素包括：

测试用例名称、简要说明、测试步骤、预期结果、关键字。

2.2BugFree工具介绍

2.2.1简介

BugFree是基于浏览器方式运行的一个bug管理工具，可以记录每个bug的处理过程，不断提醒开发者还存在哪些缺陷，对于软件的可持续发展至关重要。

所有人都可以使用BugFree创建Bug，指派Bug或者改变Bug状态。

过程大致如下：

1）如果测试人员在测试过程中发现Bug，可以新建一个Bug并且将它指派给相关的开发小组长；

2）开发小组长判断这个Bug出现的模块是由某个特定人员开发的，然后将Bug指派给他处理；

3）开发人员根据Bug的描述信息找到问题所在，然后修改程序解决Bug，再将Bug返回给当初的测试人员；

4）提出Bug的测试人员在看到某个Bug被解决后，需要去验证这个Bug是否真的已经不存在了，根据当初的操作步骤运行产品，证实问题真的解决了，就关闭这个Bug；若Bug还能重现或者测试人员不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理；

5）当测试人员和开发人员意见不统一时，由对应的设计者出面做协调，判断这个Bug的严重程度，对用户可能造成怎样的影响，再根据产品的进度和项目资源做出评估。

团队中的每个人发现问题时都可以创建Bug进行跟踪，除了软件功能上的Bug,其他各种问题，例如需求文档的改动，界面上的错别字、帮助文档的遣词造句问题等等，都可以提交Bug。

2.2.2使用

BugFree没有客户端，因此不需要运行或者安装，可以直接通过IE访问。

BugFree的使用分为三个步骤：

1）建立项目模块以及其子模块；（这一步只在项目的最开始由管理员建立）

2）用自己的用户名登录管理模块；

3）处理分配给自己的Bug和任务，发现新的bug之后可以通过BugFree发送给相应的人处理。

一个Bug只有3种状态：

Active、Resolved、Closed。

可以通过“编辑”来改变所有的状态：

1）一个Active的Bug，从一个人指派到另外一个人，使用“编辑（Edit）”；

2）Active转为Resolved只能用“解决（Resolve）”；

3）Resolved转为Closed只能用“关闭（Closed）”；

4）Resolved转为Active和Closed转为Active只能使用“激活（Activate）”。

查询Bug时可以根据自己的需求选择不同的查询条件，比如查找某个项目中的Bug，输入项目名称，点击查询后，下面就会倒序显示该项目中出现的Bug。

查询出符合条件的Bug后点击该Bug标题，将显示该Bug的详细信息。

2.3软件测试方法概述

软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法。

对测试进行分类是为了更好的明确测试执行过程，了解测试究竟要完成哪些工作。

2.3.1按测试方法划分

1）白盒测试

白盒测试也称为结构测试或逻辑驱动测试，白盒测试的对象基本上是源程序，是以程序的内部逻辑为基础的一种测试技术。

白盒测试针对性很强，可以对程序的每一行语句、每一个条件或分支进行测试，效率比较高，且可以清楚测试的覆盖程序。

2）黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是基于需求和功能性的测试，是在已知产品所具有的功能的情况下，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据并且产生正确的输出信息，并且保持信息的完整性。

2.3.2黑盒测试方法列举

黑盒测试方法主要有等价类划分法、边界值法、因果图法、错误推测法等，主要用于软件确认测试。

1）等价类划分法

等价类划分法是一种典型的、常用的黑盒测试方法。

把所有可能的输入数据，即将程序的输入域划分成若干子集，然后从每一个子集中选取少数具有代表性的数据作为测试用例。

等价类划分法包括有效等价类和无效等价类两种情况。

有效等价类是指对于程序规格说明来说，由合理的、有意义的输入数据构成的集合。

无效等价类是指由不合理的、无意义的输入数据构成的集合。

2）边界值法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

边界值分析法是通过选择等价类边界的测试用例进行测试，边界值是对等价类划分法的补充。

测试中，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。

因此针对各种边界情况设计测试用例，可以查出更多的错误。

3）错误推测法

错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

错误推测方法的基本思想:

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

4）因果图法

等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。

如果考虑输入条件之间的相互组合，可能会产生一些新的情况.。

但是要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。

因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。

这就需要利用因果图（逻辑模型）。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。

5）判定表

判定表是分析和表达多逻辑条件下执行不同操作的情况下的工具。

由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

判定表通常由四部分组成

　　条件桩：

列出了问题的所有条件，列出的条件的次序无关紧要。

动作桩：

列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。

条件项：

列出针对它所列条件的取值，在所有可能情况下的真假值。

　　动作项：

列出在条件项的各种取值情况下应该采取的动作。

规则：

在判定表中贯穿条件项和动作项的一列就是一条规则。

因此，判定表中列出多少种条件取值，也就有多少条规则。

6）正交试验设计法

正交试验设计是研究多因素多水平的又一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是分析因式设计的主要方法。

是一种高效率、快速、经济的实验设计方法。

以上是对一些常见黑盒测试方法的简单介绍，通过本章的描述，可以对TestLink，BugFree两种工具的功能和使用过程有大致了解。

在测试过程中，工具与合适的测试用例设计方法相结合，才能有效提高软件测试的效率和质量。

第三章功能测试设计和实现

本章首先对产品进行测试需求分析和方案设计，再从中选例进行研究，并且描述了功能测试的实现过程，最后对每个功能的测试结果进行分析和总结。

3.1DG产品简介

DG，DocumentGuard（敏捷安全卫士系统）是第一款国内电子文档透明加密软件，它致力于解决企业的图文档数据方面的安全问题,采用了先进的操作系统内核技术、高强度的透明加密算法。

具备灵活易用的安全策略，能实时进行图文档文件的加密工作，有效的遏制了企业内部用户有意或无意的信息泄漏。

电子文件有易复制、易传输的特点，它在给企业带来便利的同时，其安全管控也让业界头痛不已。

因为电子文件一旦被借阅，借阅者对文件就具有了掌控权，就无法像纸质文档一样进行回收操作，这客观上造成了文件的无序传播。

无数事实证明：

若系统内部存在着没有加密的电子文件，传统安全系统（防火墙等）就无法扼杀机密文件被泄密的可能。

DG安全策略有效的解决了这种安全隐患，它迥异于传统的安全策略（阻止文件被带出）；而是做到了通过任何方式被带出的文件都是加密的，保证了文件被非法窃取后无法使用。

具体地说：

一份电子文档会经历创建——编辑——浏览——保存——传输——删除这整个生命周期，而DG保证了它在周期中的任何时刻都处于加密状态，若脱离了装有DG的主机，是不能接触到解密的文件的，这样就从根本上扼杀了文件被泄密的可能。

也就是说，若有人想窃取文件，那么他通过电子邮件、网络入侵、移动存储设备、蓝牙设备、红外设备、木马程序等手段来传输的文件，都只会是被加密的，而这些文件一旦脱离了企业的计算机根本无法使用。

DG采用的安全策略。

使文件从创建初期到最后删除，其整个生命周期都具备了安全保护性。

这有异于传统的安全系统，如防火墙等（采用“堵”文件策略），但DG与防火墙、VPN等安全产品却完全不冲突，它是从“内部控制”的层面上补充了现有的安全系统。

系统内部只要存在着不加密的电子文档，理论上以往的各种安全系统（防火墙等）就无法扼杀机密文件被泄密的可能。

由于DG可以做到从系统内部加密文件，因此它从信源上保证了文件的安全，在整个安全体系中，DG扮演的角色无可取代，若把它结合传统的安全系统使用，用户将获得无与伦比的信息安全体验。

敏捷安全卫士系统分三层架构，由服务器、管理机和客户机组成。

三层架构之间互相关联，其中服务器用于注册和管理其下的管理机，管理机用于注册和管理其下的客户机以及对外发图文档进行加解密；客户机则用于实现文件的全生命周期的保护，安装客户机后，用户的日常操作习惯不需要做任何改变，图文档文件却能在操作过程中（从创建到打开、编辑、浏览、保存、传输直至删除）始终处于加密状态，从而确保了文件的安全性。

敏捷安全卫士系统架构如下图所示：

图3-1DG三层架构

3.2测试需求分析和方案

测试需求是设计测试用例的依据，测试需求分析的越细致越精准，说明对所要测的软件了解越深，对所要进行的任务内容越清晰，对提高测试用例的设计质量有很大帮助。

测试需求的细致程度还是衡量软件测试覆盖率的重要指标，测试需求是计算测试覆盖率的分母，因此，详细的测试需求能有效的进行测试覆盖的计算。

进行产品功能测试之前，对产品进行需求的理解和分析是必不可少的，对需求理解的正确与否直接影响最后测试结果的好坏。

因此如何正确的理解需求在测试人员工作中显得尤其重要。

在此次的案例研究中，功能测试主要是对功能和流程两方面进行理解。

业务流程理解：

从测试人员的角度出发，理解需求时首先应该清楚的是系统的流程，流程是贯穿整个系统的主线，只有主线通畅了才能保证后续步骤的正常进行，一旦流程不通畅，就会影响对后期工作的分析和理解。

单功能理解：

理解软件产品中的具体功能，主要是系统包含哪些主要的功能点，每个功能的期望值是什么，需要达到的用户需求是什么。

敏捷安全卫士系统由服务器、管理机和客户机组成，每层架构都具备很多功能。

服务器的功能包括：

服务器运行、查看服务器信息、注册管理机、删除管理机、查看管理机信息、服务器设置、装入升级包、IP地址设置、更新序列号（可以在试用号和正式号之间变换）、自定义密钥、备份密钥、恢复密钥、制作分厂服务器的加密狗（安装分厂服务器时需要使用加密狗启动）、管理机集群、安全卫士日志管理器（记录所有日志信息）、IE网址排除工具、安全卫士打印机控制工具。

管理机的功能包括：

登录管理机、管理机设置、组织机构、分级管理、策略模板、域同步（同步计算机、同步用户）、域用户（配置用户权限、添加到组织机构、继承上级策略）、计算机（注册客户机、配置客户机、连接客户机、注销客户机、延长脱机时间、选择部门、从部门移除）、加解密（对文件进行加密解密操作）、设置卸载码（可以防止客户机被任意卸载）。

客户机的功能包括：

客户机用于实现文件全生命周期保护安全策略，对图文档文件进行实时加解密。

DG客户端安装完成后，会在计算机屏幕右下角任务栏中显示锁标志。

右击锁标志可以进行策略更新、版本升级、文件外发、外发设置、模式切换等操作。

客户机分为三种桌面模式：

个人桌面模式、VIP桌面模式、加密桌面模式。

个人桌面模式下，无法生成任何加密文件，能够打开其他两种模式下的加密文件，但显示的内容是密文。

VIP桌面模式即手动加密桌面模式，一般可单独存在，也可和个人桌面模式进行切换使用。

加密桌面模式即强制加密模式一般可单独存在，也可和个人桌面模式进行切换使用。

DG产品的基本工作流程大致如下：

图3-2DG基本工作流程

因此图3-2中包含的功能是DG最基本且必须要实现的功能，只有满足这些功能，DG产品才能达到用户最基本的需求，对图文档进行加密操作。

除了最基本的功能外，DG产品还具备很多重要的功能，以满足客户各式各样的需求。

其中，自定义密钥功能满足用户自己定义企业密钥的需求，加强了企业文件的安全性；分级管理功能用于创建角色，不同角色可以配置不同的权限，将企业各部门中新增的管理员加入各个角色成员里，使不同部门管理员拥有不同的管理权限，这个功能方便了企业对不同机构进行管理；注册客户机的前提是管理机具备允许连接的权限，这样客户机在安装时才能连接上管理机；配置word受控，需要管理机具有允许连接、允许管理的权限，对客户机进行配置后，客户机编辑word、保存，文件就能加密；若管理机注销客户机，客户机将不再受控，不能再对受控软件进行加密，原先加密的软件也不能以明文显示。

因此下文着重对以上几个功能进行测试分析，得出测试结果。

进行功能测试时，先根据需求规格说明书列出所有功能，然后根据各个功能的特点选择合适的测试用例编写方法，在编写测试用例之前，先要根据功能构思测试用例的设计思路，然后选用测试用例编写方法，如：

等价类划分法、边界值法等等，编写适当数目的测试用例，再根据编写的测试用例执行测试步骤运行软件产品，最后比较执行出来的实际结果与预期结果是否相同，判断产品功能是否正常，是否满足用户需求，与用户手册一致。

若出现功能缺陷，需要填写并提交测试出来的缺陷，供开发者进行修正。

3.3单功能测试

单功能测试是指将软件产品中包含的所有功能单独列出来，分别进行测试。

这种测试不考虑该功能与产品中其他功能之间是否有因果联系，只针对该功能的输入参数，处理过程以及输出参数进行测试。

再在预期结果与实际测试结果之间进行评测，判断该功能是否达到用户使用的要求。

3.3.1自定义密钥

自定义密钥顾名思义，是由每个企业自己定义。

DG产品本身含有一套加密机制，可以实现对图文档的加密，增加安全性，防止重要文件的泄露。

而自定义密钥是除敏捷科技提供基本密钥外，企业自身加入的自定义密钥，两个密钥合二为一，可以成为企业独有密钥，才能区别于其他企业。

所以，对自定义密钥功能进行测试以确保该功能的正常使用，能够大大提高企业文件的安全性。

自定义密钥测试分析

对自定义密钥功能进行测试时，我们要从以下几个方面入手：

◆输入参数测试

该功能的输入参数主要包括：

输入密钥、确定密钥以及“添加”、“取消”、“确定”等按钮操作。

◆处理过程测试

处理功能包括正常处理过程和异常处理过程。

◆输出参数测试

该功能的输出参数包括自定义密钥生成的加密文件，输出位置和输出形式等。

根据上述测试分析，可列举出以下测试思路：

1.点击自定义密钥框中的“取消”按钮，回到服务器主界面。

2.自定义密钥为空，点击自定义密钥框中的“添加”按钮，添加自定义密钥失败，重新输入密钥。

3.自定义密钥长度小于6位，点击自定义密钥框中的“添加”按钮，添加自定义密钥失败，重新输入密钥。

4.自定义密钥长度大于16位时，无法继续输入密钥。

5.自定义密钥长度在6-16位之间，两次输入密钥不匹配，点击自定义密钥框中的“添加”按钮，添加自定义密钥失败。

6.自定义密钥长度在6-16位之间，且两次输入密钥匹配，点击自定义密钥框中的“添加”按钮，添加自定义密