1.引言
1.1编写目的
编写本文档的目的是进一步规范数据仓库的基础层测试工作；用于指导数据数据仓库基础层相关集成测试，主要从测试环境、测试策略、测试具体执行方法、任务计划与安排等为测试工作的展开提供指导和依据；给其他相关组的组间协调提供工作指导。
1.2测试背景
数据仓库随着企业信息化程度的不断提高，各类应用系统同时并存并支撑着企业的业务应用。越来越多企业的信息化主管在开发企业应用时已经考虑到数据集成和将来对数据的整体有效利用，因此，数据仓库被必然的选择来避免信息孤岛，实现应用的内部联系和信息的共享。而现如今由于仓库的需求在仓库发展中不断增加、变化，这要求仓库开发效率加快、准确度提高、实现更加标准化，开发的工程化、自动化趋势也越来越明显，这就要求数据仓库测试在完备的测试条件下，更加迅速、高效的完成测试任务。
1.3预期读者
本文档的预期读者包括：项目管理人员、测试管理人员、参与基础层测试的测试组成员、其他相关项目组人员
2.测试概述
2.1测试目标
DW测试主要围绕ETL进行，即保证ETL和新需求增加的数据质量。其中 ETL 测试保证：
1) 程序的运行正常；
2) 数据的质量：保证准确性和数据的稳定性；
3) ETL的效率：对数据抽取上载时SQL进行部分优化测试等。
目标是保证模型层脚本的跑通性，验证数据是否按照设计需求中既定规则取数，通过内部集成的方式降低数据的出错概率，确保数据的准确性，将输出结果与期望结果控制在既定的置信水平范围内。
2.2测试范围
测试范围是数据仓库项目基础层模型脚本、修数追数脚本及其他建表语句等，其中模型层脚本包括新增脚本及变更脚本。
2.3测试角色与职责
3.测试流程
模型层脚本各组工作大体封版时间：
数据组设计封版时间：脚本上线点前至少15个工作日；
开发组开发封版时间：脚本上线点前至少10个工作日；
测试组测试封版时间：脚本上线点前至少5个工作日；
上线演练完成时间：脚本上线点前至少3个工作日。
注：这里各组封版时间请测试负责人及时关注设计组封版情况并提醒开发组确定落实封版，避免后期测试时间紧迫无法按时完成既定测试任务。
4.测试准备
4.1.准入条件测试
4.1.1.检查受控单
检查开发提交的受控单，一方面是为了规范开发人员的脚本提交流程，另一方面则是为了检查受控库中涉及的脚本是否为本次上线范围内的脚本，若不在本次上线范围内需与相关开发人员确认具体情况。
受控单中需填写内容如下：
1）变更号：与变更跟踪登记簿中的EDW变更号一致，有时候会出现一只脚本涉及多个变更号任务，所以请测试负责人分配脚本时需要将同只脚本分
配给同个测试人员，方便测试实施；
2）里程碑名称/变更编号；
3）开发流路径：脚本测试流存放路径与其一致；
4）程序文件名：与变更跟踪登记簿中脚本名称一致；
5）负责人：相关脚本开发负责人；
6）受控原因：包括设计变更、新增实体、新增映射、MQC缺陷等；
7）变更描述：与变更跟踪登记簿中变更描述一致；
8）测试环境：开发人员单元测试环境；
9）预计上线日期：脚本的上线日期。
4.1.2.检查单元测试结果
针对开发人员提供的项目源码提交受控库申请表中填写的测试环境，在相应的环境下查看脚本是否有进行单元测试，通过SQL语句查询表中数据，检查的内容如下：
1）目标表名，显示内容包括，检查表的表名；
2）主键名，显示内容包括，检查表的主键名
3）检查类型, 显示内容包括，主键重复检查，主键空格检查，检查表的数据空间和分布倾斜因子，检查表的记录分布情况，源表记录数与目标表记录数一致性，代码有效性检查，检查倒链，检查开链和交叉链，检查脚本重跑；
4）各检查内容对应的输出数据，显示内容包括：
a)检查主键重复（主键重复个数）；
b)检查主键空格（主键含空格记录数）
c)检查表的数据空间和分布倾斜因子，检查目标表的倾斜因子是否大于
50（占用空间，峰值空间，倾斜因子）；
d)检查表的记录分布情况（AMP最大记录，AMP最小记录）；
e)源表记录数与目标表中更新的记录数一致性（源表记录，目标记录，
记录数差）；
f)代码有效性检查，检查源字段的取值范围是否在包含在对照表的取值
范围中（代码字段，无效记录）；
g)检查倒链，检查是否存在开始日期大于和等于结束日期的记录（倒链
记录数）；
h)检查开链和交叉链，检查是否存在各时期的时间段总和不等于最大日
期和最小日期差的记录（开链记录数）；
5）检查结果，显示内容包括，正常，异常；
6）检查日期，显示内容包括，脚本运行的日期；
7）系统时间，显示内容包括，脚本运行的时间。
若返回结果非空，首先确认检查日期显示为近期的时间，以保证该单元测试为针对本次上线变更所进行的，再查看各检查结果是否正常；
否则将受控单打回，通知开发人员进行单元测试后重新提交受控单方可进行集成测试。
4.2.脚本准备
4.2.1.脚本提交流程
开发人员完成开发后，将脚本提交配置管理工具受控，并以受控申请单形式通知测试人员。
4.3.编写测试用例
所谓的测试案例就是将软件测试的行为活动，作一个科学化的组织归纳。
简单的说，测试案例就是设计一个情况，软件程序在这种情况下，必须能够正常的运行并且达到程序设计的预期执行结果，所以测试案例的设计要具有目的性，根据数据仓库的特点及数据类测试的特性，总结出以下几个测试点：1）脚本变更内容检查，对照变更跟踪登记簿（必需）；
2）源表字段与目标字段的转换（必需）；
3）源表字段与目标字段的映射（必需）；
4）PK重复检查、全记录重复检查（必需）；
5）PI分布是否均匀（必需）；
6）源表数据与目标表数据的数据比对，查看进行是否正确，是否发生字段截取等（必需）；
7）记录数是否一致（必需）；
8）脚本重复执行性（必需）；
9）删除的数据正确性，发生更新时，对数据的删除是否正确（必需）；
10）拉链表的状态断链、交叉链、开链（必需）；
11）代码的取值种类和代码的范围是否与源系统一致。；
12）特定字段的约束检验，如日期字段是否有进行格式化操作，有拼加前缀字段是否需考虑出现空值情况的处理；
13）表间关系所带来的字段检验；
14）总分关系是否能保持；
15）主外关系延续性（测试范围内的表）；
16）复杂算法的正确性。
随着测试工作不断的深入，测试组会对质量组、运维组及其他组发现的问题进行归纳总结，以不断完善测试测试点。
测试案例的设计要根据脚本业务规则的不同，来选择相应的测试点进行案例设计。
4.4.数据准备
4.4.1.申请测试数据
在测试前首先保证有足够的测试数据，与设计确认是否已同步生产数据或从ODS接口组加载测试数据到测试环境，包括加载的测试环境，库名及日期，也可使用以下SQL语句查询。
若在测试过程中发现所需源表不存在或数据为空或源表的业务日期不统一，且该表涉及变更描述内容的情况，可联系设计人员或ODS接口组请求重新加载数据。但实际申请测试数据流程可能较长，一般很难在测试计划内得到解决，为了不影响测脚本的正常上线，可先通过建立空表或修改业务日期或手工造数进行解决，待数据重新申请下来再进行验证。
5.测试实施
5.1.规范性检查
为了方便仓库统一管理，避免由开发人员的编写习惯等原因带来的潜在问题和风险。项目组要求所有上线脚本必须通过规范性检查。目前仓库的规范性检查，主要通过脚本自动检查+手工检查的方式实现。
5.1.1.自动检查
编写自动检查脚本以便检查开发人员提交测试脚本的规范性。检查的指标由
项目组或者是客户制定。
5.1.2.手动检查
由于部分规范化的检查暂未实现，为了规范化的检查程度达到更广，规范检查脚本运行完毕后，根据规范性要求进行“手动检查”。
5.2.执行脚本
1）脚本跑通检查；
nohup perl 脚本名源表数据日期>[].log &
2）检查脚本是否能重复执行：使用同一个业务日期跑两次脚本（第二次执行脚本不对目标表数据产生任何影响）。
3) 运行二天以上业务日期的数据
检查目标记录是否被更新；更新数据时，经过删除和插入的操作后，检查数据记录是否丢失。
5.3.指标检查
白盒检查通过且脚本成功运行后，根据目标表的输出数据情况进行指标检查。指标检查主要包含：主键检查，字段空值检查，代码转换结果检查，数据量检查，拉链检查（针对拉链表），PI分布检查。
5.3.1.主键检查
1)目标表数据要求主键不重复，检查PK重复, 结果为“0 rows processed”时通过。
2)目标表主键要求不包含空格，检查PK是否包含空格,结果为“0”时通过。
5.3.2.字段空值检查
结果为“0”时通过。
5.3.3.代码转换结果检查
检查代码对照表中的代码是否正确转换，无输出结果时通过。
5.3.4.数据量检查
1）检查是否有重复记录，当两条查询结果相同时通过：
2）查询目标表的记录数是否跟源表的一致;
5.3.5.拉链检查（目标表为拉链表）
1）检查开链、断链和交叉链, 无输出结果时通过：
2）检查倒链，主要是检查是否存在开始日期小于和等结束日期的记录, 无输出结果时通过。
6.缺陷管理
6.1.MQC缺陷库
Mercury Quality Center 的简称,是美科利公司开发的一个基于Web方式的测试管理系统。
可以系统的控制和管理应用程序测试流程的各个阶段，包括测试需求、计划测试、执行测试及跟踪缺陷，从而保证应用系统测试的质量。
采用B/S模式，数据集中在后台的数据库中，便于共享。
打开IE，输入URL：http://128.32.96.172:8080/qcbin/start_a.htm。
进入到登陆页面，输入用户名及密码，通过身份认证后再选择域及项目，其中域选择“开发三部”，项目选择“数据仓库应用支持2008测试项目”。
6.2.缺陷流程图
注意：只有提出缺陷的测试人员或测试经理才能关闭缺陷。
6.3.缺陷提交规范
6.3.1.新建缺陷
通过用例库中的用例去新建缺陷，具体如下：测试计划->链接的缺陷->新建缺陷
6.3.2.缺陷完善
a、主题：自动生成，在自动生成脚本名字其前方填写开发人员名字，在其后方
填写缺陷主要问题描述；
b、缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，包括：提出、处理、拒绝、待验证、重现、关闭；
c、严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，
缺陷修复人员负责确认，包括：严重、一般、轻微；
d、紧急程度：指缺陷必须被修复的紧急程度。由提出人指定，包括：高、中、低；
e、缺陷起源：指引起缺陷的起因，包括：需求、架构、设计、编码、环境、数据、拒绝；
f、缺陷描述
要求提出人描述的缺陷分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂缺陷有据可查（截图或其它形式的附件）；
g、分析和修改内容
开发人员修复或拒绝修复缺陷时，需在“缺陷详细信息”模块中的“分析和修改内容”中使用“添加注释”按钮详细填写修复的内容及拒绝的原因。
其他MQC使用请参考附件：CC目录\2480\MQC相关资料。
6.3.3.缺陷跟踪
缺陷提交完成后，系统会自动发邮件通知相关缺陷负责人，但由于实际工作影响，缺陷负责人可能会忽略缺陷邮件提醒，故缺陷提出人要对缺陷负责人进行友情提醒，以便及时解决问题，避免影响脚本上线进度。做到定期查看缺陷状态，进入MQC缺陷管理页面，查看提交的缺陷状态：
对状态为‘待验证’的缺陷及时进行回归验证，如验证通过，关闭缺陷，否则需要再重新打开缺陷，并通知缺陷负责人及时修改。
对状态为‘拒绝’或‘挂起’的缺陷，需要和缺陷负责人进行确认，并让缺陷负责人对缺陷做出注释，给出拒绝或挂起的理由。
在脚本封版后，统计出状态为‘挂起’、‘拒绝’的缺陷，与脚本版本一起提交，并让相关开发人员做好后续跟踪。
7.测试后期
7.1.测试版本控制
7.1.1.测试版本对比
在脚本完成测试后，MQC上的问题都得到解决情况下，进行上线版本封版，要保持封版的版本是最新的，以免版本产生混乱，故需对版本进行比对。7.1.2.测试版本输出
1）测试版本封版
在脚本完成测试后，MQC上的问题都得到解决情况下，进行上线版本封版，封版脚本包括以下几个提交件：
a.经测试的最新上线模型脚本；
b.代码初始化脚本
c.物理模型建表语句及导数脚本；
d.追数&修数脚本；
e.上线模型脚本清单；
f.上线遗留缺陷清单及相关风险提醒（提醒开发人员、质量组相关人员进
行跟踪）。
2）上线演练版本
版本封版完成后，需要在测试环境进行一次模型上线测试，以验证所封版的脚本是否无错、对其它生产脚本有无影响，进而可以检验分析人员的影响性分析是否遗漏。
3) 上线版本
上线演练结束后，若对于除遗留缺陷未发现其他问题，可对版本进行封版，提交上线。
7.2.测试输出
7.2.1.阶段性测试小结
在测试过程中，每个阶段需要做一个总结，也可称为测试状态报告，发送相关人员进行审核，主要描述本阶段测试的总体情况，包括脚本测试情况、案例执行情况、缺陷修改状态、测试中遇到的相关问题等，对于需要其他组协助解决的问题，要发组间协同工单进行协助解决。
阶段性测试小结模板存放于配置工具指定的目录下。
7.2.2.测试报告
在测试完成后，产出一份集成测试报告，把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
工程项目管理系统测试 方案 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
工程项目管理系统测试方案 （模块测试阶段） 1.试用人员账号信息
2.人员分工 3.测试项目
4.测试用例（其他分公司按照潍坊公司用例进行，只需要更改项目编号和名称）潍坊公司用例一（分成多个任务的情况） （1）立项 项目编号：07TWF2SB0001 项目名称：潍坊电信昌乐机房改造工程 项目经理：朱汇川 项目类型：设备工程 项目概况：潍坊电信昌乐机房改造工程（介绍项目的情况） 立项时间：2007-08-01
（2）任务分解 01：领料 计划开始时间：2007-08-01 计划结束时间：2007-08-02 任务描述：到电信仓库领取工程用料（可以根据情况自由填写）02：施工 计划开始时间：2007-08-03 计划结束时间：2007-08-08 任务描述：工程施工（可以根据情况自由填写） 03：验收 计划开始时间：2007-08-09 计划结束时间：2007-08-09 任务描述：工程验收（可以根据情况自由填写） （3）计划 领料阶段人力计划：张三 领料阶段材料计划：电力电缆：RVV1-16 20M 甲方提供 电力电缆：RVV1-25 20M 甲方提供 电力电缆：RVV1-35 20M 甲方提供
电力电缆：RVV1-50 20M 甲方提供 交流排：5个单价40元/个自购 光纤跳线：单模一米 20条 20元/条自购领料阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100 计划办公费：100 计划差旅费：0 计划车辆使用费：100 计划费用合计：自动生成 施工阶段人力计划：张三、李四 施工阶段材料计划： 施工阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100
性能测试结果分析 分析原则： 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等） 注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 分段排除法很有效 分析的信息来源： 1）根据场景运行过程中的错误提示信息 2）根据测试结果收集到的监控指标数据 一．错误提示分析 分析实例： 1）Error:Failed to connect to server “https://www.doczj.com/doc/c04025988.html,″: [10060] Connection Error:timed out Error: Server “https://www.doczj.com/doc/c04025988.html,″ has shut down the connection prematurely 分析： A、应用服务死掉。 （小用户时：程序上的问题。程序上处理数据库的问题） B、应用服务没有死 （应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ C、数据库的连接 (1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关）) 2）Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成 A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多 C、在程序处理表的时候检查字段太大多 二．监控指标数据分析 1．最大并发用户数： 应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。 在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。 如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2．业务操作响应时间： 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？ 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
期中小测验 一、简答题（35分） 1．简要叙述软件项目规模成本估算的基本方法。 2．为项目制定计划是什么意思？它包括那些内容？ 3．项目的特征有哪些？ 4．简述软件危机产生的原因。 5．软件项目有什么特殊性？ 6．简述项目管理中时间、质量及成本之间的关系。 7．简述进度控制的方法与原则。 二、计算题（45分） 1．项目经理正在进行一个媒体信息查询系统项目的估算，他采用的delphi的成本估算方法，邀请2位专家估算，第一个专家给出1万，8万，9万的估算值，第二个专家给出了4万，6万，万8 万的估算，计算这个项目成本的估算值是多少？ 2．请为一个学院网站建设项目建立WBS。 3．一个项目在进行规划的时候,碰到了一个风险问题，项目经理在决定是否采用方案A。如果采用方案A需要使用一个新的开发工具，通过使用这个工具可以获利5万元，否则将损失1万元。而能够掌握这个工具的概率是20%，利用决策树分析技术说明这个项目经理是否应该采用这个方案A？（画出决策树）
（1）在下面的网络图中的相应位置填写出各活动的工期、最早开始时间、最晚开始时间、最早结束时间、最晚结束时间、时差，指出关键路径，总工期。 （2）假设总工期需要缩短，应首先选择哪个活动进行压缩，为什么？ （3）该网络图中的准关键活动有哪些？ 最晚开始时间 5．某项目由1、2、3、4四个任务构成，如下图所示。该项目目前执行到了第6周末，各项工作在其工期内的每周计划成本、每周实际成本和计划工作量完成情况如下图所示。（选做） 单位：万元
（1）根据图中提供的信息，计算出截至第6周末，该项目的BCWS、ACWP和BCWP 参数将结果直接填写在下表中： （2）计算第6周末的成本偏差CV、进度偏差SV，说明结果的实际含义。（3）如果预计完成剩余的工作，仍然会延续目前（第6周末）的偏差情况，完成整个项目实际需要投入多少资金？写出计算过程。 三、论述题（20分） （1）需求变更是导致项目失败的重要原因也是项目管理者必须面对的问题，列出你参与的（或者你所知的）软件项目过程中引起变更的原因，这个变更可以是开发过程中的任何阶段，最好按照项目的执行阶段给出变更的原因和可能的解决方法。 （2）简要叙述软件项目规模、成本估算的基本方法。
智慧树知到《科研方法论》章节测试答案 第一章 1、科学研究有两大特点，一是继承性，二是（） A:知识性 B:创新性 C:系统性 D:连续性 正确答案：创新性 2、从广义上讲，科学研究的对象是客观世界，包括自然界、社会和（）。 A:思想 B:大脑 C:人类思维 D:行为 正确答案：人类思维 3、初学者做研究应采取的原则是“有限目标，（）”。 A:量力而行 B:能够完成 C:实事求是 D:因地制宜 正确答案：量力而行 4、自然科学是研究自然界的物质结构、形态和运动规律的科学。一种代表性的观点认为，现代自然科学由（）三部分组成。 A:基础科学
B:技术科学 C:应用科学 D:实验科学 正确答案：基础科学,技术科学 ,应用科学 5、科学是指人们对自身及其周围客体的规律性认识，科学具有（）的特点。A:知识性 B:系统性 C:逻辑性 D:自洽性 正确答案：知识性 ,系统性,逻辑性 ,自洽性 6、科学是人们对自身及周围客体的一般性认识。 A:对 B:错 正确答案：错 7、正确的科研方法对科研工作的成功起着至关重要的作用。 A:对 B:错 正确答案：对 8、政治学、经济学、法学、哲学属于社会科学。 A:对 B:错 正确答案：错
9、科研方法的价值主要体现在（）。 A:创造学术价值 B:推动技术进步 C:促进社会发展 D:完善人类自身 正确答案：创造学术价值,推动技术进步,促进社会发展,完善人类自身 10、如果希望在本科阶段进入课题组或实验室参与课题研究，需要具备（）条件。 A:掌握课题所在领域相关的基础知识和专业知识 B:课程学习无负担，不为考试过关或者挂科所累 C:有足够的时间到课题组或者实验室参加课题研究 D:有很强的对新知识和新技术自学能力和吸纳本领 正确答案：课程学习无负担，不为考试过关或者挂科所累,有足够的时间到课题组或者实验室参加课题研究,有很强的对新知识和新技术自学能力和吸纳本领 第二章 1、根据课题属性，科研课题一般可分为理论性、实验性和（）研究课题三大类。 A:基础性 B:前沿性 C:综合性 D:应用性 正确答案：综合性 2、在课题研究中，涉及的新原理、（）、新材料和新工艺等都属于创新的范畴。 A:新概念
系统测试需求分析与系统测试用例设计 上海博为峰软件技术有限公司 20011年3月4日
目录 第一章：系统需求评审 (2) 1 基本信息 (2) 2 课程设计 (2) 第二章：系统测试需求分析方法 (3) 1 基本信息 (3) 2 课程设计 (3) 第三章：系统测试用例设计 (4) 1 基本信息 (4) 2 课程设计 (4) 第四章用户体验测试思路 (6) 1 基本信息 (6) 2 课程设计 (6)
第一章：系统需求评审 1基本信息 2课程设计 1、系统需求规格说明书课程介绍 系统需求规格说明书是系统测试用例设计的参考文档，只有具备良好的 系统需求规格，才可能设计出全面、合理的测试用例。因此，测试人员 对系统需求规格的评审能力就显得尤为重要； 2、系统需求规格说明书的内容介绍 该章节包括，系统需求规格的定义、系统需求规格说明书的目的、系统 需求规格说明书的特点、良性需求的定义、需求的分类、系统需求的属 性、表达需求的方法、表达需求常见的问题、系统需求规格说明书写作 要点；结合具体的系统需求规格说明书例子，讲解系统需求规格说明书 的具体写作方法。 3、系统需求的可测试性分析 从测试需求分析和测试用例设计角度分析软件的可测试性；讲解在需求 不完整的情况下，如何在有限的需求情况下，有效的开展软件测试设计 工作
第二章：系统测试需求分析方法 1基本信息 2课程设计 1、系统测试需求分析过程和方法 讲解产品测试需求分析的步骤，包括： 1）被测试系统分析 2）原始测试需求分析 3）测试需求分析 4）测试特性分析 5）测试子需求分析 并且在每个阶段引入相应的分析方法和分析策略。 2、产品测试用例设计实例解析 根据上述系统测试需求分析的步骤，以某系统为例，讲解如何从被 测试系统的原始需求出发，通过上述步骤产生测试需求或者测试子 需求。
经常听到考研朋友抱怨不知道该如何有效的进行专业课的复习尤其是跨学校跨专业考的同学。我也曾经经历过这样的困惑，但自从考研过后以及这两年的历练，再回过头看顿觉得所有迷惘烟消云散，总结出来就两字：方法。 也许大家都觉得好笑，不就是方法吗，谁不知道。但是我告诉你，很多跟我联系过的同学根本就不知道方法或者说他们根本就没有一套行之有效的复习方法。他们所知道的就是埋头苦学，早上6点起床，晚上12点睡觉，搞题海战术，这就是他们所谓的方法。我不否认刻苦学习是考上研究生的条件之一，但是我想说的是掌握了正确的方法可以事半功倍。下面我像大家介绍一下复习的时候应该掌握的方法（注：不是解题技巧） Step 1：了解考试要求即明确考试科目，全面复习。很多专业初试考的就一门课，因此内容量不是很大，大家可以根据实际内容量进行全面的阅读，第一轮的复习应该达到理解的程度，也就是说要把课本里面的所有知识点都理解。 Step 2:在第一轮理解课本内容的基础上进行真题的总结。专业真题内容大部分都出自课本或者是课本知识点的灵活运用，因此，有效复习实际上是要有重点有针对性的进行复习，而不是通篇全吃。根据我的研究，历年真题内容有很多是重复出现的，或者是互补出现的，怎么理解呢？重复出现就是某个知识点连年出现或者是间隔几年出现；互补出现就是说课本内容的重点基本是固定的，今年出现了某些，那明年将会出现另外一部分内容。具体的课本内容、考点的关系如图所示： 注：1：课本所有知识点2：某年考点3：另外一年考点4：重复考点 从上述图中我们可以知道，2跟3是一定程度上的互补关系，那何时出现这种情况呢，大部分是隔年出现。也就是说今年这个知识点考了，那明年很可能是从考试重点里头出今年没有考过的知识点，这样既没有超出考试范围，也凸显了每年知识点的变幻，是出题的一个原则。因此，大家复习的时候应以往年考过但是去年没有考的知识点为重点，去年考过的为次重点。 Step 3:找出考试重点后就要开始进行知识点的梳理。梳理的方法主要有如下几点：有名词解释的就要把所有历年出现过的都总结归纳在一下，并用★标明重复次数，如某个名词考了3次，就标3个★，这样就比较清楚了；有计算题的就要总结一下这个题型，根据上面的方法也归纳一下具体的考点，还有考试的频度，用★表示；其他题型类推。 Step 4:上述所有重点知识点都掌握以后就要进行强化训练了。所谓的强化训练就是在以前复习的基础上进行灵活的运用，具体的方法是选择相同的题型进行训练。 Step 5：把握住重点以后再有时间就是要进行非重点知识的拓展了。根据20/80法则，抓住了80%的重点就意味着可以交一份“良好”的答案了，但是要拿到“优秀”，那20%的肯定是少不了的。所以在后续阶段应抓一下非重点内容。
服务响应的时间标准 参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。 针对基础数据库添加企业信息： 添加10家企业，9家成功，1家失败，失败详细信息 Action.c(62): Error -26612: HTTP Status-Code=500 (Internal Server Error) for "http://202.117.99.211/basedatabasesite/PSInfo/IndustryFact/PSBaseInfoAdd.aspx? PSClassCode=1&%3f" Monitor name :Windows Resources. Cannot access data for measurement Processor|% Processor Time|_Total on machine 202.117.99.211. Details: 检测出一个含有负分母值的计数器。 Hint: Check that there is such a measurement on the machine (use the Add Machine dialog box) (entry point: CNtMeasurement::GetNewData3). [MsgId: MMSG-47295] 功能名称：企业基本信息维护，添加企业基本信息 10用户模拟并发操作： 系统响应时间：最短1.078秒最长4.901秒，属于可接受范围 资源使用情况： 内存分析： 其中： Handle Count(process _total)值由71030变化为71515 差值485bytes private bytes 值由2442407936变化为2469638144差值27230208bytes 变化范围约3M committed bytes 值由2625691648 变化为2652794880 差值27103232
谈项目管理和软件测试过程 1. 软件测试在公司的组织保障是基础 1.1 研发部组织结构介绍 以华友公司研发部的组织结构为例，测试部门属于研发部副总裁直接管理， 公司研发部的组织结构图 #FormatImgID_0# 对于从事软件研发的组织来说，工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理，以及其它人员，如文档编制人员和美工人员/系统硬件管理人员等。根据职能需要，可以以半独立方式进行部门和项目的矩阵管理，即职员要对项目经理/组长负责，也要对部门经理/总监负责，工作考核由双方共同完成，标准的组织应包括技术开发部/组（主要是编码和设计人员），产品开发部/组（产品需求和项目管理），测试部/组，配置管理部/组（因为配置管理人员基本上是按20个技术人员配一个配置管理人员，所以一般部门规模较小，或者只是配置管理组），软件质量保障部/组，其它部/组（如系统/文档/美工等）。华友公司组织结构中，研发部是公司软件研发的核心部门 产品研发Ⅰ部、Ⅱ部、和应用研发部主要负责： 与软件产品部或内容产品部配合，协助完成内容产品的可行性、合理性分析； 平台、网关、应用产品的研发项目的立项和方案评审；
研发项目的概要设计、详细设计工作； 研发项目的编码、单元测试工作； 组织公司相关部门进行研发产品的培训； 协助相关部门做好产品的售前技术支持工作； 协助相关部门进行软件的安装与调试； 根据相关部门的要求做好产品的售后服务工作，保障软件的运行正常。测试部隶属研发部，主要职责如下： 与内容产品部和软件产品部配合完成软件需求分析讨论，并根据需求说明书制订《项目测试方案》，编写《测试用例》，建立测试环境； 负责完成研发部各开发组研发的软件产品开发过程和投入运营之前的 新增软件和修改升级软件的模块测试和系统测试； 建立、推广并维护实施软件版本管理系统CVS和VSS； 使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录； 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线 测试工作，并提供上线测试报告； 负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。 1.2 软件产品研发各部门的组织结构分解
XX系统测试总结报告
1引言 1.1 编写目的 编写该测试总结报告主要有以下几个目的 1．通过对测试结果的分析，得到对软件质量的评价 2．分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考 3．评估测试测试执行和测试计划是否符合 4．分析系统存在的缺陷，为修复和预防bug提供建议 1.2 背景 1.3 用户群 主要读者：XX项目管理人员，XX项目测试经理 其他读者：XX项目相关人员。 1.4 定义 严重bug：出现以下缺陷，测试定义为严重bug ?系统无响应，处于死机状态，需要其他人工修复系统才可复原。 ?点击某个菜单后出现“The page cannot be displayed”或者返回异常错误。 进行某个操作（增加、修改、删除等）后，出现“The page cannot be displayed”或者返回异常错误 当对必填字段进行校验时，未输入必输字段，出现“The page cannot be displayed”或者返回异常错误 系统定义不能重复的字段输入重复数据后，出现“The page cannot be displayed”或者返回异常错误 1.5 测试对象 略
1.6 测试阶段 系统测试 1.7 测试工具 Bugzilla缺陷管理系统 1.8 参考资料 《XX需求和设计说明书》 《XX数据字典》 《XX后台管理系统测试计划》 《XX后台管理系统测试用例》 《XX项目计划》 2测试概要 XX后台管理系统测试从2007年7月2日开始到2007年8月10日结束，共持续39天，测试功能点174个，执行2385个测试用例，平均每个功能点执行测试用例13.7个，测试共发现427个bug，其中严重级别的bug68个，无效bug44个，平均每个测试功能点2.2个bug。 XX总共发布11个测试版本，其中B1—B5为计划内迭代开发版本（针对项目计划的基线标识），B6－B8为回归测试版本。计划内测试版本，B1—B4测试进度依照项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。 B6－B11为计划外回归测试版本，测试增加5个工作人日的资源，准时完成测试。 XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1—B4测试阶段都有详细的bug分析表和阶段测试报告。 2.1 进度回顾
b 项目名称（项目编号） 测试计划 文件修改控制
目录 1.1测试背景..................................................... 1.2测试范围与目标............................................... 1.3项目组织..................................................... 1.3.1组织结构............................................... 1.3.2角色与职责 ............................................. 1.3.3外部接口............................................... 1.4定义与缩略语................................................. 1.5参考资料..................................................... 1.5.1参考资料............................................... 1.5.2参考网站............................................... 2测试要点....................................................... 2.1测试方法................................................. 2.2测试工具................................................. 2.3测试内容................................................. 3测试环境....................................................... 3.1硬件环境................................................. 3.2软件环境................................................. 4产品及技术形态................................................. 5测试进度计划................................................... 5.1项目的启动和结束时间（或迭代周期计划）................... 5.2测试设计工作任务分解和人员安排........................... 5.3测试环境搭建工作任务分解和人员安排....................... 5.4测试执行工作任务分解和人员安排........................... 5.5测试分析工作任务分解和人员安排........................... 6技术质量风险分析............................................... 7测试用例描述................................................... 7.1测试类型一............................................... 7.1.1测试用例一（功能测试） ................................. 7.2测试类型二............................................... 7.2.1测试用例二（性能测试） .................................
5.1.2性能测试需求提取 复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5- 1所示。 图5- 1性能测试需求提取流程 分析提取指标 在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！ 表5- 1需求规格说明书中的性能要求 表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。 大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。 分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点： 第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是 人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚 至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关 的，得根据实际情况区分。
1、科学方法论的研究对象和学科性质。 答：研究对象： 1、科学方法的含义：人们在认识和改造世界中遵循或运用的、符合科学一般原则 的各种途径和手段，包括在理论研究、应用研究、开发推广等科学活动过程中采用的思路、程序、规则、技巧和模式。简单地说，科学方法就是人类在所有认识和实践活动中所运用的全部正确方法。 2、科学方法的研究内容：适用于各门科学的一般研究方法，如观察、实验、假说、理论、比较、类比、模拟、模型，分析与综合、证明与反驳、归纳与演绎，数学方法，以及这几十年发展起来的系统方法、信息方法、控制和反馈方法等等。这些科学方法是从各门具体科学的特殊方法中概括出来的共同方法。 科学方法论的性质： 1、它是一门正趋向于独立的学科。 2、它是一门思维科学。 3、它是一门认识“工程学”。 2、科学方法论有哪些层次和要素？ 答：层次：按照方法作用的大小和普适性程度的高低，科学方法论依次被划分为3个不同层次： 1、适合于各门学科的具体方法论； 2、某一类学科中普适性深度较高的特殊方法论； 3、具有高度普适性的根本性或一般性方法论。 科学方法论要素： 1、客体 2、主体 3、主体与客体的相互关系
3、谈谈西方社会和中国传统社会的思维方式各有什么特点？ 答：中国传统社会的思维方式是，观察事物有时是凭直觉、非理性、综合的，他们注重情感诉求；西方社会的思维方式则倾向理性主义、善用逻辑、推理的思考，他们习惯有系统、有秩序地掌握事物的性质。因此，中国传统的思维方式通常特点是精神的、感性的、内向的、综合的、主观的;而西方的思维方式通常特点是物质的、理性的、外向的、分析的、客观的。 1、西方是分析式思维的传统，中国的传统的是直觉思维。 直觉是中国人最常用的思维方式。而直觉是经验的产物，但不一定是逻辑的结果。而西方对于规律的总结，理论之于实践，是西方惯有的思维方式。正是这种差异性，使中国人极具创造力，却没有西方的推广性应用例如，在食物的调味上，中国靠直觉和经验放调味料。而西方就会认真地写下多少分量的食物要放多少调味料。 2、西方式的思维多告诉我们事情的来龙去脉，中国思维则告诉我们如何接受。例如：在教 育上，中国会用很肯定的语气告诉我们不能做，但没有告诉我们为什么。而在西方则会告诉我们为什么不能做这件事。 3、西方式思维是具象，中国式思维是抽象的。 4、西方人善用局部的、解剖的、分析的方法；中国人善于采用整体的、全息的、系统的方法。 中西方思维还有很多差异，这些是客观形成，不能说谁优谁劣，应该相互学习，取长补短。 4、如何才能促使直觉和灵感的产生？ 答：直觉是意识的本能反应，不是思考的结果。直觉思维是以头脑中已有的知识经验 为根据，以大量观察资料为基础，对研究的问题提出合理的猜想和假设或突然顿悟的思维过程，它可以创造性地发现问题、提出新概念、新思想、新理论，是创新思维的主要形式。是基于人类的职业，阅历，知识和本能存在的一种思维形式 灵感，无意识中突然兴起的神妙能力。或指作家因情绪或景物所引起的创作情。在文艺，科技活动中，由于勤奋学习，努力实践，不断积累经验和学识而突然产生的创作冲动或创造能力。灵感:指在文学、艺术、科学、技术等活动中,由于艰苦学习、长期实践,不断累积经验和知识而突然出现的富有创造力的思路灵感，是人们在艺术构思探索过程中由于某种机缘的启发，而突然出现的豁然开朗、精神亢奋，取得突破的一种心理现象。灵感给人们带来意想不到的创造，然而它的产生却是突然而来、倏然而去，并不为人们的理
软件性能测试结果分析总结 平均响应时间：在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。 也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。 定义：指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。 错误状态情况分析：常用的HTTP状态代码如下： 400 无法解析此请求。 401.1 未经授权：访问由于凭据无效被拒绝。 401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。 401.3 未经授权：访问由于ACL 对所请求资源的设置被拒绝。 401.4 未经授权：Web 服务器上安装的筛选器授权失败。 401.5 未经授权：ISAPI/CGI 应用程序授权失败。 401.7 未经授权：由于Web 服务器上的URL 授权策略而拒绝访问。 403 禁止访问：访问被拒绝。 403.1 禁止访问：执行访问被拒绝。 403.2 禁止访问：读取访问被拒绝。 403.3 禁止访问：写入访问被拒绝。 403.4 禁止访问：需要使用SSL 查看该资源。 403.5 禁止访问：需要使用SSL 128 查看该资源。 403.6 禁止访问：客户端的IP 地址被拒绝。
403.7 禁止访问：需要SSL 客户端证书。 403.8 禁止访问：客户端的DNS 名称被拒绝。 403.9 禁止访问：太多客户端试图连接到Web 服务器。 403.10 禁止访问：Web 服务器配置为拒绝执行访问。 403.11 禁止访问：密码已更改。 403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。 403.13 禁止访问：客户端证书已在Web 服务器上吊销。 403.14 禁止访问：在Web 服务器上已拒绝目录列表。 403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。 403.16 禁止访问：客户端证书格式错误或未被Web 服务器信任。 403.17 禁止访问：客户端证书已经到期或者尚未生效。 403.18 禁止访问：无法在当前应用程序池中执行请求的URL。 403.19 禁止访问：无法在该应用程序池中为客户端执行CGI。 403.20 禁止访问：Passport 登录失败。 404 找不到文件或目录。 404.1 文件或目录未找到：网站无法在所请求的端口访问。 需要注意的是404.1错误只会出现在具有多个IP地址的计算机上。如果在特定IP地址/端口组合上收到客户端请求，而且没有将IP地址配置为在该特定的端口上侦听，则IIS返回404.1 HTTP错误。例如，如果一台计算机有两个IP地址，而只将其中一个IP地址配置为在端口80上侦听，则另一个IP地址从端口80收到的任何请求都将导致IIS返回404.1错误。只应在此服务级别设置该错误，因为只有当服务器上使用多个IP地址时才会将它返回给客户端。404.2 文件或目录无法找到：锁定策略禁止该请求。 404.3 文件或目录无法找到：MIME 映射策略禁止该请求。
项目管理：测试需求 1 、熟悉需求背景及商业目标： a) 了解清楚项目发起的原因，是为了解决用户的什么问题。 b) 当前的解决方案是不是的，为什么会这样做。 2 、业务模型法： a) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），。可以参考系统分析说明书。 b) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。 3 、业务场景法： a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注。具体被哪些外部调用，每个产品线都需要自己整理添加。） b) 考虑系统内部各个用例之间的交互（有可能 PD 划分用例的粒度不同，我们暂时考虑用户一次提交并且系统的状态及数据发生变化的功能是一个用例），形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。 4 、功能分解法（对每一个 UC ）： 1). 业务功能：与用户实际业务直接相关的功能或细节。 2). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。 3). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。 4). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷健就是典型的易用性需求。 5). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。 6). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。 7). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。 性能约束：功能的细节，执行功能时，必须满足的性能要求，目前基本不涉及（因为无法量化）。
场景分析法 一、以答题业务为例： 1.答对题目增加题目积分，积分达到设定值时奖励一个礼包； 2.取题规则为随机不重复; 3.答错题目后答新题. 开始答题 是否存在 有效题目 提供题目及备选答案 答案是否 正确 增加题目积分 积分大于或等于设定值？给予无有效题目提示 结束奖励一个礼包
1.确定基本流与备选流 基本流: 步骤1. 开始答题 步骤2. 判断是否存在有效题目，存在有效题目，处理:提供题目及备选答案 步骤3. 用户答题并答对题目，增加用户相应积分。 步骤4. 判断积分是否达到设定值，达到，获取一个礼包，流程结束。 备选流1: 不存在有效题目 基本流步骤2时，题库不存在未答题目，处理：给予无有效题目提示，流程结束。备选流2: 答错题目 基本流步骤3时，答错题目，处理：提示用户答错题目，回到基本流步骤2 备选流3：答题后积分达不到设定值 基本流步骤4时，答对题后积分仍达不到设定值，处理：回到基本流步骤2 2.确定以下用例场景： 3.通过从确定执行用例场景所需的数据元素入手构建矩阵
4.设计数据，把数据填入上面的用例表中 二、下图所示是ATM例子的流程示意图。
2.场景设计：下表所示是生成的场景。 3.用例设计
4.测试用例表
三、用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。 第一步：确定基本流和备选流 基本流：登录在线网站→选择物品→登录账号→付款→生成订单； 备选流1：账户不存在； 备选流2：账户密码错误； 备选流3：用户账户余额不足； 备选流4：用户账户没钱。 第二步：根据基本流和备选流确定场景 场景1成功购物：备选流； 场景2账号不存在：基本流，备选流1； 场景3账号密码错误：基本流，备选流2； 场景4账户余额不足：基本流，备选流3； 场景5账户没钱：基本流，备选流4。 第三步：对每一个场景生成相应的测试用例 测试用例 ID 场景/条件账号密码 用户账 号余额 预期结果 1 场景1：成功购物V V V 成功购物 2 场景2：账号不存在 1 n/a n/a 提示账号不存在 3 场景3：账号密码错误 （账号正确，密码错误）V 1 n/a 提示账号密码错误，返 回基本流步骤3 4 场景4：用户账号余额不 足V V 1 提示用户账号余额不 足，请充值 5 场景5：用户账号没钱V V 1 提示用户账号没有钱， 请充值 第四步：设计测试数据 测试用例ID 场景/条件账号密码 用户账 号余额 预期结果 1 场景1：成功购物Test 123456 800 成功购物，账号余额减少 100元 2 场景2：账号不存在aa n/a n/a 提示账号不存在 3 场景3：账号密码错误 （账号正确，密码错误）Test 111111 n/a 提示账号密码错误，返回 基本流步骤3 4 场景4：用户账号余额不 足Test 123456 50 提示用户账号余额不足， 请充值 5 场景5：用户账号没钱Test 12345 6 0 提示用户账号没有钱，请 充值
性能测试工程师基本上都能够掌握利用测试工具来作负载、压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。分析原则： 1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 2. 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等） 注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 3 分段排除法很有效 分析的信息来源： 1 根据场景运行过程中的错误提示信息 2 根据测试结果收集到的监控指标数据 一．错误提示分析 分析实例： 1 Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection Error: timed out Error: Server “10.10.10.30″has shut down the connection prematurely 分析： A、应用服务死掉。 （小用户时：程序上的问题。程序上处理数据库的问题） B、应用服务没有死 （应用服务参数设置问题） 例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ C、数据库的连接 (1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数（跟硬件的内存有关）) 2 Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成 A、应用服务参数设置太大导致服务器的瓶颈
HUBEI UNIVERSITY OF AUTOMOTIVE TECHNOLOGY 在线考试系统案例分析
目录： 1、导言 现在，计算机硬件技术的发展已经达到了相当高的水平。但是，远程教育软件的开发目前还处于起步阶段，随着这项技术的不断深入发展，就要求有更好、更完善的软件系统应用到远程教育当中去，这就给软件设计人员提出了更高的设计要求。 远程教育包括很多环节，例如教学系统、答疑系统和考试系统等等。其中很重要的一个环节就是在线考试系统，同时它也是最难实现的环节。在我国，虽然远程教育已经蓬勃地发展起来，但是目前学校与社会上的各种考试大都采用传统的考试方式，在此方式下，组织一次考试至少要经过五个步骤，即人工出题、考生考试、人工阅卷、成绩评估和试卷分析。显然，随着考试类型的不断增加及考试要求的不断提高，教师的工作量将会越来越大，并且其工作将是一件十分烦琐和非常容易出错的事情，可以说传统的考试方式已经不能适应现代考试的需要。随着计算机应用的迅猛发展，网络应用不断扩大，如远程教育和虚拟大学的出现等等，且这些应用正逐步深入到千家万户。人们迫切要求利用这些技术来进行在线考试，以减轻教师的工作负担及提高工作效率，与此同时也提高了考试的质量，从而使考试更趋于公证、客观，更加激发学生的学习兴趣。例如目前许多国际著名的计算机公司所举办的各种认证考试绝大部分采用这种方式。在线考试是现阶段研究开发的一个热点。它是建立在国际互联网上的应用系统，客户端的配置可以极为简单，使考试不受地域的局限。一个完备的在线考试系统可以使用户在网上学习过后及时检验自己的学习效果，已发现自己的不足，
使得学习效率得到很大提高。在线考试系统中题目的生成、试卷的提交、成绩的批阅等都可以在网络上自动完成。只要形成一套成熟的题库就可以实现考试的自动化。这样一来，教师所要做的只是精心设计题目、维护题库，而不是组织考试，从而大大减轻了教师的负担，这表明其经济性是相当可观的。为了适应新形势的发展，我进行了这一系统的初步设计工作，也可以说是做一个初步的探索，希望它能够在各类考试中发挥高效、便捷的作用,把老师从繁重的工作中解脱出来！ 2、概述 在线考试系统主要功能包括学生管理、试卷管理、教师管理、学生在线考试等等。在线考试系统是对学校考试方式的优化和改进，是基于INTERNET环境的综合考试系统，方便教师学生进行考试和查询。目的是适应大环境的发展和方便信息的交流，充分利用学校资源，提高工作效率，系统具有标准化、分布式存储和检索、易用易维护开放等特点。 3、项目任务范围 本文主要考虑的是高校内部的在线考试系统，所以因其特殊性并不对所有人开放。系统主要用户可以分为两类：一种是学生用户，一种是教师用户。其中学生用户能使用的功能有：在线考试，成绩查询，修改信息等。教师用户使用的功能有：在线出题，修改成绩，修改试题，成绩查询等 任务分布见图一