2026年上半年软件评测师考试应用技术真题（专业解析+参考答案）

2026年上半年软件评测师考试应用技术真题（专业解析+参考答案）一、阅读下列说明，回答问题1至问题4。【说明】某公司开发一款在线教育平台的移动端应用（App），主要功能包括用户注册登录、课程浏览与购买、视频播放、在线测试、学习社区互动等。现计划对该App进行系统性的非功能测试，以评估其性能、安全性、兼容性及用户体验。问题1：针对该在线教育App，请列出至少5项需要执行的非功能测试类型，并简要说明每项测试的主要关注点。问题2：在性能测试中，需要模拟“课程开售瞬间”的高并发场景。请设计该性能测试场景的主要指标和测试策略。问题3：在安全性测试中，针对“用户登录”和“在线支付”两个功能，分别列举至少3项应重点测试的安全漏洞或风险点。问题4：为评估App在不同终端上的兼容性，请设计兼容性测试的测试矩阵，需考虑操作系统、屏幕尺寸、网络环境三个维度。二、阅读下列说明，回答问题1至问题3。【说明】某银行系统新增一个“大额交易预警”模块。该模块的规格说明如下：系统需监控单笔转账交易金额，当金额大于或等于10万元人民币时，需实时触发预警，并将预警信息（包含交易流水号、账号、金额、时间）记录至预警日志表；同时向风险管控员的监控终端发送提示消息。若交易金额小于10万元，则不进行任何操作。问题1：请根据上述规格说明，绘制该“大额交易预警”模块的因果图，并最终导出对应的判定表。原因：C1:单笔交易金额>=10万元；结果：E1:记录预警日志，E2:发送提示消息。问题2：根据问题1生成的判定表，设计相应的测试用例，需覆盖所有有效规则。问题3：现发现规格说明存在二义性：未明确“等于10万元”时是否触发预警。请分析此二义性可能引发的缺陷，并说明如何通过需求评审避免此类问题。三、阅读下列说明，回答问题1至问题4。【说明】以下是某“用户信息管理”模块中“修改手机号”功能的Java代码片段（伪代码），该功能要求用户先输入原手机号验证码，验证通过后方可绑定新手机号。```javapublicclassUserService{publicResultchangePhoneNumber(StringuserId,StringoldPhone,StringnewPhone,StringinputCaptcha){Resultresult=newResult();//1.参数基础校验if(userId==null||oldPhone==null||newPhone==null||inputCaptcha==null){result.setCode(400);result.setMsg("参数不能为空");returnresult;}//2.获取用户原手机号及系统发送的验证码Useruser=userDao.getUserById(userId);StringstoredCaptcha=cache.get("CAPTCHA_"+oldPhone);//从缓存获取原手机号对应的验证码//3.验证原手机号是否与账户绑定if(!oldPhone.equals(user.getPhoneNumber())){result.setCode(401);result.setMsg("原手机号与账户绑定不一致");returnresult;}//4.验证验证码if(!inputCaptcha.equals(storedCaptcha)){result.setCode(402);result.setMsg("验证码错误");returnresult;}//5.更新为新手机号user.setPhoneNumber(newPhone);booleanupdateSuccess=userDao.updateUser(user);if(updateSuccess){cache.delete("CAPTCHA_"+oldPhone);//清除旧验证码result.setCode(200);result.setMsg("手机号修改成功");}else{result.setCode(500);result.setMsg("系统错误，更新失败");}returnresult;}}```问题1：请采用白盒测试方法，绘制出该`changePhoneNumber`方法的程序控制流图。问题2：根据问题1的控制流图，计算其环形复杂度（圈复杂度），并列出所有独立的线性无关路径。问题3：针对此代码段，设计3个黑盒测试用例，要求使用等价类划分或边界值分析方法，并说明所用方法及用例设计思路。问题4：代码中存在一处与缓存数据安全相关的潜在缺陷，请指出该缺陷并说明可能造成的后果。四、阅读下列说明，回答问题1至问题2。【说明】某电子商务网站进行压力测试，模拟用户“搜索商品”和“提交订单”两个核心业务操作。测试工具在1小时内逐步增加并发用户数，持续运行。部分关键性能计数器数据如下表所示：时间区间(分钟)并发用户数平均响应时间(秒)吞吐量(事务/秒)CPU利用率(%)内存使用率(%)0-10501.241.5455010-201001.566.7655520-302002.0100.0806030-403003.585.7927540-504008.050.0988550-6040015.026.79990问题1：请根据上表数据，分析系统性能拐点出现的大致时间区间，并描述拐点前后系统性能表现的变化及其可能原因。问题2：请计算在并发用户数为200时，系统的资源利用率（CPU）是否处于理想区间？结合响应时间和吞吐量，对该时间点的系统性能状况进行简要评价。五、阅读下列说明，回答问题1至问题3。【说明】测试团队对某物联网设备的嵌入式软件进行测试。该软件通过传感器采集温度数据，并根据规则进行告警。部分需求如下：规则1：若连续3次采集的温度值均高于阈值T（T=30℃），则触发高温告警。规则2：高温告警触发后，若后续连续2次采集的温度值均低于阈值T，则告警解除。规则3：数据采集周期固定为5秒一次。问题1：请根据规则1和规则2，设计一个状态迁移图，描述“正常”、“高温预警”、“高温告警”三个状态之间的转换条件。问题2：基于问题1的状态迁移图，设计测试用例以实现状态覆盖。问题3：若在测试过程中，需要模拟传感器采集到一系列特定的温度值序列（如：32℃，31℃，33℃，29℃，28℃）来验证告警逻辑，请说明你将采用什么测试技术来设计这些测试数据，并简述该技术的原理。答案与解析一、【问题1解析】1.性能测试：关注点：评估系统在特定负载下的响应时间、吞吐量、资源利用率（CPU、内存、I/O）、并发用户支持能力。例如，视频播放的流畅度、页面加载速度、多人同时在线测试的稳定性。2.安全性测试：关注点：识别系统漏洞，防止未授权访问、数据泄露、恶意攻击。例如，用户身份认证、支付交易安全、SQL注入、跨站脚本（XSS）、敏感数据加密传输与存储。3.兼容性测试：关注点：验证App在不同软硬件环境下的正常工作能力。例如，在不同操作系统版本（iOS/Android各版本）、不同厂商设备、不同屏幕分辨率、不同网络类型（4G/5G/Wi-Fi）下的功能与界面显示。4.易用性/用户体验测试：关注点：评估App是否易于学习、使用高效、用户界面友好。例如，操作流程是否符合直觉，导航是否清晰，文本是否易读，色彩对比度是否合适，是否支持无障碍访问。5.可靠性测试：关注点：评估系统在长时间运行或异常条件下保持正常服务的能力。例如，App长时间运行是否内存泄漏，网络中断后恢复连接的能力，处理异常输入时的健壮性。（其他合理类型如：稳定性测试、负载测试、压力测试、安装/卸载测试等也可得分）【问题2解析】主要指标：响应时间：关键操作（如点击“立即购买”、跳转至支付页面）在并发下的平均响应时间、90%百分位响应时间。吞吐量：每秒成功完成的“课程购买”事务数。并发用户数：同时尝试购买课程的最大虚拟用户数。资源利用率：服务器端CPU、内存、磁盘I/O、网络带宽使用率。错误率：事务失败或报错的比例。测试策略：负载模型：采用“尖峰冲击”模型，在极短时间内（如1分钟内）将并发用户数从正常水平迅速提升至预估峰值（如5000-10000用户），并持续一段时间。场景设计：模拟用户完整业务流程：登录->进入课程详情页->点击购买->选择支付方式->确认支付。监控要点：重点监控数据库连接池、应用服务器线程池、支付接口网关、缓存服务（如Redis）的状态。瓶颈定位：通过分析资源监控和事务响应时间，定位性能瓶颈是在应用服务器、数据库还是外部接口。【问题3解析】用户登录：1.弱口令与暴力破解：测试系统是否对弱密码有策略限制，是否有验证码或登录失败锁定机制防止暴力破解。2.会话管理漏洞：测试会话令牌（Session/Cookie）的生成是否安全，是否具备超时失效机制，注销后令牌是否立即失效。3.敏感信息泄露：测试登录失败提示信息是否过于详细（如区分“用户名错误”和“密码错误”），是否可能被用于枚举用户。在线支付：1.中间人攻击与数据篡改：测试支付请求和响应数据是否在传输过程中被加密（如HTTPS），支付金额等关键参数在客户端是否可被篡改。2.重复提交/重复支付：测试网络延迟或用户重复点击时，系统是否有幂等性处理机制，防止同一订单重复扣款。3.支付信息泄露：测试支付过程中涉及的银行卡号、CVV等敏感信息是否在日志、缓存或前端代码中明文泄露。【问题4解析】操作系统(OS)屏幕尺寸/分辨率网络环境Android12小屏(e.g.,5.5英寸,720×1280)4G网络Android13中屏(e.g.,6.2英寸,1080×2340)5G网络Android14大屏/平板(e.g.,10英寸,2560×1600)Wi-Fi(稳定)iOS15小屏(e.g.,iPhoneSE)弱网环境(3G/高延迟)iOS16中屏(e.g.,iPhone14)网络切换(Wi-Fi<->蜂窝数据)iOS17大屏(e.g.,iPadPro)（注：矩阵需体现三个维度的组合，具体版本和型号可调整，但需覆盖主要类型和边界情况。）二、【问题1解析】因果图：原因：C1:金额>=10万结果：E1:记录日志，E2:发送消息关系：C1为1时，E1和E2同时为1；C1为0时，E1和E2同时为0。这是一个恒等关系。判定表：规则12条件C110动作E1√E2√（注：规则1：C1为真；规则2：C1为假。“√”表示执行该动作。）【问题2解析】根据判定表，设计2个测试用例：1.测试用例ID:TC_ALERT_001输入/条件:单笔转账交易金额=150,000元预期结果:系统记录预警日志，并向监控终端发送提示消息。2.测试用例ID:TC_ALERT_002输入/条件:单笔转账交易金额=50,000元预期结果:系统不记录预警日志，也不发送提示消息。【问题3解析】可能引发的缺陷：开发人员对需求理解不同可能导致实现不一致。例如，开发人员A认为“大于或等于”包含10万元，会触发预警；开发人员B认为“大于”10万元才触发，导致“等于10万元”的交易被漏报，产生功能缺陷，使风险监控出现漏洞。如何避免：在需求评审阶段，应要求需求提出方对“大于或等于”、“超过”、“不低于”等边界条件进行明确、无歧义的定义。最好使用数学表达式（如金额三、【问题1解析】控制流图节点（简化表示）：1.方法开始->2.参数非空校验（IF）->(3.失败返回/4.成功继续)4.->5.查询用户及验证码->6.验证原手机号绑定（IF）->(7.失败返回/8.成功继续)8.->9.验证验证码（IF）->(10.失败返回/11.成功继续)11.->12.更新手机号（IF更新成功）->(13.清除缓存，设置成功返回/14.设置失败返回)14./13./10./7./3.->15.方法返回。（注：应绘制出图形，此处用文字描述节点与分支逻辑。图形包含1个起点，1个终点，多个判断节点和过程节点。）【问题2解析】环形复杂度V(G)：通过控制流图计算，判断节点有：节点2（参数校验）、节点6（手机号验证）、节点9（验证码验证）、节点12（更新成功判断）。共4个判断节点。V(G)=P+1=4+1=5。（其中P为判断节点数）独立路径（示例）：1.1-2-3-15（参数为空，失败返回）2.1-2-4-5-6-7-15（原手机号不匹配，失败返回）3.1-2-4-5-6-8-9-10-15（验证码错误，失败返回）4.1-2-4-5-6-8-9-11-12-14-15（更新数据库失败，返回系统错误）5.1-2-4-5-6-8-9-11-12-13-15（所有步骤成功，修改成功）【问题3解析】1.用例1（等价类划分-有效等价类）：方法：有效等价类组合。思路：所有输入参数均有效且正确。输入：`userId`=“U001”，`oldPhone`=（与用户绑定一致），`newPhone`=，`inputCaptcha`=“123456”（与缓存中`oldPhone`对应的验证码一致）。预期结果：返回code=200，手机号更新成功。2.用例2（边界值分析-原手机号验证）：方法：边界值（边界为“一致”与“不一致”）。思路：测试原手机号与账户绑定手机号“不一致”的边界情况。输入：`userId`=“U001”，`oldPhone`=（与用户绑定的差一位），`newPhone`=，`inputCaptcha`=任意值。预期结果：返回code=401，提示原手机号不一致。3.用例3（等价类划分-无效等价类）：方法：无效等价类（参数为空）。思路：测试`userId`为空的无效情况。输入：`userId`=null，`oldPhone`=，`newPhone`=，`inputCaptcha`=“123456”。预期结果：返回code=400，提示参数不能为空。【问题4解析】潜在缺陷：验证码`storedCaptcha`从缓存中获取，但缓存键`"CAPTCHA_"+oldPhone`依赖于用户输入的`oldPhone`参数。后果：攻击者可能通过枚举或猜测其他用户的手机号作为`oldPhone`参数传入，从而尝试获取该手机号对应的验证码缓存键。如果缓存服务（如Redis）未做严格的访问隔离或密钥混淆，可能存在信息泄露风险，或与后续的验证码验证逻辑结合，可能产生逻辑漏洞。更安全的做法是使用与用户ID强关联的键，例如`"CAPTCHA_"+userId`。四、【问题1解析】性能拐点区间：大致出现在30-40分钟这个时间区间。变化及可能原因：拐点前（0-30分钟）：随着并发用户数从50增加到200，平均响应时间平缓上升（1.2s->2.0s），吞吐量线性增长（41.5->100.0），CPU利用率同步上升。系统处于性能稳定区，资源增加有效处理了更多负载。拐点处及之后（30-60分钟）：当并发用户达到300时，响应时间显著增加至3.5秒（增幅75%），而吞吐量不增反降（100.0->85.7）。当并发达到400时，响应时间急剧恶化至8秒甚至15秒，吞吐量暴跌至50.0和26.7，同时CPU利用率持续高于90%，内存使用率也持续攀升。这表明系统已进入性能瓶颈区，可能原因包括：1.系统资源耗尽：CPU接近饱和，导致线程调度等待，处理能力下降。2.内部资源竞争：可能数据库连接池耗尽、磁盘I/O瓶颈、或应用服务器内部锁竞争加剧。3.系统开始出现大量错误或超时，导致有效吞吐量下降。【问题2解析】资源利用率评价：并发用户数为200时，CPU利用率为80%。通常，对于在线事务处理（OLTP）系统，CPU利用率在70%-80%左右被认为是相对理想且有一定余量的区间。此时系统资源得到较好利用，同时还有一定的缓冲能力应对负载波动。性能状况简要评价：在并发200用户时，系统平均响应时间为2.0秒，吞吐量为100事务/秒。从业务角度看，2秒的响应时间对于“搜索”和“下单”操作可能处于可接受的上限或略偏高，但结合高达100的吞吐量，表明系统在该负载下处理能力较强，效率尚可，但响应速度已开始显现压力。需要关注响应时间的增长趋势，并考虑优化。五、【问题1解析】状态：S0:正常，S1:高温预警（可选，但题目要求三个状态，此处将“连续两次高于阈值但未满三次”视为预警状态，或根据规则直接定义为：S0:正常，S1:高温告警，S2:告警解除中？但根据规则，更精确的三状态是：正常、告警、待解除。为符合题目，调整规则解释或设计）（根据给定规则，更准确的状态迁移图如下）：状态：Normal(正常)Alerting(高温告警)Recovering(恢复中)(这是一个中间状态，表示告警后已采集到一次低于T的温度)迁移条件：Normal->Alerting:连续3次温度>T。Normal->Alerting:连续3次温度>T。Alerting->Recovering:1次温度<=T。(进入恢复检查状态)Alerting->Recovering:1次温度<=T。(进入恢复检查状态)Recovering->Normal:再1次温度<=T。(连续2次低于T)Recovering->Normal:再1次温度<=T。(连续2次低于T)Recovering->Alerting:1次温度>T。(恢复检查被打断，重新满足告警条件？但规则2要求“连续2次低于T”才解除，因此一次高于T应重置恢复计数。更严谨的FSM需要计数器。)Recovering->Alerting:1次温度>T。(恢复检查被打断，重新满足告警条件？但规则2要求“连续2次低于T”才解除，因此一次高于T应重置恢复计数。更严