软件测试管理知识.ppt

《软件测试管理知识.ppt》由会员分享，可在线阅读，更多相关《软件测试管理知识.ppt（30页珍藏版）》请在三一办公上搜索。

1、软件测试管理知识,徐登峰2011/02/26,目录,一.熟读bug三百条，bug怎找很明了二.软件测试过程中进行Bug描述 三.软件测试缺陷密度的计算方法 四.需求测试怎么做？五.巧破软件测试缺陷管理之痛 六.怎么看待缺陷漏测,一.熟读bug三百条，bug怎找很明了,古人说：熟读唐诗三百首不会作诗也会吟。很多小孩子，从小就要求背诵唐诗宋词，熟练之后自然而然就会把握住诗词歌赋的韵律。在我们测试行业，很多新人在刚踏进这个门槛的时候，最迷茫的就是怎么找bug啊，有些bug提上去，被退回来，被人说不是bug，有些bug，自己认为不是bug，别人却说你怎么不提啊，结果造成遗漏，三来二去，刚进来时候的豪情

2、万丈，被打击成垂头气丧了。,那么，作为测试工程师，如何积累对bug的敏感度，以及把握的准确度呢，这个话题，可能不只是新人，很多在这个行业做了很多年的工程师也觉得这是个老大难，在这里，我提一个建议，熟读bug三百条，bug怎找很明了。今天看了雅虎的QA典型百大missbug总结，才有此感触，的确我们应该形成经验积累的机制，尤其是bug，今年大量新同学加入我们团队，如果他们能在上岗前的培训中都过一遍我们常见典型的bug总结结果，将对他们的质量意识和bug敏感度有很好的提升，如果以后工作中再培训的话，效果就差很多了，和我们bug的发现时机是一个道理，越早发现bug，越早解决，我们所付出的代价就越小。

3、,与其临渊羡鱼，不如退而结网，相关负责人应该落实这种机制，积累一些我们这几年的典型bug，用文档或某种形式形成共享，在新同学们上岗前培训一下，我期望的是每一个新人在正式工作前，至少要熟读百个以上的典型bug，并且最好可以亲自重现或者分析其中的一些。一句话：没吃过猪肉，也应该大概见过猪跑;没提过bug，也应该大概知道bug怎么找。,二.软件测试过程中进行Bug描述,1、术语解释测试程序：提供给测试组测试的程序；测试计划：对测试程序（构件、应用程序、系统等）及其目标进行简要说明；测试bug：不符合测试需求的错误，也就是缺陷；错误跟踪系统：是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报

4、告和错误趋势，如RationalClearQuest就是一个错误跟踪系统,2、为什么要提交bug在得到一个详尽的测试程序后，剩下的工作就是执行测试计划了。但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用：1)减少由于缺陷报告不明确而被开发组驳回的情况；2)加快缺陷的处理速度；3)提高测试的可信度；4)加强测试组与开发组在整个项目过程中的团队合作3、如何才能提交好的测试bug,在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那

5、些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失去改进产品质量的机会。有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。,

6、为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤：1)结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试；2)再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；3)推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。4)总结：简要描述客户或用户的质量体验和观察到的一些特征,5)压缩：精简任何不必要的信息，特别是冗余的测试步骤。6)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。7)中立：公正

7、地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。8)评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估报告之前先自己读一遍。好的测试bug描述是告诉读者测试人员发现了什么，而不是测试人员做了什么。因此只需要根据上述八个步骤写下最少的必需重现步骤,4、如何提交bug一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。标题使用一两句话来描述错误，告诉经理、开发人员以及其他读者

8、为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如：“联系人的email没有检查合法性”；重要的就要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。项目是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。所属模块是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误；,优先级分为以下4级：1级：“马

9、上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求；2级：“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现；3级：“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等；4级：“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。重要性分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示

10、修改以后流程会更好。,三.软件测试缺陷密度的计算方法,一、缺陷密度基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defectsKLOC。缺陷密度=缺陷数量/代码行或功能点的数量。,二、计算方法可按照以下步骤来计算一个程序的缺陷密度：1.累计开发过程中每个阶段发现的缺陷总数(D)。2.统计程序中新开发的和修改的代码行数(N)。3.计算每千行的缺陷数Dd=1000*D/N。例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是：Dd1000*145/296000=0.49 defectsKLOC。,在缺陷密度度量中存在的两个主要

11、困难是：1.缺陷权值如何计算：是否将严重程度较轻的缺陷和较重的缺陷同等对待。2.代码行怎么统计：代码行的数量可能会因编程人员的技术水平和所使用的语言不同而不同。3.对于黑盒测试人员，可能不太容易获取到代码行数。为了解决以上问题，缺陷密度计算方法可以改为：D/C 即缺陷总权值 除以 功能总权值缺陷总权值计算方法=Sum（缺陷数x该缺陷等级的权值）权值可以根据自己项目的实际情况，进行拟定。功能权值计算方法跟缺陷权值计算方法类似，项目经理根据各个功能模块的复杂度拟出每一个模块权值，为了对不同项目缺陷密度的可比性，不同项目的功能权值要求要基本大致相同。,例如：三、具体实例从度量库数据收集表中提取数据分

12、析。说明：系统测试阶段的缺陷严重等级分为四级（提示、一般、严重、致命），按照严重等级为一般做为标准单位换算，4个轻微1个一般，1个严重2个一般，1个致命3个一般；缺陷严重性定义：致命-系统崩溃，丢失数据或内存溢出等严重错误；严重-主要功能或业务无效；一般-系统功能部分无效；提示-琐碎-拼写错误，文本未对齐，数据长度格式校验等系统测试发现缺陷密度：,计算出缺陷密度值，用该值与以前的项目的缺陷密度值进行比较，如果在此范围，则可作为一个测试充分的参考依据，上表计算出的的Dd=2.481，2.481都已经小于此表中对应值的下限5了，从一定角度上来说该项目测试还不充分！,四.需求测试怎么做？,需求测试

13、软件测试软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0%8 5%的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头(需求)就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述(例如形式化的方法)，因此在适用性上会受到限制。

14、通过静态手工方法进行需求测试中最常使用的手段是同行评审。,1.通过评审来测试需求,同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审(Peer Review)，尤其是正规检视(Inspection)。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。,2

15、.好的需求应当具有的特点,一个良好的需求应当具有一下特点：完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：“必要性”可以理解为每

16、项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e-g r a i n e d)的方式编写并单独标明，而不是大段大段的叙述。另外应当对所有的需求分配优先级。如果把所有的需求都看作同样

17、的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度,五.巧破软件测试缺陷管理之痛,人世间最痛苦的事莫过于我所在项目开发正陷于混乱不堪的缺陷之中。因为缺乏一套缺陷管理的有效解决方案，使程序的缺陷无法回溯，无法跟踪，解决没解决不清楚，整一个就是一片模糊。由于没有得到足够的重视，软件缺陷管理处于失控状态。软件测试人员报告的缺陷常常被遗忘掉；或没有人知道在新的软件版本里究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。更重要的是纠正过程是否引入了新的缺陷也没有人知道，再或者就是缺陷报告书写不规范，使得开发人员不得不一次次找到测试人员来面谈，还有许多无效的文档使缺陷状态混乱，相关人员无法及时获得有关

18、的变更信息。,1.什么是开发的缺陷管理？,软件中的缺陷（Defect或BUG）是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。,（1）缺陷管理的目标一般而言，缺陷的跟踪和管理需要达

19、到以下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。,（2）缺陷管理重在预防缺陷正如我们所知，BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶

20、段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此，越晚修正BUG，需要重做的事情就越多。对很多人来说，零缺陷的软件产品似乎是不切实际的。因此，我们总是听到许多软件开发人员说：“软件永远有BUG”。软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值提深思的事情了。事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。为了能够预防BUG，我们首先需要了解BUG的来源。软件BUG可以分为几个类别：第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难

21、预防。但是，适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。因此，BUG的预防尤为重要。,2.缺陷管理的核心：缺陷分析,缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。

22、BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费，但是却可带来极大的额外价值。,（1）BUG记录BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那

23、样了解产品的内在，包括深入源代码，理解产品的设计和实现。,（2）利用BUG分析了解开发质量趋势对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。在这个时候，BU

24、G分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。,六.怎么看待缺陷漏测,如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越早被

25、发现，发现和解决缺陷所花的成本就越小。,漏测的定义所谓漏测，是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里，却最终被用户所发现。如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越早被发现，发现和解决缺陷所花的成本就越小。如果缺陷是在测试组测试中发现的而不是被用户使用时发现的，那么所花的成本将小得多。如果缺陷是被开发组在开发过程中发现的，那么所花的代价将更小。因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。,漏测分析的目的进行漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进。具体来讲，就是通过分析开发和测试过程中漏测的缺陷，制定相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量、声誉和销售。在软件产品开发过程中重视漏测分析并参与到漏测分析工作中的团队越多，漏测分析的效果就越好。如果开发和测试团队都重视漏测分析、并密切配合进行漏测分析工作的话，漏测分析将取得非常好的效果。,