9A文软件测试技术-软件测试管理试题

1、MeiWei 81 重点借鉴文档】 第三章软件测试管理 简答题 1. 你是如何理解测试的层次和主要的管理活动？ 在软件测试的管理中，以下内容的定义反映测试工作的组织策略： a、软件测试遵循的标准； b、软件测试的工作范畴； c、软件测试环境； d、软件测试产品； e、适用于软件测试活动的软件资源标识规则； f、软件测试的进度安排。 软件测试遵循的标准 组织者在指定范围内选择软件测试遵循的标准， 并结合本软件系统的具体要求， 使之贯彻到 整个软件测试的计划、实现和管理过程之中。 根据标准， 需要被明确的内容包括： 测试阶段 和测试文档类型。 可以从三个角度来划分测试阶段： 面向测试操作类型的阶段

2、划分、 面向测试操作对象的阶段 划分、面向测试实施者的阶段划分。测试操作类型包括：调试、集成、确认、验证、组装、 验收、操作等。测试操作对象可以是：单元、部件、配置项、子系统、系统等。测试实施者 可以是：开发者、测试者、使用者、验收者等。各类标准从不同角度定义测试评审阶段，而 测试组织者可以在符合所选标准的同时，结合多个划分因素规定本系统的测试阶段。 各标准规定的测试文档类型也不尽相同。 如国标 软件产品开发文件编制指南 规定了两类 测试文档：测试计划、测试分析报告；国标计算机软件测试文件编制规范定义了八类测 试文档：测试计划、测试设计说明、测试用例说明、测试规程说明、测试项传递报告、测试 日

3、志、测试事件报告、测试总结报告； RRRR 软件工程化技术文件定义了三类测试文档： 测试计划、测试说明、测试报告。我们认为最后这种规定较易操作：因为，太少的测试文档 类型不利于有步骤有层次地定义测试内容， 也不利于测试用例和测试例程的良好表达； 太多 的测试文档类型易使测试组织陷入到繁杂的文档规范和编制中去；而第三种定义较为适中。 其中：测试计划在系统分析 /设计阶段提交，着重定义测试的资源、范围、内容、安排、通 过准则等； 测试说明在测试计划明确后开始编制， 针对软件需求和设计要求具体定义测试用 例和测试规程；测试报告分析和总结测试结果，测试日志是其必要附件。 MeiWei_81 重点借鉴文

4、档】 【MeiWei 81 重点借鉴文档】 2. 在实际项目中，如何对软件测试进行有效管理？ 我们的项目的生命周期大致分为以下几个阶段：需求阶段、设计阶段、 编码阶段、 系统测试 阶段和客户测试阶段， 规定各阶段的流程并指定责任人。 按照规程和项目实际情况确定个项 目的里程碑，设置多个检验点，由 QA 监督个检验点评审过程。 通过 CMM2 的六个关键域职称项目管理以 CMM 为目标和支撑进行项目的管理。在国内软 件开发行业一片混乱中， 决定走国际化的标准轨道， 使公司的开发过程与国际接轨， 接受美 国的成熟方法，以标准保证质量，以质量取信于市场。 CMM2 的六个关键域为：需求管理、 项目计

5、划、项目跟踪、质量管理、配置管理、分承包商管理。 需求管理在项目经理运用娴熟的项目管理技巧进行客户与公司的沟通， 从而达到明确需求和 管理需求的目的。 记录较大的需求变更， 减少双方需求误会和严格控制进度， 及时向开发组 反映客户的新要求。让客户得到一个质量上乘功能齐全的产品。 项目计划我们的项目经理会最终依照客户需求给出该项目的实施计划， 计划中规定出项目目 标、质量目标、项目组结构、项目开发及实施进度、资源状况和调配、风险预期以成本估算 等。在项目执行过程中，以该项目计划为基准进行项目的开发和实施，把握项目大方向。 项目追踪在项目实施过程中我们要求我们的项目经理每周至少运用项目管理工具 P

6、roject 跟 踪两次项目做到对项目的进程、 资源调配情况心中有数， 从而及时化解突发事件。 项目进程 中避免不了因需求或其他技术问题干扰进度， 这是项目经理应凭自己的经验调整进度， 分析 态势、重新调配资源。 质量管理无论在项目内部还是项目外部我们都由 QA 人员对项目进行监督， 项目内部 QA 人 员负责测试和配置管理的计划及落实， 项目外部的 QA 人员对整个项目的过程进行监控， 对 项目及项目经理做出合理评价。 配置管理采用先进的配置管理方法， 在项目初期指定配置管理计划， 并在开发期间应用。 按 照项目生命周期建立配置管理基线，并严格控制变更。 QA 按照事先规定的配置管理基线和

7、项目里程碑进行审核。保证每阶段过程合格分承包方控制对分承包方我们有严格的质量控 制。 3. 一名优秀的软件测试工程师应具备哪些素质？ 1、沟通能力 有时将客户提的要求反映给 RD,RD 常常无法理解，认为是无理取闹； RD 做的东西，推广 给客户，客户无法理解，认为 RD 是闭门造车。另外，在项目进行中，为了更快推动项目进 行，需要 QA 或测试人员积极主动的去和所有人进行沟通。 所以一名理想的测试者必须能够 同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员） MeiWei_81 重点借鉴文档】 【MeiWei 81 重点借鉴文档】 的交流能力。 既要可以和用户谈

8、得来， 又能同开发人员说得上话。 和用户谈话的重点必须放 在系统可以正确地处理什么和不可以处理什么上。 而和 RD 谈相同的信息时， 就必须将这些 话重新组织以另一种方式表达出来。 2、技术能力 就总体言， 开发人员对那些不懂技术的人持一种轻视的态度。 一个 QA 或测试者必须既明白 被测软件系统的业务逻辑概念又要会使用工程中的工具。 要做到这一点需要有一定的编程经 验，前期建议通过编写脚本或小的应用程序来训练这方面的能力， 一定的开发经验可以帮助 对软件开发过程有较深入的理解， 从开发人员的角度作出正确的评价， 简化自动测试工具编 程的学习曲线。如果能够通过自动化测试工具或自己写的程序测出

9、RD 们测不出来的缺陷， RD 就会对你刮目相看。 3、自信心 开发者指责测试者出了错是常有的事， 测试者必须对自己的观点有足够的自信心。 敢于坚持 , 如果容许别人对自己指东指西，就不能完成什么更多的事情了。 4、外交能力 当你告诉某人他出了错时， 就必须使用一些外交方法。 机智老练和外交手法有助于维护与开 发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。 如果采取的方法过于强硬， 对测试者来说， 在以后和开发部门的合作方面就相当于 “赢了战 争却输了战役” 。 5、幽默感 在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。 6、很强的记忆力 一个理想的测试者

10、应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来， 这一能 力在测试过程中的价值是无法衡量的。 因为许多新出现的问题和我们已经发现的问题相差无 几。 7、耐心 一些质量保证工作需要难以置信的耐心。 有时你需要花费惊人的时间去分离、 识别和分派一 个错误。这个工作是那些坐不住的人无法完成的。 8、怀疑精神 可以预料，开发者会尽他们最大的努力将所有的错误解释过去。 测式者必须听每个人的说明， 但他必须保持怀疑直到他自己看过以后。 9、自我督促 MeiWei_81 重点借鉴文档】 【MeiWei 81 重点借鉴文档】 干测试工作很容易使你变得懒散。 只有那些具有自我督促能力的人才能够使自己每

11、天正常地 工作。 10、洞察力 一个好的测试工程师具有 “测试是为了破坏” 的观点，捕获用户观点的能力，强烈的质量追 求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。 4. 如何利用相关测试管理工具，对测试计划和缺陷进行有效的管理？ 第一步：规划缺陷管理流程 实践证明，只有展开全面彻底地规划，才能让缺陷汇报和解决流程提供有价值的信息，使 IT 流程合理化。以下部分所描述的步骤是在创建汇报流程、定义缺陷安全等级、记录缺陷 状态和跟踪所有修改的过程中会被采用的一些步骤。 发现“缺陷” 通过使用测试工具，在 SDLC（软件开发生命周期）中未被发现的所有和项目有关的差异及

12、问题都将汇报到管理工具中。美科利 TestDirector 针对不同的差异，清晰的定义了 NEW 、 OPEN 、CLOSED 等级别。当工具中开放了一个新的缺陷问题，我们就要陆续开始登录缺陷 报告、 定义缺陷安全等级、描述缺陷、指派相关人员展开最初的调查、 将差异转交给相关的 测试主管等工作。 缺陷解决会议 召开缺陷解决会议能确保所有缺陷都能涉及并得到有效解决。 这种定期会议由来自开发、 项 目管理、 产品管理、 和项目相关的业务团队代表及测试主管共同参加，就缺陷问题展开讨论。 测试主管在会议期间对测试工具进行信息更新， 会议的中心议题是对缺陷报告进行审核。 有 了测试工具提升的完备的报告，

13、 我们就可以依据其严重程度和状态情况， 选择处理的优先权 缺陷修复 缺陷解决会议后，缺陷将被分配给合适的小组主管，以便着手解决。这些小组包括：开发小 组、环境支持小组， 或是业务团队。 通过管理工具对任务进行合理分配，能更为高效地解决 缺陷问题。 重复测试缺陷 被修复缺陷如果在环境缺陷中没有代码变更， 将马上展开重复测试， 并立即关闭。 需要代码 变更的缺陷修复会涵盖在一个版本打包中， 从而展开重复测试， 接着将根据测试结果或者关 闭缺陷，或者将缺陷重新开放。 第二步：定义缺陷状态 每个缺陷都有一个状态显示， 会在整个测试周期中得到随时地更新。 每次当缺陷状态有了更 MeiWei_81 重点借

14、鉴文档】 【MeiWei 81 重点借鉴文档】 新，评论信息就会加入到缺陷的 R&D 评论栏中。 测试工具中的缺陷状态一般会有以下几种： New: 默认值，测试分析人员输入一个新的缺陷时，其状态为“New”. Open:测试主管将缺陷状态从 “ New ”改为 “Open”,并在一定的时间内 （根据缺陷严重程度） 更新 R&D 评论信息，接着指派给适合的小组。 FiRed:当缺陷被修复并通过了联合测试，开发人员将缺陷状态从“Open”改为“ FiRed” .缺 陷修复的周期取决于缺陷的严重程度。 ReadRforRetest:当缺陷已经修复，并在一个 build 中完成了系统测试和识别 ,项目

15、/产品/发布经理将缺陷状态更新为“ ReadRtoRetest”.OnHold: 当该缺陷由于其它缺陷的 阻碍而无法在 build 中实施重复测试时，测试分析人员将缺陷状态从“ReadRtoRetest”更新 成“ OnHold ” Closed:当缺陷在一个新建的应用中完成了重复测试，测试分析人员就将状态从 “ReadRtoRetest”改为“ Closed” . Reopen:当缺陷重复测试失败，测试分析人员将状态从“ReadRtoRetest”更新为“ Reopen” . 当以前已经关闭的缺陷又在测试过程中出现时，测试分析人员将把状态从“Closed ”改为 “Reopen” . 第三步

16、：用户操作的状态修改 通过对测试工具所允许的状态变更操作， 可以为实现便捷的学习曲线和巩固一种优化的工作 流程提供帮助。状态变更包括： 根据适合的变更控制流程所进行的任何系统变更。 在进行修复操作之后，未通过测试或某个测试部分根据需要展开重复测试。 在流程中的任何时段，项目经理、系统分析人员、开发人员和测试工作人员可以 使用测试工具来恢复保存在存储器中的所有缺陷状态等。 最后：将新的流程配置到测试自动化工具中 5. 在测试管理中，应该收集哪些测试过程数据，并如何对这些过程数据进行分析？ 6. 如何做一名合格的测试人员？ 1. 具有探索精神：软件测试员不会害怕进入陌生环境。 2. 具有故障排除能力：软件测试员善于发现问题的症结，喜欢猜谜。 3. 不懈努力：软件测试员总是不停尝试。他们可能会碰到转瞬即逝或者难以重建的 软件缺陷；他们不会心存侥幸，而是尽一切可能去寻找。 4. 创造性：测试显而易见的事实，那不是软件测试员；他们的工作是想出富有创意 甚至超常的手段来寻找软件缺陷。 MeiWei_81 重点借鉴文档】 【MeiWei 81 重点借鉴文档】 5. 追求完美：他们力求完美，但