搜索
测试执行Chapter1测试执行Chapter2软件缺陷课程目录Chapter3测试报告Chapter1测试执行1.1什么是执行测试用例1.2用例的状态；什么是执行测试用例根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。1.明确要在被测软件的哪个版本上执行？2.确认要验证的测试点，在被测版本上已经实现了。3.按照测试用例的预置条件、步骤进行执行4.按照测试用例的预期结果进行结果判断5.如果结果失败，说明找到了缺陷1.当用例还尚未被执行时，是NoTest未执行状态2.当执行结果与预期结果相符时，是Pass通过状态3.当执行结果与预期结果不符时，是Fail失败状态4.当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。5.当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。Chapter2软件缺陷2.1缺陷的理论基础2.2缺陷的生命周期2.3缺陷的流程2.4缺陷的状态2.5缺陷的等级2.6缺陷实例与练习缺陷理论基础2.1.1缺陷的定义2.1.2缺陷的原因2.1.3缺陷的修复成本2.1.4缺陷的分布特征2.1.5缺陷的抗药性2.1.6并非所有缺陷都要修改缺陷的定义•软件未实现需求和规格要求的功能•软件出现了需求和规格指明不该出现的错误•软件实现了需求和规格未提及的功能•软件未实现需求和规格未明确提及但应该实现的内容•软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。•测试用例执行中发现的与预期结果不符的现象缺陷又名为BUG（臭虫）缺陷的原因需求与规格设计编码其它比例需求与规格设计编码其它缺陷的修复成本缺陷的分布特征•集结（二八定理）缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在20%的模块。并非所有的缺陷都需要修复•有一些原因，使得有些缺陷我们不修复：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复缺陷的生命周期缺陷的流程缺陷生命周期—状态缺陷状态描述New测试中新报告的软件缺陷，等待分派Open已确认的缺陷，等待开发人员修改Fixed已经被开发人员修改的缺陷，等待测试人员校验Rejected不是缺陷或不需要修复Reopen没有修复，重新打开返回开发人员Closed已经被测试人员确认得到正确修复，可以关闭缺陷的等级缺陷严重程度描述4--致命软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果3--严重–软件的次要功能丧失，或者主要功能在一些特定情况下会出错，比如金额计算等2--一般软件在某些情况下会出错，但是造成的后果影响不大1--轻微在某些情况下会出错，但是造成的后果影响很小缺陷单的编写•一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子•要做到这样，你应该怎么做呢1、提供足够的错误环境信息，使得开发人员既能够明确如何重现故障现象，又有足够的信息定位到问题的根源2、书写良好的重现步骤；3、上传附件，例如软件运行日志，抓图，网络抓包，声音，视频等。4、使用特殊的颜色对重点词语进行标记；5、使用关键词进行强调6、特殊标记一个缺陷的基本要素缺陷ID缺陷复现步骤缺陷标题期望结果测试环境实际结果缺陷发现的日期和时间附件缺陷提交人缺陷的优先级缺陷的严重等级；测试类型发现缺陷的软件版本例子-excel表例子-bugfree如何写好每部分（1）•标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。例如：Error402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的上下文信息。•差：“程序崩溃”，“报错”，“Bug”•好：“从’Kifu’中打印时5C79错误”，“’Kifuhonors’报表为空”•产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web应用的版本信息通常在页脚。•差：“你的应用”•好：”Kifuv1.01″•平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用，这些信息对我们很重要。•差：“Windows”•好：“Windows7,IE9”•是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢Bug出现时。•差：留空白•好：“每次”，“偶然”，“不重现”如何写好每部分（2）•●总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？•差：“系统不能用了”•好：在“honorreport”页面单击“打印按钮”，但是报表是空的。•●发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。•差：“空白报表”•好：“点击‘File/Saveas…’，’Save‘对话空弹出，然后点击‘OK’按钮，但是文件没有保存”•●错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。•差：“有个错误，点击它始终读不出”•好：“Error403：访问拒绝”•●复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。一步步描述如何重现次bug。•差：“打印没法使用”•好：“从‘HonorsReport’页面，点击‘打印按钮’”如何写好每部分（3）•●预期结果：描述你预期发生的结果当bug发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。•差：“我期待能正常工作”•好：“我期待能看到‘HonorsReports’的PDF文件”•真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或者如果错误抛出，抛出什么错。•差：“没法用”•好：“我收到是空的PDF文件，或者’403错误，访问拒绝’”••●附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志，同样附上它。Chapter3测试报告3.1测试报告的主要内容实例3.2测试结果分析3.3测试总结测试报告的主要内容（掌上书院）3.1.1数据统计3.1.2遗留bug情况3.1.3测试风险3.1.4测试对象评估3.1.5测试结论3.2测试总结数据统计-人力投入投入项测试人员工作量（人天）测试用例维护XXX1天/人测试执行XX、XXX9.5天/人（XX：5.5天，XXX：4天）合计XX、XXX9.5天/人数据统计-用例覆盖率用例总数通过用例数（OK）未通过用例数（NG）尚未测试（NT）无测试条件，暂时不能测试（NC）尚未开发（ND）通过率（％）备注263251001111新增加19个用例数据统计-问题单分类统计1、Bug严重级别统计致命严重一般提示合计07264372、BUG类型统计功能UI异常体验合计261010373、Bug状态统计未解决打回挂起已解决打开合计关闭合计37000004、Bug根源分析表需求类设计类编码类其他4000遗留bug情况序号BugID缺陷描述影响程度后续解决措施当前规避方法1224Web页面—下载热门推荐，中间的节日专区，配置new，hot标识时，在IE6下将产生换行。未影响功能（兼容性问题）暂时忽略在下载热门推荐时，不采用new、hot配置2314后台管理—图片管理，点击上传图片在IE6.0下，随机出现上传窗口无法打开的情况。比较小暂时忽略后台维护时，请采用IE7.0浏览器测试风险暂停的问题：1、出现概率比较低，用户操作不易复现的问题，后续由客户端修改；2、3是本地阅读定位问题，修改比较困难，不影响使用，后续优化；5、属于遗留问题；4、6、7属于内容平台问题，内容优化；暂停问题是产品人员、开发人员与测试人员沟通后暂停的。测试对象评估1.基本功能评估5.4版本在本地阅读txt格式章节提取、在线阅读预加载、下载管理重实现、用户反馈功能实现、图书内容分享、网络连接、UI上做了一些修改、优化、调整，增加了一些新功能，本地阅读、在线阅读等基本功能改动不大，且都已实现稳定。2.性能评估性能主要体现在：1.本地阅读设置方面，设置后本地阅读界面都能正常显示；2.Txt格式图书章节提取，是否精确；3.下载管理重实现，在线小说的下载，多任务的下载是否顺畅；4.在线阅读，连续阅读是否顺畅；5.Wifi和GPRS网络连接下，客户端的使用是否顺畅；3.稳定性评估软件各基本功能稳定4.易用性评估易用性较5.3版本好，在功能和界面上做了很多优化5.其他评估功能上简单易用，界面友好悦目，功能上在txt格式章节提取、下载速度上做了很大优化测试结论1.版本功能基本实现且运行稳定，问题修改及时，在预定日期内完成开发和测试进度质量评价通过，可以发布及系统上线测试结论□通过，可以发布及系统上线□不通过，需要进行重大修改更新版本重新测试评估人员XX审核人员XXX测试结果分析•测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节，“编筐编篓，全在收口”，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。•因为通过对问题单的分析、总结不仅能发现不同人提交问题的类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲区。测试总结•回顾整个项目的测试过程，总结个人成长经验，取得了什么成绩、有哪些不足、有什么好的经验或者方法可以和大家分享呢？对工作进行一个理性的分析和思考。问答培训总结