【摘要】对商业用户来说，他们后面是成百上千个供货商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供货商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

      经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供货商自动结算，卖场通过扫条形码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

      分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

      经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

      分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

      经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

      分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

      经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

风险躲在需求的迷雾之后

      以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

      像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

     ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

     ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

     ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

     ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作接口的具体细节和构造上的限制。

     ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

      前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其它任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

      下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

      经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

      在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

      优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

      由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

客户的需求观

      客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

      1、 分析人员要使用符合客户语言习惯的表达

      需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

      2、分析人员要了解客户的业务及目标

      只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。`

       3、 分析人员必须编写软件需求报告

      分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其它信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

      4、 要求得到需求工作结果的解释说明

      分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

      5、 开发人员要尊重客户的意见

      如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

      6、 开发人员要对需求及产品实施提出建议和解决方案

      通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

      7、 描述产品使用特性

      客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“接口友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

      8、 允许重用已有的软件组件

      需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

      9、 要求对变更的代价提供真实可靠的评估

      有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

      10、 获得满足客户功能和质量要求的系统

      每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

      11、 给分析人员讲解您的业务

      分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

      12、 抽出时间清楚地说明并完善需求

      客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其它获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

      13、 准确而详细地说明需求

      编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

      在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

      14、 及时作出决定

      分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

      15、 尊重开发人员的需求可行性及成本评估

      所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的资料。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

      16、 划分需求的优先级

      绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

      在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

      17、 评审需求文档和原型

      客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。

      更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

      18、 需求变更要立即联系

      不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

      19、 遵照开发小组处理需求变更的过程

      为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

      20、 尊重开发人员采用的需求分析过程

      软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

      在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

      这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

      同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

      这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

      对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

      需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

01. 为什么要在一个团队中开展软件测试工作？

02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？
 
03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）

04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
 
05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

08. 您认为做好测试计划工作的关键是什么？

09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

10. 您认为做好测试用例设计工作的关键是什么？

11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。

13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
 
15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

16. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

17. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

18. 您以往是否曾经从事过单元测试和集成测试？如果有，请谈一下这些工作的实际开展情况。
 
19. 您如何看待软件过程改进？在您曾经工作过的企业中，是否有一些需要改进的东西呢？您期望的理想的测试人员的工作环境是怎样的？

20. 您以往工作过的企业中，是否开展了软件配置管理工作？您能否描述一下这项工作的开展情况和您对这项工作的认识？
 
21. 您是否熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP。如果熟悉，您是否可以谈一下对这些方法论和思想的认识？

22. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
 
23. 在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

24. 在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

一、判断题（每题1分，12 分，正确的√，错误的╳）
1．软件测试的目的是尽可能多的找出软件的缺陷。（）
2．Beta 测试是验收测试的一种。（）
3．验收测试是由最终用户来实施的。（）
4．项目立项前测试人员不需要提交任何工件。（）
5．单元测试能发现约80%的软件缺陷。（）
6．代码评审是检查源代码是否达到模块设计的要求。（）
7．自底向上集成需要测试员编写驱动程序。（）
8．负载测试是验证要检验的系统的能力最高能达到什么程度。（）
9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（）
10．代码评审员一般由测试员担任。（）
11．我们可以人为的使得软件不存在配置问题。（）
12．集成测试计划在需求分析阶段末提交。（）
二、不定项选择题（每题2 分，10分）
1．软件验收测试的合格通过准则是：（）
A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
B． 所有测试项没有残余一级、二级和三级错误。
C． 立项审批表、需求分析文档、设计文档和编码实现一致。
D． 验收测试工件齐全。
2．软件测试计划评审会需要哪些人员参加？（）
A．项目经理
B．SQA 负责人
C．配置负责人
D．测试组
3．下列关于alpha 测试的描述中正确的是：（）
A．alpha 测试需要用户代表参加
B．alpha 测试不需要用户代表参加
C．alpha 测试是系统测试的一种
D．alpha 测试是验收测试的一种
4．测试设计员的职责有：（）
A．制定测试计划
B．设计测试用例
C．设计测试过程、脚本
D．评估测试活动
5．软件实施活动的进入准则是：（）
A．需求工件已经被基线化
B．详细设计工件已经被基线化
C．构架工件已经被基线化
D．项目阶段成果已经被基线化
三、填空题（每空1分，24 分）
1．软件验收测试包括、、三种类型。
2．系统测试的策略有功能测试、、、、易用性测
试、、、、、、、、
、、等15 种方法。
3．设计系统测试计划需要参考的项目文档有、和迭代计划。
4．对面向过程的系统采用的集成策略有、两种。
5．通过画因果图来写测试用例的步骤为、、、及把因果图转
换为状态图共五个步骤。

四、简答题（共37分）
1． 阶段评审与同行评审的区别。（4 分）
2 ． 什么是软件测试。（3 分）
3 ． 简述集成测试的过程。（5 分）
4 ． 怎样做好文档测试？（4 分）
5． 白盒测试有那几种方法？（6 分）
6． 系统测试计划是否需要同行评审，为什么？（4 分）
7． Alpha 测试与beta 测试的区别。（4 分）
8 ． 比较负载测试、容量测试和强度测试的区别。（6 分）
9 ． 测试结束的标准是什么？（3 分）
五、 设计题（共15分） 
对下面给出的程序控制图，分别以各种不同的测试方法写出最少的测试用例。 

测试人员_考试试卷（考试时间100分钟，满分100分） 
姓名：__________部门：__________员工号：__________ 
一、填空题：（每一空格2分，共60分） 
1、 软件实施活动的输出工件有 、 、 、 。 
2、 代码评审主要做 工作。 
3、 软件实施活动中集成员的职责是 。 
4、 验证与确认软件实施活动主要有 、代码评审、 、 、 、SQA 
验证。 
5、 表明测试已经结束。 
6、 软件测试的目的是 。 
7、 软件测试主要分为 、 、 、 四类测试。 
8、 软件测试活动有制定测试计划、 、 、 、 、 、测
试评估、测试结束八个步骤。 
9、 软件测试活动的输出工件有_ 、 、 、 、 。 
10、软件测试角色有 、 、 、 。 
二、不定项选择题：（每题3 分，共15分） 
1、 软件实施活动的进入准则是（） 
A、 需求工件已经被基线化 
B、 详细设计工件已经被基线化 
C、 构架工件已经被基线化 
D、 项目阶段成果已经被基线化 
2、 下面角色不属于集成计划评审的是（） 
A、 配置经理 
B、 项目经理 
C、 测试员 
D、 编码员 
3、软件测试设计活动主要有（） 
A、 工作量分析 
B、 确定并说明测试用例 
C、 确立并结构化测试过程 
D、 复审并评估测试覆盖 
4、不属于集成测试步骤的是（） 
A、 制定集成计划 
B、 执行集成测试 
C、 记录集成测试结果 
D、 回归测试 
5、属于软件测试活动的输入工件的是（） 
A、 软件工作版本 
B、 可测试性报告 
C、 软件需求工件 
D、 软件项目计划 
三、问答题：（共25 分） 
1、 项目的集中管理在软件公司的哪一个层面？（2 分） 
2、 请描述软件测试活动的生命周期。（8 分） 
3、 什么是测试评估，测试评估的范围是什么？（5 分） 
4、 阐述工作版本的定义。（2 分） 
5 、 请画出软件测试活动的流程图。（8 分） 

测试人员考试试卷（考试时间90分钟，满分100分） 
姓名：__________部门：__________员工号：__________ 
一、 判断题（每题2分,正确的“√”，错误的“╳”） 
1 、 好的测试员不懈追求完美。( ) 
2、 测试程序仅仅按预期方式运行就行了。( ) 
3、 不存在质量很高但可靠性很差的产品。( ) 
4、 软件测试员可以对产品说明书进行白盒测试。( ) 
5、 静态白盒测试可以找出遗漏之处和问题。( ) 
6、 总是首先设计白盒测试用例。( ) 
7、 可以发布具有配置缺陷的软件产品。( ) 
8、 所有软件必须进行某种程度的兼容性测试。( ) 
9、 所有软件都有一个用户界面，因此必须测试易用性。( ) 
10、 测试组负责软件质量。( ) 
二、 简答题 
1、 软件的缺陷等级应如何划分？（3 分） 
2、 如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？（5 分） 
3、 你认为一个优秀的测试工程师应该具备哪些素质？（3 分） 
4、 产品测试到什么时候就算是足够了？（2 分） 
5、 测试计划的目的是什么？（2 分） 
6、 为什么要进行软件测试?软件测试的目的是什么? （5 分） 
7、 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？（5 分） 
8、 如何做一名合格的测试人员？（3 分） 
9、 针对缺陷采取怎样的管理措施？（5 分） 
三、 专业词语解释（每题2 分） 
α测试: 
β测试: 
驱动模块: 
桩模块: 
白盒测试： 
静态测试： 
四、 选择题（每题2分） 
1.下面哪些属于动态分析( ) 
A． 代码覆盖率 
B． 模块功能检查 
C． 系统压力测试 
D． 程序数据流分析 
2.下面哪些属于静态分析( ) 
A、 代码规则检查 
B、 序结构分析 
C、 序复杂度分析 
D、 内存泄漏 
五、 设计题（10分） 
在三角形计算中，要求三角型的三个边长：A、B 和C。当三边不可能构成三角形时提示错误，可构成三角
形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等边三角形”。画出程
序流程图、控制流程图、找出基本测试路径 ,对此设计一个测试用例。 
六、 论述题 
1、 试叙述对一个软件项目测试的全过程。（10 分） 
2、 简述你对测试工作的认识过程、在以后的工作的一些建议。（6 分） 
3 、 述静态测试和动态测试的区别？（5 分） 

测试人员_考试试卷（考试时间100分钟，每题10 分，满分100分） 
姓名：__________部门：__________员工号：__________ 
1． 什么是软件测试，以及软件测试的意义？ 
2． 什么是软件测试静态分析，软件测试动态分析， 
3． 下面那些属于静态分析（） 
A、 编码规则检查 
B、 程序结构分析 
C、 程序复杂度分析 
D、 内存泄漏 
4． 下面那些属于动态分析（） 
A、 代码覆盖率 
B、 模块功能检查 
C、 系统压力测试 
D、 程序数据流分析 
5． 从测试技术角度，正确的选择是（），给出各自的含义？ 
A、 静态测试 
B、 黑盒测试 
C、 动态测试 
D、 白盒测试 
6． 从测试阶段角度，测试正确的顺序是（），同时给出所选择的正确策略含义和被测对象是什么？ 
A、 单元测试 
B、 集成测试 
C、 系统测试 
D、 确认测试 
7． 针对缺陷采取怎样的管理措施？ 
8． 在测试生命周期，测试过程分为几个阶段，以及各个阶段的含义？ 
9． 简要写出自己在理解的基础质上所认为引入测试管理的意义 
10． 在三角形计算中，要求三角型的三个边长：A、B 和C。当三边不可能构成三角形时提示错误， 
可构成三角形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等
边三角形”。画出程序流程图、控制流程图、计算圈复杂度V(g)，找出基本测试路径。