精华内容
下载资源
问答
  • 软件测试管理工具——禅道

    千人学习 2020-02-28 01:06:48
    禅道的开源版即开源有免费,功能强大、操作简便,能满足一般企业的日常测试管理需求,且应用较为广泛,值得一学。 本课程通过不到一小时的介绍,希望让大家能够了解和掌握禅道,辅助完成日常测试管理工作。 欢迎...
  • 软件测试管理

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


    项目组织分布

     

    软件测试的方法选择

     

    一、项目管理部门主要任务

    (1) 制定或修改软件开发计划和测试计划;

    (2)对整个软件项目的进度进行评估;

    (3)对一些重大问题进行决策,确保软件开发项目按计划保质量地完成;

    (4)决定每周要完成的开发和测试任务;

    (5)协调和解决开发部门和测试部门之间产生的问题;

    (6)决定提前或推后发布软件。

    二、开发部门主要任务

    (1)按照开发计划及时间进度表,编写新的程序代码;

    (2)对测试部门发现的软件缺陷报告进行分析,确定修改的优先级;

    (3)对一批软件缺陷报告进行修复后,进行软件系统集成,产生新测试版本,在提交给测试部门之前进行最基本的检查;

    (4)按照开发计划,在每个测试版本的提交日期内,将新的软件测试版本提交给测试部门进行软件缺陷修复验证和新一轮测试。

    (5)返回第一步。

    三、测试部门主要任务

    (1)根据不同测试要求,设计测试用例;

    (2)按照测试计划和项目进度表,实施软件测试;

    (3)对发现的软件缺陷编写软件缺陷报告,并及时报告给软件开发部门;

    (4)对开发部门提供的软件缺陷修改后形成的新测试版本,进行软件缺陷验证;

    (5)对开发部力提供的新测试版本,开始新一轮的测试。

    (6)返回第一步。

    四、测试组织和开发组织的关系

    基本原则:

    在软件测试管理中,要特别强调避免一个组织测试自己编写的程序,原因是任何开发组织都很难客观地测试自己的程序;

    应该成立独立的软件测试组织进行软件测试:

    l 测试组织与开发组织之间的关系越远越好。

    五、测试配置内容

    测试人员:人数、经验和专长、全职、兼职。

    测试设备:计算机,打印机等。

    测试环境:硬件、软件环境

    测试工具:各类测试工具。

    测试地点:办公室成实验室,面积大小等。

    测试策略:是否需要专业测试公司,费用如何。

    其他需求:移动存储器、电话、通讯等。

    六、主测试环境要求 
    (1)符合被测软件运行的最低要求,保证支撑软件能正常运行。
    (2)选用比较普及的操作系统和软、硬件平台。

    (3)构造相对简单、独立的测试环境。除了操作系统,测试机上只安装被测软件运行和测试必需的支撑软件,以免不相关的软件影响测试。

    (4)保证测试环境中没有病毒,利用有效的正版杀毒软件检测软件环境。

    七、辅测试环境要求

    (1)兼容性测试:在满足软件运行要求的范围内,选择一些典型的操作系统和常用应用软件,对被测软件的安装、卸载和主要功能进行验证。

    (2)模拟真实环境测试:对有些软件,特别是面向大众的商品化软件,在测试时常常需要考察其在真实环境中的表现。

    (3)横向对比测试:利用辅测试环境“克隆”出完全一致的测试环境,从而保证各个被测软件平等对比。

    (4)国际化测试:利用不同的语言环境进行测试,保证在不同的国家和地区正常使用。

    八、测试计划的重要性

    测试跟踪:

      在整个项目开发期间,计划执行多少个测试用例?在系统最终版本上执行多少个测试用例?多少个通过,多少个失败?有无忽略的测试用例?等等。如果没有测试计划,就不能回答这些问题。

     测试验证:

      在少数高风险行业中,测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的系统实际上是不合法和危险的。正确的测试计划和测试跟踪提供了一种验证手段。

    九、测试说明

    描述被测产品基本情况:

    l 测试目的

    l 变更信息

    l 软件结构及技术要求

    l 软件产品规格说明

    l 测试范围

    l 项目信息

    十、测试计划的内容

    1)测试说明

    2)测试需求

    3)测试策略

    4)测试记录

    5)测试资源配置

    6)软件缺陷追踪

    7)测试计划时间表

    8)测试计划评审

     

    十一、软件结构及技术要求

      将被测软件划分成几个组成部分,规划成一个适用于测试的完整的系统,包括数据是如何存储的,如何传递的(数据流图),每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有-些常规性的技术要求,比如运行平台、需要什么样的数据库等等。

    十二、测试范围

    简单的描述如何搭建测试平台以及测试的潜在的风险等。

    十三、测试需求

      列出所有要测试的功能项(测试项或测试点)。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。

    功能的测试

    设计的测试

    整体考虑

    十四、设计的测试

    针对用户界面、菜单结构、窗体等的设计是否合理等的测试;

    测试内容包括美观性、可用性、易用性等方面;

    系统的外观很重要,要求有尽可能好的合理性。

    十五、整体考虑

      测试系统各模块之间的接口,即测试数据流从软件中的一个模块流到另一个模块过程中的正确性,这是保证软件系统正确的前提。

    十六、测试策略

      根据不同的测试区域选择不同的测试策略:

    黑盒、白盒测试

    -功能、性能测试

    自动、手动测试

    十七、测试记录

    公正性说明

    测试用例管理工具

    软件缺陷管理工具

    特殊考虑

    经验判断

    十八、公正性说明

    要对测试的公正性、依照的标准做一个说明,证明测试是客观的。在整体上,软件功能要满足需求、实现正确、和用户文档的描述保持一致。

    要保证测试的客观,就要保证测试人员能客观的完成测试任务。

    十九、测试用例管理工具

      描述测试用例模板,管理测试用例采用了什么工具,工具的来源是什么,如何执行的,用了什么样的数据。测试用例记录中要为将来的回归测试记录信息。

    二十、软件缺陷管理工具

      在测试的计划阶段,应该明确建立一个软件缺陷管理的方法和工具。工具的来源是什么,如何执行的,需要使用什么样的数据。

    二十一、特殊考虑

      针对一些外界环境的影响, 要对软件进行一些特殊方面的测试。

      例如,对于一些用于高尖端产品的信息系统,如水下机器人、太空探测器等,测试者应给予某些特殊的测试,使它们能在恶劣的环境下有着较高的可靠性和适应性。

    二十二、经验判断

      经验判断就是利用历史数据针对系统运行或测试中经常出现的问题仔细研究考虑,使之发生率尽量的小。

      例如对于数据库系统,数据的操作(存取,副除,修改等)是其基本功能,同时也是经常出现问题(如数据冗余、死锁等)的地方。

    二十三、测试资源配置

      制定一个资源配置计划,包含每一个阶段的任务、所需要的资源。当发生类似到了使用期限或者资源共享的事情的时候,要更新这个计划。

    二十四、软件缺陷追踪

    描述软件缺陷报告的内容:缺陷名称、发现时间、发现者、修复者、发生的频率、所使用的测试用例,以及测试环境等。

    描述如何界定一个软件缺陷的性质,对软件缺陷性质的描述尽可能是定量的。

    描述软件缺陷报告的处理过程。

    二十五、测试计划时间表

        测试的计划表可以做成多个项目通用的形式,根据大致的时间估计来制作,操作流程要以软件测试的常规测试周期作为参考,也可以是根据什么时候应该测试哪一个模块来制定。

    二十六、测试计划评审

    在测试真正实施开展之前必须要认真负责的对测试计划检查一遍,并获得整个测试部门人员的认同,包括部门的负责人的同意和签字。

     

     

     

     

     

     

     

     

     

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

    千次阅读 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-05-02 15:13:18
    」 上述对话,反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言,测试大概是仅次于维护之外,最令人讨厌的工作。对软件研发主管来说,测试是必要之恶:做得不够后患无穷,做得过多又增加成本,延误...
    某甲问道:「测试做太多的话,会不会使得bug解不完?」 
    

    某乙回答:「还不简单。只要不做测试,就没有bug。」 

    上述对话,反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言,测试大概是仅次于维护之外,最令人讨厌的工作。对软件研发主管来说,测试是必要之恶:做得不够后患无穷,做得过多又增加成本,延误商机。因此,如何能够规画与执行一个最经济有效的测试工作,当是软件研发主管们须研究的一个课题。 

    软件测试的困难,在于它不仅是产品的测试,更是产品设计程序的检验。由于关乎设计的测试,准则不易寻找,经验未必得以再用,他山之石也有应用的局限性,因此难度颇高。欲提高测试的效益,有赖全盘的规画,确实的执行,与事后的检讨改进动作。许多小型软件研发单位,对于软件测试并不重视,但从许多稍具规模的软件公司均配置常设测试人员,乃至于测试品保部门来看,测试工作显然有其学问与价值的。 

    测试工作没有最佳方法可依循,是因为不同的软件所需的测试手段不同。譬如小型软件与大型系统的做法不同;订制软件与软件包的要求不同;系统软件的测试往往无法采用应用软件所使用的技巧;游戏软件与库存系统有其各自需面对的测试标的。因此,测试人员必须因应软件的特性与资源的限制,加上过去相关的经验,规画最适合的测试方式。并随着经验的累积,不断改进作法,才能找出最佳的测试方法。 

    由此可知,要做好有效的测试,不只是埋头苦干而已,它需要良好的管理,使整件工作获致最佳的成果。关于测试的管理工作,可从组织、规画、执行与检讨几个角度来探讨。以下谨就笔者粗浅的经验野人献曝一番,希望提供读者基本的协助。 

    测试组织之设计 

    由于人性总自认为自己的最好最正确,完全由软件开发人员兼任测试人员,并不值得推荐。实务上往往因软件开发单位的经济规模不够,使得开发人员经常兼任测试人员。但若可行,研发单位应尽可能配置专任的测试人员,尤其是独立于开发小组之外的测试负责人员。尽管是否应设置独立测试小组业界仍有争议,许多人甚至以为保障软件品质唯有从改进软件开发的程序做起,但大部份美国的软件公司均设有独立测试或品保人员乃至于部门,这说明了独立测试仍有其不可摇撼的地位。 

    许多的软件研发单位将测试视为次等的工作,从而配置次等人员负责相关工作。如此一来,优秀人员无从参与,也缺乏意愿参与测试工作。结果软件品质不易度量,研发的成果常常被不佳的品质抵销,实为令软件开发人员泄气之事。主管是否能体认到软件测试的重要性,通常是成功的关键。软件测试固然是支持性工作,仍应配置合理的资源,以获取整体之成效。在当前的环境下,给予测试人员较多的关注,毋宁是必要的作法。 

    测试工作规画 

    测试工作的规画,至少包含两项要点:测试目标的订定与测试资源的配置。攻击需要目标,测试亦然。测试的目的在于找出软件的问题,提供改进之参考。目标若不明,测试人员即不知如何着手。 

    测试目标的订定,最重要的在于软件通过的准则,亦即测试何时方可结束。常见的情形是:软件开发的进度不断落后,最后剩余的时间仅有两个星期,于是测试人员的目标就是把最后两周用完,尽人事听天命。究竟测试多完整,隐藏的多少错误,测试工作的生产力如何?皆一概不知。反正产品卖出去或上线后有的是时间改进。然而产品销售后再改进,成本往往大幅增高,甚至原有开发人员离职他调,连亡羊补牢都倍感困难。经验一再显示,事前的测试除错绝对比事后维护省时省钱,唯有卖不出去或不能用的软件例外。 

    对于测试的要求可简单区分为二:一种是通过目标所订之软件品质;一种是在既定资源内达到最佳成效。前者要求山头一定要攻下,不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字,若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布,无法更改者,其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求,其中最容易遵循的准则即为:重要功能永远先测。这两类测试的需求不同,足以影响到测试的计划、测试的顺序与关心的重点。读者不可不察。 

    至于测试资源配置适当性,则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源,譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足,测试流于形式,时程过短,找到错误也来不及除错,均不可取。除了测试在研发的比重,也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽,需加以注意。不同阶段测试的资源配置,也必须加以考量,如此可避免测试集中于功能测试,忽略系统测试。这些工作的适切安排,有助于协助测试工作时时都执行最重要,也最有效的测试。 

    测试执行与管理 

    测试工作执行在管理上,首先需使测试与开发人员了解轻重缓急。测试人员常常不考虑测试的效果,而只依照测试的方便性来进行测试。譬如软件有十大模块,每一模块有50个测试个案,于是他从第一个模块的第一个个案开始测,测完一整个模块,再进行第二个模块的测试,执行全部完成或无法进行为止。事实上,测试应从重要且常用的项目测起。 

    开发人员的除错,则往往从好改的改起。于是100个错误改了90个,系统主要的缺陷仍为克服。测试管理人员需特别注意此事,确保测试工作的效率。 

    进行测试管理的好处在于随时可掌握状况,并因应需求及时调整测试策略。譬如测试一段时间后,发现某子系统的问题特别多,即可调整人力,增强该部份的测试。或是某些人的测试绩效较差,则可调整工作之分配,以求整体效果。当然,这些数据的取得有赖相关信息的搜集,包括数量与时间之信息。如果可行,可记录不同测试工作耗用的人力时数,计算耗用成本,以便未来进行测试规划时拥有更精确的参考数据。 

    进行相关资料的统计与分析,最好运用工具来帮忙,以节省人力并增进效果。如果市面已有的测试管理工具符合需求,也可径行采用。测试结果的统计资料,不妨公布在大家的眼前,使得测试成果可为大家了解,亦能促进工作同仁求取更佳的成绩。附图所显示为一简单的统计图表,显示每周的测试成果、除错成果,与产品残存的问题量,可协助主管决定测试终止及发行产品的时间。 



    测试结果分析与改进 

    当(阶段)测试结束后,测试管理人员可以进行测试成果的分析。有关预定目标与实际执行结果的差异,可作为下一版软件测试检讨改进的依据。譬如预定开立的测试个案数是否达成目标,执行与通过数是否可接受?投入的测试甚至除错人力是否足够?均可视状况计算依标准工作量,作为未来执行测试工作之预估标准。经由分析软件错误的生命周期,可以研究缩短的方法,例如加速除错与重测周期,或在分析设计阶段减少错误发生的机率,以缩短测试时程。 

    由测试结果可分析出不同测试的效益,与应改进之处。以下表为例。单元测试耗用大部份的人力,可能使整合与系统测试不完全。再以发现的错误数观之,整合测试发现一个错误的成本远低于另两项。由此可见在有限的人力时间下测试,单元测试做得太多,整合测试又太少。此意谓着对于单元测试所需耗用的人力资源过度乐观,或是在测试工作的配置不尽理想,应予改进。 



      测试人力时数测试人力分布比率错误个数错误分布比率平均时数/错误数
    单元测试227.10458.6%4939.51%4.635
    整合测试87.21223.3% 5443.55% 1.615 
    系统测试70.18418.1%2116.94%3.342
    合计384.5100%124100%3.2


    除了以上的测试成效分析。如行有余力时应再对错误发生的原因加以分析,力求从问题的根源加以解决。这包含测试工作的改进与开发工作的流程改进。以前者而言,可考虑对测试人员施以较充分的训练,避免测试工作因准备不周浪费宝贵的人力与时间。测试标准程序的建立,也有助于测试工作效率的提升。至于后者,可由错误发生的原因研究预防之道。例如对需求变更未确实记载,导致设计错误的问题发生,或是软件的设计未加充分的考虑再撰写程序,导致设计不良造成的大量错误,均应加以预防,如此可望从根本解决软件的问题。 

    结语 

    欲提升软件品质与生产力,得先掌握现况。测试工作既是必要之恶,就需拟定最好的方法来面对。有关软件测试方法论的书籍文章为数固然不少,在应用上仍须因应自身的情形加以调整。品管大师戴明认为:获得好品质不能靠检验,而是来自改善工作流程。因此,测试工作只是一项起步。如何藉由测试工作,了解改善软件品质与生产力之道,才是我们追求的目标。愿祝各位软件品质的捍卫者,在工作岗位顺利前进,为测试工作赢得荣耀,更为你们的成功产品喝采。 

    展开全文
  • 软件测试管理—如何写好软件测试计划书

    万次阅读 多人点赞 2018-06-16 20:59:19
    如何写好软件测试计划书 软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。 详细的测试计划可以帮助测试项目组之外的人...

    如何写好软件测试计划书

    软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

    详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。

    什么样的测试计划书符合要求

    软件测试计划作为软件项目计划的子计划,在项目启动初期是必须规划的。在越来越多公司的软件开发中,软件质量日益受到重视,测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中,这样,如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为:“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

    案例:一份看似“不错的”软件测试计划书

    下面是某项的测试计划书

    一个软件测试计划书的目录

    提纲挈领,透过这份测试计划书的目录,如何对这份测试计划书进行评价?
    在回答这个问题之前,我们先看看测试过程中的一个重要的活动或者阶段——测试计划阶段都需要做什么?这个阶段的产出物是什么?

    测试计划阶段的任务

    测试计划可以在项目计划或主测试计划中文档化,也可以在不同的测试级别(如系统测试和验收测试)的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”(IEEE Std 829-1998)。

    测试计划受到很多因素的影响:组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进,将有更多的信息和具体细节包含在计划中。

    测试计划是个持续的活动,需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险,从而对计划作相应的调整。

    测试计划阶段需要做的事情

    对整个系统或部分系统可能的测试计划活动包括:

    • 确定测试的范围和风险,明确测试的目标;
    • 决定总体测试方法,包括测试级别、入口和出口准则的界定;
    • 把测试活动整合和协调到整个软件生命周期活动中去(采购、供应、开发和运维);
    • 决定测试什么?测试由什么角色来执行?如何进行测试?如何评估测试结果?
    • 为测试分析和设计活动安排时间进度;
    • 为测试实现、执行和评估安排时间进度;
    • 为已定义的不同测试活动分配资源;
    • 定义测试文档的数量、详细程度、结构和模板;
    • 为监控测试准备和执行、缺陷解决和风险问题选择度量项;

    明确了测试计划阶段需要完成工作,就很容易思考一份高质量的测试计划书中应该包括什么内容了。

    软件测试计划的文档化(产出物)——软件测试计划书

    下面是根据IEEE 829标准编写的一份测试计划的目录:

    这里写图片描述

    这份测试计划中:

    • 在第2部分明确了被测软件系统(产品)待测的特性和不测试的特性。
    • 在第3部分明确了测试目标
    • 在第4部分明确定义了准入/准出规则;通过和失败的标准;暂停标准和测试恢复需求

    这些内容都是很重要的内容。

    最后还描述了:

    • 测试提交产出物

    对比以上两份软件测试计划书的目录,可以看出第二份软件测试计划书的内容更加合理一些。

    如何写好软件测试计划书的内容?

    这个问题其实是“仁者见仁,智者见智”。不同的软件测试项目经理或者测试负责人、Test Leader等都有自己的看法。什么内容该写进去?写道什么程度?是否真的用心去写好每一个章节的内容?

    现实中,大多数软件测试项目经理或者测试负责人、Test Leader其实内心都是恐惧写文档的。很多时候不是不会写,而是不重视或者只是为了应付工作。原因其实很简单,无外乎有以下几种:

    • “文档无用论”,写文档还不如多用一些时间在解决项目问题上;
    • 写了软件测试计划其实也没有几个人看;
    • 文档其实不被重视;
    • 仅仅是为了应付公司品质部门、QAO的检查或者CMMI评估;
    • 在工作中测试管理的具体实践活动,依赖的是经验,而不是一份写在纸上的测试计划书;
    • 敏捷过程是“轻文档”化的;
    • 其它种种原因……

    软件测试计划真的仅仅只是一份文档吗?
    软件测试计划真的没有用吗?
    敏捷过程就真的不需要测试计划了吗?

    这些显然是一些借口或者错误的认识。

    为什么我们需要测试计划?

    无论做什么工作,都是计划先行,然后按照所制定的计划去执行、跟踪和控制。软件测试也一样,先要制定测试计划,是做好整个测试工作的前提。所以在进行实际测试之前,应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架,不断收集产品特性信息,对测试的不确定性(测试范围、测试风险等)进行分析,将不确定性的内容慢慢转化为确定性的内容,该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算,从而对测试策略、方法、人力、日程等做出决定或安排。

    在编写测试计划之前,可以考虑下面几个问题:

    • 为什么要编写测试计划?
      (1)Test Manager/测试主管等能够根据测试计划做宏观调控,进行相应资源配置等;
      (2)测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等;
      (3)便于其他人员了解测试人员的工作内容,进行有关配合工作
    • 什么时间开始编写测试计划?
      (测试需求分析前总体测试计划书/测试需求分析后详细测试计划书)
    • 由谁来编写测试计划?
      具有丰富经验的测试负责人Test Leader
    • 测试计划编写的基本思路(5W1H)
      (1)why——为什么要进行这些测试;
      (2)what—测试哪些方面,不同阶段的工作内容;
      (3)when—测试不同阶段的起止时间;
      (4)where—相应文档,缺陷的存放位置,测试环境等;
      (5)who—项目有关人员组成,安排哪些测试人员进行测试
      (6)how—如何去做,使用哪些测试工具以及测试方法进行测试。

    测试计划的要点

    测试规划与软件开发活动同步进行,在需求分析时,就开始测试策划,确定测试需求、目标、资源等。测试计划可以按不同的测试阶段(集成测试、系统测试等)来组织,也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

    测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等,其关键是制定有效的测试策略,界定清楚地测试范围,识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法,针对不同的测试目标或阶段确定测试方法,对测试工作量及所需的资源、时间进行合理的估算。所有这些,都是为了两个根本目的:测试的质量和效率。

    测试计划中需要明确测试范围

    测试主要依据“产品设计规格说明书”、代码所发生的变化及其影响的区域,来确定哪些功能和特性要测试,哪些功能和特性不需要测试。在确定测试范围时,主要考虑的因素有:

    • 优先级最高的需求功能
    • 新增加的功能和编码改动较大的已有功能
    • 容易出现问题的部分功能
    • 过去测试不够充分的地方
    • 经常被用户使用的功能和配置(占20%)
    • 哪些不需要测试的功能和特性(排除出测试范围)

    在实际的测试实施中,有时候存在测试执行到一定阶段,由于某种原因(例如:环境不具备、测试账号的问题、测试数据的问题、公司安全策略的限制等等导致测试条件不满足,从而一些之前计划在测试范围内的功能,需要排除出测试范围)测试范围需要发生变更。那么这就需要遵守变更流程,并且更新测试计划文档,以及更新后的测试计划获得审批。

    这个环节其实常常被Test Leader和Test Manager或忽视。

    我遇到过很多类似的情况,没有遵守变更流程,并且更新测试计划获得审批,这最终导致的结果是测试功能混乱;经历2-3个版本迭代之后,被测需求难以追溯。一旦存在产品发布之后出现功能上的问题,用户抱怨不断。其实这就反映出测试计划不合理而导致的问题。

    测试估算:所需资源和日程安排

    为了合理、准确地安排日程,对测试工作量要进行正确的估计。除了对工作量的估计之外,还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式,要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难,但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理,并适当增加10%-20%的余量,估算结果就比较准确了。
      
    在估算的基础上,进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的,所以人力资源的计划要有一定的灵活性和动态性,形成有机的动态平衡,保证测试的进度和资源的使用的效率。

    需要精心编写准备测试计划

    要做好测试计划,测试设计人员要仔细阅读有关资料,包括用户需求规格说明书、设计文档等,全面熟悉系统,并建议注意以下方面:

    • 让所有合适的相关人员参与测试项目的计划制定,特别是在测试计划早期;
    • 测试所需的时间、人力及其它资源的预估,尽量做到客观、准确、留有余地;
    • 测试项目的输入、输出和质量标准,应与各方达成一致;

    测试计划的主要内容

    测试计划的主要内容包括以下要点:

    1. 测试计划标识
    2. 版本修订记录
    3. 简介(目的)
    4. 主要阅读者
    5. 测试项(交付测试的一切内容)
    6. 需要测试的功能
    7. 不需要测试的功能
    8. 测试项通过/失败的准则
    9. 测试准则(入口准则、出口准则、暂停和恢复准则)
    10. 测试交付物/产出物
    11. 测试任务
    12. 进度计划(可以与10.测试任务合并做出一个进度和任务的矩阵,关键里程碑点的描述)
    13. 环境需求
    14. 工具
    15. 职责矩阵
    16. 人员和培训的需求
    17. 风险和缓解风险/预防风险的对策
    18. 批准(测试计划需要进行评审和审批)

    有一些时候对上述内容可以进行裁剪。还有一些测试团队/组织会将测试计划与测试策略合并成为一个文档。
    我在测试管理中,允许一些小的测试项目或者临时性的测试项目将测试计划(Test Plan)和测试策略(Test Strategy)进行合并。事实上,很多Test Leader,Test Manager是不愿意花费太多的精力去写文档、维护文档的。即便如此,2-3页纸的测试计划还是需要的。此时,测试策略(Test Strategy)就尤为重要了。

    测试计划需要评审

    测试计划不可能一气呵成,而是要经过计划初期、起草、讨论、审查等不同阶段,才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节,包括测试组织内部的自我评审、讨论和修改,然后交到评审会进行正式的评审,直至测试计划得到审批。

    测试计划的正式评审,项目中的每个人(产品经理、项目经理、开发工程师等)都应当参与。计划的审查是必不可少的,每一个参与者都可能根据其经验及专长提出问题或建议,弥补在测试范围、工作量、风险等各方面的不足,进一步完善测试计划。

    (更新完)

    展开全文
  • 软件测试之缺陷管理

    万次阅读 2018-03-21 20:31:13
    软件测试系列---缺陷管理 一、软件缺陷的基本概念 1、软件缺陷的基本概念主要分为:缺陷、故障、失效这三种。 (1)缺陷(defect):存在于软件之中的偏差,可被激活,以静态的形式存在于软件内部,相当于bug; ...
  • 软件测试管理者会遇到那些问题?

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

    万次阅读 多人点赞 2018-10-27 23:55:52
      软件测试工程师,和开发工程师相比起来,虽然前期可能不会太深,但是涉及的面还是比较广的。前期面试实习生或者一年左右的岗位,问的也主要是一些基础性的问题比较多。涉及的知识主要有MySQL数据库的使用、Linux...
  • 软件测试2小时入门

    万人学习 2018-10-10 16:14:16
    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、...
  • 点击禅道应用软件:访问禅道 选择开源版 输入账号密码(默认账号:admin默认密码:123456)登录页面如下: 二、开始使用禅道 1、创建部门点击组织一栏 2、点击部门,添加公司相应部门 点击编辑,...
  • 软件测试测试管理工具----禅道

    千次阅读 2018-08-16 20:38:36
    通过使用测试管理工具,测试人员或开发人员可以更方便地记录和监控每个测试活动,阶段的活动,从而找出软件的缺陷和错误,记录测试活动中发现的缺陷和改进建议。 禅道: 国产开源+商业式产品 禅道是国产的开源...
  • 软件测试面试题(面试前准备篇)

    万次阅读 多人点赞 2019-09-27 10:42:37
    是否了解软件测试需要掌握哪些知识(问到类似问题) 之前面试过,觉得自己需要补充哪些?做了哪些行动? 为什么做测试,觉得自己做测试有哪些优势?(有问到) 知道哪些Bug系统 9.测试用例的基本要素是? 二、...
  • 软件测试体系介绍

    万次阅读 多人点赞 2018-06-02 17:32:27
    后续还会对整个体系持续完善,主要的方向有软件测试价值、测试预防、探索式测试实践、质量管理、常用测试工具、可用性设计及测试等。希望对测试同仁们有帮助。这里面有很多测试领域大师的思想(重点集中在理论框架...
  • 软件测试经理面试

    千次阅读 2019-07-31 17:25:08
    软件测试面试题及答案【史上最全】 以下是软件测试相关的面试题及答案,欢迎大家参考! 1、你的测试职业发展是什么?  测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师...
  • 软件测试面试的自我介绍

    万次阅读 多人点赞 2019-04-13 18:27:27
    面试官,你好,我叫Jayce,16年本科毕业,从事软件测试将近3年的时间。在此期间做过一些项目也积累过一些经验,能够独立地完成软件测试流程的一个工作。我之前主要做过的是功能测试,web自动化测试、app专项测试、...
  • 软件测试管理——测试的风险分析

    千次阅读 2016-07-14 13:43:54
    软件测试:是一项高风险的工作,它是不可避免的,总是存在的。作为一名测试管理人员必须在平时的工作中,分析这些风险的类别,并且想出对策尽最大程度的降低这些风险。1.软件需求的风险主要表现在以下的几个方面:■...
  • 软件测试的生命周期&测试流程

    千次阅读 多人点赞 2019-04-29 21:47:16
    五、缺陷管理流程 六、软件和质量 一、软件的生命周期(基于瀑布模型的生命周期) 软件的生命周期:是指从产生到淘汰的过程 包括:计划(开发方与需求方讨论)、需求分析、设计、编码、测试(单元测试、集成测试、...
  • 软件测试十本书

    万次阅读 2017-10-18 00:46:38
    软件,已成为产品集成的必需部件。 软件产品的质量,与用户生活水平正比。 软件质量相关专业,正用武之地,期大有可为。 根据个人经验,推荐软件测试相关的十本书,静待有缘人。
  • 软件测试入门知识了解

    万次阅读 多人点赞 2018-09-05 14:59:58
    1.软件测试定义两面性 2.测试的生命周期 测试需求分析-->测试设计-->测试计划-->测试执行-->质量评估 3.软件测试过程: 需求评审和设计评审是验证软件产品的需求定义和设计...
  • 软件测试

    千次阅读 多人点赞 2019-10-10 17:39:15
    软件测试 软件测试全景图 软件测试的九个模块: 测试的定义,包括测试标准、原则、历史等; 测试五大流派,包括传统测试、敏捷测试、探索式测试、SBTM 测试方法:MBT、ReBT、RiBT等等 测试层次和类型:单元测试、...
  • 软件测试入门视频教程

    万人学习 2015-01-22 16:21:44
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • 软件测试面试题汇总

    万次阅读 多人点赞 2018-09-27 12:31:09
    转载自: ... 软件测试面试题汇总 测试技术面试题 ...........................................................................................................
  • 软件测试简历,这一点你是否漏掉

    万次阅读 多人点赞 2017-11-29 21:04:11
    几乎所有的测试简历都在长篇大论谈如何做测试,参加过多少项目的测试测试过程是怎么样的,测试如何管理,会黑盒、白盒、灰盒、彩盒.....、会写方案、测试用例。从这些内容中我无法看出你会什么,技术上哪些是你的...
  • google软件测试之道

    千次下载 热门讨论 2015-03-19 16:18:19
    每天,Google都要测试和发布数百万个源文件、亿万行的代码。...《Google软件测试之道》适合开发人员、测试人员、测试管理人员使用,也适合大中专院校相关专业师生的学习用书,以及培训学校的教材。
  • 软件测试&软件测试工程师

    千次阅读 多人点赞 2016-07-08 15:58:01
    起源: 最近在面试软件测试工程师方面的工作,今天在整理整理一下关于软件测试这方面的知识点。 一、 测试工程师: 1、 国内定位和发展前景: 测试工程师,软件质量的把关者,工作起点高,发展空间大。我国的...
  • 软件测试流程及规范

    万次阅读 2017-09-29 18:54:07
    目标制定完整且具体的测试路线和流程,为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。测试流程说明流程图需求分析 需求分析由SA制定,要求细化每一个功能的细节,每一个...
  • 软件测试配置管理的概念

    千次阅读 2010-09-08 00:08:00
    软件测试配置管理
  • 软件管理测试工具-ALM/QC

    千次阅读 2015-10-19 09:20:24
    (应用程序生命周期管理) ALM是基于web的工具,可给基于web的项目创建知识库。它是一个Java EE开发的C/S组织结构,是一个服务的集合体 阶段:指定版本→指定需求→计划测试→执行测试→追踪缺陷 (1)

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 707,927
精华内容 283,170
关键字:

软件测试管理