《软件缺陷报告教学课件电子教案.pptx》由会员分享，可在线阅读，更多相关《软件缺陷报告教学课件电子教案.pptx（52页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第6章 软件缺陷报告软件测试技术董皊目录内容第1章 软件测试概述第2章 软件测试流程和过程模型第3章 软件测试计划第4章 测试用例概述第5章 高效设计测试用例第7章 软件测试报告第8章 易用性测试第9章 Web测试第10章 测试人员的职业能力和技术支持第6章 软件缺陷报告软件缺陷的定义缺陷产生的原因6.2编写软件缺陷报告软件缺陷报告的基本信息缺陷的属性缺陷报告书写规则6.3软件缺陷报告的处理流程软件缺陷报告的生命周期回归测试6.4软件缺陷管理工具BugFree的使用软件缺陷管理工具简介BugFree软件管理工具的使用6.1 软件缺陷简介先引用编程之道中的一个小故事：编程大师说：“任何一个程序，
2、无论它多么小，总存在着错误。”初学者不相信大师的话，他问：“如果有个程序小得只执行一个简单的功能，那会怎么样呢？”“这样的程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生错误。”但初学者不满足，他问：“如果操作系统不失效，那会怎么样呢？”“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生错误。”初学者仍不满足，再问：“如果硬件也不失效，那会怎么样呢？”大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是错误的。”这个故事说明了，没有错误的程序世间难求6.1.1软件缺陷的定义B
3、ug一词的由来。软件缺陷的定义软件未达到产品说明书标明的功能。软件出现了产品说明书指明不会出现的错误。软件功能超出了产品说明书指明的范围。软件未达到产品说明书虽未指出但应达到的目标。软件测试人员认为软件难以理解、不宜使用、运行速度缓慢，或者最终用户认为不好。特殊情况有一些现象看似是缺陷但其实正确有些现象看似正确，但其实是缺陷有些现象在不同的环境和系统中，可能是缺陷，也可能不是。6.1.2缺陷产生的原因缺陷产生的原因6.2 编写软件缺陷报告失败的描述：这样的描述：“无论何时在搜索文本框中输入一串随机字符，软件都会开始进行一种奇怪的动作。”再或者这样的描述：“在word中，段落调整后出现了不正确的
4、行为。”缺陷报告的用途记录缺陷缺陷跟踪缺陷分类完整的软件缺陷报告的内容模块名称缺陷编号发现者发现日期分配给谁缺陷版本号缺陷状态缺陷类型缺陷严重等级缺陷来源缺陷处理优先级缺陷标题测试环境复现步骤实际结果预期结果注释完整的软件缺陷报告的内容1.缺陷的标题（或者叫摘要，Summary）避免使用模糊不清的词语，例如“功能中断”“功能不正确”“行为不起作用”等为了方便搜索和查询，请使用关键字；为了便于他人理解，避免使用术语或过分具体的测试细节;尽量按照缺陷发生的原因与结果的方式书写。比如“执行完A后，发生B”，或者“发生B，当A执行完后。”1.缺陷的标题（或者叫摘要，Summary）使用“在以后”、“在
5、时候”、“在期间”等连接词有助于描述缺陷的原因和结果，例如：（1）在数字字段栏中输入任意字母以后应用程序崩溃。（2）在关闭应用程序时发生内部错误。（3）发送电子邮件期间应用程序被暂停。2.操作步骤（复现步骤，Reproducible Steps）是指如何使别人能够很容易的复现该缺陷的完整步骤。必须：完整、准确、简明、可复现。不良的缺陷报告，主要问题有3个：包含了多余步骤，而且橘子结构混乱，可读性很差，难以理解；包含了过少的信息，丢失了操作的必要步骤。测试人员对软件缺陷发生的条件和影响区域没有进行隔离。2.操作步骤（复现步骤，Reproducible Steps）良好的缺陷报告，要按照下列方式书
6、写：提供测试的前提条件和测试环境。如果有多种方法触发该缺陷，请在步骤中包含这些方法。简单的一步一步的引导复现该缺陷，每个步骤只记录一个操作，并标数字；尽量使用短语和短句，避免复杂句型和句式复现的操作步骤要完整、准确、简短只记录各个操作步骤是什么，不要包含每个操作步骤执行后的结果将常见的步骤合并为较少的步骤：1.新建一个文本框2.添加文字合并为：1.新建一个文本框并添加文字。3.预期结果（Expected Result）预期结果是根据复现步骤，应该产生的正确结果，是需求规格说明书或客户希望得到的结果。案例：预期结果预期结果：选中的文本应该高亮突出显示。如果用户想改变文本内容，必须选中内容高亮突出
7、显示后才能操作。（在Mac Os 10.x和Windows操作系统中。）应该产生的正确现象：选中的文本应该高亮突出显示。产生的原因：如果用户想改变文本内容，必须选中内容高亮突出显示后才能操作。给出了具体的参考对象：Mac Os 10.x和Windows操作系统中。4.实际结果（Actual Result）实际结果是执行复现步骤后软件的现象和产生的行为。 实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。如果一个动作产生多个不同的缺陷结果，应使用数字列表分割开来，如：实际结果：1.显示“命令代码行.错误”的提示；2.显示“并且终止
8、.服务”。4.实际结果（Actual Result）有时候，一个动作产生一个结果，而这个结果，又产生另一个结果。可以把缺陷分成多个缺陷报告，或在实际结果中，列出一到两个表现特征，而把其余的特征移到注释部分。如：实际结果1.显示“命令代码行错误”的提示；注释：1.当取消这个错误提示时，应用程序仍然运行，但是文本内容显示为乱码；2.在选择乱码的文本内容后，使用更新功能，文本内容恢复正常显示。可使用截图、gif动图或者录制视频。5. 注释（Notes）注释是对操作步骤和实际结果的补充，可以包括复现步骤中可能引起混乱的补充信息，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。注释部分可以包含以下各方面
9、的内容：（1）截取缺陷特征图像文件（Screenshots）（2）测试过程需要使用的测试文件（3）测试附加的打印机驱动程序（4）缺陷出现过程中的日志文件（5）再次指明该缺陷是否在前一版本已经存在（6）多个平台之间是否具有不同表现（7）注释包含缺陷的隔离信息，指出缺陷的具体影响范围5. 注释（Notes）注释注释：1. 能在Windows 2000和Windows XP文本框中显示文本内容，但不支持Windows98；2. 刷新屏幕后，某某现象会消失；3. 使用二进制文件，不存在该错误；4. 参见附加的使用说明书和测试文件。6.2.2缺陷的属性1.模块名称（模块名称（Module）缺陷发生的功能
10、模块缺陷发生的功能模块2.缺陷版本号（缺陷版本号（Version）版本号通常用数字表示，如版本版本号通常用数字表示，如版本V1.1等。等。3. 缺陷状态（缺陷状态（Status）4. 缺陷类型（缺陷类型（Type）5.缺陷严重等级（缺陷严重等级（Severity）6.缺陷处理优先级（缺陷处理优先级（Priority）7.缺陷来源（缺陷来源（Source）3. 缺陷的状态缺陷状态缺陷状态描述描述新提交（新提交（New）新提交等待确认的缺陷打开（打开（Open）确认是缺陷，已分配等待解决的缺陷解决解决（Resolved）已经修正（Fixed）开发人员对于自己确认的缺陷会进行修正，修正完毕后，选择解
11、决方案为Fixed，并且详细记录缺陷的产生原因和修正方法。推迟解决（Postponed）对于确认是缺陷但因不是很重要、技术难度过大或需求不明确的缺陷，可以推迟到下一个版本中再解决，选择解决方案为Postponed。无法复现（Unreproduced）确认是缺陷但开发人员按照该缺陷报告中描述的环境、步骤无法复现，需要测试人员再次检查并复现的缺陷，选择解决方案为Unreproduced。重复提交（Duplicate）确认是缺陷，但已经被其他测试人员发现并记录在缺陷库中了，开发人员会将缺陷的解决方案标记为Duplicate，并注明与哪一个缺陷重复。不是缺陷（Invalid）提交的根本不是缺陷，而是测
12、试人员对需求的误解或者描述错误导致提交的“缺陷的缺陷”。关闭（关闭（Closed）确认缺陷已经被修复，将其关闭，不再关注。重新打开（重新打开（Reopen）经验证缺陷并未真正修复，将其重新打开，等待解决。4. 缺陷的类型序号序号缺陷种类缺陷种类说明说明1功能问题影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如指针循环、递归、功能等缺陷。2接口问题与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。3逻辑问题需要进行逻辑分析，进行代码修改，如循环条件等。4计算问题等式、符号、操作符或操作数错误，精度不够、不适当的数据验证等缺陷
13、。5数据问题需要修改少量代码，如初始化或控制块。如声明、重复命名、范围、限定等缺陷。6用户界面问题人机交互特性：屏幕格式，确认用户输入，功能有特性，页面排版等方面的缺陷。7文档问题影响发布和维护，包括注释等缺陷。8性能问题不满足系统可测量的属性值，如：执行时间，事物处理速率等缺陷。9配置问题由于配置库、变更管理或版本控制引起的错误10标准问题不符合各种标准的要求，如编码标准、设计符号等缺陷11环境问题由于设计、编译和运行环境引起的问题12兼容问题软件之间不能正确的交互和共享信息。13其他问题以上问题所不包含的其他问题5. 缺陷严重等级（Severity）（1）1-致命缺陷（Fatal）（2）2
14、-严重缺陷（Critical）（3）3-重要缺陷（Major）（4）4-一般缺陷（Minor）（5）5-改进意见（Enhancement）1-致命缺陷（Fatal）致命缺陷是指系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全的缺陷。或者系统所提供的功能或服务受到明显的限制，不能执行正常工作流程或实现重要功能。包括：可能有灾难性的后果，如造成系统崩溃，造成事故的缺陷等；数据库错误，如数据丢失、数据毁坏等；安全性被破坏。例如，一个导致死机的缺陷描述如下：2-严重缺陷（Critical）指可能导致系统不稳定，运行时好时坏，严重影响系统要求或基本功能实现的缺陷。比如
15、：造成数据库不稳定的错误；在说明中的需求未在最终系统中实现；程序无法运行，系统意外退出；业务流程不正确等。例如，一个异常退出的缺陷描述如下：3-重要缺陷（Major）指系统的次要功能没有完全实现，但不影响用户的正常使用，不会影响系统稳定性的缺陷。比如：提示信息不太准确或用户界面差、操作时间长等一些问题；过程调用或其他脚本错误；系统刷新错误；产生错误结果，如计算错误，数据不一致等；功能的实现有问题，如在系统实现的界面上，一些可接受输入的控件带你点击后无作用，对数据库的操作不能正确实现；编码时数据类型、长度定义错误；虽然正确性、功能不受影响，但是系统性能和响应时间受影响。例如，一个数据处理错误、但
16、对系统的影响不大的缺陷描述如下：4-一般缺陷（Minor）是指使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题，重点指系统的UI问题，比如：系统的提示语不明确，不简单明了；滚动条无效；可编辑区域和不可编辑区域不明显；光标跳转设置不好，鼠标（光标）定位错误；上下翻页，首尾页定位错误；界面不一致，或界面不正确；日期或时间初始值错误（起止日期、时间没有限定）；出现错别字，标点符号错误，拼写错误，以及不正确的大小写等。例如，一个界面显示的缺陷描述如下：5-改进意见（Enhancement）是系统中值得改良的问题。比如容易给用户错误和歧义的提
17、示；界面需要改进的；某个控件没有对齐等；测试人员可以对有疑虑的部分，提出修改建议。例如，一个测试人员的建议描述如下：6. 缺陷处理优先级（Priority）缺陷处理优先级缺陷处理优先级描述描述1-立即解决立即解决（Resolve Immediately）导致系统几乎不能使用或测试不能继续，需要立即修复的缺陷。2-高优先级（高优先级（High Priority）比较严重，影响测试，需要优先考虑的缺陷。3-正常排队（正常排队（Normal Queue）需要正常排队等待修复的缺陷。4-低优先级（低优先级（Low Priority）可以在开发人员有空余时间的时候被修正的缺陷。缺陷处理优先级表示开发人员
18、修复缺陷的重要程度和紧迫程度。一般分25级。6. 缺陷处理优先级（Priority）一般的，严重级别越高，处理优先级越高，但这并不是绝对的。只要一启动，程序就崩溃。 1级-致命缺陷，优先级也是1级-立即解决；某按钮位置摆放不合理。 4级-一般缺陷，优先级也是4级-低优先级；极少发生的数据毁坏缺陷。1级-致命缺陷，优先级是3级-正常排队；导致用户求助的安装说明书中的错别字。 4级-一般缺陷，优先级是2级-高优先级；公司的名字或logo被误用了。4级-一般缺陷，优先级是2级-高优先级。功能性缺陷一般较为严重，具有较高的优先级；而软件界面类缺陷的严重性一般比较低，优先级也低。但这也不是绝对的。一款财
19、务软件中，影响数字准确度的功能逻辑缺陷比较严重，具有较高的优先级，界面缺陷优先级较低。但在一款游戏软件中，影响界面美观和执行速度的缺陷，则拥有较高的处理优先级。另外，缺陷的优先级在项目期间会发生变化。7.缺陷来源序号序号缺陷来源缺陷来源说明说明1需求Requirement由于需求的问题引起的缺陷2架构Architecture由于架构的问题引起的缺陷3设计Design由于设计的问题引起的缺陷4编码Code由于编码的问题引起的缺陷5测试Test由于测试的问题引起的缺陷6集成Integration由于集成的问题引起的缺陷6.2.3 缺陷报告书写准则（1）遵循5C准则。Correct（准确）：每个组成
20、部分的描述准确，不会引起误解和歧义，不夸大缺陷，也不要过于轻描淡写；Clear（清晰）：每个组成部分的描述清晰，不使用模棱两可的描述，比如出现“似乎（seem）”、“看上去可能（Possible）”等含义模糊的词汇；Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容。这可以通过使用关键词，使摘要的描述短小简练，又能准确解释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“及时消息”等就是关键词；Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息，可以使开发人员很容易看懂缺陷；Consistent（一致）：
21、按照一致的格式书写全部缺陷报告。6.2.3 缺陷报告书写准则（2）报告随机缺陷对于随机缺陷应当采取适当的方法处理。首先，一定要及时详细的记录缺陷并提交到缺陷管理工具中，并在报告此类Bug时，明确说明自己不能复现这个程序错误，必要的时候要保存截图和相关日志，为开发解决Bug提供思维方向，并适当降低处理优先级。其次，在系统中留下随机缺陷的记录之后，考虑到测试项目的整体进度，对于一时难以再现的缺陷可以暂时搁置，稍后再寻找合适的时间去尽量复现，或者等开发人员有空的时候再一起调试。以免因为一颗大树而丢掉整个森林，保证项目的正常进度。最后，对随机缺陷要持续关注3到5个版本，如果在此期间从再未出现过，可以暂
22、时关闭该缺陷，可能程序员在修改别的缺陷的时候无意中修复了这个缺陷；如果随机缺陷再次出现，可以让开发过来测试机前面现场分析。6.2.3 缺陷报告书写准则（3）及时报告缺陷（4）小缺陷也值得报告如拼写错误、小的屏幕格式问题、鼠标遗迹、小的计算错误、图形比例不准、在线帮助错误、不适当的灰掉了的菜单选项、不起作用的快捷键、不正确的错误信息，遗迹其他程序员认为不值得花精力去修改的缺陷。（5）一个缺陷一个报告（6）以中性的语言描述缺陷不要使用“很糟糕”之类的带倾向性、个人观点和煽动性的措辞不要对软件的质量优劣做任何主观性的批评和嘲讽不要使用自认为比较幽默的语言，因为读者文化和观念不同。少用“我”“你”等人
23、称代词，可使用“用户”代替（7）引用别人的缺陷报告，不要擅自修改6.2.3 缺陷报告书写准则自我检查和提问缺陷报告已经向读者包含完整、准确、必要的信息了吗？一个缺陷报告中是否只报告了一种缺陷？读者是否能容易的搜索该缺陷？步骤是否可以完全复现而且表达清楚吗？是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？缺陷的标题是按照原因与结果的方式书写的吗？实际结果和预期结果是否描述不够清楚而容易引起歧义吗？6.3 软件缺陷报告的处理流程6.3 软件缺陷报告的处理流程几个特殊的场景:1.随机缺陷报不报？2.所有的缺陷都要被修复吗？3.提交一个缺陷，开发说不是缺陷该怎么办呢？4.提交一个缺陷，开发人员
24、承认是个缺陷，但是他不修复怎么办呢？6.2.1回归测试基于风险的测试方法：本质是评估系统不同部分蕴含的风险，考虑风险存在的可能性以及造成的影响，并专注于测试那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试，甚至完全不测，但是它保证了系统风险是最低的。两个方面：可能性和影响可能性：可能出错的机会，不考虑影响程度，仅仅考虑出现问题的机会有多大。影响：确实出错后会造成的影响程度，不考虑可能性，仅仅考虑出现的时候会有多么糟糕。对于一个购物系统来说，购物场景是风险影响比较大的地方；对于一个拍卖网站，拍卖流程和系统压力则是风险存在的可能性比较大的地方。6.2.1回归测试基于风险的测试方法好处
25、：通过策略性删减，减少了重复的工作量，在一定程度上缓解了测试人员的思维疲劳适当阶段引入新的测试人员来补充测试，让新加入的测试人员带来新的灵感推荐在合适的项目中，使用自动化测试工具。快、准、不厌其烦。6.4 软件缺陷管理工具BugFree的使用软件缺陷管理工具简介只要明确工作流程，就可以通过Excel或Access来实现。大型企业，要求复杂，自己独立开发缺陷跟踪系统购买缺陷跟踪产品或使用开源的。目前主流是BS或CS结构，并在服务器端应用数据库对系统数据进行管理。6.6软件缺陷管理工具Bugfree中缺陷的处理流程新提交测试人员解决开发人员验证测试人员否是已解决不是bug重复提交无法复现不解决解决
26、方案关闭测试人员BugFree的使用后台创建项目（产品），创建模块创建用户并加入组创建用户组并加入项目前台Case的提交Bug的提交Bug的测试结果本章重点事项（1）缺陷的5种定义规则有助于测试人员识别软件缺陷；（2）软件缺陷的最大来源是产品需求说明书，而不是程序代码本身。测试人员需要在前期对产品需求说明书进行验证和推敲；（3）编写软件缺陷报告时要尽量保证缺陷可以复现，遵循5C准则等。（4）为了确保导致软件缺陷的全部细节是可见的，可以使用截图或录制视频的方式提交软件缺陷；（5）对于无法复现的缺陷，要及时提交，但不能全是这种缺陷，开发人员会怀疑你的测试专业度；（6）并不是每个缺陷都会被开发人员修
27、复，对于不修复的软件缺陷测试人员也要跟踪到底；（7）软件缺陷的属性中的属性值是根据不同的项目进行定制的；（8）软件缺陷的严重级别越高，处理优先级通常越高，但这并不是绝对的；（9）软件缺陷的处理流程会由于测试项目不同而有所不同，但大同小异；(10) 软件缺陷的管理工具多种多样，都是配合项目的软件缺陷的生命周期而存在的，BugFree是一款免费开源、简单易学的缺陷管理工具。测试人员10宗最最开心的事：发现了一个很严重的Bug，特别是那种隐藏很深、逻辑性的错误；最提心吊胆的事：版本发布后，被客户或用户发现了很多或很严重的Bug；最憎恨听到的话：为什么这个Bug没有在测试的时候发现呢？最郁闷的事：刚才
28、那个版本打包打错了，你们要重测；最不想面对的事：在测试晚期或最新的版本里发现了以前一直存在的问题；最丢人的事：辛苦的发现了一个Bug，居然是该配的参数没有配等一些自己的失误造成的；最尴尬的事：一天，甚至几天都没有发现一个Bug。被开发的同学同情说“要不要我在代码里放几个Bug给你啊？”最有力的保护自己的方法：把你认为是Bug的问题都提交到Bug库中；最任重而道远的事：测试驱动开发，最好在提交缺陷的时候，能定位到缺陷发生的原因；最期待的事：测试能够越来越受重视。常见题目一、单选题（1）以下哪个部分是缺陷的最大来源？（）A.产品需求说明书B.程序代码C.设计文档D.用户使用阶段（2）以下哪一项不是
29、软件缺陷报告的基本信息？（）A.缺陷标题B.操作步骤C.实际结果D.缺陷处理优先级（3）以下哪一个更接近优秀的缺陷标题？（）A.英文单词的连字符不管用B.警告：该命令产生了错误的结果C.拷贝和复制功能执行效率低下D.插入的引号成为特殊符号常见题目（4）如何写一个良好的缺陷报告？以下说法不正确的是（）A. 报告随机缺陷、不夸大缺陷，报告小缺陷。B. 及时报告缺陷、引用别人报告不要擅自修改、缺陷报告中注明姓名和日期。C. 保证重现缺陷、包含所有重现缺陷的必要步骤。D. 在提交某些缺陷时，可以加重自己的语气以提醒开发注意。（5）关于缺陷的类型，以下哪一种属于逻辑问题？（）A.功能错误B.循环不正确C
30、.模块间接口错误D.界面风格不统一（6）关于缺陷严重级别和处理优先级的说法正确的是（）A. 缺陷严重级别越高，处理优先级越高B. 功能性缺陷总是最为严重的，而软件界面类缺陷严重性总是比较低C. 软件缺陷的处理优先级一旦设定好，就不能再变动D. 严重级别高的缺陷，处理优先级不一定高常见题目二、多选题（1）关于缺陷的识别，有以下规则，哪些说法是正确的？（）A. 软件未达到产品说明书表明的功能B. 软件出现了产品说明书表明不会出现的错误C. 软件功能超出产品说明书表明的范围D. 软件未达到产品说明书虽未表明但应达到的目标E. 软件测试人员认为软件难以理解，不宜使用，运行缓慢或最终用户认为不好（2）关
31、于缺陷报告的操作步骤的书写方式说法正确的是（）A. 需要提供测试的前提条件和测试环境B. 为了使缺陷简洁，可以在一个步骤中记录多个操作C. 尽量使用短语和短句，避免复杂句型和句式D. 可以在每个操作步骤中包含执行后的结果常见题目（3）为了更好的做回归测试，可以采取的方式有（）A. 采用基于风险的测试方法B. 在适当的阶段引入新的测试人员来补充测试C. 使用自动化测试工具D. 每次测试都要做Full Regression的测试（4）BugFree的功能模块有（）A. 软件缺陷B. 测试用例C. 测试结果D. 测试需求（5）缺陷不被修复的原因有哪些？（）A. 提交的根本不是一个缺陷，而是测试人员的
32、误解导致的B. 迫于项目的压力，没有足够的时间修复缺陷C. 限于现有开发人员的能力和技术问题，无法解决软件缺陷D. 有些缺陷看似很简单，但修改它可能会引起底层架构的变更常见题目三、判断题（1）由于各种原因，被发现的缺陷有可能是不予修复的。（ ）（2）软件缺陷是否修复通常是有专门的小组来决定的，测试人员无权擅自决定。（）（3）所有缺陷必须要修改完，才能发布软件。（）（4）缺陷报告的处理流程在各个项目中都是固定不变的。（）（5）提交无法复现的缺陷报告会被开发人员质疑，所以在复现之前，不要提交软件缺陷，等以后发现了复现步骤再提交。（）（6）被开发人员拒绝的缺陷报告，测试人员可以不予理会。（）（7）可以通过截图或录制视频的方式提交软件缺陷。（）（8）提交一个缺陷，开发说不是缺陷的时候，一定要尽量说服开发去修改。（）下节更精彩