测试 & 测试leader/测试经理的职责

 

测试leader/测试经理的职责是有效的领导一个测试团队。为了更好的履行这个职责，测试leader/必须理解测试的基本原则，作为一个测试经理在履行一个传统的领导角色的同时还应懂得该如何有效地实现一个测试流程。这是什么意思呢？测试经理应该管理、贯彻和维护一个有效的测试流程。这包括搭建一个能够支持良好沟通和有效成本控制的测试环境,创建一个有效的测试团队。

 

测试leader/测试经理的主要职责是：

 

1、在测试组织内部制定和分配测试角色。

2、根据每一次交付的版本/产物的内容制定测试范围。

3、为迎合测试需要进行测试环境的配置和管理。

4、实现和开展适当的度量和规划:

      (1) 交付的产品是否可以测试。

      (2) 测试团队是否已经做好测试准备。

5、为每一个给定版本进行测试计划、开展测试以及管理测试结果。

6、为迎合测试要求管理和壮大必须的测试资产：

      (1) 测试成员。

      (2) 测试工具。

      (3) 测试流程。

7、保持自身熟练的测试技巧。

 

测试leader应该明白怎样测试才能符合测试团队要求，换句话说，就是制定清晰的组织角色，这些可以通过创建一个任务说明或者定义一份测试规格书来实现。例如：“根据给定的版本内容预防、发现、记录以及管理缺陷”。

 

现在测试leader的任务是去沟通和贯彻有效的管理以及测试技术支持、简单的要求、团队的期望，你的同事(开发的领导以及其他领导)和上级应该被给定适当的时间计划表，完备的开发团队和测试团队。这些期望通常在功能测试的范围区域内外被定义。例如:

 

属于功能范围以内的：

(1) 创建一个新的客户曲线图。

(2) 更新客户曲线图。

(3)  … …

 

属于功能范围以外的：

(1) 安全。

(2) 备份与防御。

(3)  ... …

 

这个被定义的范围将贯穿在测试的各个不同的时期，关键的是确保你的团队或者组织能够清晰的理解在当前的版本中什么能够测试什么不能够测试。测试leader或者经理应该使用合适的测试框架和测试技术去迎合测试组织的需要。当任何测试组织的测试框架要求都很困难的去定义以下问题的时候，测试leader/经理必须进行自我反思。这些问题以及其他问题的答案，将会定义出测试基本框架的长期和短期的目标。

 

软件产品成熟度和测试的关系是什么样子的？

（ 这个地方是一张图片）

   

Acceptance: - 可接受的测试，或者称为验收测试，是指产品准备发布前由客户或者最终用户进行的测试。

System: - 系统测试，从整体上对产品进行测试，包括对软硬件环境的交互。

Function: - 对交付的各个组件进行的功能测试。

Unit: - 单元测试，是指开发者对代码的测试。

Design Review: - 产品设计阶段。

%Construction: - 可以理解为产品未完成百分比。

%Product: - 产品完成百分比

 

测试组织如何对于当前的项目中帮助预防更多的缺陷？

 

   这里确实有两方面对于测试验证和确认。不幸的是这意味着这些周期已经被几个管理/调整的团队给予了不同的定义。为了使其更简洁，一些测试应该在产品建构/建置之前被执行并且在产品建构/建置之后还会有不同类型的测试被执行。

 

   在当前的项目中尽量避免缺陷包含了产品被建构/建置之前的测试。有些方法可以帮助实现这个目标。最强大的和花费成本最高的是回归测试。回归是任意的正式的/技术的回归或者同级别的回归。一般产品开发生命周期将会提供测试团队一些有用的用于回归的测试材料/可交付产品。什么时候可以适当地实施任一个有效的开发范例应该提供这些可交付产物，例如:

 

(1) 瀑布式模型

(1-1) 需求文档

(1-2) 功能规格说明书

 

(2) 敏捷/快速开发

(2-1) 更高水平的需求文档

(2-2) 流程图

 

测试应该包含回归的过程并且任何缺陷都应该被记录和管理。

 

怎样并且什么时候测试组织能够发现这些软件缺陷？

 

测试组织能够发现软件缺陷是在产品或者一些被交付的可操作的部分以后，需要执行什么样的测试基于那个时间段产品的成熟度。主流的测试阶段顺序是：

 

(1) 设计阶段

(2) 单元测试

(3) 功能测试

(4) 系统测试

(5) 用户可接受的测试/验收测试

 

   测试团队至少应该执行三个阶段的测试：设计阶段、功能测试和系统测试。

 

   功能测试包括依靠功能规格说明书 和/或 产品需求说明书设计、实现和执行测试用例。这是测试团队依靠产品目标度量发现与测试用例之间的差异作为测试缺陷。例如测试验证一个网页是否允许一个新论坛成员登录，在这个用例中我们就以测试验证网页功能作为切入口。

 

   系统测试包含了很多与功能测试相同的过程(设计、实现、执行和缺陷跟踪)，但是他们的意图和关注焦点是不同的。功能测试关注的焦点是不连续的功能要求，而系统测试关注的焦点是系统的整体相关性。例如测试确保应用程序能够允许登录、激活和恢复一个新的论坛会员。在这个用例中我们就测试确保系统支持此功能。下面是一些系统测试的类型，对给定版本的测试哪些需要执行，可以通过下面的范围决定：

(1) 安全测试

(2) 性能测试

(3) 综合测试

 

什么是最小的度量和量化？

 

   测试团队的最重要的提交物是缺陷。缺陷是唯一的可用来衡量测试团队在整个项目中的产出的一个指标。缺陷依赖于系统被记录和跟踪 -- 一个空白的最小的缺陷记录应该包括：

 

(1) 缺陷的名称/标题

(2) 缺陷描述。什么需求没有被合理的实现？

(3) 详细描述如何重现这个缺陷。

(4) 缺陷的严重等级。

(5) 缺陷存在的功能区域。

(6) 缺陷发现者。

(7) 缺陷状态(开启的、正在进行中、解决的、关闭的)

 

这些将为度量的最小尺度提供依据：

 

(1) 缺陷上升的数量

(2) 在一定阶段内的缺陷严重程度分布

(3) 在一定阶段内的产生缺陷的功能区域分布

 

    从基线来看，度量一个测试组织的维护在于它的成熟度以及使命描述。SEI(美国软件工程研究所)应用于测试的过程成熟度模型，同时也应用于其他任何一个软件工程学科。

 

(1)初始级: (无组织状态)不可预知的简单的控制。

(2)可重复级: (不被承认的民间传说)重复执行先前的任务。

(3)已定义级: (标准的) 流程个性化，清晰，明了

(4)已管理级: (度量)过程度量和控制

(5)优化级: (优化的) 过程焦点是改进

 

    测试组织流程和测试的度量标准取决于测试经理和测试leader对测试成本收益的分析结果。如何评价一段时间内预诉讼锁定义的目标和前期取得的绩效？

 

如何去壮大和维护一个测试组织？

 

      管理和领导一个测试团队是IT行业最极具挑战性的职位之一。这个团队通常是人手不足、缺少适当的工具、缺乏资金，最终期限不确定，测试阶段常常受制于产品的延迟。测试人员流动频繁，要保持一个强有力的团队才是最重要的。怎样才能完成这些看起来不太可能的任务呢？下面介绍一下我作为测试leader和测试成员的经验：

（1）如果时间安排有冲突应该在一定时期范围内适当的更改测试计划。

（2）在测试团队和项目经理之间进行明确清晰的交流沟通。

（3）在开发成员和项目经理之间保持明确清晰的交流沟通。

（4）无论什么时候去推销自己的测试团队，记得你的卖点是团队对于项目的重要性和贡献

（5）测试组织应该确保给每个测试成员制定一个明确的角色定义和职业规划。

（6）度量和沟通测试效益回收 – 是否测试出来的缺陷到达了成本花费领域。

（7）明确一定的测试支出是投资而不是浪费。

（8）最后一定要保持冷静 -- 好运。

 

测试 & 测试设计者/测试者的职责

测试设计者/测试者的职责主要是设计和书写测试用例、执行测试用例、记录测试结果、记录和跟踪缺陷、进行测试覆盖分析等等。设计者在接到测试组织的测试要求后，应该运用适当的测试分析、测试设计和尽可能有效的测试覆盖分析方法来履行测试设计者的职责。这个目标是运用尽可能少的测试用例获得尽可能多的测试覆盖。

职责和产出

测试用例设计

测试用例设计不同于测试用例。这个设计结果是测试设计者/测试者正试图利用一个或多个测试用例达到的。它可能是正规测试执行之前的一个包含简单的测试用例内容的非正规的文档或图释。

测试用例

测试用例是用来从一个或多个角度测试应用程序的一系列有序地执行步骤。每个测试用例至少应该包括：操作步骤、测试数据和预期结果。可以使用合适的“测试用例模板”或者一些商业的/免费的/共享的软件来记录测试用例。

测试用例的执行

测试用例执行是实际的运行一个测试用例。可以通过手工或利用自动化测试工具或者测试脚本执行测试用例。

捕获测试结果

捕获测试结果主要是简单的逐条记录一个测试用例的每一个步骤成功失败与否。失败的测试用例意味着一个缺陷可能已经被发现 – 它意味着这个应用程序可能没有达到测试用例设计的预期的结果。通常导致测试用例步骤执行失败的原因有：无效的测试设计/预期结果、无效的测试数据或者无效的应用程序状态。测试者在提交缺陷之前应该确保导致测试用例执行失败的原因是由应用程序引起的，而非规格说明书，并且能够使缺陷重现。

记录缺陷

测试者应该记录下在测试用例执行期间发现的所有缺陷。缺陷记录应该包括：测试者姓名、缺陷名称、缺陷描述、严重等级、出现缺陷的功能区域和其他任何可以帮助理解缺陷的信息。

测试覆盖分析

如果测试者对测试的要求和预定义的测试范围感到满意了，就可以记录下应用程序当前的状态。如何进行测试覆盖分析依赖于对测试者有用的信息。如果测试者能够绘制测试用例图去更好的阐明需求那么测试覆盖分析就是一件很简单的事情。否则测试人员必须将测试用例分布在应用程序的各个功能模块上,并且确认是否已经完全覆盖了功能---这显然更像是某种内部检查,而不是真正的分析。

测试要求和范围

    测试者设计者和测试者在执行测试任务之前应该清晰的明确测试的要求和范围。测试者们的梦想就是可以测试所有的东西:但问题是任何应用程序的测试,都不可能给出足够的时间让你完成这个梦想.所以测试员必须确认任何一个测试用例的设计和执行都要符合当前测试所想要达到的深度和广度.如果不能,那么要么重新定义测试的范围,要么放弃这些不符。

测试阶段和测试用例设计

不同的测试阶段对测试用例的形式、内容和目的都有影响。如果设计者能够考虑到测试不同阶段那么测试的类型需要在任何一个给定的测试阶段贯彻执行。如果设计者在设计的时候根据测试深度，测试范围等，制定了测试阶段。那么显然需要根据这些给定的阶段，进行不同种类的测试。

单元测试

测试设计者，主要是开发者，创建测试用例进行代码级测试。

功能测试

测试设计者设计测试用例进行业务或功能级的测试。

系统测试

测试设计者设计测试用例进行系统级的测试（压力测试、功能测试、安全测试、可恢复性测试等等）或者完成点对点的业务测试。

可接受的测试/验收测试

在这个阶段中测试设计者通常是一个系统问题专家或者最终用户，设计测试用例对业务流程或可操作性进行测试。

任何测试用例都不能复制前一阶段完成的测试。一个最常犯的错误是测试者和测试组织通常复制功能测试阶段完成的测试来设计系统测试阶段的测试用例。

缺陷内容

缺陷是测试设计者引起的最重要的产出物。测试的主要目的是在版本发布之前发现应用程序中的缺陷；此外缺陷是唯一能够被工程组看到的可用来度量测试团队工作的指标。测试者必须形成一种缺陷记录风格，这对于缺陷过程改进是非常有用的。一个空白缺陷至少应包括：缺陷发现者、缺陷名称、缺陷描述、缺陷等级、缺陷出现区域和状态。下面以一个在功能测试中被发现经典登录缺陷为例进行分析：

缺陷名称/标题

缺陷名称/标题应该是对缺陷的存在区域和缺陷内容的一个概括性的描述。若从登录界面上找到的缺陷，应该用登录界面加上概括性的缺陷描述来定义缺陷的名称/标题。

  例如：“登录-用户在尝试三次登录失败后没有被锁定”。

缺陷描述

缺陷描述应该清晰的阐释缺陷产生的具体情形，何时能够捕获到缺陷快照或者可打印的错误。

例如：试图利用一个无效的用户ID登录系统，在前两次尝试的时候会出现预期的提示信息“用户名或密码错误-请重试”。但是到了第三次尝试的时候却直接显示了错误。根据需求用户应该被提示“无效的用户名和密码-请联系管理员”，然后被系统锁定。

如何重现缺陷

缺陷描述应该能够为项目维护小组提供尽可能详细的细节，并且开发者在进行缺陷修复的时候能够重现。

缺陷等级

缺陷的严重等级依赖于：测试的阶段、缺陷与测试成果之间的冲突、如果缺陷没有被发现可能带来的风险。使用“登陆系统”为例，如果这个缺陷在功能测试阶段被发现那么可能被定义为“中等”严重程度，但是如果在系统测试阶段才被发现或者一直隐藏在系统测试阶段，可能严重等级就被定义为“高级”。

缺陷发生区域

缺陷发生区域可能是系统的某个功能组建或者某个功能区域-亦或两者都有。以“登陆系统”为例，功能单元应该是“登陆界面”，功能区域应该是“安全”

团队中其他成员的关系

测试leader/测试经理

测试设计者和测试leader之间建立良好的合作关系是非常重要的，测试设计者必须让测试leader意识到任何的挑战都可能让测试团队走向成功。通常测试设计者（或设计者）应该更清楚的理解当前应用程序的状态和潜在的挑战。

自动化测试工程师

如果测试用例应用于自动化测试，那么测试设计者应该确保自动化测试工程师能够准确地了解测试用例试图达到什么目标，并且如果在测试执行期间出现错误系统会有什么样的响应。为了使自动化测试工程师能够更好的完成自动化测试任务，测试设计者有时候可能需要进行必要的妥协，前提是这个妥协不会对应用程序造成任何大的风险。

[转贴]

SEI：  Software Engineering Institute（软件工程研究所）

CMMI：  Capability Maturity Model Integration（集成能力成熟度模型）

CMMI ML*： CMMI Maturity Level *（CMMI 成熟度 * 级）

PA ： Process Area（过程域）

ATM ： Appraisal Team Member（评估团队成员）

SCAMPI ：  Standard CMMI Appraisal Method for Process Improvement（基于标准CMMI评估方法的过程改进）

OSSP ： Organizational Standard Software Process（组织标准软件过程）

EPG ： Engineering Process Group（工程过程小组）

 

评估 ： 主要目的是验证过程改进成果、并为组织进一步改进提供指南。

预评估 ： 预评估相当于正式评估的演习，通过预评估判定组织是否可以按照原计划进行下一步的正式评估。

正式评估 ： 由SEI授权的主任评估师领导评估小组成员严格按照SCAMPI进行评估。主任评估师将在正式评估的最后一天宣布组织的CMMI成熟度等级，同时将在一定期限内向SEI汇报评估结果。

差距分析：  主要目的是了解组织现状并确立和组织CMMI等级目标的差距，形成诊断报告，并根据诊断结果，勾画出组织过程改进的框架。通常在CMMI启动后即进行差距分析。

Readiness Review  文档审阅：文档审阅是整个CMMI实施过程中非常重要的一项工作。通过文档审阅，检查出组织过程中存在的问题。正式评估阶段的首要工作即进行Readiness Review。

评估小组： 由一支富有经验的、受过IntroCMMI课程培训并获得证书的人员组成。可由组织内部及外部成员组合而成。内部评估团队成员可以将评估过程中的经验与教训更好地贯彻到以后的过程改进中；外部评估团队成员则可以结合自身的评估经验，对组织过程进行更为准确、客观的评价，并给出意见与建议。

软件测试过程的度量

文章来源：卖烧烤的鱼博客 

1）测试度量的作用（－）
　　 A:为制定测试计划时提供依据
　　　 需要多长时间?　需要什么物质条件？　 需要多少人，什么素质的人？ 在规定的时间内能完成到什么程度？
　　　　哪些模块及功能需要重点关注？ 测试工作量占整个项目的比例？ 测试结束后我们能达到什么样的目标 ？等等
( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目 类似的情况，以能更为准确的完成计划。 )
　　B： 提高测试流程可控性
　　　　提高测试效率和质量
　　　　提高测试人员的成就感

2)在测试哪个过程做度量
（产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段）
我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步，通过 FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

3）测试度量的内容
两种度量类型：
　　　 A： 项目度量：规模、测试工作量、测试进度、测试生产率
　　　 B： 质量度量：缺陷率（阶段）、缺陷排除率、可靠性等
四个基本度量项：规模、工作量、进度、缺陷

4) 测试用例设计阶段的度量
　　　A：规模 ：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
　　　 B： 工作量 ：文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
　　　C： 进度 ：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
　　　 D： 缺陷 ：评审过程中出现的错误数量、缺陷数量，级别

5）测试执行阶段的度量：
? 测试用例执行率　　　　　　　? 测试用例通过率
? 测试用例问题发现率　　　　　? BUG数量
? BUG级别统计　　　　　　　　　? BUG分布统计（模块）
? BUG分布统计（阶段）　　　　　? BUG密度
? BUG关闭率　　　　　 　　　　? 人均BUG发现效率
? 测试用例执行工作量项目　　　? 回归测试执行工作量
? 发布文档数量　　　　　　　　? 发布文档缺陷数量、级别
? 现场发现的BUG数量　　　　　　? 回归测试现场BUG的工作量
? 版本发布过程中的验证周期　　? 版本发布过程中的验证工作量
? 测试用例覆盖率　　　　　　　? 功能的用户关注度
? 需求变化程度 　

6）测试的度量为项目实施做的贡献

度量项	含义	目的与意义
测试生产率	单位时间所测试的代码量、或者单位时间执行测试用例的数量	一个团队的测试能力
工作量变化率	实际花费工作量相对于估计工作量的偏差百分比	提高估计技能、避免过载分配任务
测试进度变化率	项目实际测试进度相对于计划进度的偏差百分比	监控项目以便适时采取纠正措施
工作量	测试所做的工作小时数	测试为整个项目贡献的工作量
缺陷密度	千行代码发现的缺陷数，千个功能发现的缺陷数	用于度量被测试系统的可靠性
测试问题的严重性	测试发现问题的严重性分布	用于确定目前被测试系统的可靠性
测试用例的问题发现效率	单个测试用例发现问题的数量	用于度量测试用例的有效性
测试用例覆盖率	需求覆盖率、功能点覆盖率、代码覆盖率等	度量测试的充分性
问题遗漏率	发布后市场反馈问题数/产品问题总数目	衡量内部测试质量
COQ		为提升测试质量所付出的工作量
COPQ		为不好的质量付出的代价

7)由谁来做度量
8)怎样做度量?
PDCA方法：
　　　　　第一步：Plan 　　（ 计划、设置标竿） ( 计划－－制定我们想要达到的目标)
　　　　　第二步：do　　　　（执行）(日报－－记录数?）