手机销售信息系统测试与收尾报告

1信息系统分析与设计第5次实验手机销售系统测试与收尾报告项目组员：2012430320124307实验时间：2015年5月20日实验地点：主楼B112室2目录第1章测试指导思想及方案.................................31.1指导思想.............................................31.2测试方案.............................................31.2.1测试的过程及组织.................................41.2.2明确开发过程中各类文档...........................41.2.3合理划分测试阶段.................................41.2.4代码审查.........................................41.2.5单元测试.........................................41.2.6集成测试.........................................51.2.7验收测试.........................................51.3测试方案的应用.......................................5第2章部分功能测试结果...................................62.1用户界面窗体设计测试.................................62.2文本框的测试.........................................6第3章谈数据安全与压缩...................................73.1数据库的安全问题.....................................73.1.1Access数据库的存储隐患..........................73.1.2Access数据库的解密隐患..........................73.1.3源代码的安全隐患.................................83.1.4程序设计中的安全隐患...........................83.2数据库的压缩技术.....................................9第4章总结...............................................94.1总结.................................................94.2问题与展望...........................................94.2.1界面不够美观.....................................94.2.2购物车功能尚不完善..............................10附件：程序部分源代码.........................................103在线手机销售系统开发完毕到投入使用之前，需要进行一系列系统集成和确认测试。软件测试的根本目的应该是找出软件中存在的漏洞和问题，而开发人员往往不容易找出自己的程序中存在的漏洞和问题，所以从理论上讲，系统的测试工作应该由专业测试人员进行。第1章测试指导思想及方案1.1指导思想针对本系统测试人员是开发者本人这一特点，本系统测试工作的指导思想以白盒测试方法为主，局部辅以黑盒测试方法。白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。相对的，黑盒测试方法是在已知系统结构的前提下，通过来测试系统每个功能是否都能正常运行并达到预期结果。在测试时将程序看作一个不能打开的黑盒子，在完全部考虑程序内部结构盒内部特性的情况下，在接口进行测试。1.2测试方案从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。41.2.1测试的过程及组织当设计工作完成以后，就应该着手测试的准备工作了，编写在线手机销售系统测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。1.2.2明确开发过程中各类文档进一步理解在线手机销售系统在开发过程中生成的有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。1.2.3合理划分测试阶段为了保证测试的质量，将测试过程进行划分，针对在线手机销售系统的特点，将测试过程划分为代码审查、单元测试、集成测试和验收测试四个阶段。1.2.4代码审查一般的软件测试应该进行代码会审。代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。针对本系统的开发特点，开发者本人再一次对所编写代码进行审查，并将其讲解给周围同学。实践证明，当再一次进行阅读和讲解时，确实可以发现许多自己原来没有发现的错误。1.2.5单元测试单元测试集中在检查本系统设计的最小单位——模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，加之测试人员就是系统的开发人员，对于该模块的I/O条件和模块的逻辑结构都非常清楚，可以采用采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使5之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。1.2.6集成测试集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如用户资料数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。1.2.7验收测试验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，软件可投入使用。1.3测试方案的应用因为本系统的测试人员是开发者本人，所以对于程序的代码等相当熟悉。在设计在线手机销售系统的单元测试时，测试人员将白盒测试方法和黑盒测试方法结合起来运用。先用白盒测试法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒测试法进行补充。集成测试及其后的测试阶段，本系统采用了黑盒测试方法。其策略包括：(1)用边值分析法和（或）等价分类法提出基本的测试用例；(2)用猜测法补充新的测试用例，重复前一步操作。6第2章部分功能测试结果在黑盒测试方法的指导思想下，通过大量用例对在线手机销售系统进行了测试。测试过程中发现了一部分设计上的漏洞及时进行了修改。由于篇幅有限，现特将本系统部分功能测试用例摘录如下：2.1用户界面窗体设计测试窗体大小。大小要合适，控件布局合理；缩放窗体。窗体上的控件应随窗体的大小变化而变化；显示分辨率。必须在不同的分辨率的情况下测试程序的显示是否正常。经过测试，发现系统用户界面窗体的大小在大部分台式机和笔记本电脑显示器上效果不一。后经分析发现，开发使用的笔记本电脑系宽屏设计，因此造成了一般尺寸的台式机显示器显示不正常的现象。及时修改页面大小可以修正此问题。其他功能未发现异常.2.2文本框的测试输入正常的字母或数字；输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多25个字符，尝试输入26个字符，检查程序能否正确处理；输入默认值，空白，空格；若只允许输入字母，尝试输入数字；反之；尝试输入字母；利用复制，粘贴等操作强制输入程序不允许的输入数据；输入特殊字符集，例如，NUL及\n等；输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示；经过测试，系统在文本框输入功能中表现正常，在出现异常输入时能够及时报错并提醒用户重新输入。7第3章谈数据安全与压缩Access数据库作为微软推出的以标准JET为引擎的桌面型数据库系统，由于具有操作简单、界面友好等特点，具有较大的用户群体。因此ASP＋Access成为许多中小型网上应用系统的首选方案。但ASP＋Access解决方案在为我们带来便捷的同时，也带来了不容忽视的安全问题。3.1数据库的安全问题ASP＋Access解决方案的主要安全隐患来自Access数据库的安全性，其次在于ASP网页设计过程中的安全漏洞。3.1.1Access数据库的存储隐患在ASP＋Access应用系统中，如果获得或者猜到Access数据库的存储路径和数据库名，则该数据库就可以被下载到本地。例如：对于手机销售商店的Access数据库，人们一般命名为Shop.mdb、store.mdb等，而存储的路径一般为“URL/database”或干脆放在根目录（“URL/”）下。这样，只要在浏览器地址栏中敲入地址：“URL/database/store.mdb”，就可以轻易地把store.mdb下载到本地的机器中。3.1.2Access数据库的解密隐患由于Access数据库的加密机制非常简单，所以即使数据库设置了密码，解密也很容易。该数据库系统通过将用户输入的密码与某一固定密钥进行异或来形成一个加密串，并将其存储在＊.mdb文件中从地址“＆H42”开始的区域内。由于异或操作的特点是“经过两次异或就恢复原值”，因此，用这一密钥与＊.mdb文件中的加密串进行第二次异或操作，就可以轻松地得到Access数据库的密码。基于这种原理，可以很容易地编制出解密程序。由此可见，无论是否设置了数据库密码，只要数据库被下载，其信息就没有任何安全性可言了。83.1.3源代码的安全隐患由于ASP程序采用的是非编译性语言，这大大降低了程序源代码的安全性。任何人只要进入站点，就可以获得源代码，从而造成ASP应用程序源代码的泄露。3.1.4程序设计中的安全隐患ASP代码利用表单（form）实现与用户交互的功能，而相应的内容会反映在浏览器的地址栏中，如果不采用适当的安全措施，只要记下这些内容，就可以绕过验证直接进入某一页面。例如在浏览器中敲入“……page.asp?x=1”，即可不经过表单页面直接进入满足“x=1”条件的页面。因此，