发布时间 : 星期四 文章2005-2011年软件评测师下午试题及答案 - 图文更新完毕开始阅读
案例分析试题五 【问题1】
测试准备成本 测试执行成本 测试结束成本 【问题2】
缺陷探测率＝测试者发现的错误数/(探测者发现的错误数+客户发现并反馈给技术支持人员进行修复的错误数) 【问题3】
质量成本项 测试成本项 测试人工费 测试投资 环境使用费 测试工具费 测试总投资 单元测试 发现缺陷数 自动测试 50000 10000 15000 （75000） 80 29
每个缺陷成本 内部（开发）缺陷成本 发现缺陷数 独立测试 每个缺陷成本 内部（测试）缺陷成本 发现缺陷数 回归测试 每个缺陷成本 外部缺陷成本 一致性成本 质量成本 非一致性成本 总质量成本 DDP
缺陷探测率 100 （8000） 215 400 （86000） 5 4000 （20000） （75000） （114000） （189000） （98.3％） 2008年5月软件评测师下午试卷
试题一（18 分）（验收测试及缺陷的管理 课本2-4章节）
阅读以下说明，回答问题 1 至问题 4，将解答填入答题纸的对应栏内。 [说明]
某软件企业内部测试部门对其 ERP 产品进行内部测试之后，由第三方测试机构进行验收测试，重点测试的质量特性包括：功能性、可靠性、易用性、效率、维护性以及可 移植性。 [问题 1]（2 分）
验收测试的依据是什么？验收测试对测试环境有何要求？ [问题 2]（2 分）
软件产品的功能性测试中应关注哪些子特性？ [问题 3]（9 分）
在实际的软件测试过程中，对缺陷的管理与分析至关重要。回答如下问题：
（1）针对本测试，Bug 的错误类型除了功能性错误外，还可能会包括哪些？（3 分） （2）严重性级别是 Bug 的重要属性，请写出常见的功能性 Bug 的严重性级别层次（3 分）。 （3）在测试过程中 Bug 的处理会处于不同的状态，请设计 Bug 管理中从发现到关闭必须经历的状态名称（3 分）。 [问题 4]（5 分）
企业内部测试部在测试“主生产计划制定”模块过程中，使用 30 个测试案例进行测试，共发现 10 个问题。开发组对软件修改后，向测试组提交问题修改报告及修改后 的软件。问题修改报告中提出：其中 3 个问题是用户需求，不是错误，无需修改，其余 7 个问题已修改完成。测试组使用上轮测试中发现这 7 个问题的 5 个测试案例进行了回 归测试，确
30
认问题已得到修改，因此测试组决定，当前版本可以进入配置管理库，进行后续集成工作。测试组的做法是否有问题？为什么？如果有问题，应写出正确的做法。 参考答案： 【案例分析】 [任务1]
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。 生产环境，或者软硬件配置接近生产环境的模拟环境。 [任务2]
① 适合性：软件为指定的任务和用户目标提供一组合适功能的能力。 ② 准确性：软件提供所需精确度的正确或相符结果及效果的能力。
③ 互操作性/互用性：软件产品与一个或更多规定系统进行交互的能力。 ④ 保密安全性：软件产品保护信息和数据的能力。
⑤ 功能依从性：软件依从同功能性相关的超标准、约定或法规的能力。 [任务3]
（1） Bug的错误类型除了功能性错误外，还包括：
可靠性错误，易用性错误，效率性错误，维护性错误以及移植性错误
（2） 常见的功能性 Bug 的严重性级别层次 致命，严重，一般，建议的
① 致命:系统崩溃、数据丢失、数据毁坏。
② 较严重：操作性错误、错误结果、遗漏功能。 ③ 一般:小任务、错别字、UI布局、罕见错误。 ④ 建议的：不影响使用的瑕疵或更好的实现。
（3） Bug错误的状态 新信息NEW），打开（OPEN），修正（FIXED），拒绝（DECLINED），关闭（CLOSED） ①新信息（NEW）：测试中新报告的软件BUG ②打开（OPEN）：被确认并分配给相关开发人员处理 ③修正（FIXED）：开发人员已完成修正，等待测试人员验证 ④拒绝（DECLINED）：拒绝修改BUG ⑤延期（DEFERRED）：不在当前版本修复的错误，下一版本修复 ⑥关闭（CLOSED：BUG已被修复 [任务4]
测试组做法存在任务，错误如下： 针对取消的3个任务：
这3个任务应该将这3个任务作为补充说明交用户确认需求，测试组在回归测试中应对这3个任务与开发组进行沟通，并由用户或项目经理确认这3个任务是否可以取消，对于不能取消的任务仍需开发组进行修改并进行回归测试。 针对测试的`7个任务：
只使用发现任务的5个案例进行回归测试是错误的，在修改这些任务的过程中，可能引入新的任务。
因此应使用全部30个案例进行回归测试。
31
试题二（20 分）（负载压力测试 课本P232）
阅读下列说明，回答问题 1 至问题 5，将解答填入答题纸的对应栏内。 [说明]
信息系统测试中，系统的时间特性、资源利用性等是衡量其效率的重要指标。在软件测试中我们通常会借助于自动化负载压力测试考核系统在一定的大用户量访问、长时 间运行、大数据量处理的使用场景下系统的性能是否满足需求，在不满足的情况下通过 故障诊断和性能调优的手段，获得系统性能的提升。
下图是某网上报名系统的负载压力测试拓扑图，主要包括数据库服务器、应用服务器、网络设备、负载均衡设备以及测试用机。测试环境网络带宽 100M，应用服务器选择 Apache Tomcat 5.0，数据库服务器选择 Oracle 10G，两类服务器操作系统都采用 Windows 2000 Server（SP4）。
负载压力测试中模拟大量考生通过此系统执行网上报名，主要测试用例包括“考生注册”和“预定座位”，报名操作的顺序是先执行“考生注册”，再执行“预定座位”。系统性能要求能够承受 10000 用户并发访问，业务执行成功率保持在 80％以上。下表是测试结果数据，其中数据库服务器资源利用属合理范围，网络带宽足够，未在结果中描 述。
32