基于微信平台会员中心小程序的软件测试设计及用例复用方法研究

绪论软件测试的背景和意义软件测试，是为了寻找缺陷，缺陷又称BUG。从电脑被发明起，电脑就存在缺陷。第一个发现有bug是格蕾斯·哈珀（GraceHopper），她是编译器的发明者。在1945年9月9日，当时她和她的团队正在研究一个计算机，该计算机在当时还不是一个完全的电子计算机，是一种复杂而又大型的电子机械装置。实验环境并不可观，天气热且实验室没有散热系统，在高温环境下，计算机因无法散热降温宕机了。技术人员尝试许多方案去解决，让计算机重新运作起来。尝试了许多解决方案，排查问题，最终发现是第70号继电器无法正常运行。哈珀观察这个出错的继电器，发现一只被继电器打死的飞蛾，她将飞蛾小心翼翼的拿了出来，记录在记事本中，并注明“第一个发现bug的实例。”自此之后，在计算机发展历史中，人们将在电脑系统或程序中的错误称为虫子（bug），这就是‘bug’的由来。回顾软件测试的发展历程，早期的软件测试只是为了“调试”，检测该系统是否可正常运行；在软件工程建立前，软件测试是为表明程序正确而进行测试；1972年，首届软件测试大会在北卡罗来纳大学举行，大会宣布：软件测试作为一项正式而独立的工作。1975年，《测试数据选择的原理》这篇文章由JohnGoodEnough和SusanGerhart在IEEE上发表，软件测试被确定为一种研究方向。1979年，Glenford Myers著作《软件测试艺术》一书，对测试重新做了定义：测试是为发现错误而执行的一个程序或者系统的过程。20世纪80年代早期，随着用户体验性的要求越来越大，软件质量的越来越受重视，测试不仅仅是一个发现错误的过程，还包含软件质量评价的内容。从此软件测试定义发生了改变，并且制定了对软件测试的各项标准。随后在1983年，《软件测试完全指南》著作的作者BillHetzel正式提出：以评价一个程序或者系统属性为目标的任何一种活动都可称之为软件测试，测试是对软件质量的度量。20世纪90年代，测试工具逐渐发展且应用了起来。到了2002年，《系统的软件测试》的作者Rick和Stefan在书中对软件测试做了进一步完善的定义：测试是为了测量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。从软件测试的发展过程中不难发现，从最初仅验证系统是否可正常运行到发现错误到保障软件质量，软件测试在逐渐成熟且运用到系统中。现代测试的目的是为了系统投入使用前，模拟用户真实操作，尽可能排查系统的故障点。软件测试的理论基础1.2.1软件测试的定义软件测试伴随软件开发而生。1979年，《TheArtofSoftwareTesting》的作者GlenfordJ.Myers，定义了软件测试：“软件测试就是为了发现错误而执行程序或者系统的过程”。在此定义中表明进行软件测试是为了发现程序中的错误。在软件工程运用起来之前，开发软件的规模比较小，软件开发的过程杂乱无章，过程随意。开发人员完成软件编写工作并自己完成调试与运行，此时的测试过程不算严谨，测试工作内容没有明确的定义，开发人员测试自己写的程序相当于改正软件中的已知错误，这样的模式需要等到代码基本完成，产品已有基本雏形时才进行测试。因此，在这种模式下的软件开发，他定义的软件测试在当时被人们广泛接受并投入运用到项目中。到了上世纪80年代初期，软件行业快速发展，软件大且复杂，逐渐开始面向用户使用，人们逐渐意识到软件的质量越来越重要。GlenfordJ.Myers定义的软件测试已经无法满足当前要求，在这个大环境下，在发展中人们对软件测试的理论基础和应用已逐渐形成。于是在1983年，IEEE对软件测试的定义做出了调整，即“使用人工或者自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足定义的需求，并找出与预期结果之间的差异。”。新的软件测试的定义继承了之前对软件测试定义中的精华，另外还完善了不足之处，软件测试可作为保证软件质量的一个重要方法，其主要内容是验证软件中各个功能模块，检查整个系统是否可正确且完整地运行预期的功能，以保障软件质量。同时，人们也应需要而开始为软件开发设计了更有效的管理流程的方法，软件系统的研发模式也逐渐由起初的杂乱无章的系统研发过程逐渐过渡到规范清晰的结构化开发过程，拥有规范的结构化分析与设计、结构化需求项目评审、结构化程序设计以及结构化测试为特征。最主要的是人们将“质量”为主的概念融入整个项目周期中。测试工作不仅仅是一个发现错误的过程，而是与整个软件周期融合一体，将测试工作作为保障软件质量的主要职能。1.2.2软件测试的目的关于软件测试，GlenfordJ.Myers定义的软件测试的目的是为了发现程序中更多的错误。随着软件测试定义不断完善，软件测试的定义也相对清晰，人们意识到软件测试不仅仅是找出软件中的错误，同时也是保障软件质量的过程。对于测试人员来说更重要的是分析错误产生的原因与意识到错误带来隐患，这样可以协助开发人员尽早发现缺陷并及时修正系统缺陷，从而保障软件质量。在软件投入正式运行前，尽可能的模拟用户可能会发生的操作，排查系统缺陷并加以改正，确保软件质量，降低软件缺陷给软件系统带来的风险。另一方面，达成软件测试的目的，也提高用户对软件的使用感。1.2.3软件测试的内容软件测试的主要工作内容是“验证”和“确认”两部分，在整个软件生命周期中，确保各个环节的正确性。1.验证：保证软件正确的实现了既定的原有需求功能（1）确定软件在生命周期中在完成阶段的产品是否达到与预期需求一致的过程。（2）证明程序的正确性程，通过运用软件测试的方法来证明程序是否符合预期设计要求的过程。（3）通过评审、审查、测试、检查等方式，对是否符合预期设计要求进行判断和提出相应的报告。2.确认：通过一系列的项目流程和测试方法，在特定的用户场景中，确保软件的运行与预期结果一致。（1）静态确认，不在计算机上运行程序，通过人工干预或分析程序的方法来证明该软件系统的正确性。（2）动态确认，通过执行程序，做出相关分析，观察程序的动态表现，来证明软件是否正确。1.2.4软件测试的原则软件测试是在软件生命周期中，在一定的需求下对程序进行规范的操作，来发现程序的缺陷，保障软件质量，并评估该程序是否满足预期的设计要求。软件测试的基本原则贯穿整个软件生命周期，帮助软件测试人员尽早且尽可能多的发现问题，并尽早让开发人员改正，有利于提高产品质量，软件测试人员负责寻找程序中的问题、评估、提出建议并加以跟进，从而不断改进测试过程。软件测试有以下几种原则，分别为：测试证明系统有缺陷，无法证明系统不存在缺陷通过测试手段可以找出系统中的缺陷，减少软件中存在缺陷的数量，但无法证明系统不存在缺陷。即便在测试过程中没有发现任何缺陷，也不能完全的说这个系统不存在缺陷。无法进行穷举测试在软件测试的过程中，大多数情况下进行穷举测试是无法实现的。如测试系统所有会发生的情况，软件质量并不会因此而提高，反而测试在某一功能点投入量太大，会影响整个项目进度。此时应遵循Good-enough的测试原则，来保证测试效果。考虑用户大概率可能输入的情况，并加以组合，选取有代表性的输入值作为一类的测试数据来进行测试，有当满足一定的测试输出结果时该类测试就需终止。3.测试的尽早介入通过大量的实验证明，在软件开发生命周期中早期发现错误的概率较大，修复缺陷的成本也较低。在软件开发生命周期后期，缺陷有存在趋于放大的趋势。因此，越在软件生命周期后期，项目团队在软件维护阶段修复缺陷成本会越来越大。因此，在软件投入使用前，测试人员要尽早的且不断的对软件进行测试，尽可能的找出更多的缺陷，开发人员尽早的修复缺陷，提高软件的整体质量，降低软件开发成本，提高用户的使用感。4.缺陷的集群性根据实验表明：80%的错误集中存在于20%的程序模块中。缺陷不是平均分布而是集群分布的，因此在进行测试过程中，如果在某一模块或程序发现了很多缺陷，那么通常在这个模块或类似功能模块中可以发现更多的缺陷。因此要花费更多的时间关注对这部分模块，进行反复且深入的测试，利用缺陷的集群性，关注相关测试点，进行充分的测试。5.排除随意性测试与缺陷发生的偶然性测试计划的内容包含进行软件测试的测试规范，测试方案，测试范围等，一般包括会要求测试数据的规范，测试工具的使用，测试文档的输出。严格按测试计划执行，按时间完成各阶段测试节点，避免测试的随意性。在进行测试过程中，在某个测试点上，如发现了缺陷，不应立马下结论是因某种操作引发的缺陷，应在此至少验证两次，来确定此缺陷的形成，避免缺陷的偶然性，影响开发定位问题，影响测试文档的输出。6.软件测试以需求为依据每个软件系统，即使复用率很高，但是根据不同品牌有不同的品牌背景需求，所以，即使是复用率很高的系统，也不能使用完全相同的测试方案来进行测试。应根据相关需求，定制个性化的测试方法，可复用大体流程的测试用例，不符合需求规定的均定义为改系统的缺陷。如在测试过程中发生理解歧义，所有问题都可以需求文档为规定来说明。7.对测试结果做全面的检查在完成缺陷修改后，不排除会引入新的问题，所以对于每个预期结果明确定义的同时，测试完成后还需对每个测试结果进行全面的检查与分析，尽可能多的发现缺陷。2软件测试的分类软件测试方法从不同角度思考有不同的种类划分。在测试过程中，使用不同的测试方法可以更加快速且准确的找出缺陷。2.1白盒测试以关注软件内部结构和程序逻辑的测试方法称为白盒测试。白盒测试好比一个打开的盒子，测试关注的是盒子内部结构的设计与构成。着重检查代码的逻辑是否符合设计规格说明书，依据程序的结构设计测试用例，对程序的逻辑进行验证，相关的模块和链路是否正常且有效。单元测试与集成测试通常运用白盒测试做为测试方法，白盒测试的主要测试方法是逻辑覆盖法。2.2黑盒测试黑盒测试又称为功能测试。与白盒测试方法不同，黑盒测试相当于把软件程序当做一个关闭状态的盒子，测试人员不关注程序内部结构如何实现，仅关注软件呈现的功能是否能正常运行。根据需求文档设计测试用例，并检查程序的运行是否与需求说明文档中的预期实现功能一致，黑盒测试主要是对软件的界面和软件功能进行测试，从而验证系统功能是否正确。2.2.1等价类划分法因不可能进行穷举测试，所以可以将软件程序中有可能会出现输入的数据划分成若干个等价类。等价类，顾名思义，从该类中选取具有代表性的数据作为一组测试数据进行验证。用该类方法，可以将等价类划分为有效等价类和无效等价类，有效等价类是指对于软件程序来说，该类数据是合理的、能够实现正常功能的有意义的输入数据集合，可以用来验证程序是否实现了正常流程的功能。无效等价类和有效等价类概念相反，无效等价类是指对于软件需求说明而言，是不合理的输入数据集合，使用无效等价类的方法设计测试用例，可以找出程序中的非正常流程情况，程序中是否对其做了相关判断限制。也相应的说明该功能的实现是否有与需求说明中要求不一致的功能点。两种不同类型的数据代表组成相关的测试用例，从而使得测试用例具有代表性和完整性。2.2.2边界值分析法 边界值分析法是对等价类划分法的一个详细的补充，对需求说明文档中要求功能的输入或输出的边界值进行测试的一种黑盒测试方法。使用边界值分析法编写测试用例中，根据需求说明文档定义边界值的情况，假设定义输入的数值为N位字符，需选取：①正好为N位字符输入，查看其输出结果；②刚刚大于N位字符输入：N+1，查看其输出结果；③刚刚小于N位个字符的输入：N-1，查看其输出结果。边界值分析法虽然属于等价类划分法的一种，但不完全等同。使用边界值分析法，应在等价类划分好的基础上，再将这个等价类的每个边界值作为测试数据进行编写测试用例。2.2.3因果图推断法 因果图推断法，又称因果图分析法。根据需求说明文档，分析定义该功能的因（输入条件）与果（输出条件），从而描绘出因果图，进而转化为判断表。因果图法适用于多种输入条件组合的功能，对需求加以分析，依据需求定义的输入条件进行划分与组合，从而分析出相关的输出结果，从而定制出高效的测试用例。同时，在使用因果图推断法的过程中，也能分析出程序规范是否存在缺陷。2.2.3错误推断法 在测试过程中，既需要验证功能的正常流程正确；也需验证在进行非正常输入流程的情况下，程序也做了相关的判断限制，也是从侧面验证该功能是否符合需求。在软件测试过程中，测试人员依靠丰富的测试经验与测试敏锐度，推测系统中可能存在的错误即为错误推断法。利用错误推断法列出程序中所有可能出现的错误，从而设计测试用例。如：提交字段为姓名、年龄、性别的表单，三个字段均为必填项，仅三个字段填写正确且完整方可提交成功。我们可以运用错误推测法，设计测试用例：三个字段均不填，提交该表单，是否可以提交成功；如提交不成功，符合需求，测试通过；如提交成功，功能与需求不符合，即为缺陷。测试过程中，随着测试人员在对产品的了解不断的加深，丰富测试经验，使用错误推断法设计的测试用例往往会更加的高效。2.3灰盒测试灰盒测试是介于白盒和黑盒测试之间的一种测试，不仅仅需要关注功能上输入、输出的正确性，还需关注程序内部的逻辑情况，但不需要像白盒测试一样那么详细的了解程序内部逻辑，灰盒测试结合了黑盒测试和白盒测试的思想核心和测试方法，它注重了程序内部逻辑和用户端操作性。2.4回归测试在软件生命周期中，只要软件的任意部分发生了变化，就可能为软件带来新的问题。软件的改变带来的新问题可能是发现了缺陷并作以修改，也有可能是在功能完成或软件维护阶段有新的需求的加入或原有需求功能的变更。回归测试是为了在新的修改代码被写入后，重新测试以确定新的代码有没有引入新的错误或导致其他部分的功能产生错误。软件有所变化，也需相应更新测试用例。在版本迭代的过程中，使用回归测试会逐渐的频繁，应选择正确的回归测试策略来提高其有效性和效率。每当软件发生变化时，进行回归测试，需再重新测试全部的用例，优先测试主流程、着重测试新的修改的部分。以便确认新的修改没有引入新的错误，同时也验证修改后的代码是否达到了预期的目的。2.5验收测试验收测试是在软件投入使用之前最后一个测试任务。也称为交付测试。验收测试的目的是再次验证确保软件的功能与相关特性符合用户使用要求。其面向对象是用户，让用户来进行测试，确认软件完成既定功能和业务要求。3软件测试相关工具介绍3.1SQLServer数据库本文介绍的是MicrosoftSQLServer2008，测试过程中将会使用到该数据库及其可视化工具对相关数据进行查看、编辑等操作。SQLServer是Microsoft公司推出的一个关系型数据库管理系统。为企业提供了工具化的数据管理。企业可以管理更高性能且安全的数据，MicrosoftSQLServer数据库提供更安全可靠的关系型数据和结构化数据的存储功能。MicrosoftSQLServer2008有三大特点是：1.可信任的：使得数据有更高的安全性、可靠性和扩展性，MicrosoftSQLServer2008会对整个数据库的数据进行相关的加密，有相关权限的用户才可访问并查看数据。2.高效的：管理者可以降低对数据库的开发、管理成本，更高效的对数据做管理。3.智能的：SQLServer2008有更强大的审计功能，CDC（捕捉变更数据）技术的运用，它能自动捕捉和记录用户在数据库进行的增删查改动作。通过使用CDC功能，我们可以知道用户对数据库做了何种的操作，还可以利用其功能还原因误操作或程序错误导致的丢失数据。为追踪数据提供了依据。3.2SQLServer2008可视化工具SQLServer是数据库管理工具，使用SQLServer2008R2ManagementStudio可视化管理工具，输入服务器名称、登录名、密码连接数据库，对数据库里的数据进行相关操作。如图3-2所示。图3-2SQLServer2008R2ManagementStudio连接界面3.3接口测试工具：Postman3.3.1接口测试接口测试是用于测试不同软件系统组件相互调用的一种测试。接口测试主要用于测试内部系统与外部系统之间的接口交互点。接口测试的重点是检查系统之间数据的传递、交换、返回数据是否正确，以及各个系统直接的依赖关系。同时，还需关注通接口请求的异常情况处理的合理性。如：微信平台对用户提供对外统一接口文档，项目人员通过接口文档提供的信息设计基于微信平台的需求功能，开发人员根据接口文档中提供的参数调用完成基于微信平台的公众号或小程序开发，测试人员根据接口文档设计接口测试用例，测试接口是否通畅等。通过接口，大大的提高了软件产品的扩展性。3.3.2postman的介绍与使用Postman最早是作为chrome的插件使用的，因强大的功能，后推出了客户端版本，更方便使用。Postman本就是为了接口测试而设计的一款调试网络程序工具，能够模拟各种网络请求，如：GET、POST、header、PUT等，能够高效的帮助开发、测试人员进行接口测试。在接口测试中，使用的最多的是GET请求和POST请求。1.GET请求一般用于请求获取服务端的数据，在Apiurl后使用‘?’拼接需要请求的参数值，点击发送按钮，会返回相关的数据，显示在Response的Body中。请求与返回数据的速度很快，但数据安全性较低，请求的参数都显示在了地址栏中。如图所示GET请求的使用方法。（因数据保密性，故隐藏相关信息）图GET请求示例2.POST请求一般用于向指定的资源提交表单。POST请求比GET请求安全性更高，POST请求不会被缓存，请求的数据不会直接暴露在URL中，它一般是在请求体的body中以键值对（“key”:”value”）的形式请求提交，点击发送，response中会返回相关数据提交的结果。如图所示POST请求的使用方法。（因数据保密性，故隐藏相关信息）图POST请求示例4微信平台会员中心小程序需求分析4.1系统目标随着微信逐渐融入人们的生活，智能手机的普及率已经达到一个较高的水平，手机已经成为人们生活中必不可少的一部分。对于手机用户而言，品牌方向用户推广大部分都需用户下载相关品牌APP，而APP在用户手机上留存率、使用率较低，一般使用一次过后会为了释放手机内存或使用频率较少而卸载APP，商家因此会损失大量的客户，也无法实现客户转换率。这一情况下，微信平台的诞生及普遍能够很好的解决。在手机用户中，几乎每个用户都有微信，社交网络营销成为品牌企业关注的重点部分。基于微信用户量粘性高这一点，给品牌企业带来无限机遇。品牌方在微信公众号中内嵌一个小程序，即开即用、免安装、不占手机内存、用完即走，再次使用只需通过‘搜一搜’功能即可再次打开使用，用户体验性极好，小程序的功能也能基本实现客户端的业务功能。为品牌方设立一个基于微信平台的会员中心小程序，品牌方对粉丝及注册的会员做相应的个性化分析及推送，提高粉丝转换率、忠实会员转化率等，对用户来说，可及时查看到品牌方的相关活动及相关会员权益。因该程序面向适用对象是不同年龄阶段的人群，不同阶段的人对手机操作使用程度不一，设计会员中心小程序的目标是应遵循功能简单且实用、安全性高、操作界面简洁明了、用户体验感好等原则。4.2需求分析需求分析阶段是系统开发的基础，在软件开发生命周期中的任何活动都是以需求为基础，需求定义了该系统需要为品牌、用户实现什么、如何呈现。需求分析从用户提出的“要求”或“需要”出发，挖掘用户真正实用的需求，以详细的描述与清晰的且规范的文档，转换为产品需求的过程。在此过程中还需考虑到设计程序的约束条件，本文测试的程序是微信平台中的小程序，小程序有平台特点、可开放的接口文档等，一切的需求都需基于微信平台的约束而考虑设计。4.2.1功能性需求分析通过品牌方的业务背景，进行调查和分析后，设计会员中心小程序系统的需求如下：1.线上用户可通过微信‘搜一搜’搜索到该小程序；线下到店用户也可通过扫描门店二维码进入小程序，并进行注册，成为品牌方的会员，获得相关会员权益等。2.个人信息：注册成为会员后，以手机号为唯一身份标识，可查看相关个人信息3.积分兑礼：会员可在线下消费，消费金额根据1:1比例转换为积分，通过累积积分，可在积分商城中使用积分兑换满足现有积分充足的物品，若与兑换物品要求的积分不足，则不可兑换。4.我的礼遇：记录与该会员相关已拥有的权益、获取的礼品、礼品的状态等，同时预约活动的相关记录也记录在其中5.品牌活动：展示品牌方所开展的活动等，告知会员有兴趣即可参加。4.2.2质量与性能需求分析为了保障系统长期稳定且安全的运行，故对系统有以下性能与质量方面的要求：1.系统的可靠性系统的设计需具有较高的可靠性，在系统发生故障情况下，需要确保用户在使用基本流程上没有较大的问题，且入数的准确性和完整性，并有一套完整的系统解决方案2.系统的易用性流程简单方便，界面友好。3.系统响应的及时性系统响应用户的操作需有有及时性，基本流程操作应在3秒内系统给出相应的处理结果。4.系统的可扩展性在系统设计中需考虑到今后需求的增加，与第三方技术对接的需要，需具有可拓展的可能。5.系统的兼容性兼容市面上流行的手机，如iPhone、华为、oppo等，确保页面显示无误，且可操作无兼容性问题。6.系统的安全性从系统录入的数据应具有保密性，且应设立相关防止攻击的策略，确保系统稳定且安全的运行。7.系统的约束基于微信平台设计的会员中心小程序，数据库要求使用SQLServer2008。开发语言为.NET8.系统的验收标准需求达标率应为100%。4.2.2数据需求用户的数据录入及更新体现在会员注册、信息修改、参与会员活动等操作上，因此需要要求在数据表结构上有一定的关联关系，通过需求分析，总结以下主要数据：1.会员信息数据：姓名、性别、手机号（唯一标识，不可修改）、地址、生日。2.积分及等级相关数据：积分记录、积分消耗记录。3.兑换记录：兑换物品、兑换状态。5项目软件测试过程5.1测试计划制定软件测试计划，是进行软件测试的第一步。测试计划设定与测试是否能顺利执行有重要的关系。首先，需确保功能的实现与需求一致，需利用黑盒测试的测试方法进行功能测试。微信能在各个手机上有稳定安全的运行，并不代表内嵌在微信平台新开发的会员中心小程序也能完美的运行。因此，对手机的兼容性测试也需要考虑到。该小程序面向对象是广大群众，使用小程序过程中，会存在访问量的并发，因此对并发操作下服务器的承载量与相应速度也需进行性能测试。本文主要介绍对该小程序进行功能测试、简单兼容性测试。5.2测试内容分析及测试用例的编写5.2.1会员注册如图所示，是会员注册页页面原型，根据需求可推测出会员注册的流程逻辑，如图所示。用户通过搜索小程序或扫门店二维码进入，分已注册和未注册两种身份人群，未注册的用户进入小程序，进入注册页面，注册完成之后进入会员中心首页；已注册用户点击小程序进入，直接到会员中心首页。因可根据这个思路设计会员注册部分的测试用例，如表所示会员注册部分测试用例。图会员注册页页面展现（原型）图会员注册流程图测试模块用例编号操作步骤预期结果实际结果会员注册1未注册用户，进入小程序进入会员注册页2注册页，不填写必填项（姓名、手机号、性别、生日、地址），点击【提交】按钮提示：请完整填写信息3注册页，输入不符合规范的手机号，如：123，点击【提交】提示：手机号输入不正确，请重新填写4点击【立即授权手机号】跳转至授权页面5在手机号授权页，点击【允许】手机号自动填写，无需再填写验证码（验证码一栏消失）6在手机号授权页，点击【拒绝】需手动输入手机号及验证码7输入不正确的手机号：13234a提示：请输入正确的手机号码8不输入手机号，点击【获取验证码】提示：请输入正确的手机号码9输入手机号，点击验证码手机端收取到验证码10输入错误的验证码提示：验证码不正确，请核对后重新输入11未勾选隐私条款，点击【提交】提示：请先阅读隐私条款并勾选12选择生日，点击【提交】不可选择小于当天的日期13输入正确的相关信息，点击【提交】1.进入会员中心

2.同时查看数据库中的用户表新增一条数据，数据与操作时注册的数据相同14已注册用户，进入小程序直接进入会员中心表会员注册测试用例5.2.1积分兑礼根据积分商城的需求可画出积分商城的流程逻辑，如图5.2.1所示，用户在积分商城进行积分兑换，如用户积分充足且礼品库存充足，即可兑换成功，同时数据库查看是否减去了所兑换数量的礼品库存，我的礼遇模块相应新增一条兑换记录，可至线下门店扫码领取；如用户积分不足，即提示兑换失败；如用户积分充足但礼品库存不足，即提示兑换失败。按照此逻辑思路可设计出积分兑礼模块的测试用例，如表所示。图5.2.1积分兑礼流程图测试模块用例编号操作步骤预期结果实际结果积分兑礼15用户积分充足且礼品库存充足兑换成功，兑换礼品库存相应扣除

2.我的礼遇模块同时记录相关兑换数据，状态为：已兑换未领取3.积分相应更新16用户积分充足且礼品库存不足提示兑换失败17用户积分不足提示兑换失败18在我的礼遇中，点击相关兑礼记录，进入详情页面，点击【立即领取】调用手机摄像头，扫描品牌门店二维码随后领取成功19扫非品牌门店二维码领取提示：领取失败表积分兑礼测试用例5.2.3品牌活动品牌活动模块主要是展示品牌方的相关活动，主要是静态页面，展示活动内容，吸引用户线下参与。故此部分仅做兼容性测试，测试过程中，分别查看iPhonex、华为p30、OPPOfind等市面上较普遍的手机，需均能完整且无误的显示。5.2.4测试用例评审测试用例评审是进行测试前一个重要的部分，由测试人员编写完成测试用例，测试用例评审是一个必要的阶段，它集齐了项目各个身份的人的思想，统一正确需求认知，集思广益，提高测试覆盖率。本文所编写的测试用例是经已评审并修改后的最终版。6测试报告经过前期充分的准备，按照测试计划，执行测试用例，提出系统中的缺陷至开发人员，跟踪缺陷，直至缺陷修复完成且无误。按时完成测试任务，用例执行率100%，测试通过率100%，符合项目上线要求。7验收测试及上线经测试，需求功能实现率为100%，测试为覆盖率100%，符合项目上线要求。提至公司团队中不了解该系统的人员当做用户来进行验收测试，在验收测试过程中，用户提出了一些建议性的优化，经项目团队评估后修改完成，部署正式环境，如期上线。上线后项目团队及时跟进相应的系统维护。8测试用例的复用性及意义随着互联网的高速发展，微信的普及，品牌方可借助社交媒体的各方面优点及微信平台的社交策略，设立基于微信平台的会员中心系统，充分发挥微信公众号及小程序的运营优势，实现品牌与用户实时互动，增加信息的及时性与准确性，对用户展开精准营销，提高用户对品牌的好感度，同时也为品牌方带来更好的口碑，促进销量。现在越来越多的品牌方都考虑在微信平台上设立会员中心系统，据了解，品牌在营销方面上的大方向是不变的，所以基于微信平台的会员中心小程序的系统的开发与测试巨有很大的复用性。在测试过程中，测试用例是基础，分析不同品牌方的背景需求，提取可共用的测试用例部分，加快测试进度，提高效率，保障产品质量。8.1复用测试用例维度分析建立高效实用的可复用测试用例，可从三个维度分析思考：1.时间维度：参考以前的类似软件程序的测试用例作为基础，可作为用例基础模板及回归测试时的复用。可为新的类似程序中为其编写通用部分测试用例以及根据其需求添加个性化的测试点。2.通用维度：以相同平台为基础的软件或类似逻辑性的软件，其测试用例可以复用。3.应用角度：以某类型的系统构建基础的测试用例，在同一领域不同应用系统中的测试过程中可以复用。8.2可复用测试用例的建立与意义分析被测软件的业务逻辑、软件运行平台、测试需求、测试类型等，提取测试点并一一列出，查看待测项目与测试用例的复用库有无相近的测试用例，如有，依据待测项目的需求，进一步将该测试用例具体化，形成完整的测试用例。对于做一种领域的软件系统的公司来说，建立测试用例的复用库有重大的意义。可以大大缩短软件测试的周期，提高软件测试的效率，提高软件测试质量的可靠性，从而确保产品质量。9总结本文结合了当代互联网背景与微信平台的营销模式下设计了会员中心小程序测试用例与测试方法。分析品牌的背景与需求，结合软件测试的目的和原则，运用软件测试的各种测试方法，设计测试方案。高效的编写了与需求相符的测试用例，项目组成员评估后完善测试用例，准确高效的对系统进行测试，提出缺陷，并跟踪缺陷直至缺陷关闭。测试完成后，对测试工作进行总结与评估，协助用户进行验收测试，项目顺利上线。对测试用例的复用性浅谈了自己些许理解，从对产品投入的时间成本和产品质量角度来说，建立测试用例复用库，且运用在项目中有不可小觑的重要作用。致谢在我的论文编写完成之际，首先我由衷的感谢我的论文指导老师李爱民老师，从对我的论文选题、主体思路、论文设计及内容等各方面予以悉心的指导与帮助。在这一过程中，让我感受到了李爱民老师的博学多识、严谨的治学风范和诲人不倦的师长风格让我受益匪浅，李老师永远是我学习榜样，老师的精神将一直激励我在工作岗位上与学习方面不断进取。然后，感谢工作中的同事对我的帮助，在编写论文过程中，与同事的不断交流，更深层次的理解到了知识运用到实践中的真谛，顺利的完成了论文的编写。此外，我要感谢我所引用和转载的文献的学者，给予我启发和引导，让我更加深入的领悟到软件测试的真谛与魅力。最后，感谢西安交通大学给予我学习提升与深造的机会，同时，向各位评审老师为评阅本文付出的辛勤劳动表示由衷的感谢！参考文献软件测试技术的研究进展[J].刘继华,陈策.

微计算机信息.

2012(10)侯兴云.基于微信的企业营销模式创新研究[D].暨南大学,2015.三元.成功软件测试管理的九大原则.测试员[EB/OL].2004.3.33.郁莲.软件测试方法与实践[M].清华大学出版.2008Aken.有关黑盒测试、白盒测试和灰盒测试的基本概念.