软件测试技术软件测试管理试题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第三章软件测试管理
简答题
1.你是如何理解测试的层次和主要的管理活动?
在软件测试的管理中,以下内容的定义反映测试工作的组织策略:
a、软件测试遵循的标准;
b、软件测试的工作范畴;
c、软件测试环境;
d、软件测试产品;
e、适用于软件测试活动的软件资源标识规则;
f、软件测试的进度安排。
软件测试遵循的标准
组织者在指定范围内选择软件测试遵循的标准,并结合本软件系统的具体要求,使之贯彻到整个软件测试的计划、实现和管理过程之中。根据标准,需要被明确的内容包括:测试阶段和测试文档类型。
可以从三个角度来划分测试阶段:面向测试操作类型的阶段划分、面向测试操作对象的阶段划分、面向测试实施者的阶段划分。测试操作类型包括:调试、集成、确认、验证、组装、验收、操作等。测试操作对象可以是:单元、部件、配置项、子系统、系统等。测试实施者可以是:开发者、测试者、使用者、验收者等。各类标准从不同角度定义测试评审阶段,而测试组织者可以在符合所选标准的同时,结合多个划分因素规定本系统的测试阶段。
各标准规定的测试文档类型也不尽相同。如国标《软件产品开发文件编制指南》规定了两类测试文档:测试计划、测试分析报告;国标《计算机软件测试文件编制规范》定义了八类测试文档:测试计划、测试设计说明、测试用例说明、测试规程说明、测试项传递报告、测试日志、测试事件报告、测试总结报告;《XXXX软件工程化技术文件》定义了三类测试文档:测试计划、测试说明、测试报告。我们认为最后这种规定较易操作:因为,太少的测试文档类型不利于有步骤有层次地定义测试内容,也不利于测试用例和测试例程的良好表达;太多的测试文档类型易使测试组织陷入到繁杂的文档规范和编制中去;而第三种定义较为适中。其中:测试计划在系统分析/设计阶段提交,着重定义测试的资源、范围、内容、安排、通过准则等;测试说明在测试计划明确后开始编制,针对软件需求和设计要求具体定义测试用
例和测试规程;测试报告分析和总结测试结果,测试日志是其必要附件。
2.在实际项目中,如何对软件测试进行有效管理?
我们的项目的生命周期大致分为以下几个阶段:需求阶段、设计阶段、编码阶段、系统测试阶段和客户测试阶段,规定各阶段的流程并指定责任人。按照规程和项目实际情况确定个项目的里程碑,设置多个检验点,由QA监督个检验点评审过程。
通过CMM2的六个关键域职称项目管理以CMM为目标和支撑进行项目的管理。在国内软件开发行业一片混乱中,决定走国际化的标准轨道,使公司的开发过程与国际接轨,接受美国的成熟方法,以标准保证质量,以质量取信于市场。CMM2的六个关键域为:需求管理、项目计划、项目跟踪、质量管理、配置管理、分承包商管理。
需求管理在项目经理运用娴熟的项目管理技巧进行客户与公司的沟通,从而达到明确需求和管理需求的目的。记录较大的需求变更,减少双方需求误会和严格控制进度,及时向开发组反映客户的新要求。让客户得到一个质量上乘功能齐全的产品。
项目计划我们的项目经理会最终依照客户需求给出该项目的实施计划,计划中规定出项目目标、质量目标、项目组结构、项目开发及实施进度、资源状况和调配、风险预期以成本估算等。在项目执行过程中,以该项目计划为基准进行项目的开发和实施,把握项目大方向。项目追踪在项目实施过程中我们要求我们的项目经理每周至少运用项目管理工具Project跟踪两次项目做到对项目的进程、资源调配情况心中有数,从而及时化解突发事件。项目进程中避免不了因需求或其他技术问题干扰进度,这是项目经理应凭自己的经验调整进度,分析态势、重新调配资源。
质量管理无论在项目内部还是项目外部我们都由QA人员对项目进行监督,项目内部QA人员负责测试和配置管理的计划及落实,项目外部的QA人员对整个项目的过程进行监控,对项目及项目经理做出合理评价。
配置管理采用先进的配置管理方法,在项目初期指定配置管理计划,并在开发期间应用。按照项目生命周期建立配置管理基线,并严格控制变更。QA按照事先规定的配置管理基线和项目里程碑进行审核。保证每阶段过程合格分承包方控制对分承包方我们有严格的质量控制。
3.一名优秀的软件测试工程师应具备哪些素质?
1、沟通能力
有时将客户提的要求反映给RD,RD常常无法理解,认为是无理取闹;RD做的东西,推广
给客户,客户无法理解,认为RD是闭门造车。另外,在项目进行中,为了更快推动项目进行,需要QA或测试人员积极主动的去和所有人进行沟通。所以一名理想的测试者必须能够同测试涉及到的所有人进行沟通,具有与技术(开发者)和非技术人员(客户,管理人员)的交流能力。既要可以和用户谈得来,又能同开发人员说得上话。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和RD谈相同的信息时,就必须将这些话重新组织以另一种方式表达出来。
2、技术能力
就总体言,开发人员对那些不懂技术的人持一种轻视的态度。一个QA或测试者必须既明白被测软件系统的业务逻辑概念又要会使用工程中的工具。要做到这一点需要有一定的编程经验,前期建议通过编写脚本或小的应用程序来训练这方面的能力,一定的开发经验可以帮助对软件开发过程有较深入的理解,从开发人员的角度作出正确的评价,简化自动测试工具编程的学习曲线。如果能够通过自动化测试工具或自己写的程序测出RD们测不出来的缺陷,RD就会对你刮目相看。
3、自信心
开发者指责测试者出了错是常有的事,测试者必须对自己的观点有足够的自信心。敢于坚持,如果容许别人对自己指东指西,就不能完成什么更多的事情了。
4、外交能力
当你告诉某人他出了错时,就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系,测试者在告诉开发者他的软件有错误时,也同样需要一定的外交手腕。如果采取的方法过于强硬,对测试者来说,在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。
5、幽默感
在遇到狡辩的情况下,一个幽默的批评将是很有帮助的。
6、很强的记忆力
一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来,这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。
7、耐心
一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。
8、怀疑精神