第六讲6执行软件测试

北风网软件测试项目实战培训如何执行软件测试讲师：孙老师（北风网版权所有)内容测试执行的工作范围软件BUG定义测试管理系统使用关于BUG的几个问题BUG的描述测试执行工作范围搭建测试环境执行测试用例发现软件缺陷（BUG）记录BUG和提交BUGBUG跟踪BUG分析和定位软件缺陷的定义软件缺陷定义，满足5个条件之一（所有软件问题都称为缺陷）软件未达到产品说明书中已标明的功能软件出现了产品说明书中指明不会出现的错误软件功能超出了产品说明书指明的范围软件未达到产品说明书虽未指出但应达到的目标软件测试员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为该软件使用效果不好。缺陷产生原因产生缺陷的原因是什么？人员（用户、设计、开发、测试、技术支持等）之间的沟通交流不够，交流上有误解或者根本不进行交流文档不完善甚至没有文档（尤其是国内中小软件企业）需求不断的变化参与人员的过度自信程序设计本身有错误软件复杂度大，缺陷很难避免（例如Windows、Word）工期短，任务重，时间压力大软件开发工具与系统软硬件的支持5缺陷的识别软件技术人员发现了问题，判断这个问题是否是缺陷的依据是什么？通过参考文档来确认缺陷需求规格说明书概要设计、详细设计用户手册…通过了解软件行业标准、行业背景（或参考同类典型软件）来发现缺陷通过沟通来确认和识别缺陷6缺陷的属性软件BUG的属性含多个方面，包括严重程度再现程度优先级别缺陷分类BUG状态缺陷描述等属性说明具体内容BUG状态指在BUG跟踪和管理过程中的状态标识。包括New、Open、fixed、suspend、closed、reject6个状态。严重程度以可能对用户造成的影响程度做为最终的判断依据。包括致命、严重、一般、微小4种。优先级别指开发人员修改BUG的优先程度，由项目经理在审核BUG时分配。包括尽快修复、必须修复、建议修复、低优先级4种。再现程度指BUG在特定环境和操作中BUG的重复出现的频率。包括每次再现、经常再现、很少再现、出现一次。缺陷分类BUG所属的分类包括功能性、界面性、易用性、性能、等特性。缺陷描述BUG出现的过程描述。包括缺陷出现的详细步骤以及使用的测试数据和附件等。Bug严重程度致命BUG：测试执行主要功能直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能点没有实现；主要模块/功能不满足需求或设计上的要求；软件的安全缺陷导致重要数据丢失或损坏。…Bug严重程度严重BUG：测试执行次要功能导致系统死机、蓝屏、挂起或是程序非法退出；系统的次要功能点没有实现；对于主要功能的执行结果与预期结果差别较大，或是计算结果不正确；软件的易用性不好，导致用户可能不能正常完成软件的主要功能操作；程序执行过程过于缓慢；程序占用占用过大的系统资源，或是占用资源后不能正常释放；主要界面有明显的错别字或描述错误。….Bug严重程度一般BUG：²软件的实际执行过程与预期结果有差异，但不严重；²非正常操作或输入导致系统出错，或执行结果不正确；²系统运行过程中偶尔（出现概率<5%）有出错提示或导致系统运行不正常；²软件交互性不好，对于用户可能造成难于操作、学习和理解；²在用户经常使用的环境中，界面不美观，影响软件品质；²界面、程序或帮助文档中文档或文字描述问题，造成用户难于理解。…BUG严重程度微小BUG：²

软件的实际执行过程与预期结果有较小的差异；²

软件不能处理用户可能使用的极端条件下的操作；²

界面、程序或帮助文档中文档或文字描述问题，但影响不大。…BUG优先级优先级别体现了开发人员修改BUG的优先顺序，分4个级别：尽快修复、必须修复、建议修复、低优先级。判定权限：项目经理。BUG优先级尽快修复：²

需要开发人员马上修复，并尽快修改完成。²

一般指BUG较为严重，并且会对其他工作造成不良影响的情况。必须修复：²

需要开发人员修复，并且要修改完成。²

一般指BUG较为严重，但对其他工作影响较小的情况。建议修复：²

开发人员最好要进行修改，但并不一定必须修复。²

一般指BUG较为轻微，影响软件品质。²

此类BUG若最终不修改，一般要做为遗留BUG。低优先级：²

开发人员可以根据实际情况来决定是否修改。²

一般指BUG无关紧要，对项目质量影响非常小。²

此类BUG若最终不修改，可以注销或做为遗留BUG。测试管理系统使用TestDirector的使用演示测试管理系统介绍项目BUG信息的记录与跟踪平台。系统用户：测试人员。开发人员。项目经理。浏览人员。测试管理系统主要功能是测试全过程的管理平台，贯穿整个测试生命周期。为测试管理者和项目经理提供量化和可视化管理。包括测试计划、测试用例、测试执行、BUG信息、测试报告、测试总结和用户反馈的各个阶段的管理。怎样发现BUG用客户的头脑思考---学会移情象愚笨的用户那样做--不遵守任何规定，不做任何假定不要局限在对显而易见事实的测试在缺陷密集区继续查找目标明确的结构化测试凭借经验，直觉和预感—经验是人们对错误行为的称谓目标明确的结构化测试在破坏性测试之前进行通过性测试

----等价类划分，数据测试，状态测试….开始破坏性测试

------竞争条件和时序错乱

------重复，压迫和重负加强测试

------BUG轰炸

------其他人员加入，BETA测试再现与优化缺陷再现（又叫重现）与优化缺陷的必要性备注：优化缺陷并不是指优化缺陷本身，而是优化缺陷的再现步骤为什么要再现与优化缺陷？关于软件中“随机”出现的缺陷如何处理？20再现与优化缺陷再现与优化缺陷的方法不要想当然的接受任何假设查找依赖关系和竞争条件的问题与压力和负荷相关的边界条件软件缺陷、内存泄漏和数据溢出缺陷的发生有一定的前提条件(清空缓存)状态缺陷仅在特定软件状态中显露(顺序)考虑资源依赖性，内存、网络、硬件共享的相互作用关注硬件的失效问题，硬件可能不按照预定方式工作(硬盘坏道)关注软件的失效问题，对缺陷的修改可能会引发新的缺陷从阅读缺陷报告入手，提高编写缺陷报告的能力(借鉴别人)21再现与优化缺陷小结再现与优化缺陷的必要性再现与优化缺陷的方法22怎样有效记录缺陷Bug的记录信息包括：软件名称、版本号、测试员、测试功能、配置环境、错误的类型、错误的等级、详细步骤、必要的附图、测试注释。保证重现缺陷判断一个缺陷报告撰写好坏的简单方法：让非缺陷报告撰写者（技术人员）依据缺陷报告重现缺陷，如果能简单、迅速的重现缺陷，表明缺陷报告较好。23怎样有效记录缺陷分析故障——使用最少步骤重现缺陷减少开发人员重现缺陷的时间使开发人员更准确的定位缺陷24怎样有效记录缺陷包含所有重现缺陷的必要步骤测试人员假定常用的操作步骤开发人员不一定熟悉，省略了必要的步骤常常造成开发人员无法重现缺陷。25怎样有效记录缺陷方便阅读举例：概述：使用“记事本”仅保存“联通”二字后再打开该文件，出现乱码。描述步骤：点击“开始”->“程序”

->“附件”

->“记事本”打开记事本软件；仅输入“联通”二字后，点击“文件”->“保存”；在打开的“另存为”对话框中保存文件后退出（文件名、保存位置任意）；打开保存的文件，出现乱码，不是“联通”二字。26怎样有效记录缺陷一个缺陷一个报告，为什么呢？举例（一个缺陷报告中两个缺陷）：概述：使用“记事本”仅保存“联通”二字后再打开该文件，出现乱码，而且“另存为”对话框中默认文件后缀写成了“.txk”。描述步骤：点击“开始”->“程序”

->“附件”

->“记事本”打开记事本软件；仅输入“联通”二字后，点击“文件”->“保存”；在打开的“另存为”对话框中保存文件后退出（文件名、保存位置任意），默认文件后缀应该是“.txt”，实际写成了“.txk”

；（假设）打开保存的文件，出现乱码，不是“联通”二字。这样有什么不良后果答案：步骤3出现的缺陷对于开发人员而言容易修复，而步骤4出现的缺陷可能很难修复，那么如果开发人员修复了步骤3出现的缺陷而没有修复步骤4出现的缺陷，这个缺陷报告是解决了还是没解决？怎样有效记录缺陷注意自己的语气举例：概述：“记事本”中“另存为”对话框中默认文件后缀写成了“.txk”。描述步骤：点击“开始”->“程序”

->“附件”

->“记事本”打开记事本软件；仅输入“联通”二字后，点击“文件”->“保存”；在打开的“另存为”对话框中，默认文件后缀应该是“.txt”，你们开发人员是不是用脚后跟考虑问题的，居然写成了“.txk”

；BUG描述的常见问题BUG描述不清,开发人员无法理解或者复现BUG严重程度定义不一致BUG优先级定义不一致BUG引入阶段没有填写的习惯.BUG提交后跟踪和处理方法不一致BUG描述不当引起的影响BUG修改时间长.大部分时间用于反复扯皮BUG处理意见测试人员与开发人员分歧很大.影响效率开发人员容易产生抵触情绪和抱有怀疑态度.影响项目工作气氛和谐.项目统计数据发生偏差,影响度量分析和工作改进可能会遗漏真正重要的问题BUG跟踪可能失去控制,遗忘或拖延重要问题的修改时限分析BUG时，要考虑以下问题：1、复现BUG现象所需的精确步骤和最少步骤有哪些？这些步骤成功复现这些现象的频率如何？2、执行测试用例的预期结果与实际结果不一致时，是测试错误，还是系统错误？也就是说，这种异常的结果起源于测试因素或测试人员的错误，还是系统故障影响顾客。3、哪些外部因素影响到这个现象？包括硬件环境、操作系统、其他软件、分辨率配置或字体设置等。4、什么是问题的根本原因（即我们通常说的“引入原因”），是代码、电子、网络，还是环境？根本原因是内部因素。5、怎样才能在不产生新BUG的条件下使这个问题得到解决？6、这种变化是否经过正确的调试，所属单元是否经过测试？7、问题解决了吗？它现在是否通过了先前失败的测试，并且系统的其余部分仍工作正常？怎样有效记录缺陷小结保证重现缺陷分析故障——使用最少步骤复现故障包含所有重现缺陷的必要步骤方便阅读尽量简单——一个缺陷一个报告注意自己的语气值得注意的经验33缺陷的管理以及状态转变Bug的状态：new、open、fixed、suspend、closed。Bug管理流程。2023/4/2软件缺陷的分类和管理1.软件错误：是指在软件生存期内的不希望或者不可接受的人为错误，其结果将导致软件缺陷的产生。2.软件缺陷：存在于软件之中的那些不希望或不可接受的偏差，入少一逗点或多一语句等。3.软件故障：软件运行过程中出现的一种不希望或不可接受的内部状态。例如软件除与执行一个多余循环过程时，若无适当措施加以及时处理，变产生软件失效。4.软件失效：软件运行时产生的一种不希望或者不可接受的外部行为结果。软件失效机理：软件错误---软件缺陷---软件故障—软件失效。2023/4/2缺陷报告缺陷报告是描述软件缺陷现象和重现步骤地集合。软件缺陷报告SoftwareBugReport（SBR）或软件问题报告SoftwareProblemReport（SPR）

缺陷报告的作用缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值

缺陷报告可以把软件存在的缺陷准确的描述出来，便于开发人员修正

缺陷报告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制

软件测试缺陷报告是软件测试的输出成果之一，可以衡量测试人员的工作能力软件测试缺陷报告的“5C”原则内容准确(Correct)

每个组成部分的描述准确，不会引起误解步骤简洁(Concise)

只包含必不可少的信息，不包括任何多余的内容内容清晰(Clear)

每个组成部分的描述清晰，易于理解结构完整(Complete)

包含重现该缺陷的完整