51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 8167|回复: 31
打印 上一主题 下一主题

[原创] 集成测试计划/特征功能测试过程分析等

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-6-11 11:48:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
[与大家分享一下,觉得有用了就看看。





本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2007-6-11 11:59:34 | 只看该作者
sdlkfj2 ,还是摘出来比较好,有用没用大家能一目了然。
                        
                              集成测试计划书
1引言

1.1编写目的

本文是描述****集成测试的大纲文章,主要描述如何进行集成测试活动?如何控制集成测试活动?集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人,集成部门经理,集成测试设计师。

1.2背景

项目名称:***集成测试

项目相关对象:******************

1.3定义

**********:********************

1.4参考资料

《*********》

2测试项目

本测试主要为***系统的集成测试,目前***的版本为2.0,测试是***的最终集成测试,是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上

3 被测特性

3.1操作性测试

主要测试操作是否正确,有无误差?分为两部分:

3.1.1返回测试

由主界面逐级进入最终界面,按EXIT键逐级返回,检查返回时候屏幕聚焦是否正确

比如:

1. 进入“系统设置”

2. 进入“频道搜索”

3. 进入“自动频道搜索”

4. 按EXIT键返回,检查当前聚焦是否为“频道搜索”

5. 按EXIT键返回,检查当前聚焦是否为“系统设置”

3.1.2进入测试

由主界面逐级进入最终界面,按MENU键返回主界面,再次进入,检查是否聚焦正确

比如:

1. 进入“系统设置”

2. 进入“频道搜索”

3. 进入“自动频道搜索”

4. 按MENU键返回主界面

5. 当前聚焦是否为“系统设置”

6. 进入“系统设置”,当前聚焦是否为“频道搜索”

3.2功能测试

测试机顶盒中每个应用的功能是否正确

3.3性能测试

3.3.1疲劳性测试

测试连续开机1个月不关机器,每3天去运行一次应用。看系统的稳定性

3.3.2大容量数据测试

前段***数据库表中含有大量数据,测试***功能

4 不被测特性

5 测试方法

1. 书写测试计划

2. 审核测试计划,未通过返回第一步

3. 书写测试用例;

4. 审核测试用例,未通过返回第三步

5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上;(测试报告必须覆盖所有测试用例)

6. 测试过程中发现bug,将bug填写在bugzilla上发给集成部经理;(bug状态NEW)

7. 集成部经理接到bugzilla发过来的bug

7.1 对于明显的并且可以立刻解决的bug,将bug发给开发人员;(bug状态ASSIGNED);

7.2 对于不是bug的提交,集成部经理通知测试设计人员和测试人员,对相应文档进行修改; (bug状态RESOLVED,决定设置为INVALID);

7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改;(bug状态RESOLVED,决定设置为REMIND)

8. 开发人员接到发过来的bug立刻修改;(bug状态RESOLVED,决定设置为FIXED)

9. 测试人员接到bugzilla发过来的错误更改信息,应该逐项复测,填写新的测试报告(测试报告必须覆盖上一次中所有REOPENED的测试用例);

10. 如果复测有问题返回第六步(bug状态REOPENED)

11. 否则关闭这项BUG(bug状态CLOSED)

12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务;

13. 本轮测试中发现的错误有98%经过修改并且通过再次测试(即bug状态CLOSED),返回第五步进行新的一轮测试;

14. 测试任务结束后书写测试总结报告;

15. 正规测试结束进入非正规测试,首先是ALPHA测试,请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员,测试人员以正规流程处理bug事件;

16. 然后是BETA测试,请用户代表进行测试。发现bug通知测试人员,测试人员以正规流程处理bug事件。

几点说明:

测试回归计划为三次;
测试用例应该写得比较详尽,步骤一定要标明清楚(应该包括:编号,测试描述,前置条件,测试步骤以及测试希望结果);
对于测试人员觉得应该进行的测试项目,测试人员应该报告测试设计人员,完善和健全测试用例;
测试报告与测试用例分开,测试报告标明测试用例序号以及是否通过Y/N;
对于集成部经理无法决定的上交项目负责人决定;
性能测试中的疲劳性测试可以结合在功能测试部分,即测试期间不关闭机器;
性能测试中的大容量数据测试放在测试后部分轮次(第二步,只需要进行一次)
6 测试通过标准

测试结果与测试用例中期望的结果一致,测试通过,否则标明测试未通过。

6.1测试结果审批过程

6.1.1测试回归申请结束

测试人员提出申请这轮测试结束,提交集成部经理;

集成部经理召集本组人员开会讨论;

讨论通过,进行下一轮测试,并且部署下一轮测试的注意事项,流程等内容;

如果发现这轮测试目前还存在问题没有解决,延期下一轮测试时间,讨论下一步工作应该如何进行。

6.1.2测试结果申请结束

测试人员提出申请测试结束,提交集成部经理;

集成部经理召集本组人员开会讨论;

1. 讨论通过,结束测试任务;

2. 如果发现目前测试还存在问题没有解决,延期测试结束时间,并且讨论下一步工作应该如何进行。

7 测试挂起和恢复条件

7.1挂起条件

进入第一轮测试,测试人员大体了解一下产品情况,如果在一小时之内发现5个以上(含5个)操作性错误,或者3个以上(含3个)功能性错误,退回测试组测试;
遇到有项目优先级更高的集成测试任务;
遇到有项目优先级更高的集成任务;
在测试复测过程中发现产品无法运行下去;
人员,设备不足。
7.2恢复条件

符合进入集成测试条件(一小时之内发现5个以下(不含5个)操作性错误,或者3个以下(不含3个)功能性错误);
项目优先级更高的集成测试任务暂告完成;
项目优先级更高的集成任务暂告完成;
复测过程中产品可以运行下去;
人员,设备到位。
8应提供的测试文件

测试计划书
测试用例
测试报告
测试总结
9测试任务

制定审核测试计划
制定和审核测试用例
进行测试活动
书写测试报告
10测试环境需求

10.1硬件需求

***********

10.2软件需求

************

10.3测试工具

*************

10.4测试需要的条件

**************

10.4.1需要的文档

用户手册
应用手册
安装说明
10.4.2需要完成的任务

程序员本人测试
测试组完成测试
11角色和职责

集成(测试)经理:控制并完成测试任务和测试过程,决定测试人员提交上来的bug是否需要修改;
测试设计人员:书写集成测试用例;
测试人员:按照测试用例进行测试活动;
开发人员:MHP程序bug修改;
用户代表:进行BETA测试。
12 人员和培训

集成测试经理有责任对测试相关人员进行测试流程,规章制度培训;
测试设计人员有责任对测试人员进行测试操作培训
13 测试进度

测试工作  进度(人*工作日)  
测试计划  8
测试设计 60
测试执行总共进度 30
每次回归进度 10
测试报告 2

14风险及应急计划

设备不到位:加紧设备购买;

人员不到位

人员请假:请假人员回来加班或赶紧测试进度/申请调配新的人员;

人员离职:调配新的人员;

人员调配到其他部门或项目:调配新的人员;

开发人员开发频频出错:通知开发部门,商量策略;

其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了:加班或延期

15审批

集成部经理 技术部经理

姓名: 姓名:

日期: 日期:
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2007-6-11 12:00:50 | 只看该作者
如何分析、撰写流程图文档
一、流程的主体说明:包括该流程要完成的主要工作及面对的对象等作一个总体的概述。  
二、流程图:根据流程图绘制的要求详细地把实际的工作过程用流程图的形式表现出来,一般包括几个部分,参与该流程的岗位或人员、流程图的名称、图标定义、流程图编号、绘制日期、执行日期等部分。  
三、流程描述:是对流程图的补充和加强。  
1.         步骤:  
1)        起点:详细描述该流程执行的先决条件;  
2)        某一步骤:详细描述此步骤的操作方法及执行完成的条件和标志。  
3)        结束:详细描述该流程结束的标志。  
2.         步骤输出的信息:列出该步骤结束后所输出的信息,可能为单个的元数据,也有可能为表单。  
3.         与此步骤相关的业务规则:步骤相当于骨骼,而业务规则则是指挥骨骼怎么运动的神经。需列出要完成此步骤要使用或遵循的相关规章制度、法律法规等。  
四、流程的输入与输出:  
五、流程中存在的问题或瓶颈:由于环境、资源、人才等各种因素的影响,流程中的某些步骤或顺序并未完全解决实际工作中的问题,或者是暂时无法解决的瓶颈,在此列出,为领导决策和将来的流程改造提供了依据。  
六、主流程洐生的子流程:一般都是主流程的反向或异常条件而引发的流程。  
七、流程的详细业务规则:在此把第三大点中列出的业务规则在此详细地列出,并列出负责制定、监督执行的相关责任人或部门。  
八、流程所需的相关资源:在此详细列出该流程所需的资源,包括人、财、物、设备、场地等等,并作初步的预算。  
九、流程中各角色(岗位)的工作职责:根据流程图中各角色负责的工作步骤,在此再详细地列出各角色的工作内容、职责、权限等。  
十、与流程的相关单据:在实际的工作流中,每多人与人、部门与部门之间信息的传递还是通过表单来传递的,所以在信息化的过程中,纸质表单还将伴随着信息系统在一段时间内存在下去;同时也是收集需求、了解需求的必须资料。每个流程都详细地列出该流程所涉及的表单及表单在此流程中所承载的信息及起的作用。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2007-6-11 12:03:21 | 只看该作者
软件特征功能测试过程分析




软件功能特征测试是国际化软件测试最先开始并且贯穿于整个软件开发过程的测试类型,目的是从软件的各个侧面进行质量保证,确保软件的特征功能符合软件的设计需求和功能规格说明。
  在执行特征功能测试前,应该对国际化软件提供的软件特征功能以及这些功能的重要性进行风险分析,以便确定测试过程中的测试成本。

  1、测试输入

  国际化软件的特征功能测试的输入内容包括:

  软件功能规格说明;

  软件需求;

  软件的性能目标;

  软件的布署场景 (Deployment Scenario) 。

  2、测试过程

  软件测试计划是指导软件测试的主要文档,指出测试的内容、测试的起止日期、测试过程、测试方法、测试用例的优先级和测试的其他详细内容,在软件设计、编码和测试期间,经常需要更新测试计划,特别是更改软件的需求后,需要及时更新软件测试计划。

  软件测试计划是指导软件测试的主要文档,指出测试的内容、测试的起止日期、测试过程、测试方法、测试用例的优先级和测试的其他详细内容,在软件设计、编码和测试期间,经常需要更新测试计划,特别是更改软件的需求后,需要及时更新测试计划。

  设计评审 (Design review) 确保软件的设计阶段包含了全部的布署场景和软件需求,遵循了软件的性能、安全性、国际化和可维护性的要求。

  实现编码评审确保软件的代码正确和遵守规范,符合软件国际化的需要。

软件的白盒测试也称为“结构测试”,是对软件的代码进行审查,找出引起软件功能缺陷的编码错误。

  软件的白盒测试也称为“功能测试”,是从用户使用的角度运行软件,执行全部的终端用户场景的测试用例,发现软件与设计需求和用户需求不一致的缺陷。

  3、测试过程分析

  创建测试计划

  测试计划文档中主要的内容是用于测试软件的测试用例,涵盖了设计评审、代码评审、配置、布署测试和负载测试的各个方面,确保软件的全部特征功能和使用场景都进行了测试。

  测试文档包括详细测试计划文档和详细测试用例文档。详细测试计划文档按照“高、中、低”的顺序列出了测试用例的优先级,对测试用例中的使用场景和需要测试的特征进行了简要描述。根据测试用例的重要性和对期望的目标和需求的全面影响,为每一个测试用例指定测试执行的优先级。

  详细测试用例文档与详细测试计划文档相对应,描述了详细测试计划文档列出的需要执行的每个测试用例的执行步骤,以及测试所需要的数据,给出了测试的期望结果。

  需要强调的是详细测试计划文档和详细测试用例文档不是一成不变的,相反,这两个文档的内容要在软件开发生命周期的全过程不断更新。例如,当软件的功能规格说明、软件的需求更改后,或者需要添加更多的测试输入时,需要及时更新文档。另外,当修改了测试用例的优先级,或者添加了使用场景或功能测试用例时,也需要及时更新这两个文档。   

  设计评审

  从软件测试的视角看,设计评审非常重要,通过全面评审软件设计内容,可以在软件开发的早期发现一些潜在与性能和安全性有关的缺陷。如果这些缺陷在编面阶段才被发现,则修正缺陷耗费的时间将比设计阶段修改缺陷大得多。

  详细而言,设计评审有助于确保下列问题:

  软件设计符合功能规格说明和软件需求的全部内容;

  确保软件设计符合全部性能目标;
软件设计考虑了应用程序在不同的布署场景时的全部安全性;
  软件设计遵守了程序耦合和内聚、一致性、通讯、类设计、异常管理、资源管理、缓冲区等的代码编写格式要求,以便开发人员可以方便地扩展和定制软件。

  软件设计遵守了国际化和本地化有关的指导准则。

  此外,软件设计评审还要确保软件能够正确处理可能的安全攻击、性能优化和内存泄漏的问题。

  实现编码评审

  在实现编码评审阶段,从详细测试计划文档中执行测试用例,对软件的代码进行审阅,这是软件单元测试的重要步骤。通过代码评审,可以在软件开发的早期发现问题。

  具体地,实现代码评审有助于确保下列问题:

  软件代码遵守了软件需求文档的要求;

  软件的类命名、变量、方法名等代码元素遵守了命名规范;

  软件代码在合适位置包含了有助于其他开发人员正确理解的注释语句;

  软件代码可以正确处理与性能、扩展性、安全性有关的问题;

  软件代码对异常管理和内存分配有关的资源管理能正确处理;

  软件代码考虑了软件国际化和本地化有关的问题;

  软件不包含冗余的从来不被调用的代码。

  此外,实现代码评审还要确保软件能够正确处理边界条件、特殊输入、可能的安全攻击、性能优化、内存泄漏和线程安全等问题。

  执行白盒测试

  白盒测试执行详细测试计划中与白盒测试有关的测试用例,通过分析软件代码的内部工作方式和程序逻辑结构,寻找软件存在的缺陷。

  分析源程序编码,确定测试不公 API 和测试代码路径所需要的输入数据,并且更新测试计划。

  白盒测试包括以下内容:

  剖析应用程序在运行时某些特殊代码的行为特征,包括代码覆盖、内存分配、竞争和死锁( Deadlock )问题;

跟踪代码路径分析与关键性能的相关的时间占用,对于基于 Web 的应用程序,还需要监视请求的执行时间;

  测试程序的内部分支路径,确保每个路径正确处理数据,返回期望的输出,而不会引起功能损失或不一致;

  测试不同的循环和条件语句,例如简单循环、嵌套循环,关系表达式、简单条件、符合条件、布尔表达式,保证代码组建的精度要求;

  安全性测试。如果软件某段代码在目标布署环境存在安全访问为题,应该分析对应的处理安全性的代码,避免程序向攻击者暴露敏感信息。

  执行黑盒测试

  黑盒测试执行详细测试计划中与黑盒测试有关的测试用例,黑河测试不需要测试者了解程序的内部结构,而主要模拟终端用户的操作方式。

  黑盒测试确保应用程序满足以下要求:

  应用程序符合需求文档中列出的全部目标;

  应用程序包括了功能规格说明指定的全部功能点;

  应用程序能够正确地处理期望的和异常的使用场景。

  黑盒测试包括以下内容:

  测试全部使用场景的外部接口。确保接口符合功能规格说明和系统需求,使用场景既包括期望的处理流程,也包括随机的输入。

  测试不同的输入类型。确保软件接口可以输出期望的结果,并且可以正确处理无效的数据和异常情况。测试的输入数据包括合理的数据、边界数据和超出最大和最小的输入数据。

  性能测试。验证应用程序在正常情况下和极限负载条件下,程序能够处理不断增加的访问请求,具有良好的扩展能力。性能测试包括负载测试和压力测试。性能测试的测试结果可以作为实现代码审阅和白盒测试的输入。

  安全性测试。从黑盒测试的观点看,安全性测试通过模拟软件真实运行环境下攻击者的操作行为,寻找软件不正确的设计和编码的安全隐患。安全性测试包括验证输入数据、破解加密和访问敏感数据、缓冲区溢出、授权和证书功能等。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2007-6-11 12:04:18 | 只看该作者
软件特征功能测试过程分析(一)




软件功能特征测试是国际化软件测试最先开始并且贯穿于整个软件开发过程的测试类型,目的是从软件的各个侧面进行质量保证,确保软件的特征功能符合软件的设计需求和功能规格说明。

  在执行特征功能测试前,应该对国际化软件提供的软件特征功能以及这些功能的重要性进行风险分析,以便确定测试过程中的测试成本。

  1、测试输入

  国际化软件的特征功能测试的输入内容包括:

  软件功能规格说明;

  软件需求;

  软件的性能目标;

  软件的布署场景 (Deployment Scenario) 。

  2、测试过程

  软件特征功能测试的过程如下图所示:



  软件测试计划是指导软件测试的主要文档,指出测试的内容、测试的起止日期、测试过程、测试方法、测试用例的优先级和测试的其他详细内容,在软件设计、编码和测试期间,经常需要更新测试计划,特别是更改软件的需求后,需要及时更新软件测试计划。

  软件测试计划是指导软件测试的主要文档,指出测试的内容、测试的起止日期、测试过程、测试方法、测试用例的优先级和测试的其他详细内容,在软件设计、编码和测试期间,经常需要更新测试计划,特别是更改软件的需求后,需要及时更新测试计划。

  设计评审 (Design review) 确保软件的设计阶段包含了全部的布署场景和软件需求,遵循了软件的性能、安全性、国际化和可维护性的要求。

  实现编码评审确保软件的代码正确和遵守规范,符合软件国际化的需要。

软件的白盒测试也称为“结构测试”,是对软件的代码进行审查,找出引起软件功能缺陷的编码错误。

  软件的白盒测试也称为“功能测试”,是从用户使用的角度运行软件,执行全部的终端用户场景的测试用例,发现软件与设计需求和用户需求不一致的缺陷。

  3、测试过程分析

  创建测试计划

  测试计划文档中主要的内容是用于测试软件的测试用例,涵盖了设计评审、代码评审、配置、布署测试和负载测试的各个方面,确保软件的全部特征功能和使用场景都进行了测试。

  测试文档包括详细测试计划文档和详细测试用例文档。详细测试计划文档按照“高、中、低”的顺序列出了测试用例的优先级,对测试用例中的使用场景和需要测试的特征进行了简要描述。根据测试用例的重要性和对期望的目标和需求的全面影响,为每一个测试用例指定测试执行的优先级。

  详细测试用例文档与详细测试计划文档相对应,描述了详细测试计划文档列出的需要执行的每个测试用例的执行步骤,以及测试所需要的数据,给出了测试的期望结果。

  需要强调的是详细测试计划文档和详细测试用例文档不是一成不变的,相反,这两个文档的内容要在软件开发生命周期的全过程不断更新。例如,当软件的功能规格说明、软件的需求更改后,或者需要添加更多的测试输入时,需要及时更新文档。另外,当修改了测试用例的优先级,或者添加了使用场景或功能测试用例时,也需要及时更新这两个文档。   

  设计评审

  从软件测试的视角看,设计评审非常重要,通过全面评审软件设计内容,可以在软件开发的早期发现一些潜在与性能和安全性有关的缺陷。如果这些缺陷在编面阶段才被发现,则修正缺陷耗费的时间将比设计阶段修改缺陷大得多。

  详细而言,设计评审有助于确保下列问题:

  软件设计符合功能规格说明和软件需求的全部内容;

  确保软件设计符合全部性能目标;
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2007-6-11 12:05:49 | 只看该作者
软件特征功能测试过程分析(二)




软件设计考虑了应用程序在不同的布署场景时的全部安全性;

  软件设计遵守了程序耦合和内聚、一致性、通讯、类设计、异常管理、资源管理、缓冲区等的代码编写格式要求,以便开发人员可以方便地扩展和定制软件。

  软件设计遵守了国际化和本地化有关的指导准则。

  此外,软件设计评审还要确保软件能够正确处理可能的安全攻击、性能优化和内存泄漏的问题。

  实现编码评审

  在实现编码评审阶段,从详细测试计划文档中执行测试用例,对软件的代码进行审阅,这是软件单元测试的重要步骤。通过代码评审,可以在软件开发的早期发现问题。

  具体地,实现代码评审有助于确保下列问题:

  软件代码遵守了软件需求文档的要求;

  软件的类命名、变量、方法名等代码元素遵守了命名规范;

  软件代码在合适位置包含了有助于其他开发人员正确理解的注释语句;

  软件代码可以正确处理与性能、扩展性、安全性有关的问题;

  软件代码对异常管理和内存分配有关的资源管理能正确处理;

  软件代码考虑了软件国际化和本地化有关的问题;

  软件不包含冗余的从来不被调用的代码。

  此外,实现代码评审还要确保软件能够正确处理边界条件、特殊输入、可能的安全攻击、性能优化、内存泄漏和线程安全等问题。

  执行白盒测试

  白盒测试执行详细测试计划中与白盒测试有关的测试用例,通过分析软件代码的内部工作方式和程序逻辑结构,寻找软件存在的缺陷。

  分析源程序编码,确定测试不公 API 和测试代码路径所需要的输入数据,并且更新测试计划。

  白盒测试包括以下内容:

  剖析应用程序在运行时某些特殊代码的行为特征,包括代码覆盖、内存分配、竞争和死锁( Deadlock )问题;

跟踪代码路径分析与关键性能的相关的时间占用,对于基于 Web 的应用程序,还需要监视请求的执行时间;

  测试程序的内部分支路径,确保每个路径正确处理数据,返回期望的输出,而不会引起功能损失或不一致;

  测试不同的循环和条件语句,例如简单循环、嵌套循环,关系表达式、简单条件、符合条件、布尔表达式,保证代码组建的精度要求;

  安全性测试。如果软件某段代码在目标布署环境存在安全访问为题,应该分析对应的处理安全性的代码,避免程序向攻击者暴露敏感信息。

  执行黑盒测试

  黑盒测试执行详细测试计划中与黑盒测试有关的测试用例,黑河测试不需要测试者了解程序的内部结构,而主要模拟终端用户的操作方式。

  黑盒测试确保应用程序满足以下要求:

  应用程序符合需求文档中列出的全部目标;

  应用程序包括了功能规格说明指定的全部功能点;

  应用程序能够正确地处理期望的和异常的使用场景。

  黑盒测试包括以下内容:

  测试全部使用场景的外部接口。确保接口符合功能规格说明和系统需求,使用场景既包括期望的处理流程,也包括随机的输入。

  测试不同的输入类型。确保软件接口可以输出期望的结果,并且可以正确处理无效的数据和异常情况。测试的输入数据包括合理的数据、边界数据和超出最大和最小的输入数据。

  性能测试。验证应用程序在正常情况下和极限负载条件下,程序能够处理不断增加的访问请求,具有良好的扩展能力。性能测试包括负载测试和压力测试。性能测试的测试结果可以作为实现代码审阅和白盒测试的输入。

  安全性测试。从黑盒测试的观点看,安全性测试通过模拟软件真实运行环境下攻击者的操作行为,寻找软件不正确的设计和编码的安全隐患。安全性测试包括验证输入数据、破解加密和访问敏感数据、缓冲区溢出、授权和证书功能等。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-6-11 16:58:42 | 只看该作者
谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2007-6-11 18:03:36 | 只看该作者
sdlkfj1 ,谢谢你。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-6-12 10:21:24 | 只看该作者
谢谢~~~你太好了
回复 支持 反对

使用道具 举报

该用户从未签到

10#
 楼主| 发表于 2007-6-19 11:56:43 | 只看该作者
呵呵,共享一下
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2007-6-19 12:52:36 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2007-6-23 08:15:38 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2007-6-23 08:15:49 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2007-6-23 08:15:59 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2007-6-23 08:16:17 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2007-6-24 12:01:18 | 只看该作者
sdlkfj2 好,有帮助,谢谢了
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2007-6-24 16:05:44 | 只看该作者
up
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2007-6-24 21:39:09 | 只看该作者
谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2007-6-28 09:14:29 | 只看该作者

回复 #1 yiyi820106 的帖子

谢谢楼主,特别为新手考虑,否则要下载还要灌水!
回复 支持 反对

使用道具 举报

该用户从未签到

20#
 楼主| 发表于 2007-7-11 16:35:30 | 只看该作者
呵呵,供大家分享sdlkfj1
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-13 10:59 , Processed in 0.100436 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表