-
Tomcat ssl安全证书配置
2009-07-12 21:26:12
话说第一次配置tomcat SSL，还真折腾了我一些时间！其实整个过程不是很复杂，要特别注意一些地方就是了！步骤如下：1）生成生成KeyPair： 在命令行模式下切换到目录%TOMCAT_HOME%，在command命令行输入如下命令（jdk1.4以上带的工具）：
keytool -genkey -alias tomcat -keyalg RSA -keypass password -storepass password -keystore name.keystore -validity 3600
其中，keytool是java命令，特别注意storepass与ketystore的值，会在tomcat 配置中用到！此外，特别注意。。。输入这个命令后，它会要求你输入一些信息，第一个信息是姓名，那个必须是使用localhost或者你所拥有的域名，最好使用域名，这个错了就会导致整个配置失败，其它信息可不输入。2）将证书导入的JDK的证书信任库中:这步对于Tomcat的SSL配置不是必须，但对于CAS SSO是必须的，否则会出现如下错误：edu.yale.its.tp.cas. client.CASAuthenticationException: Unable to validate ProxyTicketValidator。。。导入过程分2步，第一步是导出证书，第二步是导入到证书信任库，命令如下：
keytool -export -trustcacerts -alias tomcat -file server.cer -keystore server.keystore -storepass password
keytool -import -trustcacerts -alias tomcat -file server.cer -keystore %JAVA_HOME%/jre/lib/security/cacerts -storepass password
如果有提示，输入Y就可以了。这里有些地方要注意下：1》将证书导入JDK证书信任库时注意参数-keystore是JDK中的JRE即是%JAVA_HOME%/jre/lib/security/ cacerts，而且注意JDK不能放在有空格的目录中，否则会导不进去，切记！2》import 到JDK那个storepass有时候要用默认的即是changeit，至于为什么还不清楚。3）然后就是配置tomcat:配置你的Tomcat服务器配置文件%CATALINA_HOME %/conf/server.xml,不同版本会有点不一样，参考如下：xml 代码
1.
2.<Connector port="8443" maxHttpHeaderSize="8192"
1. maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
2. enableLookups="false" disableUploadTimeout="true"
3. acceptCount="100" scheme="https" secure="true"
4. clientAuth="false" sslProtocol="TLS"
5. keystoreFile="server.keystore"
6. keystorePass="password"/>
Tomcat5.5.20配置(此配置同样可用于Tomcat6.0)：
xml 代码
1.
2.<Connector protocol="org.apache.coyote.http11.Http11Protocol"
1. port="8443" maxHttpHeaderSize="8192"
2. maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
3. enableLookups="false" disableUploadTimeout="true"
4. acceptCount="100" scheme="https" secure="true"
5. clientAuth="false" sslProtocol="TLS"
6. keystoreFile="server.keystore"
7. keystorePass="password"/>
Tomcat6.0.10配置：
xml 代码
1.<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
2. port="8443" minSpareThreads="5" maxSpareThreads="75"
3. enableLookups="true" disableUploadTimeout="true"
4. acceptCount="100" maxThreads="200"
5. scheme="https" secure="true" SSLEnabled="true"
6. clientAuth="false" sslProtocol="TLS"
7. keystoreFile="server.keystore"
8. keystorePass="password"/>这里要注意，如果本身已经启用SSL，要将之前关于SSL的注释掉，防冲突了。这里的前面两个设置没试过，后面那个设置是经过验证的。
步骤还是比较多，留意该注意的地方就是了！
-
Tomcat 内存设置
2009-07-12 21:26:12
这次发布测试的JAVA项目确实让我受了不少苦啊。当然也学习了。。呵呵这次发布的是个BOSS系统，由4个子系统构成，发布前开发部也没介绍说系统有多大，当然也是自己经验缺乏，没意识到4个子系统一个tomcat下面默认内存肯定是不够的。所以发布时没有修改tomcat默认内存设置，结果出错了：java.lang. OutOfMemoryError: PermGen space。自己很菜，只得网上搜索，原来是内存不够。那就设置了，综合了网上众多网友的方法还是不行，因为上面不少是转的，有些又没转全。汗。。。折腾了不少时间，所以写下保存下。PermGen space这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。既然内存不够那就加了！如果是通过%tomcat_home%\bin中的startup.bat脚本启动，则在环境变量中加上CATALINA_OPTS这个属性。即是编辑%tomcat_home%\bin下的catalina.bat, 在最前面加上set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=128M -XX:MaxNewSize=512m -XX:MaxPermSize=512m ，当然具体设置就要看实际情况了。 其中-Xms是指初始的大小，-Xmx是指最大值，以免多次加载，一般这两个设为同一个值即可。这是针对 windows 系统，如果是linux 即修改catalina.sh。另外，如果tomcat是作为系统服务启动的，以上设置则不灵了！因为作为系统服务的话，系统启动时调用的是 %tomcat_home%\bin\tomcat5w.exe，他读取注册表中的值,而不是catalina.bat的设置，因此需要修改注册表：解决办法:
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\Java\Options
原值为
-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"
-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-Xrs改为：-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"
-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-Xrs -Xms300m -Xmx350m
重起tomcat服务,设置生效。 这个是我转摘的，我没试验过，不过看上去应该没问题的。 -
Java 与空格
2009-07-12 21:26:12
上个星期接了个测试项目是java开发的，要搭建测试环境。原来那个服务器什么都没装，只得自己装了JDK啊，TOMCAT啊， mysql那些。原以为发布个JAVA 项目非常简单，结果一塌糊涂，而这就是空格惹的祸。以前装JDK都是装在默认路径中，觉得默认路径好点，他们自己开发的东西知怎么也清楚过别人啊。呵呵。。。这次也不例外，结果着道了。这个项目的登录支持SSL协议，所以要导入安全证书到JDK的证书信任库中，结果导了大半天就是不行！汗。。。只得请教我们系统架构师，高手就是高手啊，他说JAVA 的东西不要放在目录名有空格的目录中。结果换了个目录，搞掂！但还是觉得没那么严重吧，人家自己默认路径也有空格！这个次可能碰巧吧！然后就是部署系统了，这个系统是利于CAS做单点登录（SSO）的，结果启动TOMCAT后那个CAS就是启动不了，怎么也想不明白，只得请教开发人员了。开发人员一看也懵了，这里改下那里改下还是不行。汗。。。又折腾了半个下午。最后我自己上网搜索下，终于看到了有些网友相同的遭遇。又是空格啊。。。我将TOMCAT放在目录名有空格的目录下。一个悔字啊。。。不听老人言，吃亏在眼前啊！同志们！JAVA的东西尽量不要放在目录名带空格的目录下啊。。。切记！ -
验收测试（UAT）
2009-05-31 22:58:45
按照软件开发阶段来划分测试可以分为单元测试，集成测试，系统测试，确认测试与验收测试。其中，验收测试是部署软件之前的最后一个测试操作。验收测试是按照任务书或合同或其它验收依据进行的整个系统的测试与评审，决定是否接收或拒收系统。
事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。 α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。β版本在有些项目的持续相当长，如Google的Gmail至今持续了数年，普通认为是较为成熟和产品了，但它仍然是β版本。这是对产品质量的不懈追求还是系统开发策略则不得而知了。
曾在网上看到过关于α、β测试是不是属于验收测试的讨论，最张是各有各的说法。我倒较认同其中一种说法，其认为：施验收测试的常用策略有三种，它们分别是：正式验收，非正式验收或 Alpha 测试，Beta 测试，即α、β测试是验收测试的一种。我觉得狭义的验收测试就是在公司内部由测试人员（通常是测试负责人或主管）按照设计的测试用例进行的一种测试，是系统测试的延续。广义上的验收测试则包括狭义的验收测试，α测试与β测试。一般用户对象相对固定的则只进行狭义的验收测试或是由公司内部非测试开发人员进行的α测试，如果是用户对象广泛且不固定的则有必要进行β测试。 -
软件测试原则
2009-05-25 21:27:39
软件测试作为一门科学与艺术也有着自己的原则，《软件评测师教程》中总结归纳了七大测试原则，现在将其与本人的理解列如下：1> 所有的软件测试都应该追溯到用户需求。这是勿庸置疑的，软件的产生与目的就是为了满足用户的需求，作为软件开发工程中的一个工作流程的软件测试也是以用户需求为根据的。也可以说软件测试就是为了找出与用户需求不一致的地方，当然用户需求包括用户规定的需求与潜在需求。2> 应当把“尽早地和不断的进行软件测试”作为软件测试者的座右铭。这说得一点也不为过，软件测试本身就贯穿于软件开发的各个阶段中。而且软件测试也有自己的独立的工作流程，并不只是软件开发后期阶段的检验过程。要知道由于编程不正确产生的缺陷并不占多数，绝大部分是需求分析与设计方面产生的缺陷。而且越到后期修复缺陷的成本越高，所以应该尽早地，不断地进行软件测试。3>完全测试是不可能的，测试需要终止。由于软件的复杂性，一个适度规模的程序其测试路径的组合就近似天文数字，要进行穷举测试是不可能的。另外，这也是基于测试成本的考虑。所以要进行完全测试，在有限的资源条件下，找出所有缺陷以使软件趋于完美是不可能的。4>测试无法显示软件潜在的缺陷。软件测试的目的是尽量找出多的缺陷，对软件质量进行评估。因为穷尽测试的不可能，所以从理论上说软件缺陷总是存在的，也就不能显示 软件潜在的缺陷。5>充分注意测试中的群集现象。如是有测试经验的同行都会有此体会，在某一模块或功能点上的缺陷总是特别多，往往越挖越多，这就是群集现像，也是符合80/20原理的。这是可能由于模块设计得不好，或是功能点特别复杂，亦或是负责相关模块的开发人员水平问题等这些特殊个别原理造成了缺陷群集现像。所以实际测试过程中，我也应该利用这个原理以发现更多的缺陷。6>程序员应避免检查自己的程序。这主要是心理因素，一是思维定势，二是总是认为自己是对的心理。这也就是为什么会有测试与开发之分。不过由于也就引出了另外一个问题，我们测试人员编写的测试脚本又让谁来测试呢？虽然说一般来说测试脚本在逻辑上不如实体软件程序复杂，但也是会有不少错误的。有可能就是由于脚本设计的错误造成了错误的测试，很多缺陷被忽略。在这种情况下，如果有足够的时间与人力资源相互检测测试脚本不失为一个好方法，但实际工作中往往不允许有足够的资源。这时我们可以以免一个人分别负责一整个功能模块，交叉进行，分别调其它同事的脚本，在阅读与调用脚本时就可以看作是简单的脚本测试。7>尽量避免测试的随意性。测试应该从工程的角度去理解软件测试，它是有组织，有计划，有步骤的活动。这是无疑的，测试也是一个工程。但是不是就就随机测试也是应该避免的？不是。随机测试（Ad-hoc testing）并不是随意测试，它是基于系统的测试后根据人员的经验来猜测问题的所在而进行随机测试。往往很多时候，随机测试的作用是非常明示的。这就是教程中提到的七大软件测试原则，也是非常中肯实用的原则。这比哪些讨论什么是质量模型等到实际测试更有指导意义，所以我们测试中应该好好应用。 -
软件测试与软件质量保证
2009-05-25 21:27:39
通常在一般的中小企业中会不将软件测试与软件质量保证加以细分，软件测试人员也叫做质量保证人员即QA，我所在公司也是如此。其实软件测试与软件质量保证是软件质量工程的两人不同层面的工作。
质量保证（QA）是通过预防，检查与改进来保证软件质量的。QA所关注的是软件质量的检查和测量，他的工作是软件生命周期的管理以及验证软件是否满足质量和用户需求，主要着眼于软件开发活动中的过程、步骤和产物，而不对软件进行剖析找出问题。一般情况下，QA应独立于项目之外，以第三方的姿态来对整个开发过程进行评审，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。所以，质量保证是通过过程改进来保证软件质量的。
软件测试关注的不是过程活动，而是每个过程活动的产出物。它对活动的产物进行剖析，检测以期发现更多的问题，从而保证软件质量。所以软件测试是保证软件质量的一个重要环节，但不是质量保证的一个环节。
对软件测试与软件质量保证进行区分并不是闲聊而咬文嚼字，而是要知道他们都是为了保证软件质量的两个不同层面的工作，他们对保证软件质量有着不可替代的作用。但现实中大部分中小企业都只知道软件测试而没有专门的质量保证，即使有也是虚设，其实这是本末倒置。软件测试只是项目中的一个流程或是环节，只是对个别项目。所以个别项目如果取得成功，质量得到了很好的保证，可能是因为项目的个别因素，如项目需要做得较好或是测试人员水平较高等个别因素。所以一个项目做得好不能保证别的项目也做得好，即是公司的开发水平，产品的质量水平能够提高。这就需要通过质量保证来提取成功的因素而上升到流程规范上来规范所有项目，从而提高公司产品质量水平。一个公司的好的管理标准就是有个好的规章流程得以执行，所以一个好的项目管理，质量保证也在于规章流程，这些也是共性的东西，才不会以项目中的个别因素改变而改变。当然，也并不是说有好的质量保证就有好的产品质量，他们之间不是充分的关系，而是必要。
所以软件测试与软件质量保证是两个保证软件质量的重要手段，套些初中教科书上的话，他们的关系就是相互区别，相互联系，相互依存。 -
测试用例优先级
2009-01-30 22:44:18
Priority即是优先级,只要我们提到测试用例基本上都会涉及到,或许应该说是完整的测试用例的一个基本元素.但在现实应用中是否有对测试用例进行划分,是否真正有应用到?未必!相信大部分的同行都会对测试用例进行等级划分,但仍不少同行并未认识到其重要性而没有真正应用起来.
优先级,对此我是感慨良深.春节前一个外包项目测试全面展开,项目还是比较大的,有测试用例接近3000个.拿到最新的测试用例一看,一个汗啊...我负责的接近1200个,有10多个是优先级为3的即是传说中的P3,似乎没有P2的,有也就是30个左右,其余全是P1的.一个关于用户名(注册邮箱地址)的验证如长度,允许输入字符等都设置为P1.更汗的是距离春节放假就6天了,说要春节前完成所有非P3的用例(因为开发在美国,他们没假期...).期间还不只是执行用例还要首先跟踪BUG.当然结果是推迟完成日期,可能是小学数学老师找他们谈心然后恍然大悟吧.可惜他们数学老师只会计数,不知所谓的优先级.测试效果是可想而知了,我们测试员要完成不可能完成的任务,心理感受是可想而知,效果肯定也打折扣;而开发方面收到的BUG大部分是验证不够完善或是一些较为琐碎的问题,而严重的BUG后面才发掘出来,整个项目进度受到相当大的影响.
或许你会觉得我夸张了,如果不是亲身经历我也难以相信.这是一个十分失败的项目开发测试,而其中一个原因就是没有发挥优先级作用.在软件项目中,我们几乎没有足够的时间来做任何我们需要做的事情,特别是如果测试置于项目边缘的话就更不用谈了.相信同行刚接触测试时都应该听过80/20原理跟测试是不可能穷尽的,也正是因为这样,我们必须对测试用例进行优先级设置.只有对测试用例进行了优先级设置,并在执行测试时根据所处的测试生命周期跟项目进度的需要有所放矢的选择相应的测试用例进行测试,才能有更好的测试效果并保证整个项目的进度.
那测试用例应该有哪些级别呢?没有明确的答案,这要根据项目所处的生命周期跟进度来决定.通常情况下我觉得设置3级已经足够.P1: 即是确保系统基本功能及主要功能的测试用例;P2则是确保系统功能的完善方面的测试用例;P3则是关于用户体验,输入输出的验证及其它较少使用或辅助功能的测试用例.根据所搜集的资料各优先级所占全部测试用例比例通常如下: P130%-45%,P240%-60%, P310%-15%.
不少同行却总觉得不用测试用例一样测试,更不用谈用例优先级.这是非常错误的一个观点,省了那么点时间功夫换来的是更多的付出甚至是低劣的产品. 其实,对测试用例进行优先级的设置是最基本的,也是必须的.这并不是很需要技术或技巧的东西,但一旦很好地应用了它,却可收到丰厚的回报. 当然,对测试用例做了优先级的设置还必须能很方便地筛选出所要测试用例,能快速地筛选出某个模块,某个优先级的用例进行测试,这有赖于选择个好的测试管理工具. -
回归测试漫谈
2009-01-13 21:22:06
众所周知软件测试这个职业有一个为从业者不悦的一个特点就是有时特别烦琐,要经常做重复性的东西,相信同行或多或少都会有这个感慨,而罪魁祸首就是回归测试.如果每次测试的功能点都是新的,每次执行的测试用例都是未曾执行过的话,我相信同行都不会觉得厌烦反而很有兴致想看下新的功能是怎样的,执行起用例来也特认真.我也是如此,如果做久了一个项目特别是总是推迟发布的话每天就祈祷着当前项目快点了结.一接到新项目就有如获新生的感觉...确实回归测试次数多了,测试员不由变得烦躁起来,特别如果是回归测试策略又不妥当的话简直令人发疯....
我深受其害.进新公司近半年来还没有完全是自己负责的项目,除了花了一定的时间做自动化方面的东西外,其它的时间就是执行测试用例了,当然也就有大量的回归测试了.更郁闷的是没有相应的回归测试策略,而且不少测试用例已经不再适用了,数量又多(以前新功能测试的用例),我逐渐变得厌烦,然后是麻木,最后几近崩溃.一个汗啊...痛苦泥潭中的只好搜索相关资料并结合自己的实践,总结下如何更有效地做回归测试,让回归测试做得更有意义.
所谓回归测试就是当软件发生改变时,重新测试已经通过测试的测试区域,以验证修改的正确性及其影响.其实我们做测试的大部分工作也是在做回归测试,严格按照定义的话一旦软件作了修改就必须进行回归测试.我想对修改过后的软件要进行回归测试应该就是无可厚非的,无论是教科书上的介绍还是前人的经验总结都知道回归测试的必要性与重要性.那非要做回归测试,那样怎样才能做得更为有效有意义呢?显然这都需要从测试用例着手.
首先我们必须有个管理良好的测试用例库,这个用例库中的所有用例必须是有效的,有达到足够的覆盖率,并且是容易查找组织的.这需要有良好的测试管理工具,并有相应的资源(时间与人力)去维护这个测试用例库,务必使其中没有过时,冗余的测试用例,并达到一定的覆盖率.如何管理组织好测试用例已是一个很值得深入研究的课题,在此不再阐述(我也没有很好的见解..)总之,要做好回归测试,组织管理良好的测试用例库是前提.
有了测试用例库,那我做回归测试时就执行所有有效的测试用例?这个没有绝对的答案,在很多的时候如果你有足够的资源用全部测试用例来做回归测试是最佳选择. 但现实中呢?有足够资源这个理想状态比较少,并且有些时候也没有必要这样做.如果只是修改了某个警告对话框中的单词就要执行完所有测试例以确保其修改正确性及其影响?或许你会说只有疯子才会那么做,但事实上有时候我们正是那个疯子.基本上很多时候连开发自己都不敢肯定会不会影响到其它部分,所以我们就不得不扩大测试范围.那应该如何选择回归测试使用呢?前人已经总结了很多,主要是如下4种.
1>选择全部测试用例
选择测试用例库中的所有测试用例作为回归测试用例,这是一个较为保险的方法.在理想的状态下(有足够的资源,测试人员不知疲惫),这种方法绝对是首选.但理想与现实的差距是惨不忍赌的,测试资源缺乏是行内常情,特别是由于进度而导致测试时间极为苛刻,而且测试人员会因多次执行相同用例而产生厌烦,这对测试质量影响是非常大的.所以,无论从现实资源考虑还是从成本上考虑都不可能每次回归测试包都是选择所以测试用例.
2>基于风险选择测试用例
这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包.按测试优先级来来选择最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例.这样测试任务会大为减轻但效果并不差,因为由此没有被发现的缺陷是较少并严重性较低的.
3>基于操作剖面选择测试用例
这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
4>再测试修改部分
这种是基于开发对修改的影响区域有较大把握时所采取的一个策略.通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上,此时只选择相应的测试用例来做回归测试.此策略风险最大,但成本也是最能低的,通常用于做小回归测试.
以上四种回归测试策略各有优缺点,实际应用中应根据项目的资源,进度及项目开发的模式等实际情况来选择最优策略.1>一般情况在在一个非用于基线的build中作了小修改,建议采用策略4,只测试修改部分,因为现在的开发流程中build更新较快特别是极限编程中,要进行完全的回归测试是比较不现实的,即使有自动化工具的辅助亦未必能实现.2>在一个milestone中,一个作为基线的build中则可采用策略2或3,基于一定的风险选择测试,这是一个较为折中的办法,但如果资源允许的话建议进行全回归测试.3>较重要的mileStone或是最终版本,最好选择全回归测试.因为如果一般来说此时软件改动会较大,选择全部测试较为保险.当然这还是要依据当时的实际出发.
但无论采取何种策略,回归测试还是让人欲弃之不做却又不得不做的一种测试,因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少.但是谁都不敢承担不做回归测试带来的后果,真是食之无味,弃之不能.所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试.例如安排新的测试者完成手工回归测试,让更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。或是采取轮流执行不同模块,尽量避免一人一直测试某一模块,不论从测试员感受还是测试效果来看,这都是一个不好的方法.但我觉得最重要的就是基于实际可行的话引进自动化测试,因为机器不会累,可以日夜跑.
回归测试这个令人头痛的问题需要根据项目跟测试资源等实际情况来采取更有效的策略来解决.其中需要注意的是必须重视回归测试,在测试计划中有很好的进度安排及选择相应的回归策略,重视测试用例的维护,借助于自动化工具.
标题搜索
我的存档
数据统计
- 访问量: 44546
- 日志数: 33
- 建立时间: 2007-05-03
- 更新时间: 2017-11-16
