测试执行课件

测试执行Sunday,January1,2023课程内容测试执行的工作范围联想软件BUG定义测试管理系统使用关于BUG的几个问题BUG分析技术1.测试执行工作范围搭建测试环境执行测试用例发现软件缺陷（BUG）记录BUG和提交BUGBUG跟踪BUG分析和定位联想软件BUG的属性含多个方面，包括按严重程度、再现程度、优先级别、质量特性、BUG状态、引入阶段等。联想软件BUG定义： 指在测试过程中，软件不满足需求或质量要求的情况下，由测试人员提出的缺陷均称为BUG。属性说明具体内容BUG状态指在BUG跟踪和管理过程中的状态标识。包括待修复、待验证、已解决、遗留和注销5个状态。严重程度以可能对用户造成的影响程度做为最终的判断依据。包括致命、严重、一般、微小4种。优先级别指开发人员修改BUG的优先程度，由项目经理在审核BUG时分配。包括尽快修复、必须修复、建议修复、低优先级4种。再现程度指BUG在特定环境和操作中BUG的重复出现的频率。包括每次再现、经常再现、很少再现、出现一次。质量特性BUG反映出软件产品质量的特性。包括功能性、可靠性、易用性、效率、可维护性、可移植性6大特性。引入过程为BUG最初引入的过程或阶段。包括需求、系统设计、概要设计、详细设计、UI设计、编码、用户文档。BUG严重程度致命BUG：测试执行主要功能直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能点没有实现；主要模块/功能不满足需求或设计上的要求；软件的安全缺陷导致重要数据丢失或损坏。…BUG严重程度严重BUG：测试执行次要功能导致系统死机、蓝屏、挂起或是程序非法退出；系统的次要功能点没有实现；对于主要功能的执行结果与预期结果差别较大，或是计算结果不正确；软件的易用性不好，导致用户可能不能正常完成软件的主要功能操作；程序执行过程过于缓慢；程序占用占用过大的系统资源，或是占用资源后不能正常释放；主要界面有明显的错别字或描述错误。….BUG严重程度微小BUG：²

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

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

界面、程序或帮助文档中文档或文字描述问题，但影响不大。…BUG优先级尽快修复：²

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

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

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

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

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

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

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

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

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

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

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

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

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

------BUG轰炸

------其他人员加入，BETA测试分离缺陷和再现记录每一件事------寻找有效的重建步骤查找时间依赖和竞争条件压迫和负荷相关特定软件状态资源依赖性或其他不要忽视硬件不要沉溺于单一测试方式有效的软件缺陷描述简洁------不说废话单一------一次说一个问题,或者一个BUG只需改一处明显和通用----每个人都能了解你在说什么再现------保证缺陷可重建不做评价-----陈述事实而不是显露情绪监视修复过程并补充完善BUG描述

------建立缺陷的生存周期和档案BUG描述不当引起的影响BUG修改时间长.大部分时间用于反复扯皮BUG处理意见测试人员与开发人员分歧很大.影响效率开发人员容易产生抵触情绪和抱有怀疑态度.影响项目工作气氛和谐.项目统计数据发生偏差,影响度量分析和工作改进可能会遗漏真正重要的问题BUG跟踪可能失去控制,遗忘或拖延重要问题的修改时限BUG描述4.3怎样处理BUG报告问题的说服技巧---有效的问题报告---及早提出问题---给点儿建设性意见---人人喜爱的软件是不可能的,注意主观意见的分寸缺陷不是生来平等的---并非所有缺陷都能够(值得)修复软件缺陷生命周期-----寻找适当的人协助学会妥协和争取------建立和运用你的影响力评估和准备后续维护方案----眼光放长远BUG跟踪BUG跟踪遗留：经项目经理确认在本版本中可以不修改的缺陷。注销：实质上不是程序的最终BUG，但需要保留。例如，所对应需求发生变更或是被取消的BUG，或是由于产生歧义，项目经理建议注销的BUG（需要根据情况酌情定夺）。5.BUG分析技术分析BUG时，要考虑以下问题：1、

复现BUG现象所需的精确步骤和最少步骤有哪些？这些步骤成功复现这些现象的频率如何？2、

执行测试用例的预期结果与实际结果不一致时，是测试错误，还是系统错误？也就是说，这种异常的结果起源于测试因素或测试人员的错误，还是系统故障影响顾客。3、

哪些外部因素影响到这个现象？包括硬件环境、操作系统、其他软件、分辨率配置或字体设置等。4、

什么是问题的根本原因（即我们通常说的“引入原因”），是代码、电子、网络，还是环境？根本原因是内部因素。5、

怎样才能在不产生新BUG的条件下使这个问题得到解决？6、

这种变化是否经过正确的调试，所属单元是否经过测试？7、

问题解决了吗？它现在是否通过了先前失败的测试，并且系统的其余部分仍工作正常？归纳和演绎归纳法是一种从特殊到一般的思维过程，从对个别实例的认识当中，概括出共同特点，得出一般性规律的思考方法。演绎法是一种从一般的推测和前提出发，运用排除和推断过程做出结论的思考方法。归纳法分析

归纳法BUG分析技术是从测试结果发现的线索入手，分析它们之间的联系和关系，导出BUG原因的假设，然后再证明是否定这个假设，具体步骤如下：①从BIM系统中，收集有关BUG信息，列出程序哪些执行正确，哪些执行错误的信息。②组织BUG信息数据。整理这些BUG信息或对应的测试用例集，尽力发现其中规律，使用分类法构造一张线索表。③提出假设。分析线索之间的关系，根据测试人员的技术和经验，导出一个或多个错误原因的假设。④证明假设。演绎法分析演绎法BUG分析技术

是列出所有可能的BUG原因的假设，然后通过执行相关测试用例排除不适当的假设，最后在通过进一步测试验证余下的假设就是BUG原因，具体步骤如下：①当测试发现了BUG后，首先确定是由于程序出错造成的，否则