缺陷等级

判断题 软件测试就是为了验证软件功能实现的是否正确，是否完成既定目标的活动，所以软件测试在软件工程的后期才开始具体的工作。 （初级） （ × ） 发现错误多的模块，残留在模块中的错误也多。( √ ) （初级） 测试人员在测试过程中发现一处问题，如果问题影响不大，而自己又可以修改，应立即将此问题正确修改，以加快、提高开发的进程。（ × ）（初级） 单元测试通常应该先进行“人工走查”，再以白盒法为主，辅以黑盒法进行动态测试。 （ √ ）（中级） 功能测试是系统测试的主要内容，检查系统的功能、性能是否与需求规格说明相同。（ √ ）（中级） 软件质量管理即QM由QA和QC构成，软件测试属于QC的核心工作内容。（√）（高级） 软件测试只能发现错误，但不能保证测试后的软件没有错误。(√) 软件就是程序。(X) 测试只要做到语句覆盖和分支覆盖，就可以发现程序中的所有错误。(X) I18N测试是指对产品做出具有国际性的规划，而L10N测试则是指对软件做出符合本地需求更改工作。（√）【高级】 （ × ）用黑盒发测试时，测试用例是根据程序内部逻辑设计的。 （ √ ）白盒测试是基于对程序控制结构了解的基础上来设计测试用例的。 （ × ）测试是为了验证软件正确的实现了用户需求。 （ √ ）确定测试主要测试软件功能是否满足用户的合理需求，以“需求规格说明书”为测试依据。 （ √ ）软件测试时经常要输入无效的

什么是软件？ 软件是计算机系统中与硬件相互依存的另一部分， 软件包括程序+文档 什么是软件测试？ （1）软件测试是在现有软件（程序+文档）中寻找缺陷的过程； （2）软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程，目的是检验系统是否满足需求规格说明书中的要求 软件测试的目的？ 测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求。 黑盒测试： 又叫功能测试，把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程，根据规格说明书，通过操作软件验证程序的功能是否与规格说明书规定的一致。 白盒测试： 也称结构性测试，是基于代码的测试，按照程序内部的逻辑结构，检测程序是否能按预定要求进行正确的工作。 回归测试： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 冒烟测试： 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，冒烟测试又称版本验证测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。 简单地说，冒烟测试就是用较少的人，在较短的时间内测试程序的主要功能，如果通过再进行正式的测试。 aplha测试和bate测试的区别？ Alpha测试(α测试)： 通常也叫“验证测试”，主要是指在软件开发完成以后

1.什么是软件测试? 答:软件测试是 为了发现错误而执行程序的过程 。或者说，软件测试是 根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例 (即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。（1.验证程序正常运行 2.验证满足用户需求 3.发现缺陷） 2. 软件测试的目的? 答;测试的目的是想 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷 ，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。 3.什么是需求文档测试？ （主要测试需求中是否存在逻辑矛盾以及需求在设计上是否可以实现） 1、需求文档是否符合用户需求； 2、需求文档是否符合逻辑； 3、技术上是否能实现； 软件开发过程中，通常会有专门的测试人员，他们首先 会根据需求文档编写测试用例 ，用于指导如何测试，以及那些输入条件预期得到什么结果 4. 什么是设计文档测试? 答:测试设计是否符合全部需求以及设计是否合理 5.什么是 α测试 ? 答:Alpha测试(α测试)是 由一个用户在开发环境下进行的测试 ，也可以是 公司内部的用户在模拟实际操作环境下进行的受控测试 ， Alpha测试不能由程序员或测试员完成 。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。 目的是评价软件产品的功能

bug的缺陷类型： 代码/功能缺陷：需求文档中有，设计出来了，但是实现过程出了错误 设计缺陷：需求文档中有，但是没有设计出来。 界面缺陷 bug的等级：分为四级 1.致命错误 （1）常规操作引起的系统崩溃，死机，死循环，闪退 （2）造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄漏 （3）涉及金钱计算 （4）阻断性测试，所有测试工作进行不下去 阻断错误一般发生在冒烟测试等主流程上，比如，如果注册之后才能进行内部操作，然而无法注册 2.严重错误 （1）重要功能不能实现 （2）错误的涉及面广，影响到其他重要功能正常实现 （3）非常规操作导致的程序崩溃，死机，死循环，闪退 （4）界面超级难看 （5）密码明文显示 3.一般错误 不影响产品的运行，不会成为故障起因，但对产品外观和下道工序影响较大的缺陷 （1）次要功能不能实现（和主要功能的区别：主流程之外的功能算是次要以及主要功能模块中的控件出现问题，但主要流程仍然能正常实现）比如说：注册时，用户名指明用户名为中文，但输入英文注册成功了，但不影响登录后的功能使用） （2）操作错误（数据库中列名，类型错误等） （3）查询结果错误 （4）前端界面的简单输入限制未做出错误提示 （5）例：删除操作未给提示，防止误操作 4.细微错误： （1）界面上的错误，界面布局，文字格式，按钮样式等轻微错误 （2）辅助说明描述不清楚 （3

开发同学说，感觉我的等级划分是乱来的。所以特别来记录下缺陷等级程度的划分。 测试过程中发现的缺陷一般分为如下几类： 功能问题（FunctionError）：对产品、项目质量有影响，但尚难以确定是否是错误，暂时无法解决 功能缺陷（FunctionDefect）：不满足用户需求等bug的总称 页面缺陷（UIDefect）：页面美观性、协调性、错别字等 建议类（Suggestion）：对产品、项目的建议性意见，不强制要求修改 硬件性能：进行性能测试时使用，暂定：网络延时、内存问题、CPU占用、硬盘问题 安全性问题：进行系统安全测试时使用，暂不订具体标准 业务流程问题：进行业务流程测试时进行 数据库性能：暂不执行 模块间接口问题:涉及有模块间数据传递时使用 其他(Other):其它 根据各类缺陷的严重程度将缺陷分为5个等级，具体如下： 1、低(Low) -建议类错误，对软件的改进意见或者建议。如： 　　a、功能建议 b、操作建议 c、校验建议 　　d、说明建议 　　e、UI建议 2、中(Medium) -使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。如： 　界面错误： 　　a、使操作者不方便或者遇到麻烦，但不影响执行工作功能的实现 　　b、界面、控件的摆布、图标、输入输出不规范 提示类错误： 　　a、删除操作未给出提示 　　b

转载至： https://www.cnblogs.com/yoyoketang/p/12194550.html 前言 我们在做功能测试的时候，执行完一轮测试用例，输出测试报告的时候，会有统计缺陷的数量和等级。 在做自动化测试的过程中，当你的测试用例越来越多的时候，如果执行一轮测试发现了几个测试不通过，我们也希望能快速统计出缺陷的等级。 pytest结合allure框架可以对用例的等级做详细的划分。 用例等级 allure对用例的等级划分成五个等级 blocker　 阻塞缺陷（功能未实现，无法下一步） critical　　严重缺陷（功能点缺失） normal　　 一般缺陷（边界情况，格式错误） minor　 次要缺陷（界面错误与ui需求不符） trivial　　 轻微缺陷（必须项无提示，或者提示不规范） 比如我的用例有以下4条 那么对应的用例的等级应该是 修改个人信息-sex参数为空 这个属于边界值情况的测试，应该是normal级别 修改个人信息-sex参数传F和M两种类型，成功(枚举类型) 这个是针对接口的功能点详细测试 critical级别 修改个人信息-修改不是本人的用户信息，无权限操作 这个是针对接口的功能点详细测试 critical级别 修改个人信息-修改自己的个人信息，修改成功 这是用例是测试主流程 blocker级别 pytest用例

以下内容首发于微信公众号【ITester软件测试小栈】： 测试面试题集-1.测试基础理论 大家好我是coco小锦鲤最近很多小可爱在找工作、找实习 因为知识积累不系统 不会总结 经验不足等原因 还没有找到理想的测试工作 看着身边的朋友 都纷纷收到了心仪的offer 而自己却待在原地 恐慌和对未来的迷茫每日剧增 接下来每周五给大家推送面试系列记得持续关注哦 Q: 一、进行测试用例设计的时候用到的方法有哪些？ A: 最常使用的测试用例设计方法包括等价类划分法、边界值分析方法、场景法、错误推测法。其中，最容易发现错误的是边界值法，使用最多的是场景法。以注册为例：首先从需求确定用户名和密码的长度类型约束，根据需求写测试点，然后设计测试数据，编写测试用例。 Q: 二、测试计划包括哪些主要步骤和信息？ A: 测试计划包括引言、测试基本内容（测试目的、测试范围、测试环境、测试工具、测试人员）、实施计划（任务分配、进度安排）、风险控制等。 Q: 三、测试报告需要包含哪些内容？测试报告交付文档有哪些？你认为测试报告的侧重点是什么？ A: 测试报告包括：引言、测试基本信息、测试结果及缺陷分析、测试结论和建议，交付文档。 交付文档有测试用例、提交的bug、测试报告。 测试报告的侧重点是测试结果和缺陷分析，测试结论。 Q: 四、bug的生命周期？你是怎么跟进bug的？ A: bug的生命周期

测试做久，才发现开发方会在价钱、缺陷等级数量上总会有讨价还价的现象。由于我们公司比较特殊，都是帮公司公司内部做测试，可能有些测试公司，只是做测试，外包别人的项目做测试。像测试外包公司，在价钱方面应该是商量好的，钱大家觉的合适就做，不行就不做。但我们公司，给内部做测试，就算测试部门没有盈利，还是要为开发方服务的。不知道其他公司是什么情况。 我们公司，在每周五会开PM会议，测试方回提报发现的缺陷数量和缺陷等级。对应严重等级、次严重等级，高层主管会对开发PM提出“严厉的要求”。所以今天在我们办公室上演了一场开发方和测试PM讨论缺陷个数的戏幕。这个专案是在星期一测试方结案的。到星期五了， 开发方PM觉的他们的缺陷数量太多了，在高层主管面前不好，说明白一点就是会影响他们的绩效表现和年终奖。在他们明显的对话中，感觉到开发方有扯皮的现象，目的就有一个希望测试PM少报几个缺陷。 他主要的说辞是：1、他不懂得用MANTIS， 不知道如何关闭缺陷， 2、现在才意识到缺陷数量会影响他们的绩效，（所以到星期五才来说明这个问题，要求测试部门更改测试报告） 3、觉的缺陷数量太多，有好几个缺陷问题是由于一个多线程争用资源而导致的缺陷，所以这几个缺陷应该是算做一个缺陷。（为何现在才意识到，如果当初提报缺陷的时候，早些找出原因所在，不就可以和QCM沟通了。） 可能由于主管和开发PM比较熟悉，也就把测试报告改了

软件及相关系统日益庞大和复杂，开发过程和软件产品不可见，需求的易变、多变，这一系列的问题导致大量的 软件质量问题， 时刻提醒着软件工程师们提高软件测试技术，力求屏蔽更多的软件缺陷。缺陷分析和缺陷预防技术已经渗入到软件测试的每一个环节中。 最近在51Testing上看到相关的文章，再结合自己收集到的资料，稍微进行了一下总结，红色部分是偶自己的看法。 常见缺陷分析技术主要有七类： 1 、 ODC 缺陷分析： 由 IBM 的 waston 中心推出。将一个缺陷在生命周期的各环节的属性组织起来，从单维度、多维度来对缺陷进行分析，从不同角度得到各类缺陷的缺陷密度和缺陷比率，从而积累得到各类缺陷的基线值，用于评估测试活动、指导测试改进和整个研发流程的改进；同时根据各阶段缺陷分布得到缺陷去除过程特征模型，用于对测试活动进行评估和预测。 2 、 Gompertz 分析： 根据测试的累积投入时间和累积缺陷增长情况，拟合得到符合自己过程能力的缺陷增长 Gompertz 曲线，用来评估软件测试的充分性、预测软件极限缺陷数和退出测试所需时间、作为测试退出的判断依据、指导测试计划和策略的调整； 3 、 Rayleigh 分析： 通过生命周期各阶段缺陷发现情况得到缺陷 Rayleigh 曲线，用于评估软件质量、预测软件现场质量； 一般用于推测一段时间后，软件中还会残留多少BUG。 4 、四象限分析：

（1）什么是软件测试？软件测试的目的与原则？ 定义：在规定的条件下对程序进行操作，以发现程序错误、衡量软件质量，并对其是否能满足设计要求进行评估的过程。 目的：在于发现错误、发现程序中存在的代码或业务逻辑错误、检验产品是否符合用户的需求、提高用户体验。 原则：如二八原则、测试应尽早启动、介入。 （2）什么是软件质量？ 软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。 （3）软件的生命周期？ 计划阶段----需求分析----设计阶段----编码----测试----运行与维护 （4）软件生存周期及其模型？ 整个生存周期包括：问题的定义及规划、需求分析/评审、软件设计、软件编码、测试阶段、运行维护六个时期 周期模型：瀑布模型、迭代模型 （5）软件测试分为那几个阶段？ 单元测试、继承测试、系统测试、验收测试是个主要阶段 单元测试：通常由开发人员进行 集成测试：将模块按照设计要求组装起来进行测试，主要目的是发现与接口相关的问题 系统测试：是在继承测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求 验收测试：上线前的最终测试 （6）什么是测试用例？测试脚本？两者的关系是什么？ 用例：未实施而编制的一组测试输入、执行条件、各种环境设置以及预期结果以及期望结果的一个特定的集合 脚本