精华内容
下载资源
问答
  • 测试管理之--用例管理

    千次阅读 2018-08-07 18:24:53
    用例管理是测试管理中非常重要的一项工作,用例也是产品测试设计的重要产出。用例管理的好坏也直接决定着测试执行的效果。我们的用例管理也经历了几个阶段的发展,获得了诸多的经验和教训。 测试用例包括如下元素:...

    用例管理是测试管理中非常重要的一项工作,用例也是产品测试设计的重要产出。用例管理的好坏也直接决定着测试执行的效果。我们的用例管理也经历了几个阶段的发展,获得了诸多的经验和教训。

    测试用例包括如下元素:测试用例编号、测试内容、测试条件、测试过程、预期结果、实际测试结果、备注、测试时间记录、测试人员、项目负责人、监督人员、测试日期等。

    典型的测试用例模板如下所示:

    用例管理1.0阶段

    典型特征如下介绍:

    用例数量少:有几百个用例,相对来说数量比较少;

    用例无特定编号:无唯一的对应编号,只有一个数字编号,不利于维护;

    用例粒度不统一:功能用例粒度偏细且全,没有针对性,且用例之间彼此有交叉,不利用问题快速定位;

    用例分类不合理:涵盖功能性、性能、可靠性、可用性、稳定性等,有两个问题,一是用例分类不全,二是用例针对性不强,偏系统性较多;

    用例执行步骤多:一般的用例执行步骤在10个左右,甚至多的有10几步,相对比较多;

    用例整合不到位:用例整合的不够好,其实很多用例都可以连在一起测试,或者说按照一定顺序测试更好,可以节省更多时间;

    用例数据留存不明确:测试用例没有明确说明哪些要截图、截什么图,也没有明确说留存什么数据,这样执行的过程中没有参照,容易遗漏;

    测试报告编写不方便:测试报告是在测试用例执行完之后编写的,由于用例测试执行不是特别方便,所以测试报告的编写就会有偏差,偶尔出现返工的情况;

    无专属自动化测试用例:这个阶段是没有专门的自动化测试用例的,所有用例跟着产品测试走;

    我们的用例管理2.0阶段:

    需求-checklist-用例对应不明确:在我们的用例管理中,checklist是一个测试点的列表,是用例管理的核心,与需求、测试用例有明确的对应关系。如下示例:

    用例管理2.0阶段

    典型特征如下介绍:

    用例数量增多:近万个用例,用例数量增加较大,增加了很多管理成本;

    用例有唯一的编号:所有用例都有唯一的编号,维护比较方便;

    用例粒度相对统一:比如功能测试侧重纯功能且针对性比较强,不再与其他功能交叉,便于问题定位;

    用例分类比之前丰富:涵盖功能性、性能、可靠性、可用性、可维护性、稳定性、线上场景模拟等,较之前更加完善;

    用例执行的步骤:按照设计的原则,简单用例尽量控制在8步以内;系统性的复杂用例,也尽量控制在12步以内;

    用例整合:把测试配置类似、测试前后有关联性的用例进行梳理,给出建议的测试顺序,并整理测试配置,多个用例可以共用;

    用例数据:对测试执行过程进行了统一的数据留存要求,个别特殊用例额外标识出需要截图和留存的数据;

    测试报告:测试报告以checklist为范本,进行了修正整理;优化了报告的可读性;

    专属的自动化测试用例:本版本暂未大肆编写,只是讨论了专属用例的实现思路和方式,另外将自动化的测试用例、产品测试的测试用例、测试checklist三者前后对应起来,更加直观性和一致性。

    简要示例如下:

    checklist模板说明

    checklist测试点模板

    测试报告概览:

    测试报告详细结果:

    用例管理3.0阶段

    测试用例通过2.0阶段的发展,管理的水平有了很大提高,但是成本和代价依然比较大,需要很多人工投入,且维护起来不是特别方便。3.0阶段我们准备借助测试模型来自动编写,这样管理的成本大大降低,当然这需要一定的技术突破,目前我们也正在做相关的调研,希望可以尽快落地。

    总结

    用例管理是需要很多经验积累的。通过用例管理1.0阶段,我们充分认识到我们的不足和存在的问题,同时也找到了改进的方向;通过用例管理2.0阶段,我们把1.0阶段暴露的问题基本上都优化和解决了,同时结合工作实践做出了一些改进,大大提高了我们的工作效率和水平,但是仍有一些根深蒂固的问题难以突破,比如庞大用例数量的管理、需求变更带来的用例维护、用例扩充的及时性、用例的自动化实现、专属的自动化用例等等。通过多方面的技术调研,我们找到了一些曙光和方向,部分公司也已经在落地实行,对于我们来说,挑战和压力都比较大,那就是通过测试模型的建立来自动化的生成测试用例。这种方式可以解决很多我们用例管理2.0阶段的问题,但是技术要求的难度可想而知,目前的人力和时间未必允许投入过多的资源去做。这也是目前自动化测试的一大技术方向,希望有兴趣的同学可以多研究下。

    展开全文
  • 测试管理之--管理制度

    千次阅读 2018-07-11 18:05:21
    俗话说,无规矩不成方圆,测试管理也是如此,想要让测试人员都按照一定的要求和准则去做事情,一些必要的管理制度是必不可少的。对于我们团队来说,主要分为如下几个方面,大家可以参考:1、测试管理制度,包括分权...
    俗话说,无规矩不成方圆,测试管理也是如此,想要让测试人员都按照一定的要求和准则去做事情,一些必要的管理制度是必不可少的。
    对于我们团队来说,主要分为如下几个方面,大家可以参考:
    1、测试管理制度,包括分权管理、分级审查、分级监督、绩效考核、工作总结、外部工作、测试评审等制度,示例如下:

    2、测试开发制度,包括测试开发流程、用例管理、开发规范等制度,示例如下:

    3、产品测试制度,包括测试流程、用例管理、测试报告、版本控制等制度,示例如下:

    4、交付测试制度,包括测试流程、验收测试、度量分析、客户培训等制度,示例如下:

    良好的制度可以产生如下作用:
    1、所有测试人员都有一个工作的标尺,大家一视同仁;
    2、可以规范化和流程化测试过程,让大家养成好的习惯;
    3、可以提高测试的工作效率,整体提升工作水准;
    4、做到有“法”可依,违规处理相关人员时有参考依据;
    5、使得整个团队形成一个整体,大家互相配合,互相监督,一起成长。
    总的来说,制度是很好的一个管理方式,一定要结合当前团队的实际情况和公司的整体管理要求,把控好适当的“度”。我相信,测试管理的水平一定会提高,而最终受益的,一定是测试人员、测试部和公司。

    展开全文
  • 软件测试管理知识总结

    千次阅读 2019-07-15 17:48:00
    1 软件测试管理概述 1.1软件测试管理基础 1,软件测试管理目标:软件测试管理的目标是通过系统的、高效的、适用的技术、方法和体系来监督、促进和达到这个软件测试的目标。 • 可用测试资源 • 使用适当的测试技术和...

    1 软件测试管理概述
    1.1软件测试管理基础
    1,软件测试管理目标:软件测试管理的目标是通过系统的、高效的、适用的技术、方法和体系来监督、促进和达到这个软件测试的目标。
    • 可用测试资源
    • 使用适当的测试技术和方法
    • 明确具体软件测试任务
    决定软件测试管理时应考虑:
    在这里插入图片描述
    2,软件测试管理定义:对每项具体软件测试活动以及总体软件测试全局的监督、评估、决策和管理的过程。软件测试的管理就是对每一种具体测试任务、流程、体系、结果、工具等进行具体监督和管理。
    分类:比较常见把软件测试管理分为8类:
    1.软件测试需求管理
    2.软件测试质量管理
    3.软件测试团队管理
    4.软件测试文档管理
    5.软件测试缺陷管理
    6.软件测试环境管理
    7.软件测试流程管理
    8.软件测试执行管理
    9.其它(计划、用例、报告、成本、风险)
    3,软件测试管理范围与来源:
    系统测试需要管理的内容:
    需求分析阶段:测试需求。
    测试计划{测试范围,时间进度,人员团队,环境(本地环境,测试环境,验收环境,
    生产环境,镜像环境)的服务器,网络等。风险,质量
    4,软件测试管理特色:
    在这里插入图片描述
    1)敏捷开发的流程:
    在这里插入图片描述
    2) 质量问题持续反馈:敏捷测试管理=质量问题持续反馈
    在这里插入图片描述
    3)自动化测试策略:新功能测试用手工测试旧模块可以使用自动化测试
    在这里插入图片描述
    4) 敏捷测试管理工具:HP Agile Manager、微软的Visual Studio 2012,包括TFS 2012、
    Scrum模板(MS VS Scrum 1.0)、Test Manager 2012、Coded UI Test等。
    1.2软件测试管理体系
    1,建立软件测试管理体系的主要目的
    1.对软件产品的评估和测量
    2.对软件产品的缺陷识别和控制
    3.产品设计和开发的验证
    4.软件过程的监视和测量
    5.有流程和规范指导
    2,ISO 9001与软件测试
    1)ISO9000基础:ISO是国际标准化企业的缩写。9000是标准的代号,ISO将9000下的编号分配给与质量管理和质量保证的有关标准。
    2)ISO 9000质量管理体系的八大原则:
    原则一:以用户为关注焦点
    原则二:领导作用
    原则三:全员参与
    原则四:过程方法
    原则五:管理的系统方法
    原则六:持续改进
    原则七:基于事实的决策方法
    原则八:互利的供方关系
    3)ISO9001对软件测试管理的指导作用
    3,软件测试成熟度模型TMM
    TMM是当前影响力最大的软件测试过程模型
    它的优点如下:
    a)等级水平结构、关键活动和角色的定义最为精细;
    b)测试相关因素覆盖最全面;
    c)支持测试过程成熟度增长;
    d)有定义良好的评估模型的支持;
    e)实施TMM能改进测试过程,并有助于提高软件质量、软件工程生产力和缩短研发周期,减少投入。
    在这里插入图片描述
    4,如何建立测试管理体系
    某企业用于测试管理的结构图:
    在这里插入图片描述
    测试活动实例图:
    在这里插入图片描述
    1.3软件测试管理要素
    1,测试管理五要素:质量;人员;流程;资源;技术
    2,软件测试管理体系本身是软件的应用,就是一种技术,一是工具。软件测试管理体系涉及功能测试、性能测试、安全性测试等多种软件测试类型,包含了软件测试流程中各阶段的流程规范、测试理论、测试工具等各方面内容。
    在这里插入图片描述
    3,相互关系:试管理的5个工作面基于软件测试金字塔的构成
    相互关系如下:
    在这里插入图片描述
    1.4 软件测试管理策略
    2 软件测试需求管理
    2.1软件测试需求概念
    1,软件测试需求:以一个项目的观点看待软件测试工作,这个项目的范围就是软件测试需求,它定义了软件测试工作的范围,是进行其他测试活动的基础。
    软件测试需求的内容: –功能测试需求
    –性能测试需求
    –可靠性测试需求
    –国际化与本地化测试需求
    –安全性测试需求
    2,软件需求管理
    1)软件需求的概念:
    软件测试需求管理是要通过人为的和技术的手段、方法和流程,以保证和监督测试团队明确测试软件产品的目标。
    定义1:软件需求就是一个为软件系统的需求进行启发、组织、建档的系统方法,一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。
    定义2:一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一的过程。
    2)软件需求管理要求:
    a)软件需求规格说明已文档化,并经评审后存档。
    b)文档化的软件需求规格说明受管理和控制。
    c)供软件工程和管理使用的分配基线已建立,使软件产品满足分配需求的接收标准;分配需求是制定软件开发计划的根据,是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。
    d)软件开发计划、软件工作产品和软件过程活动与软件需求保持一致。
    业界常见的测试过程中存在的问题 :
    软件测试本身的需求文档不全,有些需求待定;
    产品质量维度事先没有全面明确,要包括的测试类型不全;
    测试计划和编写测试案例没有规范;
    没有系统的测试需求分析方法、流程或指导;
    测试中经常会出现需求和缺陷遗漏、测试设计遗漏的问题。
    3)软件测试需求管理意义
    (1)失败经验教训说明必须要有软件测试需求管理
    (2)业界专家建议必须实施软件测试需求管理
    (3)缺乏成熟的理论和统一标准而需要需求管理
    在这里插入图片描述
    2.2软件测试需求分析
    1,分析的目标和任务:
    1)软件测试需求分析的目标:软件需求分析的目的就是要对软件测试要解决的问题进行详细的分析,弄清楚参与软件测试活动的干系人对软件测试活动和交付物要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。
    2)测试需求分析主要有两个任务:
    (1)通过对测试活动需要解决问题及其环境的理解、分析和综合,建立分析模型。
    (2)在完全弄清所有测试活动干系人对测试的确切要求的基础上,用 “软件测试需求规格说明书”把测试需求以正式书面形式确定下来。
    (Software Test Requirement Specification,SRS,简称测试需求书)
    2,分析的方法
    1)软件测试需求分析的意义:
    如果把测试活动比作软件生命周期,测试需求就相当于软件的需求规格,测试用例相当于软件的详细设计,测试用例的开发过程相当于软件的编码过程。但是软件测试不是简单把“软件”两个字全部替换成了“测试”这样简单,就测试需求分析的方法而言,即可以参考软件需求分析方法,又有其独特性。
    2)软件测试需求分析的方法:
    (1)通过软件的需求推导软件测试需求(最通用的方法)
    3,分析的过程
    1)软件测试需求分析的过程
    (1)软件测试需求分析干系人分析
    (2)需求收集和整理
    (3)测试需求的优先级排序
    (4)评审测试需求
    在这里插入图片描述
    4,分析结果和评审
    评审内容: 评审的内容包括完整性检查和准确性检查。
    评审的方法: 相互评审、交叉评审;轮查;走查;小组评审;评审人员
    正式评审小组中,一般存在多种角色,包括协调人、作者、评审员等。
    评审员需要精心挑选,保证不同类型的人员都要参与进行来,通常包括开发经理、项目经理、测试经理、系统分析人员、相关开发人员和测试人员等。
    2.3 软件测试需求管理内容
    1,变更管理
    从关注几个方面的问题来分析软件测试需求管理的内容:
    (1)定义测试需求
    (2)测试需求确认
    (3)建立测试需求状态
    (4)测试需求评审
    (5)测试需求责任制
    (6)测试需求跟踪
    1)软件测试需求的变更的原因:
    a)客户的需求变更
    b)市场需求变更
    c)技术或非技术的其他原因
    2)软件测试需求变更管理:
    a)测试需求变更管理的必要性
    b)测试需求变更管理的意义
    c)软件测试需求变更的主要任务:
    分析变更的必要性和合理性,确定是否实施变更;记录变更信息,提交变更申请;做出更改;修改相应的软件测试工作,如更新测试用例等;评审后,正式发布新版本的软件测试需求说明书。
    d)建立测试需求管理模型
    2,状态管理
    在测试工作进展的过程中,可能存在若干种状态:
    (1)只知道大致需求,具体细节还有待细化;
    (2)已经初步确定,等待评审;
    (3)已经确定的,并经过团队评审,在可预期未来不会发生变更;
    (4)已经评审完毕正在进行设计、实现测试用例的测试需求;
    (5)完成设计、实现测试用例的测试需求。
    1)软件测试需求的状态
    Open:对于原始需求或接收到的正式需求,但未正式进行需求分析之前的需求状态统一定义为:“Open”状态
    Analyzed:对需求状态为“Open”的需求,若已完成需求分析过程,但还未正式通过需求评审前,其状态统一定义为“Analyzed”状态
    Reviewed:对需求状态为“Analyzed”的需求,若已正式通过需求评审,但还未完成测试,或测试结果为不合格之前,其状态统一定义为“Reviewed”状态
    Resolved:对需求状态为“Analyzed”或“Reviewed”的需求,若已完成需求设计和编码,且已通过单元测试,其状态统一定义为“Resolved”状态
    Passed:对需求状态为“Resolved”的需求,如果已通过正式测试,其状态统一定义为“Passed”状态
    Unresolved:对需求状态为“Resolved”的需求,如果未通过正式测试,其状态统一定义为“Unresolved”状态。
    Closed:对需求状态为“Resolved”的需求,若需求已正式上线商用,且得到客户和项目团队的共同认可后,其状态统一定义为“Closed”状态。
    Cancel:当原定义的某些需求被取消时(包括上线前取消和上线后取消),其需求状态统一定义为 “Cancel”状态。
    Failed:对需求状态为“Closed”的需求,若需求在上线商用后发现问题或存在缺陷,需要对其进行修正时,其需求状态统一定义为“Failed”状态
    测试需求状态转换
    在这里插入图片描述
    3,文档版本管理
    定义:软件测试需求文档的版本管理是软件测试需求管理的基础,籍此可以使得同一软件测试需求文档可以被测试团队中不同的人员编辑,并且记录下每次编辑的增量,必要的情况下还可以回滚到某个版本。
    HP Application Lifecycle Management文档版本管理的功能:
    • 权限管理
    • 每次文档升级后的版本管理和恢复
    • 团队协作时同时操作
    • 文档版本比较
    4,跟踪管理: 指跟踪一个软件测试需求使用期限的全过程。
    1)软件测试需求跟踪有两种方式,正向跟踪与逆向跟踪:
    正向跟踪:以软件测试需求为切入点,检查软件测试需求说明书中的每个需求是否都能在测试用例设计和实现中有相应的测试用例对应。
    逆向跟踪:测试用例设计和实现等测试交付物是否都能在软件测试需求说明书中找到测试需求与之对应。
    2)软件测试需求跟踪的作用
    • 为测试团队提供了软件测试需求跟踪能力。
    • 通过跟踪软件测试需求的后续测试用例信息可以帮助确保所有软件测试需求被实现,没有遗漏。
    • 在对软件测试需求进行增、删、改等变更时可以确保与之对应的测试用例也进行必要的更新,而不被不忽略。
    • 及时可靠的对软件测试需求进行跟踪,使得维护时能正确、完整地实施变更,从而提高生产效率
    2.4 惠普测试需求管理解决方案
    用于现代应用测试的软件解决方案有惠普应用生命周期管理 (ALM) 是一款应用测试软件,可为您提供统一的存储库、一致的用户体验,可定制的仪表板,支持从单一存储库管理整个应用生命周期,包括从需求开始到准备交付为止的整个过程。
    惠普应用程序生命周期管理流程图:
    在这里插入图片描述
    (1)指定版本
    (2)指定需求
    (3)计划测试
    (4)执行测试
    (5)追踪缺陷
    惠普应用程序生命周期管理系统模块有11个模块,如图左侧边栏所示。
    ![在这里插入图片描述](https://img-blog.csdnimg.cn/20190715173149379.png
    在这里插入图片描述
    3 测试团队管理
    3.1 重视测试团队的管理与建设
    1,重要性和必要性:测试团队面临的挑战
    测试人员被认为低人一等
    测试时间永远不够
    缺乏简单易用的测试辅助工具
    缺乏具体通用的测试技术
    很难清楚了解用户需求和期望
    缺乏可明确衡量测试质量达标的度量
    很难确定一个测试实例是否执行完毕
    很难找时间作自动化测试
    测试所需文档经常不全
    很多任务要同时考虑,很难保质保量做好每一件
    2,专业的测试团队管理系统与工具
    专业软件项目管理系统的功能:
    a)集成了产品功能管理、进度管理、测试计划、测试用例、测试结果、缺陷和测试报告等模块。
    b)从记录产品的功能开始到根据功能点设计测试用例、执行测试用例记录缺陷生成测试报告,所有流程都在专业项目管理系统中完成。
    c)测试工程师、开发工程师和项目经理通过系统进行有效沟通。
    3, 软件测试团队管理最佳实践
    最佳实践的十个建议:
    a)明确测试人员的职责
    b)培养人才阶梯
    c)形成学习和培训机制
    d)公平和透明的绩效考核标准
    e)设立“back up”体系
    f)确保测试人员有职业发展渠道
    g)经常和员工交流
    h)奖惩分明
    i)打造共赢的团队文化
    j)领导以身作则
    3.2 测试团队的组织管理
    1,常见测试团队的组织结构:
    在这里插入图片描述
    2,软件测试组织的专业分工
    测试团队常见的角色分工
    在这里插入图片描述
    3,测试团队与开发团队的比例
    影响测试团队与开发团队的比例的因素:

    1. 质量风险
    2. 测试意识
    3. 发布流程
    4. 测试效率
    5. 合理估计项目的开发测试比的方法
    6. 手工测试工程师和自动化测试工程师的比例
      3.3 测试团队的员工管理
      1,测试工程师的职责:测试工程师的职责要从不同维度划分
      在这里插入图片描述
      2,测试人员的综合技能要求
      1.问题的分析和解决能力
      2.面向客户的创新
      3.精湛的技术
      4.项目管理
      5.对质量的执着追求
      6.战略远见
      7.自信
      8.冲击力和影响力
      9.跨界合作
      10.人际关系意识
      11.思维和心理素质
      12.相关业务知识
      13.软件测试专业技能
      14.计算机体系结构
      15.编程技能
      3,测试人员的职业发展
      职业规划的几个基本点: 测试技术轨道;测试管理轨道
      建议职业规划的基本原则:择己所爱、择己所长、择世所需、择已所利
      4 软件测试文档管理
      4.1 测试文档的必要性和重要性
      1,测试文档的必要性:编制测试文档的必要性体现在以下几方面:
      a)提高项目测试过程的透明度
      b)文档化能规范测试,提高测试效率
      c)便于团队成员之间的交流与合作
      d)对于项目“传承”的重要性
      e)是测试人员经验提升的最好途径
      f)有利于项目测试的监控作用

    2, 测试文档的重要性:
    测试文档是用来记录、描述、展示测试过程中一系列测试信息的处理过程,通过书面或图示的形式对项目测试活动过程或结果进行描述、定义及报告。
    4.2 测试文档规范
    1,国家标准《计算机软件文件编制规范 》
    GBT9386-2008中规定的测试文档的格式和内容:
    测试计划:描述测试活动范围、方法、资源和进度。它规定被测试的项、被测试的特征、应完成的测试任务、负责每项工作的人员以及与本计划有关的风险等。
    测试说明:包括三类文档:

    1. 测试设计说明
    2. 测试用例说明
    3. 测试规程说明
      测试报告 :包括四类文档:
    4. 测试项传递报告
    5. 测试日志
    6. 测试事件报告
    7. 测试总结报告
      2,国际IEEE 829标准:IEEE 829-1998也被称做829软件测试文档标准。作为一个IEEE的标准定义了一套文档用于8个已定义的软件测试阶段,每个阶段可能产生它自己单独的
      文件类型。
      测试计划
      测试设计规格
      测试用例规格
      测试过程规格
      测试记录
      测试附加报告
      测试摘要报告
      4.3 常用测试文档
      1,测试策略:在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境约束
      而规定的软件测试的原则、方式、方法的集合。
      制定软件测试策略的过程:
      1.明确制定软件测试策略的输入
      2.明确软件测试策略的输出
      3.制定具体的软件测试策略:
      (1)确定测试的需求
      (2)评估风险并确定测试优先级
      (3)确定测试策略
      2,测试计划:一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
      编写测试计划的步骤:
      1.确定测试计划的目标
      2.确定测试计划的内容:测试对象;测试内容;术语定义;团队之间的责任分配;确定测试范围;测试阶段;测试策略;资源要求;测试人员要求;测试进度;测试用例;缺陷报告;风险和问题
      3, 5W1H法制定测试计划:What, Where, When, Who, Why, How
      3,测试规范:为了一个特定的测试目的(例如,产品的验收等),对被测软件产品或功能进 行测试的有关文件。
      测试规范的内容:
      1.软件测试规范的定义
      2.软件测试规范描述的内容:
      • 测试计划规范
      • 测试用例设计规范
      • 测试工具使用规范
      • 缺陷跟踪系统录入规范
      • 缺陷严重等级和优先级划分规范
      • 缺陷分类规范
      • 缺陷状态修改规范
      • 缺陷递交流程规范
      • 测试报告规范
      • 测试退出规范
      • 软件测试类型规范
      • 开发语言测试规范
      • 软件测试流程规范
      • 界面测试规范
      4,测试用例:测试用例的格式
      软件测试用例的基本要素包括:
      测试用例编号
      测试标题
      重要级别
      测试输入
      操作步骤
      预期结果
      5,缺陷报告:为了便于管理测试发现的软件错误,通常要采用软件缺陷数据库,将每一个发现的错误输入到软件缺陷数据库中,软件缺陷数据库的每一条记录称为一个软件问题报告。
      缺陷报告文档的几个特殊性如下:
      • 只针对具体软件缺陷行为,也就是Bug具体信息。
      • 有统一的在线模板。
      • 缺陷报告的编写质量是衡量测试工程师技术水平的常用度量。
      • 缺陷报告的信息直接关乎软件产品具体功能和设计行为。
      • 缺陷报告是开发人员、测试人员、项目经理每天工作的主要共同的对象。
      • 缺陷报告的数量是所有软件测试项目衡量软件质量重要指标之一。
      6,测试结果报告:把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。
      书写软件测试报告的一般方法:
      1.确定报告的读者
      2.书写测试报告的准则
      • 报告内容应是真实的可靠的
      • 使用准确、简洁的文风,保持测试报告有良好的格式
      • 行文保持客观、对事不对人、关注问题本身

    4.4 测试文档管理
    1,测试计划的评审:测试计划评审的内容:可行性,正确性,全面性
    测试计划评审的参与者:项目经理、软件开发团队、产品部门、市场测试文档管理工具部门等软件测试干系人。必要的时候甚至需要邀请法务等部门参加测试计划的评审。
    2,测试用例评审:可分为测试组内部评审和项目组评审
    评审主要侧重于:1 测试用例本身的描述是否清晰,是否存在二义性;
    2. 是否考虑到测试用例的执行效率,往往测试用例中步骤不断重复执行,验证点却不同,而且测试设计的冗余性,都造成了效率的低下;
    3 是否针对需求跟踪矩阵,覆盖了所有的软件需求;
    4. 是否完全遵守软件需求的规定。因为即使再严格的评审,也会出现错误,应视具体情况而定。
    评审的角度不同,评审的侧重点也不同:
    1. 收集客户需求的人员注重测试用例是否符合业务逻辑;
    2. 分析软件需求规格的人注重测试用例是否跟软件需求规格要求一致;
    3. 开发负责人会注重你的用例中对程序的要求是否合理。
    3,测试文档管理工具:惠普 Application Lifecycle Management(ALM)是一款集成了测试文档管理功能的专业软件研发管理系统
    使用HP ALM 进行测试管理包括四个步骤:
    (1)明确条件:分析你的应用程序并且确定下你的测试条件。
    (2)测试计划:根据你的测试条件创建你的测试计划。
    (3)执行测试:在你的测试运行平台上创建Test sets。
    (4)跟踪缺陷:报告在你的应用程序中的缺陷并且记录下整个缺陷的修复过程。

    4.5 测试用例管理
    1, 编写测试用例的挑战与应对: 传统的独立(电子表格)文件形式的局限性和挑战
    1.测试用例的存储安全。
    2.测试用例难于分类与查询。
    3.与测试需求的对应关系难以维护。
    4.团队合作问题。
    5.测试用例的版本信息难于完整管理。
    6.难以实现测试用例的执行与结果管理。
    7.测试用例与缺陷的对应关系难以维护。
    2, 最佳测试用例特点:
    最佳测试用例的设计原则包括:
    (1)依据原则
    (2)全覆盖原则
    (3)规范原则
    (4)全面原则
    最佳测试用例的特点有以下几方面:
    (1)完整性
    (2)准确性
    (3)简洁性
    (4)清晰性
    (5)可维护性
    (6)适当性
    (7)可复用性
    (8)其它
    3,测试用例生命周期:
    在这里插入图片描述
    4,测试用例管理工具:通常使用基于数据库的软件研发管理系统
    测试用例管理工具一般应包括如下功能:
    • 测试用例ID管理
    • 测试用例的维护
    • 测试用例分类管理
    • 用例的导入导出
    • 用例搜索功能
    • 提供测试需求、测试结果和缺陷的对应关系
    4.6 测试文档最佳实践
    在测试文档管理中应该要注意以下几个方面:

    1. 建立测试文档管理制度
    2. 加强文档版本管理
    3. 创建测试文档库的访问规则
    4. 使用工具管理文档
    5. 写缺陷报告的建议
      • 多读优秀缺陷报告,学习最佳实践。
      • 每个缺陷报告尽量截取图片和log,帮助开发人员快速定位问题。
      • 对重现步骤自己要多执行几遍,确保开发人员可以再现缺陷。
      • 缺陷报告要客观得体,不要包含自己的主观情绪。
      5 软件质量模型
      5.1 软件质量概念
      1,软件质量的重要性: 导致项目进度延误、预算超支或项目失败、项目终止。
      软件质量高降低项目开发成本,包括维护成本、修复成本等
      2,软件质量的定义:
      ·ISO/IEC9126: 反映软件产品满足规定需求和潜在需求能力的特征和特性的总和
      ·MJ.Fisher: 所有描述计算机优秀程度的特性的组合
      ·ANSI/IEEE Std 1061-1992: 与软件产品满足需求所规定的和隐含的能力有关的特征或特性的全体
      3,软件质量的特性: •用户–如何使用软件、软件性能和使用软件的效果
      •开发者–中间产品的质量以及最终产品
      •管理者–总的质量,而不是某一特性
      5,ISO/IEC9126规定,软件质量可用6个特性来评价:
      • 功能性:软件所实现的功能达到它的设计规范和满足用户需求的程度
      • 可靠性:在满足一定条件的应用环境中,软件能够正常维持其工作的能力
      • 可用性:对于一个软件,用户在学习、操作和理解过程中所做努力的程度
      • 效率:在规定条件下,用软件实现某种功能所需的计算机资源(包括时间)的有效程度
      • 维护性:当环境改变或软件运行发生故障时,为使其恢复正常运行所做努力的程度
      • 可移植性:为使一个软件从现有运行平台向另一个运行平台过度所做努力的 程度

    GB/T 16260-2006质量模型 :
    在这里插入图片描述
    5.2 软件质量分层模型
    在这里插入图片描述
    1,McCall模型(FCM):软件质量要素(factor),衡量标准(criteria)和量度标准(metrics)。在FCM三层模型中,软件质量概念是基于11个特性之上,这11个特性分别面向产品操作(product operation)、产品修正(product revision)和产品转移(product transition)
    在这里插入图片描述
    2,Boehm模型:
    • 软件质量模型第一层: 功能性、可靠性、可用性、效率、可维护性和可移植性
    • 第二层给出了23个质量特性: 可访问性、可说明性、准确性、可扩充性、通信
    性、完备性、简洁性、一致性、设备独立性、效率、人类工程、可读性、可维
    护性、可修改性、可移植性、可靠性、健壮性、自包含性、自描述性、结构性、
    可测试性、可理解性和可用性
    • 第三层是软件质量度量,通过对软件开发各个阶段进行问卷调查,实现对软件
    开发过程的质量控制
    3,ISO/IEC 9126质量模型:该模型将软件质量定义为六大特性:功能性、可靠性、可用性、效率、可维护性和可移植性,每个特性又分为一系列子特性。
    4,GB/T 16260-2006质量模型:该模型在上述模型的基础上对软件质量从6个质量特性和27个质量子特性进行概念性描述。
    5.3 软件质量度量与评价
    软件质量定量评价公式:
    通过国内外多年研究,在软件质量的定量评价方面取得了一定成果。国外著名软件质量度量和评价产品中都给出了相关的计算公式,如Panorama++,Logiscope,McCabe IQ等
    •可维护性:0.5可测试性+0.5可理解性
    •可测试性:0.5结构性+0.5McCabe复杂度
    •可理解性:0.25结构性+0.25McCabe复杂度+0.25简洁性+0.25自描述性
    •结构性:0.2编码语句的最大嵌套层次+0.2修改全局数据+0.2使用Goto语句+0.2数据习惯用法+0.2无条件循环语句所占比例
    • 简洁性:0.4
    实体的习惯用法+0.4局部调用+0.2被调用
    • 自描述性:0.2B_comment + 0.3全部注释行所占的比例 + 0.5注释实体所占比例
    • 可移植性:0.5 * 独立性 + 0.5 * 完整性
    • 独立性:0.5 * 异常比例 +0.5 * 用户定义类型
    • 完整性:(if语句 + case语句 + 初始化对象)/ 3
    • 可靠性:0.33
    完整性+0.33模块性+0.34可测试性
    • 模块性:0.5 * 编码行数 + 0.5 * 结构性
    6 软件测试流程管理
    6.1 软件测试流程管理基础
    1,测试流程管理的意义:
    a)角色分工的统一和集中分配便于管理和绩效考核
    b)沟通所需的软件开发和测试流程环节和结果、步骤帮助团队成员明确各自的工作任务
    c)明确测试流程便于领导层及时发现隐患,并采取行动
    d)便于新员工快速学习应做的工作,并融入团队工作
    6.2 软件测试的一般流程
    1,开发模式与软件测试流程
    ISTQB定义的软件测试过程:
    a)测试计划和控制;
    b)测试分析和设计;
    c)测试实现和执行;
    d)评估出口准则和报告;
    e)测试活动结束
    典型的软件测试流程:
    需求分析
    需求评审
    开发人员编写排期
    测试计划排期
    编写测试用例
    用例评审
    提交基线
    测试执行与结束
    2, 计划与设计阶段: 测试设计与测试计划>>测试项目确认
    在这里插入图片描述
    3, 实施测试阶段:
    实施测试阶段的环节:
    1.执行测试用例
    2.记录原始测试数据
    3.记录和报告缺陷
    4.对所发现的缺陷进行跟踪、管理和监控
    具体测试流程:
    1.系统测试
    2.性能测试
    3.自动化测试实施流程
    4.测试的执行
    5.缺陷管理流程
    6.3 敏捷测试流程
    1,敏捷测试流程的特点:全程参与;轻量级文档;轻量级测试用例
    敏捷开发模型适用的场景:需求可能快速变化,开发周期短,发布频率快
    敏捷测试的核心:迭代
    在这里插入图片描述
    流程分析:
    在这个流程中弱化了文档,强调了各个人员的沟通,通过这种迭代的方式,三个月的项目,可以能两个月或两个半月就会完成。

    敏捷测试的流程:第一块面板中是开发人员未实现的功能,第二块面板中是开发完成的功能,测试人员对其进行测试,发现不通过的就放回未开发的面板中,测试通过的将放到
    第三块面板中。

    2,敏捷测试中的新功能测试和回归测试
    针对新开功能的测试的策略:
    1.以用户用例(User Case)或者用户故事(User Story)替代测试用例。
    2.持续进行验证,一旦一个具有完整功能的代码模块完成,立刻开始测试工作,而不是等待整个功能完全完成才着手测试。
    3.更多实施端到端(End-to-End)的测试,重视从最终用户角度出发保证业务流程的正确性和健壮性。
    回归测试的策略:
    1)实现更多的自动测试来保证回归测试的效率
    2)对回归测试做适当的裁剪
    •通过代码变更区域的分析,只针对受影响的范围进行测试。
    •根据用户关注程度和基于风险分析,对功能点进行优先级排序,必要的时候只测试高优先级的功能点,而忽视较低优先级的功能点。
    3,敏捷(开发)测试活动:主要由三部分构成,从最初的用户故事设计和发布计划,到几次 Sprint周期的迭代开发和测试,以及最后的产品发布阶段。每个时间段都有相应的测试活动。
    在这里插入图片描述
    4,Sprint 周期中的主要测试活动:
    ·估算验收测试时间;
    ·测试框架的搭建;
    ·详细设计验收测试用例
    5,敏捷测试中的测试工程师:
    1)测试人员需要具备的素质
    • 具有质量检测和编写代码的能力
    • 具有防止缺陷和质量控制的能力
    • 具有开发和执行测试程序的能力
    • 总结而言,有三方面的基本素质要求:代码编写、测试和分析 。
    2)测试人员的主要职责
    • 定义质量
    • 交流缺陷
    • 及时反馈
    6.4 惠普测试流程管理工具
    使用惠普 ALM 进行测试流程管理的最佳实践:
    使用专业的软件项目管理软件:
    a)需求分析
    b)测试计划
    c)测试设计
    d)测试执行
    e)缺陷管理
    f)测试总结
    g)持续改进
    7 软件测试执行管理
    7.1 软件测试执行基础
    1,软件测试执行的内容:主要包括4项任务:
    • 执行测试计划预定的测试,包括执行所有已设计的测试用例
    • 记录原始测试数据
    • 记录缺陷
    • 对所发现的缺陷进行跟踪、管理和监控
    软件测试的执行包括:手动测试,自动测试

    软件测试执行的内容就是要决定怎样执行测试和测试什么决定测试执行的内容需要明确以下信息 :
    

    a)测试执行依据的文档
    b)制定测试执行计划
    c)记录测试执行的结果
    d)执行测试的过程
    e)测试执行活动结束或终止
    f)核实测试结果并报告缺陷
    g)测试执行的准备
    h)测试执行过程
    2,影响测试执行的因素:
    实际软件测试过程中,测试资源、测试质量、测试时间之间相互制约
    软件测试执行影响因素:
    • 测试计划
    • 测试环境准备
    • 测试实现
    测试执行进度计划的影响因素:
    • 过程成熟度
    • 测试的时间
    • 测试的规模
    • 测试的资源
    • 产品的质量
    • 测试的文档
    3,测试执行管理要考虑和关注的环节
    1)戴明环指导测试执行
    2)测试执行的起始
    • 记录测试执行结果
    • 测试执行的流程
    • 测试执行入口准则
    • 测试执行关键信息
    3)测试执行的结束
    • 确保所有的测试工作全部完成
    • 移交测试工作产品
    • 总结经验教训
    • 在配置管理系统中归档所有的结果、记录、报表和其他文档及交付物
    4,软件测试执行的控制
    1)测试执行控制阶段的主要测试活动:
    按预定的计划执行测试
    确定测试执行范围和风险
    确定测试执行目的
    确定测试执行方法
    确定测试执行资源
    计划测试执行的进度
    确定测试执行入口准则和出口准则
    监控和记录测试执行过程
    度量和分析测试结果
    修正测试执行计划
    做出决定
    2)常用的度量指标
    a)在测试分析和设计中发现的缺陷数
    b)测试用例设计完成率
    c)测试环境准备的进度
    d)测试用例执行情况(如:测试用例执行率、测试用例通过率)
    e)缺陷信息(如:缺陷密度、发现和修改的缺陷比例、再测试的通过率)
    f)需求、风险或代码的测试覆盖率
    g)测试的成本
    3)对测试实现和执行阶段进行监控的度量方法:
    1.测试环境配置的百分比。
    2.测试数据装载的百分比。
    3.测试条件和测试用例执行的百分比。
    4.测试用例自动化的百分比。
    4)评估出口准则和报告阶段涉及的度量:
    1.测试需求的覆盖率。
    2.测试用例的覆盖率。
    3.测试用例执行通过/失败的数目。
    4.提交的缺陷数目,根据缺陷的严重程度和优先级进行的分类。
    5.提交的缺陷数目,接受的缺陷和被拒绝的缺陷的比例。
    6.计划成本支出和实际成本支出的偏差。
    7.计划花费时间和实际花费时间的偏差。
    8.测试中识别的风险和处理的风险数目。
    9.由于事件制约因素浪费的时间。
    7.2 软件测试执行结果的评估
    1,测试通过与失败:测试执行对每一项要测试的内容都必须有个结论。
    即测试是否通过。答案为“是(Yes)”或者“否(No)”
    通过:测试实际输出结果和测试期望结果一致
    未通过:测试实际输出结果和测试期望结果不一致
    • 测试结果的不一致或者失败并不一定是由于测试对象的缺陷引起的,也许是因为测试环境出错、测试人员执行测试时人为误差等。
    • 如果是由于测试对象引起的不一致,那么测试人员需要提交相应的缺测试
    结果的比较:手动比较;自动比较
    2,测试覆盖率与通过率:测试执行人员应该正确理解四个度量指标
    测试覆盖率:是用来度量测试完整性的一个指标
    测试执行率:指实际执行过程中确定已经执行的测试用例比率
    测试通过率:用来度量测试执行结果的一个指标
    缺陷解决率:指某个阶段已关闭缺陷占缺陷总数的比率
    3,测试通过标准
    出口准则(Exit Criteria):
    •可用于报告和计划什么时候可以停止测试
    •与利益相关者达成一致的通用和专门的条件,用于正式定义一个过程的结束点
    •出口准则的目的可以防止将没有完成的任务错误地看成任务已经完成评估测试

    出口准则和报告阶段的主要测试活动有:
    •将测试状态和测试计划中的出口准则进行比较。
    •评估是否需要更多的测试执行,或者是否需要更改测试出口准则。
    •输出测试总结报告。
    评估测试出口准则和报告阶段的主要输入:
    1)测试状态报告、缺陷状态报告、风险状态报告、项目测试周报告/月报告、测试出口准则和测试计划。
    2)回归测试所运行的用例全部通过。
    3)缺陷经过验证。
    4)所有缺陷都被指明处理方式。
    5)同行审查没有新的缺陷或没有严重缺陷产生。
    对测试组所测试项目或产品的测试审查工作的基本原则:
    1)不依据所设计测试用例,进行自由测试。
    2)测试时间保持在3个正常工作日以内。
    3)如发现严重缺陷,则一轮测试结束后,更新版本并执行回归测试。
    4)提交当日测试纪录。
    5)编写同行审查总结报告(报告以简单为好)。
    一种定义缺陷分类的方法:
    A类—— 严重错误
    (1) 由于程序所引起的死机,非法退出
    (2) 死循环
    (3) 导致数据库发生死锁
    (4) 数据通讯错误
    (5) 严重的数值计算错误
    B类—— 较严重错误
    (1)功能不符
    (2)数据流错误
    (3)程序接口错误
    (4)轻微的数值计算错误
    C类—— 一般性错误
    (1)界面错误(详细文档)
    (2)打印内容、格式错误
    (3)简单的输入限制未放在前台进行控制
    (4)删除操作未给出提示
    D类——较小错误
    (1) 辅助说明描述不清楚
    (2) 显示格式不规范
    (3) 长时间操作未给用户进度提示
    (4) 提示窗口文字未采用行业术语
    (5) 可输入区域和只读区域没有明显的区分标志
    (6) 系统处理未优化
    E类——测试建议(非缺陷)
    4,测试执行结果报告:
    定义:测试执行总结报告是将数据收集和分析结果进行文档化,并且提交给相应的团队作为以后项目的参考文档。测试执行总结报告是进行软件测试过程评估和改进的重要输入,也是进行相关开发过程改进和测试度量数据库更新的主要输入。
    测试执行结果报告包含:
    ·一个测试执行的结果报告模板;
    ·缺陷状态报表;
    ·验收测试结果报告
    测试执行总结报告主要构成部分:
    • 概要信息
    • 测试风险
    • 测试工作量
    • 测试执行
    7.3 软件测试执行的最佳实践
    1,测试执行注意事项
    a)全方位的观察测试用例执行结果
    b)加强测试过程记录
    c)及时确认发现的问题
    d)与开发人员良好的沟通
    e)及时更新测试用例

    2,提高测试执行水平的十个注意点
    a)工作效率
    b)耐心
    c)责任心
    d)排查问题的能力
    e)回归测试的覆盖度
    f)敏捷测试模式的效率
    g)注意细节
    h)提高自动化测试覆盖度
    i)不断自我提高
    j)提高业务熟练度
    8 发布工作
    1,定义:惠普应用程序生命周期管理(ALM)通过定义发布和循环来组织和跟踪即将进行的发布。测试流程始于在Management模块中定义Releases。该模块用于根据项目需求、测试和缺陷,累排列业务的优先级别和质量期望。
    2,发布树例子:
    1.)Cycle 1-New Features Testing:测试此次发布的程序中实现的新特点。新特点测试之后,开发团队修正测试中记录的缺陷。但是,根据缺陷的危急程度和严重性,一些缺陷可能会等到下一个周期才修正。
    2) Cycle 2- Integrated System Testing:这个周期中测试新功能可能对原有功能产生的影响。
    3) Cycle 3-Perfomance Testing:根据一些标准来测试应用程序的性能,例如程序支持的并发用户数量和程序响应时间。
    4)Cycle 4-User Acceptance Testing: 这一周期确保新产品的点满足业务期望。
    3,创建发布树工具
    通过创建发布树来定义发布的分层架构。根据组织架构的测试流程,可以为每个程序创建一个发布文件夹,或多个程序创建一个文件夹。
    4,新建发布/发布详细对话框
    在New Release对话框,你可以定义一个新的发布。在Release Details对话框可以查看和更新所选择的发布的详细内容。
    5,指定循环细节
    在DETAILS页面,执行下列任务:

    1. 从START DATE 列表中选择周期开始日期
    2. 从END DATE列表中选择周期结束日期
    3. 在DESCRIPTION字段,输入周期期望完成的目标的描述。
      6,重新计划发布/循环/里程碑: 该对话框可以用来重新安排发布、周期或者里程碑的开始和结束日期
      7,添加附件到循环: 向周期添加附件时可能会有环境要求。
      8,指定发布或循环的需求
      在REQUIREMENTS子模块定义需求后,在MANAGEMENT模块中创建周期,并向发布或周期分配需求。在Requirement模块,确定每个周期中需要覆盖哪些需求,并由此将这些需求分配到相关周期。使用需求决定程序中哪些内容需要测试。
      9,进度标签: 进度标签显示当前发布或周期进展状况的目测指标。可以看到已用时间和剩下时间,已经完成和剩下的测试实例,实际的和需要的执行比率等信息。
      10,质量标签: 标签以图表的形式显示了全过程中提交的发布或周期缺陷
      9 需求管理
      使用ALM的应用程序生命周期管理路线图包括以下阶段:
      在这里插入图片描述
      1 定义循环需求的优点
      需求详细描述需要解决或实现的内容,以达成正在开发的应用程序的目标。在项目前端清晰正确地定义需求提供以下优点:
      a)向利益相关者提供定义优先级的指导方针
      b)在利益相关者之间设定清晰的预期
      c)减少浪费并消除不必要的支出
      2 在ALM中如何使用需求
    1. 如何在 ALM 中创建和管理需求。包括以下步骤:
      1.先决条件: 通过收集功能和技术规范、市场和业务需求文档以及利益相关者目标等信息,确定需求的范围。
      2.创建需求: 通过创建需求树,定义需求范围的层次结构框架。
      3.导入业务流程模型:如果使用业务流程模型,可以通过导入使用标准建模工具创建的模型,创建需求的框架 。
      4.跟踪需求:可以在需求之间添加可跟踪性。
      5.计算风险:可以根据需求的性质和你掌握的资源,使用基于风险的质量管理计算在哪个级别,测试每项需求。
      6.创建覆盖率: 在需求和测试之间创建覆盖率,以确保在项目中实现所有需求。
      7.链接到缺陷: 可以将需求链接到特定缺陷。
      8.分配至版本: 将需求分配到在“版本”模块的版本树中定义的版本或周期。
      9.分析需求: 复审需求以确保它们满足定义的需求范围。
      10.建立基线: 创建基线以批准或比较应用程序生命周期中的重要里程碑。
      3 介绍需求
    2. 对于每一个需求主题,测试工程师均应该创建相应的详细测试需求列表。
    3. 在需求树中的每一个需求均要求被详细描述,并且应该包括所有与需求相关的附件。测试工程师分配每个需求一个优先级,此优先级会作为测试组创建测试计划的一个考虑因素。
    4. ALM在需求树中有机的组织并显示数据。需求树中每一行都显示了一条独立的需求。需求树中可以显示如表所示细节信息。
      在这里插入图片描述
      在这里插入图片描述
      4 创建需求树
      需求工具栏包括如下的按钮
      在这里插入图片描述
      5 创建需求
      1)创建需求包括以下步骤

    a) 创建需求:
    •打开“需求”模块。在 ALM 侧栏的需求下,选择需求。在查看菜单中,选择需求树。
    •创建文件夹。右击需求根文件夹,然后选择新建文件夹。要创建子文件夹,请右击文件夹并选择新 建文件夹。
    •添加需求。右击需求文件夹,选择新建需求。要创建子需求,请右击需求并选择新建需求。

    b) 导入需求
    •除了直接在ALM 中创建需求以外,还可以从 Microsoft Word 、Microsoft Excel 或其他第三方需求管理工具将需求导入 ALM 项目。要导入需求,必须先安装相应的插件。

    c) 更新需求
    •对于每个需求,可以更新其详细信息、附件和多信息文本文档。右击需求,选择需求详细信息。将打开“需求详细信息”对话框。

    d) 将需求转换到测试 ·为帮助在“测试计划”模块中建立测试计划树,可将需求用作定义测试的基础。

    2)如何创建需求——用例场景
    用例场景提供在“需求”模块中指定需求的示例。
    3)需求详细信息
    4)需求模块菜单和按钮
    5)描述和注释选项卡
    6)查看需求历史
    6 可跟踪矩阵概述
    1)可跟踪性矩阵允许你确定需求和需求之间以及需求和测试之间的关系的范围。它有助于你验证是否满足所有需求,如有更改还可标识更改的需求范围。

    2)可跟踪性矩阵列出源需求及其关联的需求和测试。对于每个源需求都会列出关系总数。低值可能表示源需求关联的需求或测试不够。高值可能表示源需求太复杂,可以进行简化。零值表示不存在关联关系。
    7 覆盖率分析
    此需求有十二个子项(包括自身)。在“覆盖率分析”中,可以看到两个子项的状态为失败(一个或多个由此需求覆盖的测试失败)。进行分析时,可以看到与此需求关联的三个 (27%) 测试失败。

    10 测试计划
    此项内容过多,后续补充~

    展开全文
  • 【软件测试】测试管理工具----禅道

    千次阅读 2018-08-16 20:38:36
    测试管理工具: 指在软件开发过程中,对测试需求,计划,用例和实施过程进行管理,对软件缺陷进行跟踪处理的工具。 通过使用测试管理工具,测试人员或开发人员可以更方便地记录和监控每个测试活动,阶段的活动,...

    测试管理工具:
    指在软件开发过程中,对测试需求,计划,用例和实施过程进行管理,对软件缺陷进行跟踪处理的工具。
    通过使用测试管理工具,测试人员或开发人员可以更方便地记录和监控每个测试活动,阶段的活动,从而找出软件的缺陷和错误,记录测试活动中发现的缺陷和改进建议。
    禅道:
    国产开源+商业式产品
    禅道是国产的开源项目管理软件,专注研发项目管理,内置需求管理,任务管理,bug管理,缺陷管理,用例管理,计划发布等功能,实现了软件的完整生命周期。
    主界面:
    这里写代码片
    禅道下载地址:http://www.zentao.net/
    禅道使用总体框架图:
    这里写图片描述
    接下来看使用的详细步骤:
    一,建立部门结构:
    1)维护公司信息
    2)维护部门结构
    3)维护子部门
    二,添加账号
    1)进入组织视图
    2)选择用户列表
    3)然后选择添加用户或批量添加
    这里写图片描述
    4)用户添加完成后,即可将其关联到某一个分组中
    这里写图片描述
    三,创建第一个产品
    1)进入产品视图
    2)选择右侧添加产品
    下图为一个已经创建好的产品
    这里写图片描述
    四,创建第一个项目
    进入项目视图,点新增项目。
    在这个页面设置项目名称,代号,起止时间,可用工作日,团队名称,项目目标和项目描述等字段。
    这里写图片描述
    五,维护用例视图模块
    1)进入测试视图,选择用例。
    2)在页面左侧,会出现该产品的用例模块列表
    3)模块列表下部,有维护模块的连接,点击链接即可维护模块。
    这里写图片描述
    六,维护bug视图模块
    1)进入测试视图选择bug
    2)页面左侧会出现产品的bug模块列表
    3)同样在模块表的下部,有模块维护的连接,点击此链接可维护模块
    这里写图片描述
    七,创建测试用例
    进入测试视图,选择用例,选择创建测试用例
    这里写图片描述
    八,测试套件,报告和公共用例库的维护
    测试套件是把服务于同一个测试目的或同一运行环境下的一系列测试用例有机的组合起来。
    公共用例库可以把不同的测试模块或者是测试功能点所引用到的测试用例做分类管理,有效提高测试用例复用性。用例库下创建用例,只属于该用例库所有。
    九,管理测试版本
    1)测试版本关联测试用例
    这里写图片描述
    2)指派或领取用例
    3)更改测试版本的状态
    十,执行用例
    1)在测试–>测试单(版本)的用例列表页面,用户可以按照模块来进行点选,或者选择所有指派给自己的用例,来查到需要自己执行的用例列表。
    在用例列表页面,选择某一个用例,然后选择右侧的执行菜单,即可执行该用例。
    2)失败用例转bug
    如果一个用例执行失败,那么可以直接由这个测试用例创建一个bug,且其重现步骤会自动拼装。
    点击测试–用例列表页右侧的转bug图标操作,点击转bug按钮进行操作。
    这里写图片描述
    3) 测试版本生成测试报告
    十一,提交bug
    1)进入测试视图的‘Bug’
    2)点击页面右侧的‘提Bug’,即可进入Bug创建页面
    十二,验证bug,关闭
    当开发人员解决bug之后,就需要来验证bug,如果没有问题,则将其关闭。
    十三,激活bug
    如果开发人员解决bug之后,验证无法通过,可以将bug重新激活,交由后的解决者去重新解决。
    或者一段时间后bug重现,也需要激活。
    十四,查看报表统计
    在bug列表页面,点击页面上部的统计报表,即可出现统计报表页面。

    展开全文
  • 软件测试管理——测试的风险分析

    千次阅读 2016-07-14 13:43:54
    作为一名测试管理人员必须在平时的工作中,分析这些风险的类别,并且想出对策尽最大程度的降低这些风险。1.软件需求的风险主要表现在以下的几个方面:■需求变更风险,在项目的后期用户总是不停的提出需求变更从而...
  • 测试管理中可能存在的问题及分析

    千次阅读 2019-01-02 12:30:00
    摘要:本文结合实践,主要探讨了在中小型软件企业中,在测试资源不是很充足的情 况下的软件测试管理。文中前两部分简要介绍了软件测试管理及测试的范围,方法及重要性,之后对当前国内中小型软件企业在测试及测试...
  • 自动化测试管理平台思路

    千次阅读 2016-08-14 14:29:52
    类似开发,自动化测试脚本也是需要管理的,当实施自动化测试的伙伴不止是一个人的时候,为了能更好的管理脚本,就需要一个自动化测试管理平台。所以,结合需要,我自己做了个轻量级web版自动化测试管理平台,在此给...
  • 测试管理工具——QualityCenter

    千次阅读 2019-04-09 11:37:48
    (3)测试管理工具 QualityCenter(质量中心)——对整个测试流程进行全面管理,包括:版本管理、需求管理、用例的管理、执行用例、缺陷跟踪管理、数据分析统计管理等。 (4)白盒测试工具 Junit、Jtest 2....
  • 使用 TestLink 进行测试管理

    千次阅读 2017-03-17 16:12:32
    作为基于web的测试管理系统,TestLink的主要功能包括: 测试需求管理测试用例管理测试用例对测试需求的覆盖管理测试计划的制定测试用例的执行大量测试数据的度量和统计功能。 TestLink的最新版本是1.6.2。在本文...
  • 如何建立测试管理体系

    千次阅读 2015-10-11 10:54:58
    所谓“工欲善其事,必先利其器”,有了事半功倍的工具,自然能提高效率,软件测试管理系统就是建立软件测试管理体系、保障 软件测试顺利进行的利器。 测试管理体系既可以通过强大的测试管理工具来体现,也可以通过...
  • 软件测试管理

    千次阅读 2018-05-29 22:55:37
    项目组织分布 软件测试的方法选择 一、项目管理部门主要任务(1) 制定或修改软件开发计划和测试计划;(2)对整个软件项目的进度进行评估;(3)对一些重大问题进行决策,确保软件开发项目按计划保质量地完成;(4)决定...
  • 测试管理之--团队管理和建设

    千次阅读 2018-08-07 13:38:00
    怎么才能做好测试团队的管理和建设,下面来谈一下我的经验和教训。 我认为,做好以下三点就足够了: 1、放权; 2、沟通; 3、监督; 表面上看,不就是这三个词六个字吗?有什么大不了的,大家都可以做到。有...
  • 【腾讯TMQ】测试管理平台大比拼

    千次阅读 2016-09-06 14:58:30
    测试管理平台就是测试人员的“器“,找到一个合适的管理平台使测试人员事半功倍。本文介绍了目前流行的测试管理工具QC、 Mantis、 BugZilla、TestLink、Redmine等希望读者通过本文找到适合的工具。
  • 常用测试管理工具对比

    千次阅读 2017-10-27 12:54:32
    对于中小企业来说,选择一款适合的测试管理工具或者工具集合石走向规划管理的必经之路,本文从以下几个方面对目前流行的几款工具: 1、QC(QC是TC的升级版,QC的升级版QC 11就是ALM11) 2、禅道(bugfree升级版) ...
  • 国内比较好用的5款测试管理工具

    千次阅读 2018-10-18 13:47:14
    做好测试的前提是写好测试用例,写测试用例则需要一款好用的测试管理工具。国外有几款好用的测试管理工具,由于服务器部署在国外,国内访问会比较卡,还有就是语言不是中文的大家用起来也比较困难,这里就不推荐大家...
  • 软件外包测试管理与实践

    千次阅读 2008-02-22 17:35:00
    软件外包测试管理与实践 管理是指通过计划、组织、领导、控制等途径去完成某个任务、达成某个目的。以此类推,软件外包测试管理,就是指利用以上途径,去满足软件外包测试任务的需求。 本文围绕这一主题,主要从...
  • ISTQB 初级认证 课件PPT 第5章 测试管理
  • 自动化测试管理平台QTP based开发设计已完成(在原有平台上进一步开发与优化)...... 由多位测试专家组成,结合多年自动化测试实战经验,自动化测试平台对QTP进行深入的扩展与支持,可靠稳定: 主要功能: 1)项目...
  • 软件测试管理--目录

    千次阅读 2007-11-19 18:02:00
    前 言第一部分 基础篇第1章 测试管理概论1.1 三个基础测试概念1.2 软件测试基本流程1.3 软件测试管理攻略1.3.1 测试管理主要内容1.3.2 本书测试管理攻略第2章 软件测试背景2.1 测试案例2.2 软件测试发展...
  • 软件测试管理—如何写好软件测试计划书

    万次阅读 多人点赞 2018-06-16 20:59:19
    如何写好软件测试计划书 软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。 详细的测试计划可以帮助测试项目组之外的人...
  • 往期文章: 华为软件开发云测评报告一:项目管理 华为软件开发云测评报告二:代码检查 体验环境 体验方式:PC端 ...了解华为软件开发云的测试管理服务功能,分析其优缺点; 自动化测试工具
  • 是面向测试人员的一个模块,可以管理测试计划、测试套件以及测试用例,同时微软还为测试的执行提供了一个很牛逼的插件——Test Explorer,这东西可以直接安装在火狐或者谷歌浏览器上,然后直接截图,创建 bug,是你...
  • ISTQB AL-TM认证中文参考书:《软件测试管理》连载系列 ISTQB作为一个专业的提供软件测试认证的机构,得到了全球软件测试人员的认可。目前中国有越来越多的人已经获得ISTQB FL初级模块的认证。由于测试职业发展和...
  • XQual Studio (XStudio) 是目前业内功能最全的测试管理工具,特别提到的是它完全免费!它的功能可以与HP QualityCenter媲美,完全具有测试需求、测试用例管理、测试执行、缺陷跟踪、报表分析功能。目前业内的免费版...
  • 软件测试管理者会遇到那些问题?

    千次阅读 2018-01-16 20:38:31
    一、测试负责人要进行严格的测试进度跟踪吗? 很多时候,由于人力资源的不足,测试项目负责人都是在执行测试,这样就使整个项目缺乏...通常,测试负责人需要完成下面这些内容的管理工作:测试用例执行情况;每个测
  • 测试管理--测试的任务安排

    千次阅读 2017-09-24 22:15:25
    某leaderA有3个任务,①原有功能的优化 ②新活动项目 ③已开展项目测试,接下来这个leaderA做了下面这些工作 1、评估了这3个工作的工作量 (是leader一定要学会工作量的评估,就是要对需求对业务的高度理解,...
  • 软件测试管理经验谈 (转)

    千次阅读 2018-05-02 15:13:18
    某甲问道:「测试做太多的话,会不会使得bug解不完?」 某乙回答:「还不简单。只要不做测试,就没有bug。」 上述对话,反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言,测试大概是仅次于维护之外...
  • TestLink测试管理工具使用流程说明

    千次阅读 2009-06-12 13:52:00
    根据实际情况,基本上我们可以按照如下的流程来实施我们的测试管理方案:首先创建项目然后创建需求创建计划创建用例给需求指派用例(可能不止一个)给计划添加用例为用例指定执行者执行计划/报告bug查看分析结果 1....
  • 软件开发过程中的测试管理

    千次阅读 2015-06-25 15:27:42
    测试是开发中必不可少的工作  首先,一个软件产品或系统的...对测试管理和执行,其重要性不亚于对程序本身的开发。你可以花费巨大的资源和努力进行程序的开发,可是你要是没有与此配套的完善的测试,所开发出来的
  • 测试管理工具TestDirector安装部署及常见问题解决方法 【背景描述】相信很多IT公司,在软件开发、测试过程中,都遇到过这样的场景:提交测试人员的版本,在测试过程中,发现缺陷以后,需要汇总提交开发人员确认并...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,782,105
精华内容 712,842
关键字:

测试管理