2009 上半年软件评测师考试真题及答案-下午卷
试题一
【说明】
软件测试的质量决定着被测产品的质量,是企业关注的重点。
【问题 1】(3 分)
请简要叙述软件测试质量包括哪些管理要素。
•测试过程,例如技术过程、管理过程、支持过程。
•测试人员及组织。
•测试工作文档,例如测试计划、测试说明、测试用例、测试报告、问题报告。
【问题 2】(2 分)
请简要论述软件测试质量控制的主要方法。
•测试文档评审。
•测试活动审核。
•制定质量保证计划。
•采取背靠背测试。
【问题 3】(4 分)
企业衡量软件测试的质量经常采用两个指标:测试用例覆盖率和缺陷修复率,请简述这
两个指标的概念。
测试用例覆盖率=测试需求对应数目/测试需求数目。(2 分)
缺陷修复率=累计关闭的缺陷数/累计打开的缺陷数。(2 分)
【问题 4】(9 分)
企业内部测试组在测试某办公自动化系统的过程中,使用 60 个测试用例进行测试,共
发现了 20 个问题。
开发组对软件修改后,向测试组提交问题修改报告及修改后的软件。问题修改报告中提
出:所发现问题中的 5 个问题是用户所要求的,无需修改,其余 15 个问题已修改完成。
测试组使用针对上轮测试中发现的 15 个问题的 36 个测试用例进行了回归测试,确认问题已
得到修改,因此测试组做出结论:当前版本可以进入配置管理库,进行后续集成工作。
请简要分析测试组的做法是否存在问题并简述理由。
此办公自动化系统提交给用户之后,用户在使用过程中发现了 5 个问题,测试项目经理
打算采用缺陷探测率来对测试人员进行绩效评估。请计算此测试项目的缺陷探测率。
测试组做法存在问题(1 分),理由如下。
(1)•针对取消的 5 个问题:
不对开发组提出取消的 5 个属用户需求问题进行回归测试是错误的。(1 分)
测试组应该将开发组所述的用户需求作为补充说明由用户确认,测试组在回归测试中应对这
5 个问题与开发组进行沟通,并由用户或项目经理确认这 5 个问题是否可以取消,对于不能
取消的问题仍需开发组进行修改并进行回归测试。(2 分)
(2)•针对测试的 15 个问题:
只使用发现问题的 36 个用例进行回归测试是错误的,在修改 36 个测试用例发现的 15 个问
题的过程中,可能引入新的问题,(1 分)
因此应使用全部 60 个用例进行回归测试,或者准确判断这 15 个问题的修改波及到多少个用
例,然后用这些用例来执行回归测试。(2 分)
缺陷探测率=测试人员发现的缺陷数/ (测试人员发现的缺陷数+用户发现的缺陷数)=20/
(20+5) =80%。(2 分)
试题二
【说明】
某“网站稿件管理发布系统”是采用 J2EE 架构开发的 B/S 系统,Web 服务器、应用服
务器以及数据库服务器部署在一台物理设备上。
系统实现的功能主要包括稿件管理和文档上传下载。稿件管理模块可以对稿件进行增
加、查询、删除、修改、显示和批准等操作,批准后的稿件即可在网站上发布;文档上传下
载模块可以将稿件直接以 Word 文档的格式进行上传下载。
系统性能需求如下:
(1)主要功能操作在 5 秒钟内完成;
(2)支持 50 个在线用户;
(3)稿件管理的主要功能至少支持 20 个并发用户;
(4)在 50 个用户并发的高峰期,稿件管理的主要功能,处理能力至少要达到 8trans/S;
(5)系统可以连续稳定运行 12 小时。
【问题 1】(3 分)
简要叙述“网站稿件管理发布系统”在生产环境下承受的主要负载类型。
“网站稿件管理发布系统”在生产环境下承受的主要负载类型有:
(1)并发用户的操作属于并发执行负载。
(2)连续稳定运行 12 小时属于疲劳强度负载。
(3)大量稿件的查询操作属于大数据量负载。
【问题 2】(3 分)
简要叙述进行“网站稿件管理发布系统”的性能测试中应测试的关键指标。
在进行“网站稿件管理发布系统”的性能测试中应测试的关键指标包括:
(1)并发用户数。某一物理时刻同时向系统提交请求的用户数。
(2)事务执行响应时间。是系统完成事务执行准备后所采集的时间戳和系统完成待执
行事务后所采集的时间戳之间的时间间隔,是衡量特定类型应用事务性能的重要指标,标志
了(2)用户执行一项操作大致需要多长时间。
(3)交易执行吞吐量(trans/s)。每秒钟执行的业务数,或系统服务器每秒钟能够处
理的交易数。
【问题 3】(3 分)
请简述访问系统的“在线用户”和“并发用户”的区别。
并发用户:指某一物理时刻同时向系统提交请求的用户。
在线用户:指在某段时间内访问系统的用户,这些用户并不一定同时向系统提交请求。
【问题 4】(3 分)
系统性能需求中要求“系统可以连续稳定运行 12 小时”,若系统连续运行 12 小时完成
的总业务量为 1000 笔,系统能够提供的最大交易执行吞吐量为 200 笔/小时,试设计测试周
期,并说明理由。
系统连续运行 12 小时完成的总业务量为 1000 笔,系统能够提供的最大交易执行吞吐量
为 200 笔/小时,因此系统吞吐量在极限情况下,完成 1000 笔业务需要的时间就是测试周期,
BP 1000/200=5 小时。
原因:在增加单位时间的负载情况下,需要缩短测试周期,保证系统在 12 小时内的总
业务量。
【问题 5】(8 分)
下图为并发 50 个用户执行“稿件查询”操作的测试结果。
(1)请判断结果是否满足系统性能需求并说明理由。
(2)简要说明 Transactions per Second 与 Average Transaction Response Time 之间
的关系。
(1)交易执行响应时间平均值为 10.936 秒,与需求“主要功能操作在 5 秒钟内完成”
不符合,不满足测试需求。
交易执行吞吐量(trans/s)平均值为 3.75,与需求“稿件管理的主要功能在 50 用户并
发的高峰期,性能最低达到 8trans/s”不符合,不满足测试需求。
从服务器资源的使用情况来看,CPU、内存、硬盘的资源利用率都比较低,无硬件方面
的瓶颈。
(2)二者都是体现系统的交易执行效率。
在系统性能比较稳定的情况下,随着负载增加 Transactions per Second 会基本保持不
变,而 Average Transaction Response Time 会递增。
试题三
【说明】
场景法是黑盒测试中重要的测试用例设计方法。目前多数软件系统都是用事件触发来控
制业务流程,事件触发时的情景便形成了场景,场景的不同触发顺序构成用例。场景法通过
场景描述业务流程(包括基本流(基本流程)和备选流(分支流程)),设计用例遍历软件系
统功能,验证其正确性。
下面是对网上银行支付交易系统的基本流和备选流的描述:
注:假定输入的银行卡号是正确的;不考虑备选流内循环情况。
【问题 1】
使用场景法设计测试用例,指出所涉及到的基本流和备选流。基本流用字母 A 表示,备
选流用题干中描述对应编号表示。
根据题目中已经确定的基本流与备选流,可以设计场景,每个场景覆盖一种在该案例中
事件的不同触发顺序与处理结果形成的事件流,最后得出所有的测试用例。下面就是所有的
测试用例和用例中所涉及的基本流与备选流。
用例 1:A
用例 2:A、B
用例 3:A、C
用例 4:A、D
用例 5:A、B、C
用例 6:A、B、D
以上顺序可以互换。
【解析】
本题主要考查黑盒测试中的场景法测试用例设计。
采用场景法来设计测试用例,其基本思想和依据是站在用户的角度上检测软件的功能,发现
软件的错误。
基本流是指经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)。备选流
是指:一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中;也
可以起源于另一个备选流;或者终止用例而不再加入到基本流中(一般是各种错误情况)。
使用场景法设计测试用例的基本步骤如下:
(1)根据规格说明,描述出程序的基本流及各项备选流。
(2)根据基本流和备选流确定场景。
(3)对每一个场景生成相应的测试用例,可以采用矩阵或决策表来确定和管理测试用例。
(4)对生成的测试用例进行复审,去掉多余或等价的测试用例,然后确定实际测试数据。
在本题中,根据题目中已经确定的基本流与备选流,可以设计场景,每个场景覆盖一种在该
案例中事件的不同触发顺序与处理结果形成的事件流,最后得出所有的测试用例。下面就是
所有的测试用例和用例中所涉及的基本流与备选流。
用例 1:A
用例 2:A、B
用例 3:A、C
用例 4:A、D
用例 5:A、B、C
用例 6:A、B、D
【问题 2】
请针对问题 1 设计的测试用例,依次将银行卡号、初次输入密码、最终输入密码、卡内
余额、银行卡可支付额度等信息填入下述测试用例表中。表中行代表各个测试用例,列代表
测试用例的输入值,用 V 表示有效数据元素,I 表示无效数据元素,n/a 表示不适用,例如
C01 表示“成功支付”用例。
根据“问题 1”得到的测试用例,按照问题二的提示和要求,可以得出下面的场景分
析表。
每行顺序可以互换。
【解析】
本题要求我们根据问题 1 设计的测试用例来完成本题的问题,那么根据题目的意思,CO2
对应用例 2,那么这个时候存在密码不正确的错误,根据备选流 B 的描述,可知初次输入密
码处应该是 I(表示无效数据),而后面的操作肯定是都没用(n/a);而 C03 对应用例 3,这
个时候存在卡内余额不足的错误,因此银行卡可支付额度没用(n/a);同理可以求得后面个
用例的情况,具体可参加答案。
【问题 3】
在上述系统中,假设银行卡号只能输入 0〜9 的数字,请参考下表,给出用边界值法检
查卡号字符合法性的关键测试数据(字符或 ASCII 值)。