空间管理您的位置: 51Testing软件测试网 » 码农Damon的个人空间 » 日志

超详细的商城购物类系统的测试计划，来自码农Damon整理首发！

上一篇 / 下一篇 2018-05-10 16:47:27 / 个人分类：随笔

查看( 2702 ) / 评论( 0 ) / 评分( 0 / 0 )

1．目的

网上电子商城购物系统的这一“测试计划”文档的目的是：

（1）提供一个对网站开发项目测试的总体安排和进度计划，确定现有网站的信息和应测试的网站相关性能及体验

（2）标明推荐的测试需求（高层次）。

（3）推荐可采用的测试策略，并对这些策略加以说明。

（4）确定所需的资源，并对测试的工作量进行估计。

（5）列出测试项目的可交付元素

2．背景

a.系统名称：

超划算360网上电子商城购物系统

b.系统简介：

该系统旨在实现一个网上电子商城，旨在互联网上销售服饰、珠宝、饰品、化妆用品、母婴用品、数码家电、体育用品、日用品、箱包、鞋类等。该系统将面向所有消费者用户。

c.软件应用：

适用于网上产品的信息收集和发布活动，为用户提供良好的交易平台。

3．范围

网上电子商城购物系统包括的测试类型有：数据库测试、功能性测试、业务周期测试、用户界面测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移/恢复测试、配置测试、安装测试等

测试概要
类别	子类别	功能点
流程测试	购买	首页-浏览页面-商品祥情-咨询-购买-购物车-支付提醒-注册/登陆-付款-查询
	搜索	首页-导航/商品类别-产品页面
	申请供货商	账户信息-申请供货商-填写详细信息-审批-反馈-批准-显示-上传产品
	经营消费商	账户信息-申请经营消费商-审批-反馈-批准-显示
	退货	订货页面-退货-审批-反馈信息-退款提示-客户查询
	积分到账	积分查询-查询显示页面
	团购	购买-付款页面-合计付款金额
功能测试	界面测试	色彩搭配
		整体布局
		控件是否有效
	性能测试	链接测试
		搜索测试
		输入域测试
		分页测试
		交互性数据测试
		页面响应(加载时间，响应时间)
	负载测试	确保系统在超出最大预期工作量的情况下仍能正常运行
	负载测试	多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障
	故障转移和恢复测试	客户机断电
		服务器断电
		通过网络服务器产生的通信中断
		DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断
		周期未完成（数据过滤进程被中断，数据同步进程被中断）。
		数据库指针或关键字无效
		数据库中的数据元素无效或遭到破坏
兼容性测试	服务器+客户端+数据库服务器	Window2000(S) WindowXp Window2000(P) Window2003
兼容性测试	浏览器	Window IE6.0以上 NetScape FireFox Maxthon 其他(世界之窗)
安全性测试	应用程序	对数据或业务功能的访问
安全性测试	系统级别	对系统的登录或远程访问

（二）测试需求

已被确定为测试对象的项目有：

1．数据库测试

2．功能性测试

3．业务周期测试

4．用户界面测试

5．性能测试

6．负载测试

7．强度测试

8．容量测试

9．安全性和访问控制测试

10．故障转移/恢复测试

11．配置测试

（三）测试风险

软件测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：

　　1．质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；

　　2．测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；

　　3．需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；

　　4．质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；

　　5．测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；

　　6．测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；

　　7．有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；

　　8．回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

　　前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

　　针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

　　测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；

　　有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；

　　有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案。

（四）测试策略

测试策略提供了推荐用于测试对象的方法。第二节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对测试对象进行测试。对于每种测试，都应提供测试说明，并解释其实施和执行的原因。如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。例如，“将不实施和执行该测试。该测试不合适。”制定测试策略时所考虑的主要事项有：将要使用的方法以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行。测试类型有如下几种：

（1）数据和数据库完整性测试

数据库和数据库进程应作为“网上电子商城购物系统”中的子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和方法。

表1-8数据库测试说明表

测试目标：	确保数据库访问方法和进程正常运行，数据不会遭到损坏。
方法：	调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据或对数据的请求。检查数据库，确保数据已按预期的方式填充，并且所有数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据]
完成标准：	所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。
需考虑的特殊事项：	测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（其中的记录数很有限）来使所有无法接受的事件具有更大的可见性。

（2）功能测试

测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面(GUI)与应用程序交互并分析输出结果来验证应用程序及其内部进程。以下列出的是每个应用程序推荐的测试方法概要：

表1-9功能测试说明表

测试目标：	确保测试对象的功能正常，其中包括导航、统计、购买和检索等。
方法：	利用有效的和无效的数据和操作来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。
完成标准：	所计划的测试已全部执行。所发现的缺陷已全部解决。
需考虑的特殊事项：	确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）