SQA到底是什么？

   一、 前言

　　在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教。

　　二、SQA的理论探索

　　2.1、过程的 认识

　　我们都知道一个项目的主要内容是：成本、进度、质量良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道 IBM的软件是以质量为最重要目标的，而微软的&ldquo足够好的软件&rdquo策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。

　　软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 &ldquo人、过程、技术&rdquo。首先要明确的是这三个因素中，人是第一位的。

　　现在许多实施 CMM的人员沉溺于CMM的理论过于强调&ldquo过程&rdquo，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。 &ldquoXP&rdquo中的一个思想&ldquo人比过程更重要&rdquo 是值得我们思考的。我个人的意见在进行过程改进中坚持&ldquo以人为本&rdquo，强调过程和人的和谐。

　　根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 &ldquo要保证项目不失败，我们应当更加关注管理&rdquo，注意这个事实没有说明另外一个问题&ldquo良好的管理可以保证项目的成功&rdquo。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。

　　如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个&ldquo评估标准&rdquo出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：

　　(1)质量重要

　　(2)规模较大

　　这是 CMM产生的原因。它引入了&ldquo全面质量管理&rdquo的思想，尤其侧重了&ldquo全面质量管理&rdquo中的&ldquo过程方法&rdquo，并且引入了&ldquo统计过程控制&rdquo的方法。可以说这两个思想是CMM背后的基础。

　　上面这些内容形成了我对软件过程地位、价值的基本理解在这个基础上我们可以引申讨论 SQA。

　　2.2、生产线的隐喻

　　如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。 SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。

　　抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 &ldquo决策、执行、反馈&rdquo三个重要方面。

　　QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

　　2.3、SQA和其他工作的组合

　　在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。

　　根据 hjhza 的意见&ldquo中国现在基本有三种QA(按照工作重点不同来分)：一是过程改进型，一是配置管理型，一是测试型&rdquo。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。

　　下面根据本人经验对它们之间的关系进行一个说明。

　　2.4、QA和QC

　　两者基本职责

　　QC：检验产品的质量，保证产品符合客户的需求是产品质量检查者

　　QA：审计过程的质量，保证过程被正确执行是过程质量审计者

　　注意区别检查和审计的不同

　　检查：就是我们常说的找茬，是挑毛病的

　　审计：来确认项目按照要求进行的证据仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了&ldquo证实&rdquo，审计的内容主要是过程的对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

　　对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。

　　在这样的分工原则下， QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有而QC来检查产品是否符合质量要求。

　　如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

　　2.5、QA和SEPG

　　两者基本职责

　　SEPG：制定过程，实施过程改进

　　QA： 确保过程被正确执行

　　SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。

　　QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。

　　如果企业的 SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。

　　管理过程比较成熟的企业，因为企业的文化和管理机制已经健全， SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。

　　另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的 SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。

　　这种情况在许多 CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛!

　　2.6、QA和组织级的监督管理

　　有的企业为了更好的监督管理项目，建立了一个角色，我取名为 &ldquo组织级的监督管理者&rdquo，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。

　　为了有效管理项目， &ldquo组织级的监督管理者&rdquo必须分析项目的数据。

　　他们的职责对照上图的模型，就是执行 &ldquo反馈&rdquo职能。

　　QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。

　　SQA职责最好不要和&ldquo组织级的项目管理者&rdquo的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。

　　如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理而 QA来确保这个管理过程的运行。

　　三、SQA的工作内容和工作方法

　　3.1、 计划

　　针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：

　　有重点：依据企业目标以及项目情况确定审计的重点

　　明确审计内容：明确审计哪些活动，那些产品

　　明确审计方式：确定怎样进行审计

　　明确审计结果报告的规则：审计的结果报告给谁

　　3.2、审计/证实

　　依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。

　　注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。

　　审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

　　3.3、问题跟踪

　　对审计中发现的问题，要求项目组改进，并跟进直到解决。

　　四、SQA的素质

　　过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。

　　服务精神：为项目组服务，帮助项目组确保正确执行过程

　　了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识

　　了解开发：对开发工作的基本情况了解，能够理解项目的活动

　　沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

改进型组织-过程改进组织最佳实践

改进型组织是一个平衡发展的组织，它由业务线、流程线、QA线、IT线、协调线共五线组成，简称五线谱组织。业务线：负责产品质量、过程质量、为执行负责；流程线：负责流程质量，为优化流程负责；QA线：负责识别流程执行偏差，提供执行的第三方可视性，为流程可视性负责；IT线：负责流程的IT化质量，为流程高效负责；协调线：负责业务线、流程线、QA线、IT线的平衡发展，负责他们协同工作，为协同、平衡负责。

企业发展的初期，一般由业务线、IT线、协调线构成，IT线的工作一般是维护日常办公，确保其他人员正常工作，协调线由一把手亲自挂帅，业务线为企业赚取合法的利润，推动公司的进一步发展。这时候的企业我们一般叫人治期的企业，依靠老板的&lsquo人治&rsquo进行管理，因为人少，人治期管理往往高效，否则无法度过人治期。

度过人治期的企业，规模越来越大，依靠人的管理已经不能适应企业发展的当前需求，因为随着人员的增加，沟通成本在上升，组织效率在下降，这时需要从&lsquo人治&rsquo走向&lsquo法治&rsquo，需要把组织中的骨干人员的工作经验，沉淀到公司的流程制度中，形成&lsquo牛路&rsquo，在组织内进行推广，建设成&lsquo高速公路&rsquo。高速公路建成后还需要寻找到一条能用数据证明成功的改进之路。本阶段的企业我们称为法治期企业。法治期的企业需要建立流程线、QA线，强化IT线、协调线。我国的法治建设还有很长的路要走，不仅仅是制度的缺失，更重要的是制度的执行，所以温总理说：&ldquo遇上一个好总理，不如有一个好制度&rdquo。遇上好总理救了一个白血病患儿，如果有一个好的白血病儿的救助制度，挽救的则是上万人的宝贵生命。我不妨补充一句：&ldquo一个好制度需要一个好机制才能得到执行&rdquo，改进型组织就是一个好机制运行的最佳实践。

国内很多企业在从人治走向法治的过程中往往忽略流程线、QA线的人员建设。

比如有的直接导入ERP，造成&ldquo不上ERP等死，上ERP找死&rdquo。就其原因，不是ERP本身不好，而是方法不对。ERP的本质就是企业供应链流程的载体，导入ERP需要梳理供应链流程，需要流程线的人员，流程梳理后需要有人去识别流程的执行情况，需要QA人员。如果我们忽略流程线、QA线的队伍建设，强行把供应链的流程固化到ERP软件，短期看的确可能提升了效率，从长远看，组织流程优化的效率被降低了。

有的企业在引入ISO9000，CMMI、IPD、6sigma的过程中，常常造成&ldquo流程和执行两张皮&rdquo，他们把过程改进等同于引入先进的流程、照搬模型或标准，囫囵吞枣，忽略流程线、QA线人员建设，反反复复折腾3、5年，还是发现流程无法有效执行。他们急于看到过程改进的效果，结果总是&ldquo欲速则不达&rdquo。就其根源，还是在于忽略了五条线（业务线、流程线、QA线、IT线、协调线）的平衡发展。

所以我们说，良好的改进型组织是一个业务线、流程线、QA线、IT线、协调线平衡发展的组织。

改进组织：

过程改进必须以项目方式来进行，需要规划好每期项目的目标和范围，规划项目的过程就是&lsquo开发正确的产品&rsquo，为过程改进项目提供正确的方向，规划过程改进的组织一般叫做管理导航组，职能类似于产品经理（规划出合适的产品，以满足客户的需要）。

    过程改进项目是一个执行主体，主要任务是完成项目目标，正确地开发产品。

       业务线

业务线的职责是正确的执行流程，为客户提供优质产品，为企业赢利。业务线就是一个传统的公司，包含市场营销、研发部、生产、采购、计划部、技术支持部、客服部、财务部、人事部、行政部等。

随公司的发展，流程线、QA线的增加，IT线、协调线的强化，公司发展成为一个改进型的组织机构。

矩阵结构是业务线的常见运行模式，业务线由资源线、项目线构成，项目线以项目为单位进行管理，每个资源向资源线、项目线的领导同时汇报。

梳理项目线的工作是企业流程改进主要工作。资源线的工作是基础，项目线是工作效率的直接体现。为平衡资源线与项目线的职责划分，部分公司把平台建设划归资源线负责。一般地：例行工作划归部门工作，项目工作划归项目线工作。

     流程线

流程线的职责是定义或优化公司流程，流程线的人员组成由专职EPG和兼职EPG组成，专职EPG来自过程管理部，其擅长领域一般有：过程改进、CMMI、IPD、ISO9000、6sigma等。兼职EPG则根据改进项目的覆盖范围来自相应的部门。兼职人员需要选择骨干人员，形成公司的&lsquo牛路&rsquo，代表公司的高效的工作方式。

       识别牛路，将骨干的知识经验沉淀到公司的流程，通过培训、试点、推广建设成公司的&ldquo高速公路&rdquo是过程改进的基础工作。

QMS质量文件体系

       我们把流程线发布的所有流程的集合叫QMS质量文件体系，QMS质量文件体系包含架构和若干个过程，每个过程由过程定义、规范（可选）、标准（可选）、培训教材、记录文件组成，记录文件一般有模板、表格、过程检查单、产品检查单；

QMS架构

架构包含QMS概貌图、研发管理流程、供应链管理流程、项目管理流程、文件体系。

过程开发步骤

1.         由骨干与专职EPG形成初稿，然后向EPG Leader 提交评审申请；

2.         EPG Leader 审核流程初稿，审核通过后安排评审计划，确定参加评审的人员、时间、地点、分工等；

3.         评审人员进行预审，根据个人经验和检查单识别可能的缺陷；

4.         通过会议识别正式的缺陷，必要时讨论修复措施，修复并验证缺陷；

5.         评审关闭后形成正式的工作产品，纳入受控库，打上基线标签；

6.         将基线后的工作产品交业务线客户代表进行统一验收，验收通过后进行统一发布。流程发布一定要注意频率，建议在半年以上。

过程资产库PAL

公司资产库一般作为流程线对外的窗口，资产库内容一般包含QMS质量体系文件、公司最佳实践、度量库（过程能力、过程目标等），资产库一般也提供过程改进建议的收集，发布过程改进项目的最新状态和最新规划。

过程资产库需要在项目的执行过程中得到不断的优化。

建立统一的发布窗口，做好流程线发布流程的受控管理，前者方便流程执行者，后者方便流程线自己。

     QA线

QA的工作主要是产品过程审计、流程过程审计，引导流程的工作由EPG、兼职EPG完成，QA工作需要保持独立性，以第三方（独立于流程线、业务线之外）的声音识别流程执行的偏差，为管理层充当第三只眼睛和耳朵。QA既不能把关项目的过程质量，也不能把关项目的产品质量，产品质量和过程质量都是业务线的职责。

    很多公司因为过程审计没有为项目带来价值从而否认QA价值，让QA去组织技术评审，收集度量数据，参加项目的技术文档评审，QA的工作重心已经发生了偏离，流程的执行情况被掩盖，导致几年之后流程还是无法落地，这与QA的声音不响亮有很大关系。

    质量领域没有超人，我们不能把QA假定为一个超人去期望QA解决所有的质量问题，只有一个组织分工合理、职责清晰、和谐运作、全员努力，才能解决公司的质量问题。这就是真正意义的全面质量管理。

跟多家企业的很多部门经理和主管接触，听到较多的感慨是人太难管理了，很多紧急的事情没人干，有些工作又多个部门在抢着干，信息的沟通总觉得不畅通。到底是哪里出了问题？是人的素质不够吗？这使我想起韩永生教授在雅戈尔讲过的一个历史上的真实故事。

l770年，J.库克船长带领船队来到澳洲，随即英国政府宣布澳洲为它的领地。为开发澳洲，英国政府把判了刑的罪犯向澳洲运送，这样不但解决了英国监狱人满为患的问题，而且给澳洲送去了丰富的劳动力。运送罪犯的工作则由私人船主承包。

当时英国私人船主提供的条件很差，船上拥挤不堪，营养与卫生条件极差，死亡率高。据英国历史学家查理.巴恃森写的《犯人船》记载，1790年到1792年间，私人船主运送犯人到澳洲的26艘船共4080名犯人，死亡为498人，平均死亡率为20％。其中一艘名为&ldquo海神号&rdquo的船，420个犯人死了158人，死亡率高达37％。这么高的死亡率不仅经济上损失巨大，而且在道义上引起社会强烈的谴责。如何解决这个问题呢？

其中想到的一种做法是依靠人性的改善，进行道德说教，让私人船主良心发现，改恶从善，不图私利，为罪犯创造更好的生活条件。但在人们为了巨额利润而敢上断头台的时代里，企图以说教来改变人性，无异于缘木求鱼。私人船主敢于乘风破浪，冒死亡的风险把罪犯送往澳洲就是为了暴利。他们尽量多装人，给最坏的饮食条件，以降低成本增加利润，看来都是无可厚非的理性行为。而且，私人船主之间也存在竞争，大家都在拼命压低成本，谁要大发善心，恐怕在激烈的竞争中无法生存下去。在这种情况下，要把运送罪犯死亡率的下降寄希望于人的善良是毫无用处的。

另一种做法是由政府进行干预，通过监控强迫私人船主富有人性地做事。由政府以法律形式规定最低伙食和医疗标准，并由政府派官员到船上负责监督实施这些规定。这种做法成本很高，要派官员到运送罪犯的船上去执法，是一件带有风险的苦差事，不给高薪没人肯干。但有了这些官员，罪犯的待遇并没有根本改善。往往秉公执法的官员也被船主迫害致死，而一些见风使舵的官员最后和船主同流合污。

多年后终于找到了一种简单易行的制度：政府不再按上船时运送的罪犯人数付费，而按下船时实际到达澳洲的罪犯人数付费，路上犯人死亡还要罚款。当按上船时的人数付费时，船主拼命多装人，而且，不给罪犯吃饱，把省下来的食物在澳洲卖掉再赚一笔，至于有多少人能活着到澳洲与船主无关。当按实际到达澳洲的人数付费时，能运送到多少人对船主至关重要。这时船主就不想方设法多装人了。要多给每个人一点生存空间，要保证他们在长时间海上生活后仍能活下来，要让他们吃饱，还要配备医生，带足常用药。罪犯是船主的财源，当然不能虐待了，这正如牧羊人不会虐待自己的羊一样。这种按到澳洲的人数和这些人的健康状况支付费用的制度实施后，罪犯的死亡率大大下降，效果立竿见影。

私人船主的人性没变，政府也不用去立法或监督，只是改变一下流程和付费制度，一切就都解决了。这正是强调流程和制度的原因。有位名人曾经说过，一种坏的制度会使好人做坏事，而&mdash种好的制度会使坏人也做好事。制度并不是要改变人的本性，而是要引导员工做有利于公司整体利益的事。

其实，每位员工都好比一粒铁粉，之所以没有调动起他们的积极性，是因为没有吸引他们的磁场！在无磁场的空间，他们就是一盘散沙，无序、散乱，然而一旦放入磁铁，他们就聚集成规则有序的形状，跟着磁铁行动。这里的磁铁就是企业的流程和制度体系。

战略用远景和价值观聚集人心，吸引志同道合者共同奋斗；流程则为到达战略目标铺设输油管道和高速公路；制度是保证管道和道路畅通的规则和处罚措施，谁违反这些规则导致流程不畅通，谁就得到制裁。人性只能用制度引导，而不能靠说教改变。

因此，当我们在管理上发现问题的时候，先想一想为什么会出这样的问题？是不是现有流程、制度方面的缺陷引诱员工出这样的问题？如何改进流程和制度才能预防这类问题的产生？当公司鼓励所有员工都可以提交类似的合理化建议，并得到公司奖励的时候，内部自我适应的流程优化机制就建立起来了，这种自我优化的力量才是最强大的力量。

最近正在学习测试管理方面的知识，从图书馆借来一本新出的书，决定将学到的知识记录下来。

1、管理就是负责任，测试管理就是对一个测试小组负责，对一个个的测试项目负责，有了责任意识，我们才能做好测试管理工作。

2、从技术角色转到管理角色的风险

一般从测试工程晋升到测试组长，是从一个技术角色转换到技术加管理的角色，其中才能在一些风险。

（1）       领导意识薄弱。

作为测试工程师，“自己做好，其他不管”是可以，但作为测试组长公对公，就事论事，如果你不去督促，就是你失职。

（2）       沟通不够。

测试组长要与开发小组保持沟通，以得到真实的开发进度，了解需求和开发文档上没有写道的内容，以及他们对测试工作的反馈。测试组长要和直接领导保持沟通，还可以和公司的其他部门保持沟通，及时了解尽可能多的信息。

（3）       视野狭窄。

测试组长不能只站在测试工程师的立场上，以纯技术的角度来看问题，要站在一个高度，放宽视野，了解公司的发展规划和近期策略，了解公司所专注行业的发展情况，了解测试技术和测试管理的发展情况，了解项目的意义和规划。

3、要熟悉项目、熟悉团队中的每一个人，把合适的人放在合适的位置上。

4、让你的领导及时知道你在干什么，定期主动与上级领导汇报工作进行沟通，方式不限。

5、记录自己的体会

6、积极的状态就是一个好的开始，只有积极的员工才会受到认同和青睐。

7、测试组长要愿意付出，心态好，不能斤斤计较。

8、人品要好，否则做不长久。

9、对领导或客户的安排，要从自己的角度提出自己的看法。要注意提出看法的方式和时机。不要让人反感。

10、测试工作中，确定一个正式的工作流程很重要。

11、不要轻易的解雇一个人，要弄清楚问题出在什么地方再做决定。

12、要学会换位思考。

面向对象程序是把功能的实现分布在类中。能正确实现功能的类，通过消息传递来协同实现设计要求的功能。正是这种面向对象程序风格，将出现的错误能精确地确定在某一具体的类。

因此，忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格上，主要体现在两个方面：

1、数据成员是否满足数据封装的要求。

数据封装是数据和数据有关的操作的集合。检查数据成员是否满足数据封装的要求，基本原则是数据成员是否被外界（数据成员所属的类或子类以外的调用）直接调用。当改变数据成员结构时，是否影响了类的对外接口，是否会导致相应的外界必须改动。有时强制的类型转换会破坏数据的封装性；

2、类是否实现了要求的功能。

类所实现的功能都是通过类的成员函数执行的，应改首先保证类成员函数的正确性。在单元测试中去验证类成员函数的正确性。类成员函数的正确行为只是类能够实现要求的功能的基础，类成员函数间的作用和类之间的服务调用是单元测试无法确定的，需要进行集成测试，还要检测类提供的功能是否满足设计的要求；

39、软件风险分析

风险分析是对潜在的问题识别和评估的过程，即对测试的对象进行优先级划分；包括两部分：

（1）       发生问题的可能性

（2）       影响严重性

40、测试用例划分-等价类划分

等价类划分为两种情况：有效等价类和无效等价类。

有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的继承。利用有效等价类用来检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效类相反。

41、确定等价类的原则：

（１）在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类；

（２）在输入条件规定了输入值的集合或规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。

（３）在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类；

（４）在规定了输入数据的一组值(n个)，并且程序要对每一个输入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类；

(5)在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

（６）在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类；

42、测试用例划分-边界值分析法

（1）边界条件

（2）次边界条件

43、因果图设计方法

因果图法是从用自软语言书写的程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。

利用因果图设计测试用例的方法：

(1)               分析程序规格说明的描述，原因常常是输入条件或是输入条件的等价类，而结果是输出条件。

(2)               分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的‘因果图’。

(3)               表明约束条件。在因果图上使用若干个标准的符号标明约束条件。

(4)               把因果图转换成判定表。

(5)               为判定表中的每一列表示的情况设计测试用例。

44、因果图表示方法

通常在因果图中，用C_i表示愿应，E_i表示结果。各节点表示状态，“1”表示出现，“0” 表示不出现；

恒等：若原因出现，则结果出现，若原因不出现，则结果不出现；

非：（~）若原因出现，则结果不出现，若原因不出现，则结果出现；

或(∨)：若几个原因中有1个出现，则结果出现，若几个原因都不出现，则结果不出现；

与(∧):若几个原因都出现，结果才出现，若其中有1个原因不出现，则结果不出现；

   原因与原因，结果结果之间的约束条件：

E(互斥)：表示两个原因不会同时成立，两个中最多有一个成立；

I(包含)：表示3个原因中至少有一个必须成立；

O(唯一)：表示两个原因中必须有一个，且仅有一个成立；

R(要求):表示a出现时，b必须也出现，a出现时不可能b不出现；

M(屏蔽):表示当a是1时，b必须是0，而当a为0时，b的值不定；

45、判定表驱动法

判定表由四部分组成：

（1）       条件桩：列出了问题的所有条件。

（2）       动作桩：列出了问题规定可能采取的操作。

（3）       条件项：列出了针对它所有列条件的取值，在所有可能情况下的真假值。

（4）       动作项：列出在条件项的各种取值情况下应该采取的动作。

（5）       规则：任何一个条件组合的特定取值及其相应要执行的操作。

适合使用判定表设计测试用例的条件：

（1）       规格说明以判定表的形式给出，或很容易转换成判定表；

（2）       条件的排列顺序不影响执行哪些操作；

（3）       规则的排列顺序不影响执行那些操作；

（4）       当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；

（5）       如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

46、功能图法

一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。

功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构型。

47、测试方法选择的综合策略

（1）进行等价类划分，包括输入条件和输出条件的等价划分。

（2）在任何情况下都必须使用边界值分析方法。

（3）可以用错误推断法追加一些测试用例，这需要靠经验和智慧。

（4）对照程序逻辑，检查自己设计出的测试用例的逻辑覆盖程度。如果没有达到要求，则补充足够的测试用例。

（5）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定驱动法。

（6）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

（7）功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

（8）对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

主动思考，积极行动；

一开始就牢记目标，不迷失方向；

重要的事情放在首位；

先理解人，后被人理解；

寻求双赢；

互相合作，追求1+1>2；

终生学习，自我更新，不断进步；

32、ISO9126质量模型

功能性：适合性，准确性，互操作性，依从性，安全性；

可靠性：成熟性，容错性，意恢复性；

意使用性：易理解性，易学习性，易操作性

效率：时间特性，资源特性；

可维护性：易分析性，易更改性，稳定性，易测试性；

可移植性：适应性，易安装性，一致性，易替换性；

33、质量途径

过程质量有助于提高产品质量，而提高产品质量有助于提高使用质量。因此，评估和改善过程是提高产品质量的一种手段，而评价和改进产品质量是提高使用质量的一种方法。

34、软件产品质量需求包括内部质量、外部质量和使用质量。

35、外部质量和内部质量的质量模型

1、功能性

适合性；准备确性；互操作性；保密安全；功能性依从性。

2、可靠性

成熟性；容错性；易恢复性；可靠性依从性。

3、易用性

易理解性；易学性；易操作性；吸引性；易用性依从性。

4、效率

时间特性；资源利用性；效率依从性。

5、维护性

易分析性；易改变性；稳定性；易测试性；维护性依从性。

6、可移植性

适应性；易安装性；共存性；易替换性；可移植性依从性。

36、使用质量的质量模型

有效性；生产率；安全性；满意度。

37、测试组织管理者必须具备

理解与评价软件测试政策、标准、过程、工具、培训和度量的能力；

领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范没有偏见；

吸引并留住杰出测试专业人才的能力；

领导、沟通、支持和控制的能力；

测试时间、质量和成本控制的能力；

38、测试人员的选择

一般能力：表达，交流，协调，管理，质量意识，过程方法，软件工程等；

测试技能及方法：测试基本概念及方法，测试工具及环境，专业测试标准，工作成绩评估等；

测试规划能力：包括风险分析及防范，软件放行/接收准则制定，测试目标及计划，测试计划和设计的评审方法等；

测试分析，报告贺改进能力：包括测试度量，统计技术，测试报告，过程检测及持续改进。

15、集成测试组装时要考虑的问题?

也叫组装测试或联合测试；

1.       在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2.       一个功能模块是否会对另一个功能模块产生不利影响；

3.       各个子功能模块累计起来，能否达到预期的父功能；

4.       全局数据结构是否有问题；

5.       单个模块的误差是否会累计放大；

16、部件测试

子系统的集成测试成为部件测试。是检查组装后子系统与系统需求的不一致。

17、模块组装为系统的方式有两种？

1．一次性组装方式(big bang)

2．增值式组装方式：自顶向下（深度优先或广度优先的策略进行测试），自底向上，混合增值。

18、集成测试应当确定关键模块

在集成测试时应当对关键模块进行及早的测试，关键模块的特征如下：满足某些软件需求；在程序模块中位于较高的层次（高层控制模块）；较复杂、较易发生错误；有明确定义的性能要求。

19、集成测试的组织和实施

制定集成测试计划时应该考虑如下因素：采用何种系统组装方法来进行集成测试；集成测试过程中连接各个模块的顺序；模块代码编制和测试进度是否与集成测试的顺序一致；测试过程中是否需要专门的硬件设备。

20、软件实效分类

软件错误(software error)：是一种人为的错误，导致软件缺陷的产生；

软件缺陷(software defect)：软件缺陷是存在于软件之中的不希望或不可接受的偏差，其结果是使软件运行于某一特定条件时出现软件故障，这个时候软件缺陷被激活；

软件故障(software fault)：是指软件运行过程中出现的一种不希望或不可接受的内部状态。如无适当处理便产生软件失效。软件故障是一种动态行为；

软件失效(software failure)：是软件运行时产生的一种不希望或不可接受的外部行为结果；

软件实效机理：软件错误-软件缺陷-软件故障-软件失效；

21、失效强度

失效强度表示每个自然单元出现的失效数目；是表示可靠性的另一种形式；

22、错误与缺陷的分布

需求：56%；设计：27%；代码：7%；其他：10%；

23、自动化测试的优势

1．提高测试质量

2．提高测试效率

3．提高测试覆盖率

4．执行手工测试不能完成的测试任务

5．更好的重现软件缺陷的能力

6．更好的利用资源

7．增进测试人员与开发人员之间的合作伙伴关系

24、适合使用自动化测试工具的环境

1．需要反复进行的工作

2．负载压力测试

3．公司有大量的测试人员和开发人员

4．如果需要进行测试系统后台或者内部的性能特性，进而进行故障定位和性能调优。

25、自动化测试工具的局限性不适用于

1、定制的项目

2、周期很短的项目

3、业务规则复杂的对象

4、人体感观与易用性测试

5、不稳定的软件

6、涉及物理交互

26、自动化测试应用策略

1．提高测试质量

2．减少测试过程中的重复劳动

3．实现自动化，解决手工测试不能解决的问题

4．选择合适的自动化测试工具

5．确定测试工具的应用时机

6．确定测试重点

7．确定测试目标和指标

8．充分利用测试工具的优势

9．加强对测试工程师的技能培训，测试工具的使用者必须对测试工具非常了解

27、功能自动化测试工具的两种录制模式

1．环境判断模式：根据你选取得图形用户界面对象，把你对软件的操作动作录制下来，并忽略这些对象在屏幕上的物理位置。

2．模拟模式：记录鼠标点击、键盘输入和鼠标在二维平面图上的精确运动轨迹。

28、负载压力测试

负载测试：是为了证明在与产品规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明书中规定的，可接受的响应时间一致的测试过程。

压力测试：是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时出现中断，即识别系统的薄弱环节。压力测试中可能暴露的系统缺陷有内存缺陷，系统资源过量消耗、磁盘空间用完等。

29、进行脚本录制与分配的过程中，应该遵循

１．脚本越小越好，尽量做到一个功能一个脚本。

２．选择负载压力最高的业务功能进行测试。

３．选择所需要的操作进行录制。

30、测试工具模拟多用户并发访问有两种方式

１．进程回放模式：客户端与服务器的访问采用进程方式，每一个虚拟用户通过一个进程建立与服务器的通信连接并访问。

２．线程回放模式：客户端与服务器的访问采用线程方式，每一个虚拟用户通过一个线程建立与服务器的通信连接并访问。

31、录制脚本的回访模式的步骤

１．协议选择

２．创建测试脚本

３．参数化测试数据

４．创建虚拟用户

５．执行测试

６．分析测试