- 1、本文档共12页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
数字化校园信息项目系统测试方案
测试任务与步骤
系统测试是衡量产品质量的重要过程。建立详细的测试计划是测试工作保质保量完成的前提。而一个详细的测试计划需要依据项目的实际实施中发生的活动和系统需求来编制,我们将在项目实施过程中根据需要而制订详细、切实可行的测试计划。
本项目进行测试的主要任务有:
制订测试计划、测试标准及测试风险评估和避免措施
设计测试过程、用例和数据
测试执行
评价商业情况的准确性
利用测试结果,监控和改进测试过程
分析测试结果,给出测试报告,确定系统的可用性
验收测试过程包含以下步骤:
制定测试策略和过程
设计测试用例和数据
准备测试环境
测试执行
测试总结
制定测试策略和过程:
在测试过程中,客户对递交的系统进行测试和评估,确信系统满足规定的验收标准,确定系统是否能够提高工作效率。客户将对系统的各个方面进行评估。制定一个好的测试范围是成功进行验收测试的关键。
下面提出系统测试的主要范围:
用户界面测试:验证用户界面符合标准。要求的测试数量取决于开发过程中为保证一致性所采用的工具,一般在测试刚开始时进行;
功能测试:保证系统的运行满足功能需求,使用工具BugBase;
接口测试:保证与其它系统或子系统的接口工作正常;
兼容性测试:保证系统在各种可能的用户群众都可以正常使用,如,不同的操作系统、浏览器、数据库等;
负载测试:保证系统在最大设计负载下运行平稳,一个好的测试经验是让系统在超过最大设计负载25%的数据和处理负载下运行;
恢复测试:保证备份和恢复程序工作正常,以及当系统遇到突发事件如断电、网络连接中断时对数据的正确处理。一般来说,恢复程序的基本测试在系统测试开始时进行,然后在系统测试结束之前再进行进一步的恢复测试;
安全测试:验证系统安全满足要求,必须是系统的合法用户才能登录并进行允许的相关操作。由于安全是系统的基本功能,所以安全测试通常安排在系统测试的开始;
转换测试:验证现有的数据能进行正确的转换。通常情况下,在处理测试过程中转换的数据与新数据一起使用来验证数据转换的正确性;
文档测试:验证系统的用户手册、安装手册、帮助信息等说明性文档的内容是否符合功能及易读、易理解;
性能测试:验证系统满足性能标准(例如响应时间)。使用工具loadrunner
验收测试工作通常由不同的用户来进行(例如:业务人员测试系统功能,技术人员测试系统性能等)。有些情况下,一些测试工作可以合并在一个测试中完成。为协调各类测试人员的工作,做好周密的计划是非常重要的。
设计测试用例和数据
测试用例和数据准备的目的是帮助用户在不熟悉实际环境的时候,能正常的测试系统并对系统做出正确的评价。
测试用例和数据的准备是一项枯燥和费时间的工作。为了提高工作效率可以从以下几方面着手:
将信息放在一个指定的位置,便于反复利用,降低变化产生的影响;
一次完成一个步骤,避免冗余和额外的工作;
尽早尽可能完成多个步骤。
为了保证每一个业务流程准备测试用例和数据的正确性,在测试计划中应遵循下列过程,并完成以下步骤:
确定要测试的业务情况类型
确定每个要求的测试用例
合并所有的测试用例,生成测试大纲
编制测试脚本,包括必要的系统输入信息和期望的输出结果
检查信息保证每一步的准确性和完整性(即,确定业务情况类型、确定测试用例、生成测试大纲和编制测试脚本)。
(1)确定业务情况类型
确定实际商业环境中出现的业务情况类型是非常重要的。每一种业务情况类型都对应一个实际商业业务。业务情况类型可以被表达成多种状况(例如,简单情况、或需要进行复杂处理的例外情况)。
(2)确定测试用例
对每一条规定验收要求,确定测试用例。每个测试用例包括测试条件(包括生成测试条件需要的测试数据类型)和期望的结果。每个测试用例都应该是唯一确定的(例如,赋一个数值)。
(3)生成测试大纲
对每一种业务情况类型,生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例,将测试用例的条件映射为测试大纲是非常必要的。
测试大纲中测试用例的顺序安排是非常重要的,它应考虑多种方面的因素,主要考虑的因素:
按照系统产生的数据,在测试大纲中安排测试用例的顺序,使得一个测试的结果作为另一个测试前提。
按以下顺序编制测试大纲:
确定唯一的标识(例如,测试大纲编号)
确定业务情况类型
对每种业务情况类型进行测试之前,列出成功完成测试必需的测试用例数目
对每个测试用例按照测试进行的顺序给出测试用例编号
(4)编制测试脚本
在了解系统构造的情况下,将测试大纲概要作为编制测试脚本的指导。
根据系统输入指导测试人员如何进行测试。例如,编写详细的测试步骤或给出如何进行数据输入的说明(如已经填好数据的屏幕实例)。即使没有相应的测试,也要包括每一个必要的测试步骤以便确定测试条件。确定进行测试的时间(例如,进
文档评论(0)