2019测试7测试管理

测试管理,张亶2020/6/5,Ageda,测试的缺陷管理,测试的组织管理,测试的流程管理,2,TMM介绍与测试流程改进,Bug分类,按严重程度分类按优先级分类按照测试种类分类功能测试的缺陷性能测试缺陷UI测试的缺陷兼容性测试的缺陷,缺陷报告,软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。,缺陷报告的读者对象,缺陷报告的直接读者是软件开发人员和质量管理人员来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。,缺陷报告的写作准则,为了书写更优良的缺陷报告，需要遵守“5C”准则Correct（准确）：每个组成部分的描述准确，不会引起误解；Clear（清晰）：每个组成部分的描述清晰，易于理解Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；Consistent（一致）：按照一致的格式书写全部缺陷报告。,缺陷报告的组织结构,缺陷的标题缺陷的基本信息测试的软件和硬件环境；测试的软件版本；缺陷的类型；缺陷的严重程度缺陷的处理优先级。复现缺陷的操作步骤；缺陷的实际结果描述；期望的正确结果描述；注释文字和截取的缺陷图像。,Bug的处理流程,Bug的处理流程,1Bug提交2BUG确认&分配3BUG分析4BUG解决&评审5BUG验证6Rejected状态的BUG的处理7Postponed状态的BUG的处理8Duplicated状态的BUG的处理9Monitored状态的BUG的处理,缺陷管理工具的网络投票排名,1.bugzilla2.bugfree3.TestDirector4.ClearQuest5.JIRA6.Mantis7.bugzero8.QualityCenter,案例：微软的缺陷管理,Ageda,测试的缺陷管理,测试的组织管理,测试的流程管理,2,TMM介绍与测试流程改进,流派1：常用组织结构模型,1.独立的测试部门,优点：保护SQA工程师的独立性和客观性有利于资源的共享,缺点：难于深入项目并发现关键问题SQA工程师发现的问题不能及时解决,常用的组织结构模型,2.独立的测试工程师,优点：能够深入项目发现实质性问题SQA工程师发现的问题能够及时解决,缺点：SQA工程师之间的沟通和交流独立性和客观性不足,常用的组织结构模型,独立的测试工程师,流派2：测试组织作为开发组织的一部分,这个模型的优点是：唯一的优点是，当项目非常小人员很少的时候，这个模型可以降低开销，提高效率；这个模型的缺点是：测试服务于开发，测试不能独立的不受限制的完成客观的有意义的测试任务；测试资源（包括人员、资金、工具、时间）受开发管理者的控制，不可能实现客观的正确的资源配置；,测试组织作为项目组织的一部分,这个模型的优点是：测试服务于项目，项目管理者能够以比开发者更客观公正的立场处理开发与测试的关系；测试管理者向项目管理者报告，发现的问题会得到更好的关注；这个模型的缺点是：项目管理者一般与开发管理者具有相同的议程和兴趣关注；测试被作为项目资源的一部分，被项目管理者支配；测试的资源可能得不到合理的利用，甚至得不到保证；,测试组织独立于项目,这个模型的优点是：公司管理者会从公司利益的角度调整测试与项目的关系；测试管理者向公司管理者报告，项目问题得到客观反映，产品质量可以得到充分关注；测试资源可以得到较充分的保证，并会在项目中合理的分配；这个模型的缺点是：比起前两个模型，该模型的缺点不谈也罢；,当公司规模达到一定程度，同时有多个项目在进行前两种模型肯定不适合，它们也会在不同程度上造成资源浪费，测试的客观公正性也会得不到保证。第三种模型就成为必然的选择。,资源不充分的测试组织,假设，多个项目同时进行，测试组织负责所有项目测试任务，按照前面提到的配备比例，每个项目都会组成一个测试小组（该小组向测试组织报告）。如果测试组织的测试人员，即使不考虑技能条件，也不能满足前面的比例配备要求，最终为每个项目配备的测试人员可能很少，甚至没有，这样开展组织制定的测试活动可能根本无法实现。,任务驱动式人员配备和组间协作式组织测试过程。任务驱动式人员配备，要求测试组织根据各个项目情况，结合测试人员情况，为每个项目配备一个测试小组，测试人员与开发人员比例一般在1：10左右。在没有测试任务的情况下，测试人员可以被调到需要测试人员的测试小组。,组间协作式组织测试过程，是在每个项目中，测试小组负责项目的测试任务，测试活动在测试小组的主导下开展，活动中需要或者部分需要开发人员的参与完成，参与测试的开发人员在测试组成立时确定。测试小组对开发人员有下达任务、工作结果审核的权力。,测试人员的能力,沟通能力能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通技术能力就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线,测试人员的能力,自信心开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。外交能力当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。幽默感在遇到狡辩的情况下，一个幽默的批评将是很有帮助的,测试人员的能力,很强的记忆力一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。怀疑精神可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。自我督促干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。洞察力一个好的测试工程师具有测试是为了破坏的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。,测试人员的公关,避免开发人员与测试人员产生矛盾开发人员的注意事项：不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试测试人员的注意事项：发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。请留意另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。,企业的测试策略,理念企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。如何合理地减少测试工作量减少冗余的测试白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作减少无价值的测试无价值的测试通常是由于不懂得测试技术引起的。如何“偷工减料”偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。,企业的测试策略,“偷工减料”方法的测试优先级：哪些功能是软件的特色？哪些功能是用户最常用的？如果系统可以分块卖的话，哪些功能块在销售时最昂贵？哪些功能出错将导致用户不满或索赔？哪些程序是最复杂、最容易出错的？哪些程序是相对独立，应当提前测试的？哪些程序最容易扩散错误？哪些程序是全系统的性能瓶颈所在？哪些程序是开发者最没有信心的？,Ageda,测试的缺陷管理,测试的组织管理,测试的流程管理,2,TMM介绍与测试流程改进,简化版测试流程,第一步：制定测试计划。该计划被批准后转向第二步。第二步：设计测试用例。该用例被批准后转向第三步。第三步：如果满足“启动准则”，那么执行测试。第四步：撰写测试报告。第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。,审批,审批,回归测试,完成测试,QC版测试管理过程,定义需求计划测试执行测试缺陷跟踪,定义需求,定义测试范围创建需求详述需求分析需求创建需求：建立需求树，定义总体的测试需求详述需求：为需求树上的每一个主题，建立一个详细的测试需求列表；分析需求：生成报告和图表辅助分析创建的测试需求，检验需求是否适用于测试范围。,作测试计划,制定测试策略制定测试目标定义测试创建需求覆盖设计测试步骤自动测试分析测试计划制定测试策略：确定应用程序、系统环境、测试资源制定测试目标：把应用程序分解为可测试的功能。建立一棵测试计划树按级别把应用程序分解为测试单元或主题。定义测试：为每个测试主题确定测试类型。创建需求覆盖：把每个测试与一个或多个测试需求关联起来。设计测试步骤：通过在测试计划树上增加测试步骤来开发手工测试。自动测试分析测试计划：生成报告和图表辅助分析测试计划。检查计划是否符合测试目标。,执行测试,缺陷跟踪,测试启动准则,同时满足以下条件，允许开始测试：（1）测试计划已经制定并且通过了审批；（2）测试用例已经设计并且通过了审批；（3）被测试对象已经开发完毕并等待测试。,测试完成准则,有许多中准则，例如ZBB&ZRB（微软）准则，还有,以下为一个例子。同时满足以下条件允许结束测试：（1）功能性测试用例通过率达到100；（2）非功能性测试用例通过率达到90；（3）相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。,测试文档模板,测试计划参考模板测