电子商城网站测试计划

相关推荐

电子商城网站测试计划

　　时光飞逝，时间在慢慢推演，又将迎来新的工作，新的挑战，一起对今后的学习做个计划吧。可是到底什么样的计划才是适合自己的呢？以下是小编帮大家整理的电子商城网站测试计划，欢迎大家分享。

电子商城网站测试计划

电子商城网站测试计划1

　　项目开发单位：

　　湖南万众一网通科技有限公司

　　项目测试单位：

　　湖南万众一网通科技有限公司

　　一网通网上电子商城购物系统

　　测试计划

　　1.简介

　　1.1目的

　　1.2背景

　　1.3范围

　　1.4使用文档

　　2.测试需求

　　3.测试风险

　　4.测试策略

　　4.1测试类型

　　4.1.1数据和数据库完整性测试

　　4.1.2功能测试

　　4.1.3业务周期测试

　　4.1.4用户界面测试

　　4.1.5性能评价

　　4.1.6负载测试

　　4.1.7强度测试

　　4.1.8容量测试

　　4.1.9安全性和访问控制测试

　　4.1.10故障转移和恢复测试

　　4.1.11配置测试

　　4.1.12安装测试

　　5.测试概要

　　（一）简介

　　1．目的

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

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

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

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

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

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

　　2．背景

　　a.系统名称：

　　网上电子商城购物系统

　　b.系统简介：

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

　　c.软件应用：

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

　　3．范围

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

　　（二）测试需求

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

　　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数据库测试说明表

　　（2）功能测试

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

　　表1-9功能测试说明表

　　（3）业务周期测试

　　业务周期测试应模拟在一段时间内对“网上电子商城购物系统”执行的活动。应先确定一段时间（例如一年），然后执行将在该时段内发生的.事务和活动。这种测试包括所有的每日、每周和每月的周期，以及所有与日期相关的事件（如备忘录）。

　　表1-10业务周期测试说明表

　　（4）用户界面测试

　　通过用户界面(UI)测试来核实用户与软件的交互。UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司或行业的标准。

　　表1-11用户界面测试说明表

　　（5）性能评价

　　性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是将测试对象的性能为当作条件（例如工作量或硬件配置）的一种函数来进行评价和微调。

　　注：以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用测试对象来执行的特定用例，例如，添加或修改某个合同。

　　表1-12性能测试说明表

　　（6）负载测试

　　负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

　　注：以下事务均指“逻辑业务事务”。这些事务被定义为将由系统的最终用户通过使用应用程序来执行的具体功能，例如，添加或修改某个合同。

　　表1-13负载测试说明表

　　（7）强度测试

　　强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。注：以下提到的事务都是指逻辑业务事务。

　　表1-13强度测试说明表

　　（8）容量测试

　　容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内是否能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。

　　表1-14容量测试说明表

　　（9）安全性和访问控制测试

　　安全性和访问控制测试侧重于安全性的两个关键方面：

　　a.应用程序级别的安全性，包括对数据或业务功能的访问

　　b.系统级别的安全性，包括对系统的登录或远程访问。

　　应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有经理才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户信，（包括财务数据），而“用户二”只能看见同一客户的统计数据。

　　系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

　　表1-15安全性和访问控制测试说明表

　　（10）故障转移和恢复测试

　　故障转移和恢复测试可确保测试对象能成功完成故障转移，并从硬件、软件或网络等方面的各种故障中进行恢复，这些故障导致数据意外丢失或破坏了数据的完整性。

　　故障转移测试可确保：对于必须始终保持运行状态的系统来说，如果发生了故障，那么备选或备份的系统就适当地将发生故障的系统“接管”过来，而且不会丢失任何数据或事务。

　　恢复测试是一种相反的测试流程。其中，将应用程序或系统置于极端的条件下（或者是模仿的极端条件下），以产生故障，例如设备输入/输出(I/O)故障或无效的数据库指针和关健字。启用恢复流程后，将监测和检查应用程序和系统，以核实应用程序或系统是正确无误的，或数据已得到了恢复。

　　表1-16故障转移和恢复测试说明表

　　（11）配置测试

　　配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件,例如，应用程序、驱动程序等。而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。

　　表1-17配置测试说明表

　　（七）测试进度和里程碑

　　1．项目测试进度

　　以下测试工作任务的起止时间为：

　　（1）制定测试计划

　　-确定测试需求

　　-评估风险

　　-制定测试策略

　　-确定测试资源

　　-创建时间表

　　-生成测试计划

　　（2）设计测试

　　-准备测试计划说明书

　　-确定并说明测试用例

　　-复审和评估测试覆盖

　　（3）实施测试

　　-单元测试阶段

　　-集成测试阶段

　　-系统测试阶段

　　-提交测试分析报告

　　（4）测试活动总结

　　（1）测试目的

　　提供一个对《网上电子商城购物系统》软件进行测试的总体安排和进度计划，确定现有项目的信息和应测试的软件构件标明推荐的测试需求（高层次）推荐可采用的测试策略，并对这些策略加以说明确定所需的资源，并对测试的工作量进行估计，列出该项目的可交付元素。

　　（2）测试范围

　　1.测试用户注册会员功能是否正确

　　2.测试是否能够区分用户类别进行登录

　　3.测试用户的登录功能是否正确

　　4.测试用户基本资料管理功能是否正确

　　5.测试用户账号管理功能

　　5测试概要

　　流程：所有无效流程，有效流程

　　界面：单页面下所有控件有效(1.能检验非法输入．2.控件的长宽，用户体验；3.页面布局．控件组合逻辑测试，)

　　性能：页面的加载时间，响应时间，图片的显示效果

电子商城网站测试计划2

　　1引言

　　1.1目的

　　测试网上购物系统中的各个功能模块是否满足用户需求，并测试是否存在bug。预期达到能够使系统进行快速的改进和系统的提高。为了在软件投入生产性运行之前，尽可能多地发现软件的错误。

　　1.2背景

　　“网站购物平台系统”的项目旨在开发一套网上电子商务的平台，它将实现用户通过互联网完成商品采购的整个过程。用户可以通过此平台的网上商品展示和检索获取自己所需要的商品的基本信息，并且可以根据自己的需求，通过互联网提交订单的内容来判断是否与此用户交易。

　　在执行本测试计划之前，需要完成系统的网站详细设计。

　　1.3定义

　　黑盒测试：Black-Box Testing

　　回归测试：Regression Test

　　功能测试：Function Testing

　　性能测试：Performance Testing

　　界面测试：UI Testing

　　兼容性测试：Compatibility Testing

　　安全性测试：Security Testing

　　2任务概述

　　2.1测试范围

　　本测试计划主要包括单元测试、集成测试、系统测试和验收测试。测试用例能够检查的范围包括：

　　①．模板设计和功能是否正确；

　　②．接口关系是否正确；

　　③．用例是否全部实现；

　　④．是否达到需求规格中的性能要求。

　　2.2测试方法

　　手工测试、自动化测试、WEB测试通用方法、Visual Studio 20xx、黑盒测试

　　2.3测试资源

　　资源：①测试服务器

　　②稳定的测试服务器，IP地址为：192.168.10.23

　　③测试审核人一名，测试实施人员一名

　　工具：①测试中使用的Bug管理工具为经过改进的`Bug管理工具②自动化测试工具待定

　　3测试需求

　　3.1测试计划说明：目标背景见引言

　　3.3功能测试

　　4应急处理

　　4.1处理措施

　　①人为因素：A.雇佣不到合适的人或人员流动

　　B.测试团队新组建没有合作经验或意见不统一

　　C.测试人员经验不足，对产品特性理解的不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证不标准

　　应急措施：A.进行相关人员的招聘

　　B.推迟进度计划，从其他部门协调有能力的人员，协调团队的团结性

　　C.对人员进行培训，提高培训的强度

　　②资源：Bug的生命周期过长

　　应急措施：A.及时分配修复任务，并检查监督

　　B.对于暂缓处理的缺陷，要记录并跟踪

　　③其他方面：用户需求变更

　　应急措施：项目启动初期就和用户书面约定好需求变更控制流程、记录并归档用户的需求

　　变更申请

　　④测试环境：测试环境与实际运行环境不一致，造成测试结果的误差

　　应急措施：测试环境按照软件运行的标准环境进行测试

　　4.2问题跟踪

　　在商品写入方案中：是否使用右键和菜单实现了增、删、改的功能

　　增加零配件使用商品和价格配置器，查看零配件使用商品编辑窗口拖动功能是否正确等

【电子商城网站测试计划】相关文章：

电子商城项目计划书12-27

测试计划模板07-25

测试计划模板[精选]07-22

网站运营计划04-14

网站推广计划06-07