《软件工程》教学辅导8——软件质量与质量保证5篇

第一篇：《软件工程》教学辅导8——软件质量与质量保证

《软件工程》教学辅导8——软件质量与质量保证

第八章 软件质量与质量保证

一、软件质量的定义

软件质量反映了以下三方面的问题。

1．软件需求是度量软件质量的基础，不符合需求的软件就不具备质量。

2．在各种标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。

3．往往会有一些隐含的需求没有明确地提出来。如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求，软件质量也不能保证。

二、影响软件质量的因素

1．影响软件质量的主要因素

2．软件质量讨论评价应遵守的原则

三、软件质量保证策略

为了在软件开发过程中保证软件的质量，主要采取下述措施：

1．审查

2．复查和管理复审

3．测试

四、软件质量保证活动

1．验证与确认

2．开发时期的配置管理

五、软件评审

通常，把质量定义为用户的满意程度。为使得用户满意，有两个必要条件：

（1）设计的规格说明要符合用户的要求；

（2）程序要按照设计规格说明所规定的情况正确执行。

设计质量的评审内容

程序质量的评审内容

1．软件的结构

2．与运行环境的接口

六、软件质量保证的标准

1．ISO质量保证模型

2．ISO 9001标准

七、结构化的软件测试

软件测试在程序员对每一个模块的编码之后先做程序测试，再做单元测试，然后再进行集成（综合或组装）测试，系统测试，验收（确认）测试，平行测试，人工测试，其中单元测试的一部分己在编码阶段就开始了，测试横跨开发与测试两个阶段，又有不同的人员参加，测试工作本身是复杂的。

据统计测试工作量要占软件开发总成本的40％到50％以上。

测试的目的是确保软件的质量，尽量找出软件错误并加以纠正，而不是证明软件没有错。

测试的范围是整个软件的生存周期，而不限于程序编码阶段。

软件测试的概念和原则

1、测试的概念

（1）软件测试

软件测试是对软件计划、软件设计、软件编码进行查错和纠错的活动（包括代码执行活动与人工活动）。

（2）程序测试

程序测试是早已流行的概念。它是对编码阶段的语法错、语义错、运行错进行查找的编码执行活动。找出编码中错误的代码执行活动称程序测试。纠正编码中的错误的执行活动称程序调试。通过查找编码错与纠正编码错来保证算法的正确实现。

（3）软件确认与程序确认

软件确认是广义上的软件测试，它是企图证明程序软件在给定的外部环境中的逻辑正确性的一系列活动和过程，指需求说明书的确认，程序的确认。程序确认又分成静态确认与动态确认。静态确认包括，正确性证明，人工分析，静态分析。动态分析包括动态确认与动态测试。

①静态分析是不执行程序本身，分析程序正文可能导致错误的异常情况。可以人工的进行分析，也可以用测试工具静态分析程序来进行，被测试程序的正文做为输入，经静态分析程序分析得出分析结果。静态分析包括结构检查，流图分析，符号执行。

②动态分析是执行被测程序，从执行结果分析程序可能出现的错误。可以人工设计程序测试用例，也可以由测试工具动态分析程序来做检测与分析。动态测试包括功能测试和结构测试。动态测试的内容包括：单元测试，也称逻辑测试，模块测试，功能测试。组装测试也称集成测试，综合测试，或结构测试，子系统测试。系统测试是软硬件或子系统的组装测试。

（4）各种软件错误的出现比例

①功能错，占整个软件错误27％，是需求分析设计不完整而引起的。

②系统错，占整个软件错误16％，是总体设计错误而引起的。

③数据错，占整个软件错误10％，由编码错误引起的。

④编码错，占整个软件错误4％，程序员编码错误引起的。

⑤其它错，占整个软件错误16％，由文档错和硬件错所引起的。

2、测试过程

3、测试的原则

测试的原则如下：

（1）测试前要认定被测试软件有错，不要认为软件设有错。

（2）要预先确定被测试软件的测试结果。

（3）要尽量避免测试自己编写的程序。

（4）测试要兼顾合理输入与不合理输入数据。

（5）测试要以软件需求规格说明书为标准。

（6）要明确找到的新错与已找到的旧错成正比。

（7）测试是相对的，不能穷尽所有的测试，要据人力物力安排测试，并选择好测试用例与测试方法。

（8）测试用例留作测试报告与以后的反复测试用，重新验证纠错的程序是否有错。

软件测试技术

1.软件测试的目标

测试的目标：

（1）测试是为了发现程序中的错误而执行程序的过程；

（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

（3）成功的测试是发现了至今为止尚未发现的错误的测试。

2.测试方法

按照测试过程是否在实际应用环境中来分，有静态分析与动态测试。

测试方法有分析方法（包括静态分析法与白盒法）与非分析方法（称黑盒法）。白盒法是通过分析程序内部的逻辑与执行路线来设计测试用例，进行测试的方法，白盒法也称逻辑驱动方法。黑盒法是功能驱动方法，仅根据I/O数据条件来设计测试用例，而不管程序的内部结构与路径如何。白盒法的具体设计程序测试用例的方法有：语句覆盖、分支（判定）覆盖、条件覆盖、路径覆盖（或条件组合覆盖），主要目的是提高测试的覆盖率。黑盒法的具体设计程序测试用例的方法有：等价类划分法，边界值分析法，错误推测法，主要目的是设法以最少测试数据子集来尽可能多的测试软件程序的错误。

（1）静态分析技术

不执行被测软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。

（2）动态测试技术

当把程序作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。这样动态测试的算法有：

①选取定义域中的有效值，或定义域外无效值。

②对已选取值决定预期的结果。

③用选取值执行程序。

④观察程序行为，记录执行结果。

⑤将④的结果与②的结果相比较，不吻合则程序有错。

动态测试既可以采用白盒法对模块进行逻辑结构的测试，又可以用黑盒法做功能结枸的测试，接口的测试，都是以执行程序并分析执行结果来查错的。

（3）黑盒测试和白盒测试

①黑盒测试法

黑盒测试法把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息的完整性。黑盒测试又称为功能测试。

②白盒测试法

白盒测试法的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序的结构和处理过程。这种方法按照程序内部的逻辑测试程序，检验程序中的每条通路是否都能按预定要求正确工作，白盒测试又称为结构测试。

3.设计测试方案

（1）白盒法

①句覆盖

②判定覆盖

③条件覆盖

④判定／条件覆盖

⑤条件组合覆盖

⑥点覆盖

⑦边覆盖

⑧路径覆盖

这部分是本章的重点，要求掌握句覆盖、判定覆盖和条件覆盖，会做题。

（2）黑盒法

测试的步骤

软件纠错技术

八、面向对象的软件测试

九、软件测试计划与测试分析报告

十、软件维护

软件维护的定义、分类、特点

人们称在软件运行/维护阶段对软件产品所进行的修改就是维护。

1．结构化维护与非结构化维护的对比

2．维护的代价

3．维护的问题

软件维护步骤及组织

维护步骤

需要经历以下四个步骤。

（1）分析和理解程序

（2）修改程序

（3）重新验证程序

（4）维护组织

软件的可维护性

软件维护的副作用

逆向工程和再生工程

逆向工程与再生工程是目前预防性维护采用的主要技术，逆向工程术语源于硬件制造业，相互竞争的公司为了了解对方设计和制造工艺的机密，在得不到设计和制造说明书的情况下，通过拆卸实物获取信息，软件的逆项工程也基本类似，不过通常“解剖”的不仅是竞争对手的程序，而且还包括本公司多年前的产品，此时得不到设计“机密”的主要障碍是缺乏文档。因此，所谓软件的逆向工程就是分析已有的程序，寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生命周期内的，将软件某种形式的描述转换为更抽象形式的活动都可称为逆向工程。

第二篇：浅谈软件质量保证

浅谈软件质量保证

摘要：

Software Quality Assurance软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用

前言：

SQA的由来：随着第一个正式的质量保证和控制方案在1916年贝尔实验室的出现，整个制造业都认可了这一方案，时至今日每个公司都有其保证其产品质量的机制，公司对质量的保证也渐渐成为其核心的市场策略。对于软件开发来说，一个项目的主要内容是：成本、进度、质量。软件本身作为一种无形产品，其质量指的是：“系统,部件或者过程满足顾客或者用户需要或期望的程度”。在20世纪五六十年代，质量保证曾经只由程序员承担。而正规的软件质量保证标准首先在20世纪70年代初军方的软件合同中出现，此后迅速传遍整个商业世界。提出而随着市场化发展的成型，任何软件公司对自己产品的质量问题越来越关注，测试所花费的成本越来越多。在起初国外很多的大软件公司公司比如IBM、CA等，SQA的职责就是测试（主要是系统测试）。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少。另外由于软件最终使用者的不专业性，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，促进了事先预防的SQA职能的产生。随后随着软件开发模型的不断演化和发展CMM模型的出现，它引入了“全面质量管理”的思想，至此许多公司将SQA人员独立于项目组，以保证评价的客观性。专业的SQA人员应运而生。

简介：

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。其根本目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

SQA的基本目标：

1: 软件质量保证工作是有计划进行的。

2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。3: 将软件质量保证工作及结果通知给相关组别和个人。

4: 高级管理层接触到在项目内部不能解决的不符合类问题。

具体分析：

1：软件质量所包含的因素及软件质量评价标准：

软件质量包含的因素：正确性，可靠性，效率，完整性，可用性可维护

性，灵活性，可测试性，可移植性，可复用性，互操作性等等。

软件质量评价标准：质量需求准则，着眼点是是否满足用户的要求；质量设计准则，开发者在设计实现时是否按软件需求保证了质量。质量度量准则，为质量度量规定了一些检查项目。

从事专业SQA的人员所应具备的基本素质，工作中的基本职能及与其他相似职能的区别：

SQA人员所应具备的基本素质：

按照软件界已经达成的共识：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。SQA小组的成员首先应当时刻以客户的观点看待软件。从事SQA工作由于要按照相应的标准对专业的行为加以监管，深刻了解企业的工程，并具有一定的过程管理理论知识 对开发工作的基本情况了解，能够理解项目的活动，因此首先应具备较高的关于软件开发方面的知识；在工作中过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任；还应具有服务精神即为项目组服务，帮助项目组确保正确执行过程；另外应善于沟通，能够营造良好的气氛，避免其工作本身成为一种找茬活动。我所在的小组在课程实践过程中就出现过负责设计的同学对编码阶段的同学出现质疑，最终出现不愉快的事情。

工作中的基本职能以及于其他相似职能的区别：

要做好SQA工作首先应该明确SQA人员的职能以及与QC、SEPG的区别。QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者； SEPG：制定过程，实施过程改进；

而SQA人员的主要工作为审计过程的质量，是过程质量审计者，其基本职能为确保过程被正确执行。其本身并不参与过程的制定，A的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

3：SQA活动：

软件质量保证由各种任务构成，这些任务分别与两种不同的参与者有关：做设计工作的软件工程师和SQA小组成员。

软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制活动）

SQA小组成员的职责为辅助软件工程小组得到高质量的最终产品。其主要工作如下：

为项目准备SQA计划。该计划在制定项目计划实制定，由所以感兴趣的相关部门评审。该计划将控制由项目组和SQA小组执行的质量保证活动。在计划中应标识一下几点：需要进行的评价；需要进行的审计和评审；项目可用的标准；错误报告和跟踪的规程；由SQA小组产生的文档；为软件项目提供的反馈数量。另外还需明确最终审计的结果报告给谁。

参与开发该项目的软件过程描述。软件工程小组为要进行的工作选择一个过程。SQA将评审过程描述以保证该过程与组织政策，内部软件标准，外界所订标准（如ISO9001）以及软件项目计划的其他部分相符。

评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。SQA小组识别记录和跟踪与过量的偏差，并对是否已经改正进行核实。

审计指定的软件工作产品，对其是否符合定义好的软件过程中的相应部分进行核实。SQA小组对选出的产品进行评审；识别，记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。在审计过程中。注意审计一定要有项目组人员陪同，双方要开诚布公，坦诚相对。审计的内容主要包括：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理。偏差可能出现在项目计划，过程描述，采用的标准或技术工作产品中。

记录所有不符合的部分并报告给高级管理者。对不符合的部分进行跟踪直至问题得到解决。

4：软件评审：软件评审是软件工程过程中的过滤器。评审被用于软件开发过程的多个不同的点上，起到发现错误和缺陷节日引发排错活动的作用。软件评审起到的作用是净化分析，设计和编码的软件工程活动。在课程实践过程中由于初始需求分析的不明确以及后来概要设计过程中关键点的遗漏所引发的错误曾经导致我们小组代码的两次大部分返工，现在看来在课程实践过程中没有进行软件评审所致

5：正式技术评审（FTR）

正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。

正式技术评审的目标是：发现功能、逻辑或实现的错误；证实经过评审的软件的确满足需求；保证软件的表示符合预定义的标准；得到一种一致的方式开发的软件；使项目更易管理。

评审会议一般由3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个：工作产品可不可以不经修改而被接受；由于严重错误而否决工作产品；暂时接受工作产品。

评审总结报告和记录保存：评审会议结束时，生成一份评审问题列表，完成一份包括“评审什么？由谁评审？结论是什么？”的评审总结报告。

评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。

评审指导原则：评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松；制定日程并且遵守日程；不要离题，限制争论和辩驳。有异议的问题不要争论但要记录在案；对各个问题都发表见解。问题解决应该放到评审会议之后进行；做书面笔记；限制参与者的人数并坚持事先做准备；为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。；为了让评审有效，为FTR分配资源和时间；为了提高效益对所有评审进行有意义的培训；评审以前所做的评审。

6结合课程实践浅谈自己的感受

下面我将结合课程的实践讲一讲个人对于软件质量保证的一些感受，首先说一说每个人所扮演的角色，负责编码的同学相当于软件工程师的角色，而负责需求分析及概要设计的同学责同时兼任了SQA小组成员的角色。在具体实现过程中，在需求分析阶段，通过需求调研我们小组大体明确了客户即TA对机动车违章管理系统的需求，但由于没有把需求调研的工作做到位，在完成需求分析的过程中，我们小组出现了一些问题，主要是对TA要求的理解出现了分歧。此时承担SQA小组责任的同学并没有严格要求自己进一步与TA沟通，解决理解上的分歧，而是个人主观的认为自己的理解就是对的。致使在具体实现时与初始需求出现了一些偏差。这个问题的发生，主要是因为承担需求分析的同学同时兼任SQA小组工作的原因，致使监督的客观性方面出现了问题。在概要设计阶段由于考虑到后期一些功能在后期具体实现中的困难，没有严格按照获取的需求进行设计，主要是出于实现难度的考虑草率的对本已获得的需求进行了一些修改致使本就出现变差的需求进一步打了折扣。在编码阶段针对出现问题时，更是仅仅是就问题而谈问题，把原始的计划放到了一边。回顾整个课程的过程：从在初始人员定位时并没有认识到SQA小组的重要性，因此并没有严格指定专人负责，只是在出现问题时才想到，而在明确两人兼任SQA小组工作后，也没有严格制定明确的计划，也没有正式的评审各项软件工程活动，仅仅是想到什么就说什么，不但造成了小组成员间的冲突，更是对问题的解决没有多大的帮助。而“软件工程师”即从事编码的同学虽然对软件本身进行了一些测试，修正了一些错误，改进了一些BUG，但这一切都是通过想当然去做的，并没有参考设计文档。结论：

无论何种软件只有在保证其质量的前提下才能体现出它的价值。软件质量保证则是保证软件质量的基石。而在软件质量保证的过程中，首先应该明确自己的定位，而后严格按照上面提出的步骤与方法去实现才能更好的完成SQA工作。这一切，都需要我们在今后的学习、工作中积极地去实践。

参考文献：

软件工程实践者的研究方法 Roger S.Pressman

软件质量保证 Schulmeyer,G.G

第三篇：软件质量保证管理

1、V模型：V模型是在RAD模型的基础上演变而来的，由于开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。V模型具有面向客户、效率高、质量防范意识等特点。

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动---审核过程，也就是静态的测试过程；右边是对左边结果的验证，是动态的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。V模型避免了瀑布模型所带来的误区-----软件测试是在代码完成之后进行的。p302、什么是变更控制？（P111）

软件开发过程中都会产生许多变更，如配置项，配置，基线，构建的版本，发布的版本的变更，对于这些变更，都要有一个控制机构，以保证所有的变更都是可控的，可跟踪的，可重现的。这样的一类机构对变更的管理，就是变更控制。

3、软件可靠性概念？（P176）

软件可靠性是指在给定时间内，特定环境下软件无错运行的概率，软件可靠性包含了以下三个要素：规定的时间，规定的环境条件，规定的功能。

4、CMM（P195）

CMM：能力成熟度模型，用来衡量组织软件过程成熟度和评价其软件过程能力。能力成熟度是指一个特定过程被明确定义，管理，测量，控制并且是有效的程度。分为五个等级： 初始级 软件过程的特点是无序的，甚至是混乱的。几乎没有什么过程是进过定义的。可重复级 关键过程区域集中关注软件项目所关心的，与建立基本项目管理控制有关的事情。

已定义级 将软件生命周期的各个阶段严格的划分出来，从组织这个层次来保证过程质量该进

已管理级 软件产品的质量目标被量化管理，它遵循了全面质量管理活动的科学程序，关键过程域的关注焦点是建立起对软件过程和正在构造的软件工作产品的定量了解。

优化级 关键过程域包括那些为了实施连续不断的和可测的软件过程改进，组织和项目都必须解决的问题。

5、TQM的实施步骤（P265）

（1）建立质量小组，负责过程改进，流程完善，不断发现质量问题提出并实施解决方案。

（2）进行TQM思想的教育，通过教育，要让每个员工深刻认识到“满足顾客的需求是第一的”的思想，理解“什么是顾客需求”，如何让顾客满意等内容。

（3）了解市场，明确顾客需求，了解目前研发的软件产品的市场，包括竞争对手，客户群等，让员工明白什么是质量好的软件产品或软件服务，认真对待质量要求，开发出合格的产品。

（4）建立明确的质量基准和质量评估机制，以便和实际质量水平进行对比，识别质量的目标和工作的重点区域，采取相应措施。

（5）建立相对完善的奖励机制，在认可和给予奖励的过程中，应力求公正，真实，选择恰当的时间，恰当的场合，恰当的方式。

2、版本控制的目的:是在于对软件开发过程中文件或目录的发展过程提供有效的追踪手段，保证在需要时找到旧的版本，避免文件的丢失，修改文件的丢失和相互覆盖，通过对版本库的访问控制避免未经授权访问和修改。另外软件的控制是实现团队开发，提高效率的基础。

3、PDCA包括4个部分：计划、执行、检查、行动描述总结

(1)计划计划：就是分析当前状况，发现问题，找出原因和主要原因，制定质量方针、质量

目标、质量计划书和管理原则。管理原则有：过程方法、管理的系统方法、持续改进

(2)执行：执行时计划的履行和实现，主要按计划实施地去做，去落实具体对策，并实施过

程的监控，使活动按预期设想前进，最终达到计划设定的目标。

(3)检查：是对执行后效果的评估。检查是伴随着实施过程自始至终的，不断收集数据、信

息获取的过程，并通过数据分析、结果度量来完成检查。

行动：重点在于检查完结果，要采取措施，即总结成功的经验，吸取失败的教训，实施标准化，以后依据标准执行。

4、阶段性开发模型：增量模型和迭代模型

(1)增量模型描述软件产品的不同阶段是按产品所具有的功能进行划分的，先开发主要

功能或用户最需要的功能，然后随着时间的推进，不断增 加新的辅助功能或次要功能，最终开发出一个功能完善的，稳定的产品。

(2)迭代模型描述软件产品的不同阶段是按产品深度或细化程度来划分，先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需要的全部功能。然后随着时间推进,不断细化已具有的功能或完善已具有的功能,这个过程是一个迭代的过程

6、零缺陷质量管理的实施步骤：（P268）

（1）建立推行零缺陷质量管理的组织事情的推行都需要组织的保证，通过建立组织，可以动员和组织全体职工积极的投入零缺陷管理，提高他们参与管理的自觉性也可以对每个人的合理化建议进行统计分析，不断进行经验交流，公司的最高管理者要亲自参加，表明决心，做出表率，要任命相应的领导人，建立相应的制度，要教育和训练员工

（2）确定零缺陷管理的目标，确定零缺陷小组在一定时期内所要达到的具体要求，包括确定目标项目，评价标准和目标值

（3）进行绩效评价，（4）建立相应的提案机制

（5）建立表彰制度

SQA组织的责任是审计软件经理和软件工程组的质量活动中出现的偏差。

7、SQA计划（P283）

SQA在项目早期要根据项目计划制定与其相应的SQA计划，定义各阶段的检查点。标识出检查审计的工作产品对象，以及在每个阶段SQA的输出产品。具体实施步骤如下：

（1）了解项目的需求，明确项目SQA计划的要求和范围

（2）选择SQA任务

（3）估计SQA的工作量和资源

（4）安排SQA任务和日程

（5）形成SQA计划

（6）协商，评审SQA计划

（7）批准SQA计划

（8）执行SQA计划

SQA计划包含以下内容：

（1）目的，SQA计划的目的和范围（2）参考文件，该SQA计划参考的文件列表（3）管理，组织，任务，责任（4）文档，列出所有的相关文档，如程序员手册，测试计划，配置管理计划等（5）标准定义，文档标准，逻辑结构标准，代码编写标准，注释标准等（6）评审/审核（7）配置管理，配置定义，配置控制，配置评审（8）问题报告和处理（9）工具，技术，方法（10）代码控制（11）事故/灾难控制，包括火灾，水灾，紧急情况等。

8、评审和审核的区别？（P285）

评审：过程进行时，SQA对过程的检查，SQA的角色在于确保当执行工程活动时，各项计划所规定的过程得到遵循，评审通常通过评委会的的方式进行，是对工作流程的评审

审核：在软件工作产品生成时，SQA对工作产品进行的检查，SQA的角色在于确保开发工作产品中各项计划所规定的过程得到遵循，审核通常通过对工作产品的审查来执行。侧重于产品本身。

SQA报告应遵循三条原则SQA和高级管理者之间应有的沟通渠道，SQA报告必须发布给软件工程组织但不必发布给项目管理人员，在可能的情况下向关心软件质量的人发布。

SQA度量是记录花费在SQA活动时间人力数据。涉及以下三方面：软件产品评估度量、软件产品质量度量、软件过程审核度量。

SQA的评估任务是软件开发前期对目标的软件和硬件资源进行评估，以确保其充分性和适合性。

9、白盒测试、黑盒测试（P390）

白盒测试将被测试程序看做一个盒子，测试者能够看到被测程序，可以分析被测程序的内部结构。

白盒测试可以用来对代码结构进行全面测试，常用的有语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖，循环测试

黑盒测试常用来验证软件或模块功能是否得到实现，主要运用单元的性能和功能方面的测试除了测试其功能外，还需确保代码在结构上可靠，健全并能够有良好的响应。黑盒测试主要运用于单元的功能和性能方面的测试。功能测试包括用户界面测试各种操作的测试不同的数据输入逻辑思路，数据输出和存储的测试。

区别：关键区别应该就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能

10、测试的原则概括为10项：

（1）所有测试的标准都是建立在用户需求之上2软件测试必须基于“质量第一”的思想去开展各项工作3实现定义好产品的质量标准4软件项目一启动。软件测试也就是开始5穷举测试是不可能的6第三方进行测试会更客观，更有效7软件测试计划是做好软件测试工作的前提8测试用例的设计出来的，不是写出来的9不可将测试用例置之度外，排除随意性10对发现错误较多的程序段，应进行更深入的测试

39、功能测试的概念：是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能正常使用、是否实现了产品规格说明书要求、是否能适当地接收输入数据而产生正确的输出结果等。

5、风险管理法：SEI（软件工程研究所）风险控制一般分5个步骤：P80

(1)风险识别：试图系统化的方法来确定威胁项目计划的因素。识别方法包括：风险检

测表、头脑风暴会议、流程图分析、与项目人员面谈。

(2)风险分析：可以分为定性风险分析和定量风险分析。定性风险分析是评估已经识别

风险的影响和可能性的过程。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。

(3)风险计划：制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对

措施、结果、负责人。

(4)风险控制：方法：风险避免、风险弱化、风险承担、风险转移。

(5)风险跟踪：监视风险的状况，检查风险的对策是否有效、跟踪机制是否在运行，不

断识别新的风险并制定对策。

6、评审的内容：分为管理评审、技术评审、文档评审、过程评审（P217简答）

(1)管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评论基准,对体系文

件的适应性和质量活动的有效性进行评价。目标：按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准要求和提供的质量方针和目标。输入：体系审核的结果。输出：《管理评审报表》

(2)技术评审是对产品以及各阶段的输出内容进行评估。目的：确保需求说明、设计说明书

与最初的说明书保持一致，并按照计划对软件进行了正确的开发。输入：需求文档、源代码、测试用例、评审检查单、其它文档。输出：技术评审报告

(3)文档评审分为格式评审和内容评审。

(4)过程评审是对软件开发过程的评审，其主要任务是通过对流程的监控，保证SQA组织

定义的软件过程在项目中得到了遵循，同时保证质量方针能得到更快更好的执行。

40.朱兰三部曲：

质量策划：为建立有能力满足质量标准化的工作程序，质量策划是必要的质量控制：为了掌握何时采取必要措施纠正质量问题就必须实施质量控制

质量改进：质量改进有助于发现更好的管理工作方式

40、从软件开发的各阶段论述如何提高软件产品的质量？

1、需求

我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。

2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。

3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。

4、另外注意引用的术语和词汇是否前后一致。

5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。

另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。

2、设计

软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正

是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：

1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。

2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。

3)维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。

4)可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。

5)可靠性：包括缺陷数量、容错性、可用性。

6)使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。

3、编码

代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。

也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作

周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。

代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。

4、测试

测试人员在测试过程中，需要站在不同的利益相关者的角度，对测试对象的质量进行检查和验证，例如：测试人员除了关注需求文档中明确描述的需求条目之外，还应该关注隐现的需求，比如：竞争对手的产品特征、用户的群体特征和使用习惯等。因此，在测试过程中，测试人员除了关注测试对象的功能测试之外，还需要针对其他非功能特性进行测试。

为了在测试过程中尽量多的覆盖质量特性，测试人员需要清楚的了解产品有哪些质量特性是客户最关注的因此，测试人员在进行具体的测试用例设计和执行之前，需要定义该产品应该满足的质量特性集。

第四篇：《软件测试与质量保证》读书报告

学生课程读书报告

姓

名

某某某

学号＿

0000000＿

专

业＿ 软件工程＿＿ 班级＿**级软件*班

读书报告题目

××××××××××××× 指导教师及职称

XXX

开课学期

2011

至＿ 2012 学年＿1＿学期

此处写题目(应用此格式)

学号：

姓名：

1.一级标题格式（黑体小四）

正文格式（宋体五号）

1.1 二级标题格式（楷体五号加粗）

正文格式（宋体五号）

参考文献

[1] 作者一, 作者二, 作者三等.论文题目.期刊名称, 年份, 卷号(期号):起始页-终止页.[2] 作者一, 作者二, 作者三等.书名(版次).出版社, 年份, 起始页-终止页.

第五篇：软件测试与质量保证实验指导

实验一.NET软件调试及测试计划

一、实验目的

通过本实验，熟悉.NET软件调试环境与技巧及测试计划的内容，并掌握测试计划的制定过程，能够针对具体项目完成测试策略的制定、测试人员的安排、测试进度安排、测试资源组织等工作。

二、实验内容

1.掌握.NET软件调试环境与调试技巧。基本内容如下：

一、学习附件一的内容，掌握调试技巧；

二、学习c# 中跟踪和调试的技巧-------如何使用 Debug

2.研究给定项目的需求规格说明书，提取测试需求，按照小组的人员情况，安排测试进度，为每一阶段的测试选定测试方法，最后按照给定的测试计划书模版生成完整的测试计划书。

项目需求规格说明书及测试计划模版由教师给出（见相关附件）。

（http://blog.csdn.net/zhouhuozhi/archive/2009/05/14/4180605.aspx）

三、实验要求

1、做好实验预习，掌握，并熟悉本实验中所使用的测试环境及相应的测试软件。

2、写出实验报告，内容是：

（1）实验日期（2）实验题目（3）实验内容

（4）实验结果，包括测试用例，代码清单、测试结果分析和心得体会。

3、本实验以小组为单位，每组上交一篇报告，报告的名称要包括组内人员的姓名。

四、实验学时

本实验需要2学时。

注：实验二与实验三任选一个做；实验四与实验五任选一个做

实验二 单元测试

一、实验目的

通过本实验，熟悉单元测试的目的、内容，并掌握黑盒单元测试的基本方法，能够按照具体要求对指定的程序设计测试用例并进行单元测试。

二、实验内容

1、黑盒单元测试（二选一）

（1）等价类划分法

三角形问题的需求规格描述如下：

输入三个整数a、b、c，分别作为三角形的三条边，现通过程序判断由三条边构成的三角形的类型为等边三角形、等腰三角形、一般三角形（特殊的还有直角三角形），以及构不成三角形。

现在要求输入三个整数a、b、c，必须满足以下条件：

条件1 1≤a≤100 条件2 1≤b≤100 条件3 1≤c≤100 条件4 a

1、条件2和条件3，程序给出“边的取值超出允许范围”的信息。

如果输入值a、b、c 满足条件

1、条件2和条件3，则输出下列四种情况之一：（1）如果不满足条件

4、条件5和条件6中的一个，则程序输出为“非三角形”。（2）如果三条边相等，则程序输出为“等边三角形”。（3）如果恰好有两条边相等，则程序输出为“等腰三角形”。（4）如果三条边都不相等，则程序输出为“一般三角形”。针对此需求：

1、自己编写程序实现，程序语言不限，并要求在实验前完成；

2、分析该程序的输入，建立等价类划分表，并根据等价类表设计测试用例；

3、根据边界值条件设计不少于10组的测试用例；

4、用所有测试用例对程序进行测试，记录每组测试用例对应的输出结果，并对结果进行分析；

5、确定是否存在bug，如果存在bug，分析其原因并调试修复。（2）因果图法

有一个饮料的自动售货机，其规格说明如下：投入相应的钱数，然后按下相应饮料的按钮，如果钱数不够，则给出信息“投入钱数不够！请继续投入！”，如果金额够，就给出饮料，并找零。如果机器内该饮料已经售完，则提示“该饮料已经售完！”，如果不再买其它的饮料则退钱。如果光投入钱没有选择饮料，则给出提示“请选择饮料！”，如果没有投钱就选择饮料，也会给出提示。（本程序由教师给出）分析该需求中的原因和结果，列出来； 画出因果图；

根据因果图生成判定表（决策表）； 根据判定表设计测试用例；

运用测试用例对程序进行测试，并记录测试结果；

6、提交实验报告，报告内容如下：实验题目、实验目的、实验内容、程序清单、测试用例、测试结果、结果分析、心得体会。

三、实验要求

1、做好实验预习，提前编写相关程序，并设计测试用例。

2、写出实验报告，内容是：

（1）实验日期（2）实验题目（3）实验内容

（4）实验结果，包括测试用例，代码清单、测试结果分析和心得体会。

3、本实验以小组为单位，每组上交一篇报告，报告的名称要包括组内人员的姓名。

四、实验学时

本实验需要4学时。

实验三 单元测试

一、实验目的

通过本实验，熟悉单元测试的目的、内容，并掌握白盒单元测试及面向对象的单元测试的基本方法，能够按照具体要求对指定的程序设计测试用例并进行单元测试。

二、实验内容

1、白盒单元测试（二选一）

（1）对实验二中编写的三角形程序，画出其程序流程图；分析程序流程图，确定程序分支；

（2）设计分别满足语句覆盖、路径覆盖、条件覆盖及条件组合覆盖和路径覆盖的测试用例；

（3）用测试用例对程序进行测试，记录测试结果，并对结果进行分析，如果存在缺陷则修改程序，继续测试；

2、面向对象的单元测试

对给定的类设计桩程序或驱动程序，设计测试用例，对其进行单元测试。

三、实验要求

1、做好实验预习，提前编写相关程序，并设计测试用例。

2、写出实验报告，内容是：

① 实验目的

② 实验内容

③ 实验结果，包括测试用例，代码清单、测试结果分析和心得体会。

3、上报实验源代码（或测试脚本、测试结果文件、测试报告），本实验以小组为单位，每组上交一篇报告，报告的名称要包括组内人员的姓名。

四、实验学时

本实验需要4学时。

实验四 集成测试

一、实验目的

通过本实验，熟悉集成测试的目的、内容，并掌握自底向上和自顶向下集成测试的基本方法，能够按照具体要求对指定的程序设计测试用例并按要求进行集成测试。

二、实验内容

自选一个包含多个模块的程序，完成以下工作： *

1、编写辅助程序

2、自底向上集成

三、实验要求

1、做好实验预习，提前编写相关程序，并设计测试用例。

2、写出实验报告，内容是：

① 实验目的。② 实验内容

③ 实验结果，包括测试用例，代码清单、测试结果分析和心得体会。

3、上报实验源代码（或测试脚本、测试结果文件、测试报告），本实验以小组为单位，每组上交一篇报告，报告的名称要包括组内人员的姓名。

四、实验学时

本实验需要4学时。

实验五 系统功能测试

一、实验目的

通过本实验，熟悉系统功能测试的目的、内容，并掌握功能测试基本方法，能够功能规格说明对指定的系统设计测试用例并进行测试。

二、实验内容

对指定的系统，参照系统功能设计测试用例，并进行功能测试，记录测试结果。计算器程序功能测试

给定简单四则运算计算器系统由两个窗体构成，一个是计算窗体，一个是帮助信息窗体。该系统的主要功能是进行十进制的二元加、减、乘、除运算。

系统需求描述如下：四则运算计算器计算用户输入的两个数字的计算结果，要求既能用鼠标点击文本框和命令按钮，也可以脱离鼠标，完全用键盘操作。当用户输入的内容不是合法的数字时，要求程序能给出提示。当用户进行除法运算，并且输入“0“作为分母时，要求程序能给出相应的错误提示。当用户以任何顺序输入数据时，要求程序都能计算出正确结果。当用户完成一次计算后，即可以不清除就再次输入数据，也可以按“清除”键后再输入运算数。要为用户提供帮助功能，用户可以通过点击计算窗体中的帮助按钮进入帮助窗体。在计算窗体中，按返回按钮应退出系统。

三、实验要求

1、做好实验预习，提前编写相关程序，并设计测试用例。

2、写出实验报告，内容是：

① 实验目的② 实验内容

③ 实验结果，包括测试用例，代码清单、测试结果分析和心得体会。

3、上报实验源代码（或测试脚本、测试结果文件、测试报告），本实验以小组为单位，每组上交一篇报告，报告的名称要包括组内人员的姓名。

四、实验学时

本实验需要4学时。