从业多年测试人员总结软件测试常见问题（笔试、面试）

lsekfe

1、什么是软件测试？其目的是什么？你怎么看待软件测试？
　　是为了发现错误而执行程序的过程。在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
　　目的是暴露程序中的错误。发现测试对象与预期的差异。具体地不同测试阶段对应不同测试目的。
　　软件测试工作者要站在用户的额角度思考问题，从用户的实际使用环境、习惯着手验证被测对象应用表现。与软件开发的创造性思维不同，软测活动的思维模式则是破坏性的通过构建正常、异常输入去考验被测对象的健壮性。测试工作是一项极其重要的质量保证活动。因为测试部门是软件发布质量把控的出口，又可能是用户意见反馈的入口。
　　2、软件测试的生命周期？各阶段对应的工作？
　　测试周期是指从测试项目计划建立到BUG提交的整个测试过程，包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。软件测试周期与软件生命周期并行，存在于软件生命周期的各个阶段。
　　需求分析阶段：测试人员了解需求、对需求进行分解、分析，得出测试需求。
　　测试计划阶段：根据需求编写测试计划/测试方案。确定测试范围，测试通过的标准，测试的时间、人力、物力、资源、风险等。输出测试计划文档
　　测试设计、测试开发阶段：测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例。输出测试方案文档。
　　测试执行阶段：测试执行阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试。
　　测试评估阶段（BUG提交）：在执行的过程中记录、管理缺陷，测试完成后编写测试报告，进行测试评估。
　　3、测试计划和测试方案的内容和区别？
　　测试计划确定测试范围，测试通过的标准，测试的时间、人力、物力、资源、风险等；
　　测试方案确定测试的方法、类型；确定用例设计的方法，缺陷管理流程；缺陷严重程度的划分、用例格式等。
　　测试计划一般由测试经理、测试主管或项目测试负责人制定，属于管理文档，解决的是做什么的问题。测试方案由测试工程师设计，属于技术文档，解决的是怎么做的问题。
　　4、需求评审的内容？参与人员？测试人员为什么要参与需求评审？
　　内容：同步产品对于需求的详细设计,收集大家对于需求的各种反馈。
　　参与人员：产品、设计、研发、运营，测试等其他岗位的人
　　当面同步需求，对于需求的合理性、全面性的反馈。
　　5、测试用例的设计方法有哪几种，分别对应什么典型业务功能？
　　等价类划分
　　等价类即是某个测试对象的输入域的集合。是一种常用的黑盒测试方法。它将全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件，从而用少量代表性的测试数据取得较好的测试结果。等价类可分为有效等价类和无效等价类。
　　在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
　　在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；
　　在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类
　　在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类
　　在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
　　实例：三角形等价类划分https://blog.csdn.net/slforeverlove/article/details/48296121
　　业务：邮件注册功能。
　　测试用例实际就是各个等价类的排列组合。
　　边界值分析
　　边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
　　大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
　　构造测试数据是要考虑3个点的选择：上点，即边界值点；内点，即与范围内的点；离点，离上点最近的点，当域是开区间时离点在域内，闭区间时离点在域外。
　　边界值设计法为每一个有效等价类多增了2个上点的用例。为每一个无效等价类选择的是离点的用例。
　　应用场景与等价类相同
　　判定表驱动分析
　　在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
　　判定表通常由四个部分组成。
　　1)条件桩（ConditionStub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
　　2)动作桩（ActionStub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
　　3)条件项（ConditionEntry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
　　4)动作项（ActionEntry）：列出在条件项的各种取值情况下应该采取的动作。
　　因果图法
　　等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视。
　　针对需求规格，将原因及影响对应关系分为两组：输入与输出，输入与输入。每种又分别对应四类
　　输入与输出：关系主要有恒等、与、或、非。
　　恒等：输入a，一定产生对应的e。没有a的输入，就不会产生e的输出。
　　与（^）：只有同时有a和b的输入，才能产生对应的e。
　　或（v）：输入a或者b，就可以产生对应的e
　　非（~）：只有不输入a，才能产生对应的e
　　输入与输入：异、或、唯一、要求。
　　异：即互斥，所有输入条件只能成立一个，可以一个都不成立。
　　或：所有输入条件至少成立一个，可以多个条件共存
　　唯一：所有输入条件中只能且必须成立一个。
　　要求：如果输入条件a发生了，那么b也会发生。
　　采用因果图法设计测试用例的步骤：
　　1)分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
　　2)分析软件规格说明描述中的语义，找出原因与结果之间,原因与原因之间对应的关系，根据这些关系,画出因果图。
　　3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。
　　4)把因果图转换为判定表。
　　5)把判定表的每一列拿出来作为依据,设计测试用例。
　　场景设计
　　用事件触发来控制流程的，对于涉及业务流程的软件系统，使用场景设计法设计是比较恰当的，比状态迁移类多了些异常的东西。
　　基本流：输入经过每一个正确的流程运转最终达到的额预期结果。
　　备选流：表示输入经过每一个流程运转时可能产生异常情况，但经过纠正后仍能达到预期的结果。
　　异常流：表示输入经过每一个流程运转时，产生的异常终止的现象。
　　错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误,列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。从而有针对性的设计测试用例的方法。
　　6、缺陷的级别及管理流程？
　　缺陷等级一般划分为四个等级，致命、严重、一般、提示。
　　致命（Uregent）：主流程无法跑通，系统无法运行，崩溃或业务中断，应用模块无法启动或异常退出，主要功能模块无法使用。如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循环报错，无法正常退出。
　　严重（veryhigh）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。如：1.功能未实现；2.功能存在报错；3.数值轻微的计算错误
　　一般（Medium）：界面、性能缺陷。如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条
　　提示（Low）：易用性及建议性问题。如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
　　缺陷管理流程说明：
　　1、测试人员填写bug并（Assign）给测试负责人，状态为New；
　　2、测试负责人（review）缺陷。主要检查报告规范，以及确认bug。若是有效的bug，状态变化为open，并分配给开发人员；若bug无效则指派（Assign）回给测试人员，bug状态依旧为new
　　3、开发人员根据缺陷描述确认是否时缺陷，若是则进行修复，修改完成并进行单元测试后，将bug的状态变为fixed，在comment中说明修改方法，并指派给缺陷发现人。若不是缺陷或者延期修改的，将bug状态变化为Rejected，同时也在comment中注明原因。
　　4、测试人员每天查看自己提交的bug的状态变化，应该成为每个测试人员的例行行为；
　　5、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试；如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen（必须说明reopen、closed状态变化原因或者操作过程）；
　　6、若对（Reject）的缺陷进行再次确认后测试人员认为是缺陷，则需（Reopen）缺陷至开发人员出，并comment原因。
　　7、如果回归测试通过，可是修改的同时又引入新的bug，则重新提交bug，状态为new。如果需要的时候注明相关联的bug号；
　　8、只有当所有的bug状态为closed，才可发布版本。
　　注：每当bug状态改变后，必须给出相应的注释和说明，以便查看bug生命周期的变化情况。
　　7、测试准入和通过的标准？
　　准入标准：
　　开发人员编码结束，并已完成单元测试
　　需求说明书规定的功能或开发人员提交的功能说明书的功能均已实现
　　冒烟测试通过，界面上的功能均实现，符合设计文档规定的功能。
　　开发人员向测试部提交《测试申请》
　　通过标准：
　　达到100%需求覆盖
　　所有1、2级用例被执行，3级用例执行率达到95%，4级用例执行率达到80%
　　1级、2级缺陷100%修复，3级95%修复，4级60-80%修复
　　具体缺陷问题需要和用户沟通确认。

Miss_love

支持分享