1.软件缺陷 告地基本组成元素包括
缺陷的编 、缺陷的标题、缺陷的基本信息、测试的软件和硬件环境、测试的软件版本、缺陷的类型、缺陷的严重程度、缺陷的处理优先级、缺陷的复现步骤、缺陷的实际结果描述、期望的正确结果、截取的缺陷图像、注释文字 等
2.缺陷地状态主要包括
激活（新建/打开）、已修复、关闭、从新打开、推迟、不能复现、重复、不是缺陷
3.缺陷地严重程度主要包括
致命的、 严重的、一般的、较小的、建议性的
4.什么是软件缺陷
所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
5.怎么判断是不是软件缺陷/p>
用户体验不好
界面上有明显的错误信息
功能不完备，导致功能缺失
功能不完善
逻辑不正确，与需求说明书不符
模块之间的交互性不好，与其他的模块做集成性测试时遇到问题
程序的性能不够好，不能承载压力考验
6.软件缺陷必须符合哪5个原则/p>
软件未达到产品说明书表明的功能
软件出现了产品说明书指明不会出现的错误
软件功能超出了产品说明书指明范围
软件未达到产品说明书虽然未指明但应达到的目标
软件测试人员认为难以理解、不易使用、运行速度缓慢、或者最终用户觉得不好
7.缺陷地产生主要原因有哪些原因主要地原因是什么/p>
没有编写说明书、设计、编码、其他
没有编写说明书
8.当你发现一个缺陷时，应该怎么确认的确是一个缺陷/p>
首先，可以将软件需求说明书、用户手册以及联机帮助作为识别和判断缺陷的辅助工具。
其次，通过增加自己对测试软件产品的行业背景知识的了解来发现被忽视的问题。
最后，通过沟通的方式来收集、学习和分享其他人判断缺陷的方法和经验。
9.正式提交一个缺陷前，你应该做什么/p>
再次确认是否是缺陷，记录下缺陷查收的每一个步骤（在现缺陷），编写缺陷 告，提交缺陷
10.怎么处理无法在现的缺陷/p>
首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
其次，对于寻找难以再现的缺陷要合理的安排时间
最后，在测试过程中对未在现缺陷予以关注
11.什么是重复缺陷么避免重复缺陷/p>
指在统计周期再次发生的同类型缺陷。
一个人测试可以在提交的时候输入关键字进行筛选一下。
多人测试尽量分模块进行测试，提交之前都应该筛选一下。避免重复提交。
12什么是无效缺陷么避免无效缺陷/p>
软件产品中不符合用户需求的地方即可认定为软件缺陷(Bug)。这里软件产品可以是代码段、应用程序、软件系统、产品文档等任何软件工程行为的产品。
前细化需求，保证对需求理解正确，避免提交存在歧义的缺陷：
对于自己把握不准的缺陷，提交前进行讨论
在提交bug之前，一定要保证bug能够重现，并且在bug中清楚的描述重现步骤
保证测试环境的准确性，并且做好版本的配置管理
13.什么是缺陷 告哪些用途/p>
用于记录缺陷，对缺陷进行分类，为解决不同的缺陷分配合理的资源，并通过缺陷 告对处理缺陷的过程进行跟踪，从而使软件缺陷得以修复。
记录缺陷、缺陷分类、缺陷跟踪几大用途
14.缺陷 告的5个写作准则是什么/p>
准确、清晰、简洁、完整、一致 （5C原则）
15.缺陷 告的内容有哪些/p>
缺陷的编 、缺陷的标题、缺陷的基本信息、测试的软件和硬件环境、测试的软件版本、缺陷的类型、缺陷的严重程度、缺陷的优先处理级、缺陷的复现步骤、缺陷的实际结果描述、期望的正确结果描述、截取的缺陷图像、注释文字
16.缺陷 告的组织结构是什么/p>
缺陷的编 、缺陷的标题、缺陷的基本信息、测试的软件和硬件环境、测试的软件版本、缺陷的类型、缺陷的严重程度、缺陷的优先处理级、缺陷的复现步骤、缺陷的实际结果描述、期望的正确结果描述、截取的缺陷图像、注释文字
17.缺陷 告的写作需要注意什么问题/p>
自我检查和提问：
缺陷 告已经向读者包含完整、准确、必要的信息了吗一个缺陷 告是否只 告了一种缺陷骤可以完全复现而且表达清除吗实际结果和期望结果是否描述准确等
避免常见的错误：
不要“我”“你”而用动词或者必要时使用“用户”代替
不要使用模糊词汇“似乎”“大概”等
不要对软件的质量优劣做任何的主观性强的批评和嘲讽
不确定的缺陷测试问题不要放在缺陷管理数据库。
18.缺陷的分类/p>
测试过程中发现的缺陷一般分为如下几类：
代码问题：不满足需求、功能实现错误；对产品或项目质量有影响的bug可统一划入；
设计缺陷：页面美观性、协调性、错别字等
用户体验：对产品、项目的建议性意见，不强制要求修改
性能问题：进行性能测试时使用，暂定： 络延时、内存问题、CPU占用、硬盘问题
安全问题：业务功能存在的安全问题
接口问题: 涉及有模块间数据传递时使用
配置问题: 由于提供的配置不当或者配置不能够满足实际要求而出现的问题
缺陷错误严重程度：
5级-建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
3级—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
2级—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
1级—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
19.如果测试提交的缺陷开发人员不认可怎么办/p>
第一步:与开发人员反复友好沟通;
第二步:反复复现缺陷的存在，并可以将缺陷复现的截图与复现步骤整理成文档提供给开发人员;
第三步:如果还是不能说服开发人员,可以将该情况反映给测试组长或者测试经理,由测由测试组长或者测试经理评估协调。
20.简述缺陷的生命周期。
1.New 新建
2. Open 打开
3. Assign 指派
4. Test 测试
5. Verified 确认
6. Deferred 延期
7. Reopened 重新打开
8. Duplicate 重复
9. Rejected 拒绝
10. Closed 关闭
21.缺陷按照严重程度可以分为哪些类型/p>
缺陷错误严重程度：
5级-建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
3级—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
2级—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
1级—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
22.缺陷按照优先级可以分为哪些类型
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！