支付宝WAP支付平台测试方案

支付宝 WAP 支付平台测试方案 一、 项目简介 支付宝 WAP平台 从总体上分为 子模块，分别是登录、注册、账户管理、交易管理、缴费中心和交易接口，系统结构图如下： 二、 测试方案组成 部分 根据我们对 支付宝 WAP平台 设计方案 的分析， 认为 本测试 方案 应该由 三个部分组成，即软件验证技术、软件确认技术和 软件测试 管理技术。它们内涵及相互之间的关系如下图所示： 支付宝 WAP 支付平台 测试方案 测试技术 层面 测试管理层面 软件验证技术 需求规格说明验证 软件测试 团队组织管理 设计规格说明验证 代码验证 软件测试 计划管理 交付验证 软件确认技术 单元测试 软件缺陷（错误）跟踪管理 集成测试 系统测试 软件测试 件管理 交付测试 其中， 软件验证技术 着眼于排除软件开发文档中的错误。验证活动涉及的文档按开发流程主要涉及需求规格说明、设计规格说明（包括概要设计规格说明、详细设计规格说明、数据库设计规格说明）、编码规格说明、产品交付文档等一系列书面材料。目前验证技术的实施在很大程度上是依靠测试人员手工完成的。验证活动视实际需要有时还会涉及到开发人员和目标客户，需要得到他们必要的理解和支持。验证测试采用的主要测试手段有：面对面质询、文档抽查、非正式会议、同行评审等等。 相对于软件验证技术， 软件确认技术 则主要着眼于排除程序代码中的错误。活动涉及的对象主要是程序部件的代码或软件成品。在实施过程中，常常按被测代码的规模和测试所处的层次将软件确认测试分为 四个阶段 ，即： 单元测试（也叫类测试） 、 集成测试（也叫组装测试） 、 系统测试和交付测试 。确认测试基本上由 软件测试 人员对照相关开发文档运行程序独立完成的。必要时，也可让设计人员带领测试人员阅读程序代码共同发现其中的错误，（即所谓代码评审会）。 我们 认为 ，在单元测试 ( 或类测试 ) 阶段，应该有软件编码人员参与，这样能减轻测试人员阅读代码障碍。原则上，测试理论不提倡程序作者负责把关自己编写的程序的质量。在实际实施过程中，可视实际情况灵活处理。（如成对编程可能会较好的处理单元测试这个难题，上面提到的代码评审会也是为应对这个难题而想出的一个好办法。），软件确认技术 目前已经部分地实现了 测试工具 的自动化，市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作 （例如用于 Java 代码单元测试的 Junit 工具，又如用于 GUI 测试的 Rational Visual Test 工具，等等）。 软件验证技术和软件确认技术均属于 测试技术 层面的东西。然而对于工程质量的保证而言，光靠软件 测试技术 还远远不够，还需要技术管理层面上的东西。 我们这里强调 软件测试管理技术的 目的 正是为弥补这个不足。按照管理的对象不同，测试管理技术大致涵盖 软件测试 团队组织管理、 软件测试 计划管理、软件缺陷（错误）跟踪管理以及 软件测试 件管理四大部分。下面， 针对 支付宝 WAP 平台 项目对该测试方 案做一个详细的诠释。 三 、 在 支付宝 WAP 平台 测试 过程采用的测试 内容 3.1 在 支付宝 WAP 平台 采用测试 验证技术 我们将对 支付宝 WAP 平台 采用 软件验证技术 ， 主要包括 需求规格说明验证 、 设计规格说明验证、代码验证以及交付验证 。以下逐一说明。 需求规格说明验证的主要任务是保证用户的功能需求、业务需求、以及其他的一些需求（如非功能性需求、约束性需求等等）都已经被分配到软件需求规格说明的各需求项中。 设计规格说明验证相对需求规格说明验证而言，稍微复杂些，它包括 3 个部分的内容：即概要设计规格说明验证、详细设 计规格说明验证以及数据库设计规格说明验证。其中概要设计规格说明验证的主要任务是确保软件需求规格说明中的需求项全部已经分配到了概要设计规格说明的各软件模块之中并且无多余物，详细设计规格说明验证的主要任务是确保概要设计规格说明中的模块已经全部分配到详细设计规格说明的各软件单元之中并且无多余物，数据库设计规格说明虽然从范畴上讲应该属于详细设计规格说明范畴，但 我们 认为 应该把它独立出来实施验证活动。（数据库设计和软件设计毕竟有很多不同之处。）数据库设计规格说明验证的重点任务是验证数据库与外部应用程序的接口是否正确、数 据操作实现界面是否清晰、数据库整体设计是否合理、数据表设计是否符合 3NF 要求（如违反范式要说明详细理由）以及数据表中的字段（键）和索引的设计是否高效合理等等。 代码验证的内容包括：代码编写规范审查、代码审查和代码静态分析三个部分。代码编写规范审查主要是审核代码排版的格式以及注解的格式是否符合开发团队的相应规范；代码审查的任务主要是验证详细设计中的软件单元是否都已被代码覆盖并正确实现，并且代码中不含冗余物；代码静态分析技术主要任务是检查变量或标号的定义与使用、表达式运算以及程序的流程设计上是否存在缺陷或错 误。 做完代码验证以后，软件系统需要依次做单元测试、集成测试和系统测试，这部分内容属软件确认技术范畴， 下面有专门的论述。软件系统在做完系统测试后，就面临着交付使用的问题，在系统正式移交给用户之前，还需要做交付验证和交付测试。交付 测试技术 下文有专门的论述，不赘述，这里主要谈交付验证技术。 交付验证包括安装验证和使用验证两部分内容。其中，安装验证的主要任务是保证程序能按照用户手册的提示正确安装到目标机器上，使用验证 的主要任务是确保程序能按照用户手册的提示的操作正确完成某项功能或事务处理。这两部分工作通常是由测试人员完成的，用以核实相关安装和使用手册是否正确无误。 3.2 在 支付宝 WAP 平台 中应用软件确认技术 为了确保及时、尽早发现软件中存在的问题，我们将在 支付宝 WAP平台 的测试过程使用 的 确认技术包括 ： 单元 测试技术 、集成 测试技术 、系统 测试技术 和交付 测试技术 。 单元测试 ： 主要任务是验证详细设计规格说明中所划分出来的软件单元是否被程序编制人员用代码形式正确地实现了。这里软件单元可能是某个函数（或称方法）也可能是某个抽象数据类型（如类、数据结构或者模板）。单元测试在实际测试当中也常常被称为类测试（在面向对象的设计中）或白盒测试（白盒的意 思是面向代码）。测试人员输入设计好的测试用例，测试被测单元能否按照设计要求处理这些测试用例，对出现异常的测试用例，测试人员将 做记载并反馈给软件开发团队。 集成测试： 对照软件概要设计规格说明，验证各软件单元组装后形成模块能否达到概要设计规格说明中模块的设计目标；在模块级集成工作完成之后，测试人员还应测试各模块组装后形成的用户系统内部存在冲突，各模块能否正常工作。通常在做集成测试时先是从分系统内部的集成测试开始做起，做完以后再测试各分系统是否能集成为最终要实现的大系统。也有其他做法（如自顶向下集成测试方法 、核心系统先做集成测试或每日集成测试等等）。总之，万变不离其宗。集成测试要保证模块的内部正确性以及保证模块能最终集成为大系统。 系统测试 ： 系统测试的主要任务是验证经集成测试后形成的软件系统是否满足软件需求规格说明中的各需求项。这些需求项包括：业务需求、功能需求、非功能性需求（如：性能、可靠性、安全性、系统维护等方面的要求）以及一些约束性需求（如开发标准、编程语言、通讯协议）等等。由于需求项涉及的领域很广泛，这就导致了系统测试中对应的测试门类相当庞杂。如：功能测试、执行路径测试、可靠性测试、压力测试、可恢 复性测试、可移植性测试等等。这些测试最显著的特征是在一定环境条件下（如：模拟现场或极端条件），设计各种测试用例，输入并运行完整的软件系统，根据软件系统运行过程中的实际表现，评估软件系统是否符合软件需求项的各类要求。 交付测试： 在做完系统测试以后，软件产品就到了交付用户使用这个阶段了。交付过程中的重要一环就是交付测试，交付测试的目标是保证用户对所交付的系统的满意。与前面所讨论的测试不同，交付测试主要的参与者应该是目标客户。客户参与越多越好。交付测试的内容一般包括安装测试、可用性测试、 alpha 测试、 beta 测试等。其中安装测试的主要任务是测试软件系统能否在模拟环境下或实际现场由目标用户顺利完成在目标机器上的安装；可用性测试的主要任务是测试软件系统在完成安装以后能否完成用户的模拟任务或现场任务； alpha 测试采用的形式一般是由一个用户在开发环境下对软件系统进行类似于黑盒的测试，测试的目的是从用户的角度评价软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色； beta 测试采用的形式一般是先由软件的多个用户在实际使用环境下使用 beta 版软件系统一段时间，然后把使用中出现的各类故障 或缺陷反馈给 beta 测试负责人员，再由测试负责人员移交给软件开发者，由开发人员负责修正并完善软件系统。Beta 测试的目的是确保软件产品交付给全体用户之前能部分或全面地修正其在实际应用中可能出现的各类 BUG 或不足。 3.3 支付宝 WAP 平台 中 采用 用 软件测试 管理技术 如前文所述， 测试技术 解决了测试采用的方法和技术问题，然而， 对于一个工程而言，还需要相应的测试管理才能保证各项测试活动的有序开展。因此，在 支付宝 WAP 平台 软件测试 管理技术要解决的问题是如何确保软件 测试技术 （包括软件验证技术和软件确认技术）能在软件项目在软件生命内得到顺利实施，并产生预期的效果。 按照 软件测试 管理面对的管理对象的差异， 软件测试 管理技术大致分为 软件测试 团队组织管理、 软件测试 计划管理、软件缺陷（错误）跟踪管理以及 软件测试 件管理四大部分。以下一一诠释： 软件测试 团队组织管理通俗地讲就是测试团队应该如何组建。 根据我们现有的测试队伍，我们有 测试领域专家，具有极为丰富 软件测试 经验，对软件开发过程中常见的缺陷或错误了然于胸，此外，还具有较好的亲和力和人格魅力。其次， 我们的 队还具有很多具备一技之长的成员，如对某些 测试工具 运用娴熟或能轻而易举 地编写测试脚本。另外，测试团队还聘有兼职成员。如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的工作。 软件测试 计划管理通俗地讲就是安排好测试流程。这部分内容具体涵盖 软件测试 策划、软件 测试技术 剪裁、测试进度管理、成本管理等几个部分。其中测试策划工作主要是指具体测试活动实施之前做好策划工作，如起草测试大纲以及测试计划；软件 测试技术 剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的 测试技术 ；测试进度管理工作主要是指排出各项测试的时间进度 及人员安排，如有变动时应做相应调整；测试成本管理工作的内容即开列出测试活动中会涉及到的资源需求。 四 、 测试 支付宝 WAP 平台 的 流程图 五 功 能 性能 测试方法 1. 等价类划分法： 有效等价类： 指输入完全满足 程序 输入的规格说明，是由有效且有意义的输入 数据 所构成的集合，利用有效等价类可以检验程序是否满足规格说明所规定的功能和 性能 。 无效等价类： 和有效等价类相反，即不满足程序输入要求或者由无效的输入数据构成的集合。 2. 边界值分析法 ： 指对输入的边界条件进行分析，设计出针对边界值的测试用例。 数值的边界值检验 字符的边界值检验 如： ASCII 和 Unicode 编码方式 其他边界值检验 选上所有选项（最大值） 不选上任何一项（空，零） 只选一项 （最小 值） 3. 因果图法： 就是利用图解法分析软件输入（原因）和输出条件（结果）之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。 4.功能图法 功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入 /输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。 5.错误推测法： 推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场 景等，在找到缺陷后，设计出相应的测试用例。 6.正交实验设计方法： 主要步骤是： （ 1） 对软件 需求 规格说明中的功能要求进行划分（层层分解与展开），分解成具体的、相对独立的基本功能。 （ 2） 根据基本功能的 质量 需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。 （ 3）确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。 权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。 （ 4） 加权筛选，生成因素分析表。 （ 5） 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。 利 用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。 六 测试环境的搭建 本测试方案需要 开发商提供的硬件和软件如下： 6.1 硬件 1）提供带有 WAP 浏览器的不同类型的手机终端。 2）提供一定的笔记本电脑 ，和网络设备。 6.2 软件 1）提供软件测试工具。 2）提供开发平台的工具包 七 测试方案 工作量估算 7.1 测试技术方案 根据该系统的运行环境， 系统需求和系统设计，以及组成系统的 各 子模块。我们必须编写各个测试阶段 ，各模块的测试用 例。 1） 根据设计规格得出的基本功能测试用例 ； 2) 界值测试用例 ； 3) 态转换测试用例； 4) 误猜测测试用例； 5) 常测试用例； 7.2 用例数量的估算 根据本系统的需求和系统 设计 ，大约需要测试用例的数量如下： 系统需要测试用例： 13X2 16X13X4 858 个 7.3 需要实行用例测试人员 根据本系统的完成期限，每个测试人员在 1 2 月内需要测试的功能模块进行平均计算，需要测试人员为： 858/60=14.3人 ，即 14 个人两个月内完成测试。 以每人月工资 3000 元计算 ，共需 14X2X3000 84000 元 如果考虑到不同的手机终端，每一个类型的手机增加 1/3X84000 元 28000 元 考虑到上税：总花费需要： 84000手机机型数 X28000 元税率。 附录：系统开发和软件测试高级工程简介： 1、学术总监：柏永林 高级软件工程师 ， 从事软件开发设计架构 23 年。 目前 担任技术总监。 具备扎实的计算机理论基础。 英国诺丁汉大学研究软件构架模式技术多年。 曾任 国家级软件园：西安软件园西部数通公司总工程师和总构架师。 在多年的软件工程技术开发和集成过程中，成功组织、设 计、管理、开发出了如 CALL Center、 SMS、 WORKFLOW 的技术 B/S C/S 构架系统、嵌入式（如手机）开发应用等。在 Middle-tiers 技术开发方面，主持设计开发了综合业务即时服务系统（ CALL Center+WorkFLOW+SMS+FAX+C/S+B/S+DATABASE 的大型综合服务和监控系统）。熟练掌握 WEB Services， XML Schema， XML， WSDL， SOAP， UDDI。精通企业级 J2EE 和嵌入式 J2ME等技术规范（如 EJB 组件、 Web 技术 JSP、 Struts、 JSF 等）和 MVC 模式，精通 UML 建模语言和 POWERDESIGNER、 RATIONAL ROSE 以及 Jbuilder/Eclipse 等开发平台，精通世纪桥架构开发系统 ，熟悉 WAP 开发。 2、 赵卫栋 曾任高级嵌入式软件工程师、项目经理等职 ， 在国内著名通信公司、美资外企工作，先后担任高级嵌入式软件工程师、项目经理等职。精通 C 语言、 Vxwork、 linux、各种通信协议， 3G 系统和各种通信设备。技术方向： pSOS for PowerPC (开发过 850 860 8260 驱动 ) ，Tornado(vxworks) for Arm(开发过 1200) for PowerPC( 8260 )， 开发过 DSP，网络处理器（ ixp1200 ixp2400 c5 c3e） ， 数据链路层协议，网络层协议，以太网交换机，路由器， 三层交换机等 Linux 下开发过网络安全产品。项目经验： REM 32E1 板， 3G REM 接口板（路由引擎模块）， MPA（媒体转发）板， NGN 项目中的 CA （呼叫代理）板，高密度语音板， 155M ATM 接口模块。 3、 和征 西安理工大学信息管理硕士。参与分析、设计和开发了陕西建设机械 股份有限公司网上进销存管理系统、企业 Intranet 管理系统、临汾网络通讯公司网站系统、西安理工大学图书馆网站、柏高酒店网站管理系统。以 Oracle 数据库作为企业数据中心，通过 J2EE 技术和XML 技术 ,以及 Web Services 技术，对企业不同信息系统进行集成，分析、设计和开发了陕西建设机械股份有限公司企业应用集成系统 (简称 EAI)，通过企业门户网站的形式对企业提供应用集成功能。精通 Java 语言、 JSP 以及 J2EE 技术 ,对 J2EE 架构以及基于 J2EE 架构的Web Services 技术有深刻的理解 ,。精通 C#语言、 VB、 VB.NET 语言以及 ASP、 ASP.NET 技术 ,熟悉 XML 技术和微软的 XML Web Services 技术 ,。 4、 王晓鹏 毕业于西安电子科技大学。多年从事通信行业 .曾在 NOKIA 从事移动通信工程 .在华为大学西安分部从事通信培训。熟悉计算机通信网络 ,获得 CISCO 公司的 CCNP 资格证书 .熟悉移动通信 2G 技术 ,在工程设计 ,实施 .技术支持和培训方面有丰富的积累和经验 ,对 3G 标准WCDMA,CDMA2000 制式的技术及设备比较熟悉。 5、 王永强 西安理工大学计算机科学与技术硕士。曾担任项目经理、软件 技术总监等职务。从事过智能温控系统设计与维护，电力调度自动化通信软件设计。熟悉 B/S,C/S 架构系统开发，熟悉 SQL Server， Sybase 等大型数据库，成功开发出智能卡业务支撑系统，元器件管理信息系统等。从事过基于嵌入式平