软件测试工程师面试题汇总（华为篇）1、怎么来设计测试方案根据测试需求（包括功能需求和非功能性需求），识别测试要点，识别测试环境要求，安排测试轮次，根据项目计划和开发计划做整体的测试安排。

被测试的特性：通过对需求规格说明书进行分析，列出本次测试需要进行测试的各部分特性（如要测试的功能需求、性能需求、安全性需求等等）。

不被测试的特性：由于资源、进度等方面原因，本次测试不列入测试范围的特性。

测试组网图：进行本次系统测试所需要的软硬件设备、配置数据及相互间的逻辑、物理连接。

今后测试执行时需要依据这个组网图来进行环境的搭建。

2、如果给你一个B/S系统你怎么来进行测试此题答案还可用于回答测试流程，测试流程题亦可参考15题。

阅读系统需求，充分理解需求，记录问题，并与项目需求人员充分沟通。

编写测试需求，包括系统功能和非功能测试要点、罗列测试类型、测试进度、质量要求等。

制定测试计划，包括熟悉测试业务、设计测试用例、执行测试用例、进行测试小结、编写测试报告，任务颗粒度一般应小于5人天编写测试用例，根据测试方案设计用例，即便没有明确的性能和安全测试要求，也应识别进行此两项测试。

执行软件测试。

进行测试小结，如果测试持续时间较长，每个版本间隙总结本轮测试。

编写测试报告，总结测试过程，汇总度量数据。

3、怎么进行工作流的测试把握需求，找准结点，理清流程，画出流转图，弄清节点间的数据流转，设计测试用例的时候必须覆盖所有可能的流程。

工作流：如果问到有没有做过，根据对工作流的了解情况回答，如果比较了解，可以把参与的某个项目中说上一些有工作流的，如果不是很了解就说没有做过，但是学习过相关知识。

4、做性能测试的时候都需要关注哪些参数并发访问量，服务器响应时间（最小、平均、最大）并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。

负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。

负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。

压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。

如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。

还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。

大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。

大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

5、客户没给性能指数，怎么开展性能测试如果客户没有提出明确的性能指标，可以按照惯例和经验设置，需要和项目经理协商，一般由项目经理确认，质量保证负责给出建议。

举例说一个Server端程序，要求峰值时CPU和MEM消耗在75％以下，而一个页面的访问响应时间一般认为用户的忍耐时间是3－5秒以内，这些要参考实际的应用来确定用户规模、操作频率、同时在线数等。

6、有没有做过接口测试，是如何做的通过编写测试程序，获得接口指针，逐个调用接口函数验证其正确性，及失败操作7、测试过程中是如何来保证软件质量的测试用例编写完毕后要加强评审的力度，确保测试用例覆盖所有需求点执行测试过程中注意做小结检查覆盖情况、审视所提缺陷质量，复测时应注意相关模块的测试测试时间宽裕的话可以做交叉测试，用以确保测试质量。

8、测试方案都写什么内容1 概述2 被测对象分析3 应测试的特性4 不被测试的特性5 总体设计方法6 测试模型6.1 测试组网图6.2 结构/对象关系图6.3 测试原理6.4 操作规程7 测试需求7.1 环境需求7.2 被测对象需求7.3 测试工具需求7.4 测试代码需求7.5 数据需求7.6 其它需求8 测试设计8.1 工具设计8.2 测试代码设计8.3 用例设计8.3.1 设计原则8.3.2 测试项目9.附录（测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案）以往华为测试方案目录如下：第1章技术方案1.1. 测试需求描述1.1.1. 测试类型分析1.1.2. 测试内容1.2. 缺陷分类1.3. 缺陷级别第2章 SOW及规格的应答2.1. 测试需求应答2.2. 交付件应答2.2.1. 软件交付件应答2.2.2. 非软件交付件应答2.3. 项目里程碑项目完成时间应答2.4. 质量目标应答2.5. 验收标准应答2.6. 限制应答2.6.1. 合作供应商人员组织应答2.6.2. 硬件设备应答2.6.3. 合作项目开发场地应答第3章类似项目成功案例第4章项目详细工作计划第5章项目估算9、测试方案和测试计划的区别测试方案是技术性的；测试计划更多是管理性的。

测试计划主要要考虑测试的技术可行性、关键技术、资源投入、进度安排、风险管理、配置管理、输入输出等。

测试计划更多地供高层管理者决策时做参考；同时对后续测试工作开展起指导作用。

在一些小项目中，可能只需要一个测试方案，测试计划内容相对较少，可以与测试方案合并进行；而一些大项目中，也许要设计数十个测试方案，这就需要一个提纲挈领的东西了，这就是测试计划的作用。

10、测试用例是根据什么写的系统测试用例根据需求和设计编写（华为的SDV测试用例是根据《测试方案》和测试策略来编写的）11、是怎么来设计测试用例的？答：先熟悉系统需求，把握测试要点，设计用例的原则首先是要覆盖每个需求点，可以通过填写需求跟踪矩阵来保证覆盖。

黑盒测试的测试用例设计方法：等价类划分法、边界值分析法、错误推测法、因果图。

12、有没有测过手机终端的项目根据实际情况回答，如果没有测试过，可以回答，公司有过类似业务。

手机终端测试13、对测试工作的认识答：软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。

软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。

软件测试是为了发现错误而执行程序的过程。

软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。

编码和单元测试属于软件生命周期中的同一个阶段。

在结束这个阶段后对软件系统还要进行各种综合测试，这是软件生命周期的另一个独立阶段，即测试阶段。

华为独立外包测试一般包括ST（系统测试）和SDV（详细设计验证）两个阶段。

14、缺陷是怎么管理的答：我们采用了Rational ClearQuest来管理缺陷。

测试人员执行测试，发现缺陷，录入CQ，要求填写项目名称、子系统名称、模块名称、缺陷标题、缺陷描述（描述场景、现象）、缺陷级别、提出人等。

状态：已提交。

项目经理或开发组长确认缺陷后分配给开发人员，状态：已分配。

开发人员修复缺陷完成后，将修复缺陷所花费的时间填写的Schedule中，缺陷的产生原因填写在备注中，因采用UCM模式，所有造成该缺陷的错误代码文件，在UCM视图中可以统计。

状态：已处理。

测试人员复测，如缺陷已经修复，则关闭缺陷，状态：已关闭。

如缺陷仍然存在，则修改状态为已分配。

当缺陷存在争议时，开发组长或开发人员可以申请否决，由项目经理、技术经理、测试负责人、相关开发人员和测试人员共同决定缺陷是否可以否决。

状态：已申请否决、已否决。

当前不能修复，或当前版本无法解决的缺陷可以申请延期，状态：已申请延期、已延期。

15、介绍一下测试流程答：项目启动后进行需求培训，测试人员尽早的参与到项目需求的培训和评审，也就是测试工作应该从需求阶段开始介入。

项目经理编写《项目计划》，开发人员产出《需求规格说明书》，这时测试组长就要根据《项目计划》开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，进度安排和风险识别等内容。

《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理。

测试组长需要根据评审意见修改《测试计划》，并上传到CC上，由配置管理员管理。

待开发人员把《需求规格说明书》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员；测试组长组织测试成员修改测试方案，直到评审通过后才进入下个阶段――编写测试用例。

测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。

这时开始编写用例才能保证用例的可执行和对需求的覆盖。

测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。

其中操作步骤和预期结果需要编写详细和明确。

测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。

同样，测试用例也需要通过开发人员，测试人员的评审，测试组长也需要组织测试人员对测试用例进行修改，直到评审通过。

在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。

提交测试中心后根据《测试计划》进度安排，测试组长组织进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。

待到开发修改完bug并转来新的测试版本，测试人员开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。

16、一个关于测试方案评审的分歧我们原本的流程是完成方案包括用例后进行评审，华为的建议是，在测试方案（即测试人员总结出测试重点等）之后，即进行评审，不能等全部用例完成。

关于版本缺陷密度的问题：问有没有统计。

如果CQ中正常登记的话，是可以利用工具统计出来。

CQ 还可以根据需要定制查询。

关于测试提交标准：我讲了公司的标准，他说客户也会有自己的标准。

我回复说是可以依据客户标准进行调整，17、Unix系统熟识，运用Informix 数据库。