SCI论文（www.lunwensci.com）:
摘要：现有的移动应用开发模式为产品经理确定功能需求后,研发人员按照需求文档进行项目开发。测试人员在开发完成后根据用例测试应用是否满足功能需求。该模式下,产品经理、研发人员和测试人员对应用需求的理解以各自视角为基准。研发人员在模块开发时只有通用的代码规范标准,而无与具体功能需求相关联的约束,导致代码实现上功能划分不合理、接口职责不单一以及数据和状态组织不明确等问题。由此,本文提出了一种基于行为描述的移动应用开发模式。行为的发生可以用指定状态下特定数据值(或多个值的组合)来表示,即利用数据和状态描述行为。实践表明,本文提出的移动应用开发方法灵活、高效、扩展性强,具有较高实际应用价值。
关键词：行为描述；软件开发；开发模式；移动应用；单元测试
Behavior Description Development Method for Mobile Applications
JIN Xiaojun1,ZHAO Hua1,CHEN Yong2,YU Jialin3,4
(1.Shanghai SAIC Mobility Technology and Service Co.,Ltd.-Nanjing Branch,Nanjing Jiangsu 210037;2.College of Mechanical and Electronic Engineering,Nanjing Forestry University,Nanjing Jiangsu 210037;3.Peking University Institute of Advanced Agricultural Sciences,Weifang Shandong 261325;4.Department of Soil and Crop Sciences,Texas A&M University,College Station Texas 77843)
【Abstract】：In the existing mobile application development model,after the product manager determines the functional requirements,the R&D personnel carry out project development according to the requirements document.Testers test whether the application meets the functional requirements according to the use case after the development is completed.In this mode,product managers,R&D personnel,and testers take their own perspectives as the benchmark for their understanding of application requirements.When developing modules,developers only have general code specification standards without constraints associated with specific functional requirements,resulting in unreasonable functional division in code implementation,non-single interface responsibilities,and unclear data and state organization.Therefore,this paper proposes a mobile application development model based on behavior description.The occurrence of behavior can be represented by a specific data value(or combination of multiple values)in a specified state,that is,the behavior is described by data and state.Practice shows that the mobile application development method proposed in this paper isflexible,efficient,and highly scalable,and has high practical application value.
【Key words】：behavior description;software development;development mode;mobile applications;unit test
0引言
随着移动互联网的迅速发展,移动应用在日常生活中占据着及其重要的位置。同时,为了满足用户的多元化需求,移动应用通常需要快速的迭代和更新[1]。现有的移动应用开发模式为产品经理确定功能需求后,研发人员按照需求文档进行项目开发。测试人员在开发完成后根据用例测试应用是否满足功能需求[2]。该模式下,产品经理、研发人员和测试人员对应用需求的理解以各自视角为基准。研发人员在模块开发时只有通用的代码规范标准,而没有具体功能需求相关联的约束,导致代码实现上功能划分不合理、接口职责不单一以及数据和状态组织不明确[3]。另外,还存在研发人员编写的代码的可测试性和可测试的角度与测试人员难以保持一致、需要额外编码实现埋点需求和编写各个模块的单元测试代码等问题[4,5]。
为解决现有开发模式存在的不足,本文提出了一种基于行为描述的移动应用开发模式。行为的发生可以用指定状态下特定数据值(或多个值的组合)来表示,即利用数据和状态描述行为。功能行为或用户交互的发生会导致应用数据和状态的变化。比如用户点击按钮,UI方面会有对应的页面切换或页面布局的变化；数据方面会有诸如网络请求的触发,继而发生数据的更新。实际上,页面的变化也是数据(导航栈或页面层级栈的内容)的变化。简而言之,应用的功能或者用户的交互都可以用行为的发生来描述,而所有行为的发生都可以用指定状态下特定数据值(或多个值的组合)来表示,即利用数据和状态来描述行为。
1行为描述
行为描述的总体思想为：(1)总能将用户的操作或功能行为的发生用某个(些)状态和数据值的变化来表示；(2)状态和数据具有唯一性,可以做为描述功能需求或行为的统一标准。以产品经理,研发人员和测试人员约定的数据值和状态来描述功能和行为,可以使各角色对需求理解的认知保持一致。研发人员的开发过程由应用的功能行为进行驱动,编写的代码功能独立,职责分离,且代码具有高可测试性和低耦合性。同时,研发人员可以根据约定好的数据和状态配置单元测试用例,以此来对各接口和功能进行验证,而无需再额外编写单元测试。研发人员功能开发过程中,产品经理即可根据约定的数据和状态配置埋点信息,无需等待功能开发完成。进一步的,产品上线后,可根据行为描述配置应用的功能期望,以此主动发现并快速定位线上问题。根据行为描述,可以将功能描述,代码实现,埋点,单元测试以及远程诊断作为一整个链条串通起来,且该模式完全符合行为驱动开发(Behavior-Driven Development,BDD)的开发模式。除此之外,数据和状态的组合可以自然形成语义化的描述过程。
2数据
数据包括[数据名称],[数据变量名],[数据值名称]和[数据变量值]。[数据名称]和[数据值名称]为研发人员和产品经理,测试人员约定的数据描述,[数据变量名]和[数据变量值]则为其对应的代码中与之绑定的变量名和变量值(即研发人员在编码时需要按照约定定义相关的变量属性),如表1所示。
如此,即可用这些数据来描述应用行为的发生。比如,当[订单类型]变化成了[预约单]即代表发生了下单行为；当[订单状态]变化成了[已完成]表示行程的行为已结束。进一步地,产品经理可以用其来配置埋点,当[订单状态]为[已完成]时记录埋点值[order_finished],对应的移动客户端在运行时检测[orderStatus]变量的变化,当变量值发生变化且值等于[3]的时候,记录埋点[order_finished]。
3状态
状态是指功能行为发生的过程(包括起始和结束),分为通用状态和业务状态。通用状态包括[控件交互状态],[页面交互状态]和[视图交互状态]。[控件交互状态]为用户的具体操作行为,包括[点击事件],[长按手势],[拖动手势]和[滑动手势]。结合页面中控件元素的唯一标识,我们可以判断哪个控件发生了交互行为,以及行为对应的事件类型。组合控件交互状态和相关数据可以用于埋点和单元测试用例的配置,简单的示例:在下单页面是有4个按钮,分别为预约单下单,包车单下单,接机单下单和送机单下单。此场景下需要提供的状态为[控件交互状态]-[点击事件],数据为[当前选中订单类型]。如此,埋点配置为当[控件交互]-[点击事件]状态发生时,若[当前选中订单类型]的数据值为[预约单],则记录埋点[click_reserve_ order_button]。配置单元测试用例则为当[控件交互]-[点击事件]状态发生时,若发生交互的控件为预约单按钮,则[当前选中订单类型]的数据值应该为[预约单]。对应的移动客户端的实施逻辑为HOOK控件的各类事件响应方法,当事件的响应方法被触发即代表用户进行了交互操作行为,在该状态下对相关变量值进行判断和匹配,从而实现埋点和测试用例的处理。
[页面交互状态]为应用页面发生的跳转,即页面状态的变化。移动客户端可以通过监控系统导航栈来追踪页面的交互状态,当导航栈新增页面时表示应用跳转到新的页面,反之,则为离开当前页面。页面交互状态主要用于PV类型埋点的配置,比如示例:当用户进入订单详情页时记录埋点值,客户端在导航栈发生变化即页面发生跳转的时候检测当前页面是否是[订单详情页],若是,则记录埋点值。在这个情况下,产品经理在MIS端配置埋点的流程为当[页面交互]-[页面进入]状态发生时,记录埋点值[view_order_detail_ page]。
[视图交互状态]为当前页面或窗口的子视图状态的变化,包括[普通视图]和[弹窗]两种,[普通视图]为当前页面上添加或展现的视图；[弹窗]为窗口上添加或展现的视图。在设置视图交互状态时需指定视图的唯一标识符。通常以视图的类名做为标识,但对于非自定义的视图(比如系统默认弹窗视图),不同的弹窗其类名是相同的,这种场景下标识符取类名加弹窗上的标题文本(若类名相同标题亦相同则认为是同一个视图)。根据视图交互状态可以配置埋点,比如在发生[视图交互]-[普通视图]状态时,当[视图名称]为[计费详情视图]时,记录埋点值[click_price_detail_view]。需要注意的是,此处的[计费详情视图]也属于数据,需要由研发人员事先绑定变量后提供给产品经理。[计费详情视图]会绑定标识名称,即类名[PriceDetailView]。除此之外,还可配置简单的视图展现的单元测试用例,比如点击[计费详情视图按钮]后,视图交互状态中的[视图名称]应为[计费详情视图]。
业务状态以方法或函数为单位,即某个指定的方法执行即代表业务状态的发生,包括开始执行(行为发生)和结束执行(行为结束)。比如在下单页面,产品经理和测试人员需要描述用户[请求行程预估价格]这个行为,也就是研发人员需要单独实现这个接口,即在下单页面对应的类里面,需要有[请求行程预估价格]这个方法,其职责就是用来请求预估价格,当该方法执行时表示发生了请求预估价格这个行为,方法执行结束代表行为结束,并返回执行结果描述行为的最终状态。具体步骤为,首先由研发人员将[请求行程预估价格]与类中的方法[requestEstimatePrice()]进行绑定,并对其实施HOOK操作,当方法执行时注入埋点或单元测试用例逻辑处理的代码。由此,产品经理即可用以配置埋点,当[业务状态]-[请求行程预估价格]-[开始]发生时,记录埋点值[request_estimate_price]。当[业务状态]-[请求行程预估价格]-[结束]时,若[返回值]为[失败],则记录埋点值[request_estimate_price_failed]。
4实施流程
以页面为单位,产品经理和研发人员,测试人员对功能行为进行拆解,分割出描述功能需求所需要的数据以及状态。在MIS端对数据和状态进行配置(研发人员对数据和状态进行绑定,并提供给产品人员和测试人员用以配置埋点和测试用例)。根据配置的数据和状态自动生成和导出当前页面对应类的模板代码文件(包含数据变量名和状态对应函数名的定义)。产品经理在MIS系统内对相应数据和状态进行选择(或组合)以配置埋点。研发人员和测试人员一起根据数据和状态配置单元测试用例(单元测试为白盒测试,测试人员的测试一般为黑盒测试。在该模式下,测试人员和研发人员一起根据行为链路中的状态来配置单元测试用例,可以使测试人员了解黑盒中的实现细节,并且使两者的测试视角保持一致)。研发人员对模板代码中的数据进行赋值操作,对模板函数中的内容进行编码实现。下发单元测试用例到客户端,验证研发人员对模板代码中的数据和函数的实现是否正确及符合预期的行为描述。下发埋点配置信息至客户端,自动完成埋点功能。对于用户反馈的偶现的问题,研发人员根据行为描述配置状态和数据的预期作为问题诊断的用例。检测用例执行时的数据和状态以定位线上问题。行为描述开发流程示意图如图1所示。
远程诊断是提供给研发人员进行问题调试的工具,产品上线后,可根据行为描述配置应用的功能期望,以此来主动发现线上问题,并在问题发生时上传指定的环境数据值来帮助研发人员快速定位问题。比如,账号登录点击下一步按钮后,只有两种预期的行为结果,一个是提示手机号格式不对,一个是弹出输入验证码的页面,如果发生了这两种结果之外的情形,即可判断当前应用功能出错。对应数据和状态的配置为进入[点击下一步]状态,若状态[结束]时,[显示校验失败提示]的状态没有执行过,且[页面交互]状态未发生变化,则应用功能出错。此时,上报[区号],[手机号],[同意服务条款]的值和业务状态[校验手机号]的返回值。
5结语
本文提出了一种基于行为描述的移动应用开发模式。行为描述的基本思想为总能将用户的操作或功能行为的发生用某个(些)状态和数据值的变化来表示；且状态和数据具有唯一性,可以做为描述功能需求或行为的统一标准。因而,行为的发生可以用指定状态下特定数据值(或多个值的组合)来表示,即利用数据和状态描述行为。按照该模式进行移动应用开发有如下优势：以产品经理,研发人员和测试人员约定的数据值和状态来描述功能和行为,可以使各角色对需求理解的认知保持一致；研发人员的开发过程由应用的功能行为进行驱动,编写的代码功能独立,职责分离,且代码具有高可测试性和低耦合性；研发人员可以根据约定好的数据和状态配置单元测试用例,以此来对各接口和功能进行验证,而无需再额外编写单元测试；研发人员功能开发过程中,产品经理即可根据约定的数据和状态配置埋点信息,无需等待功能开发完成；产品上线后,可根据行为描述配置应用的功能期望,以此主动发现并快速定位线上问题。实践表明,本文提出的移动应用开发方法灵活、高效、扩展性强,具有较高实际应用价值。
参考文献
[1]赵晓丹,陶然.四种移动应用开发模式比较与分析[J].智能计算机与应用,2018,8(1):72-75.
[2]罗勇,赵晓霞.浅析混合移动应用开发模式[J].中国设备工程,2018(4):173-174.
[3]詹丽红.混合移动应用开发模式的新策略[J].中国新通信,2019,21(9):109.
[4]杜帅,鄂海红,许可.混合移动应用开发模式的新策略[J].软件,2015,36(6):12-17.
[5]高向玉.移动应用开发模式探讨[J].智库时代,2018(43):184-186.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！
文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/41900.html
