赞
踩
1)软件未实现产品说明书要求的功能
2)软件出现了产品说明书指明不应该出现的错误
3)软件实现了产品说明书未提到的功能
4)软件未实现产品说明书虽未明确提及但应该实现的目标
5)软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。
为了发现软件产品中的各种缺陷,而对软件产品进行验证和确认的活动过程,此过程贯穿整个软件开发生命周期。 简单的说,软件测试是以发现错误为目的而执行的一个程序或系统的过程。
仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢? 由于载体不一样,所以系统测试和一些细节可能会不一样。 那么我们就要先来了解,web和app的区别。
web项目,一般都是b/s架构,基于浏览器的,而app则是c/s的,必须要有客户端。那么在系统测试测试的时候就会产生区别了。
首先从系统架构来看的话,web测试只要更新了服务器端,客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的,除非用户更新客户端。如果是app下修改了服务端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
接着是性能方面,web页面可能只会关注响应时间,而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别,这里就不谈。
相比较web测试,app更是多了一些专项测试:
一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断,来电,短信,关机,重启等。
而弱网测试是app测试中必须执行的一项测试。
包含弱网和网络切换测试。
需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。
需要测试丢包,延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过,这里不再讲了。
web测试是基于浏览器的所以不必考虑这些。而app是客户端的,则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。
包括安装时的中断、弱网、安装后删除安装文件,更新的强制更新与非强制更新、增量包更新、断点续传、弱网,卸载后删除app相关的文件等等。 就自动化来讲,web大多用的selenium、webdriver,而app则是appium。
性能使用的工具web则是LR,app使用Jmeter要多一点
缺陷的概要描述要清晰准确,要使相关开发负责人员能够一目了然问题是什么。
一个完整的缺陷报告单,必须包含其必要的元素信息, 例如:概要描述,缺陷发现人,测试环境,浏览器,缺陷重现步骤,严重等级,指派人,所属功能模块等等,必要元素信息必须描述全面清楚。
缺陷的重现步骤必须描写清晰明了,使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷,使其定位缺陷的原因所在。
测试数据,测试的数据作为重现缺陷的一个重要元素信息,一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
附件截图信息,附件或截图信息能让开发人员能够一目了然的清楚问题的所在。
原文地址:www.51testing.com/html/04/n-3…
1、链接测试
链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。
链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。
例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。
如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。 另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。
例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
3、压力测试
负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。
1、导航测试
导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。
通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? 在一个页面上放太多的信息往往起到与预期相反的效果。
Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。 Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
2、图形测试
在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
图形测试的内容有:
(1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
(2)验证所有页面字体的风格是否一致。
(3)背景颜色应该与字体颜色和前景颜色相搭配。
(4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。
这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的拼音与语法检查功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓相关文章列表。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。
例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致? 对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
1、平台测试
市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。
这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。 因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。
例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,JavaScript是Netscape的产品,Java是Sun的产品等等。
另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。
在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
Web应用系统的安全性测试区域主要有:
(1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
(2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
(3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
(4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
(5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
1)按照是否执行被测试软件来分:
静态测试:是指不运行软件,测试包括代码检查、静态结构分析、代码质量度量等,主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。
动态测试:指通过运行被测程序,检查运行结果与预期结果的差异,分析差异原因,并分析软件运行效率、健壮性等性能。 动态测试是目前公司主要的测试方式
2)按照测试技术分为黑盒测试和白盒测试:
黑盒测试:黑盒测试又叫功能测试或数据驱动测试,在完全不考虑程序内部结构和内部特性的情况下,通过软件的外部表现来发现其缺陷和错误。
白盒测试:白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构进行测试程序,通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
3)按照测试手段来分,可以分为手工测试和自动化测试
4)按照过程阶段来分,可以分为单元测试、集成测试、系统测试和验收测试
单元测试:通过模块(类/方法/函数)测试,使代码达到设计要求 主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。
集成测试:将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题,各模块功能之间是否有影响。
系统测试:是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。 系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方 ,进行改正。
验收测试:验收测试是在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的最后一次软件测试活动,也称为交付测试。 通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。
计划-》需求分析-》设计-》程序编写-》测试-》运行/维护
测试计划-》需求分析-》测试用例-》测试用例执行-》提交bug-》回归测试
V模型:反映了测试与开发阶段之间一一对应的特点,测试在开发之后,出错后回归测试量大。
W模型:测试伴随整个开发周期,测试与开发同步进行,有利于尽早发现问题
H模型:软件测试活动完全独立,与其他流程并行。
白盒测试方法有 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
测试分为白盒测试和黑盒测试,回答时,要注意分开说。白盒测试用例设计有如下方法:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。依据就是代码结构。
黑盒测试用例设计方法:基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。依据是用户需求规格说明书,详细设计说明书。
一个好的测试工程师,不仅要基础扎实,对自身的性格、责任心都有非常高的要求。
具体如下:
(1)掌握基本的测试基础理论
(2)本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现
(3)可熟练阅读需求规格说明书等文档
(4)以用户的观点看待问题
(5)有着强烈的质量意识
(6)细心和责任心
(7)良好的有效的沟通方式(与开发人员及客户)
(8)具有以往的测试经验
(9)能够及时准确地判断出高危险区在何处.
大致说四点即可,当然说全更好。
集成测试有十种策略:
(1)大爆炸集成
(2)自顶向下集成
(3)自底向上集成
(4)三明治集成
(5)分层集成
(6)基干集成
(7)基于功能的集成
(8)基于消息的集成
(9)基于风险的集成
(10)基于进度的集成.
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。
兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。
兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般都能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了。
1、检查系统是否有中毒的特征;
2、检查软件/硬件的配置是否符合软件的推荐标准;
3、确认当前的系统是否是独立,即没有对外提供什么消耗CPU资源的服务;
4、如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的;
5、在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况。
黑盒/白盒,静态/动态,手工/自动,冒烟测试,回归测试,公测(Beta测试的策略)
用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;
对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;
具体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。
在Bugzilla中,Bug报告状态分为以下几种状态,
arduino
复制代码
待确认的 unconfirmed 新提交的 new 已分配的 assigned 问题未解决的 reopened 待返测的 resolved 待归档的 verified 已归档的 closed
Bug处理意见(Resolution)
csharp
复制代码
已修改的 fixed 不是问题 nvalid 无法修改 wontfix 以后版本解决 later 保留 remind 重复 duplicate 无法重现 workforme
界面不稳定;
根据需要配置它的不同的部分,过程很烦琐。
流程控制上,安全性不好界定,很容易对他人的Bug进行误操作;
没有综合的评分指标,不好确认修复的优先级别。
需求分析 + 需求变更的维护工作;
根据需求 得出测试需求;
设计测试方案,评审测试方案;
方案评审通过后,设计测试用例,再对测试用例进行评审;
单元的常见错误一般出现在以下五个方面,因此这五个方面是单元测试应该关注的重点。
1、单元接口。
2、局部数据结构。
3、独立路径。
4、出错处理。
5、边界条件
在单元测试时,由于单元本身不是一个独立的程序,一个完整的可运行的软件系统并没有构成,所以需要设置一些辅助测试单元,辅助测试单元有两种,一种是驱动单元,另外一种是桩单元。
1、驱动单元(Driver):用来模拟被测单元的上层单元,相当于被测函数的主函数,如main函数。所以驱动单元主要完成以下4个步骤:
(1)接受测试数据,包含测试用例输入和预期输出;
(2)把测试用例输入传送给被测单元,驱动被测单元测试;
(3)将被测单元的实际输出和预期输出进行比较,得到测试结果;
(4)将测试结果输出到指定位置。
2、桩单元(Stub):用来代替被测单元工作过程中调用的子单元。
桩单元模拟的单元可能是自定义函数:这些自定义函数可能尚未编写完成,为了测试被测单元,需要构造桩单元来代替它们,可能存在错误,会影响测试结果,所以需要构造正确无误的桩单元来达到隔离的目的。
驱动单元和桩单元都是额外的开销,虽然在单元测试的时候必须写,但是并不需要作为最终的产品提供给客户。
一般的单元执行策略有三种:孤立的单元测试策略(Isolation Unit Testing),自顶向下的单元测试策略(Top Down Unit Testing)和自底向上的单元测试策略(Bottom Up Unit Testing)。
需要注意的是:在集成测试中也有自顶向下和自底向上的测试策略,但是测试对象不同。
1、孤立的单元测试策略(Isolation Unit Testing)
方法:不考虑每个模块与其它模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试。
优点:这个方法比较简单,最容易操作,可以达到很高的结构覆盖率,可以并行开展,该方法是纯粹的单元测试。
缺点:桩函数和驱动函数工作量很大,效率低。
2、自顶向下的单元测试策略(Top Down Unit Testing)
方法:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块,其次对第二层进行测试,使用上面已经测试过的单元做驱动模块,以此类推,直到测试完所有模块。
优点:可以节省驱动函数的开发工作,效率高。
缺点:随着被测单元一个一个被加入,测试过程将变得越来越复杂,并且开发和维护的成本将增加。
3、自底向上的单元测试策略(Bottom Up Unit Testing)
方法:先对最底层的模块进行单元测试,将模拟调用该模块的模块设置为驱动模块,然后再对上面一层做单元测试,用下面已经测试好的模块做桩模块,以此类推,直到测试完所有模块。
优点:可以节省桩函数的开发工作量,测试效率较高。
缺点:不是纯粹的单元测试,底层函数的测试质量对上层函数的测试将产生很大影响。
脚本生成器;
场景控制器;
结果分析器。
1、 测试设计
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行场景
5、 监视场景
6、 分析测试的结果
以上,最好是结合一个案例,根据以上流程来介绍。
在同一时间点,支持多个不同的操作。
LoadRunner中提供IP伪装,集合点,配合虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。
集合点,即是多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。集合点失败,则集合点的操作就会取消,测试就不能进行。
需求管理
n 定义测试范围
n 定义需求树
n 描述需求树的功能点
测试计划
n 定义测试目标和测试策略。
n 分解应用程序,建立测试计划树。
n 确定每个功能点的测试方法。
n 将每个功能点连接到需求上,使测试计划覆盖全部的测试需求。
n 描述手工测试的测试步骤
n 指明需要进行自动测试的功能点
测试执行
n 定义测试集合。
n 为每个测试人员制定测试任务和测试日程安排。
n 运行自动测试。
缺陷跟踪
n 记录缺陷
n 查看新增缺陷,并确定哪些是需要修正的
n 相关技术人员修改缺陷
n 回归测试
n 分析缺陷统计图表,分析应用程序的开发质量。
Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Functional testing (功能测试),也称为behavioral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。 本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。
Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
自动化测试相关教程推荐:
2023最新自动化测试自学教程新手小白26天入门最详细教程,目前已有300多人通过学习这套教程入职大厂!!_哔哩哔哩_bilibili
2023最新合集Python自动化测试开发框架【全栈/实战/教程】合集精华,学完年薪40W+_哔哩哔哩_bilibili
测试开发相关教程推荐
2023全网最牛,字节测试开发大佬现场教学,从零开始教你成为年薪百万的测试开发工程师_哔哩哔哩_bilibili
postman/jmeter/fiddler测试工具类教程推荐
讲的最详细JMeter接口测试/接口自动化测试项目实战合集教程,学jmeter接口测试一套教程就够了!!_哔哩哔哩_bilibili
2023自学fiddler抓包,请一定要看完【如何1天学会fiddler抓包】的全网最详细视频教程!!_哔哩哔哩_bilibili
2023全网封神,B站讲的最详细的Postman接口测试实战教学,小白都能学会_哔哩哔哩_bilibili
如果对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。
如有不懂还要咨询下方小卡片,博主也希望和志同道合的测试人员一起学习进步
在适当的年龄,选择适当的岗位,尽量去发挥好自己的优势。
我的自动化测试开发之路,一路走来都离不每个阶段的计划,因为自己喜欢规划和总结,
测试开发视频教程、学习笔记领取传送门!!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。