现代软件工程的质量保证

现代软件工程,第七部分现代软件工程的质量保证,现代软件工程,本部分主要参考书,软件验证与确认的最佳管理方法（美）Steven R. Rakitin著于秀山等译（电子工业出版社）2002测试流程管理（美）Rex Black著（北京大学出版社）2001软件工程与软件测试自动化教程张克东、庄燕滨（电子工业出版社）软件工程规范（美）Watts. S.Humphrey著，傅为、苏俊、许青松译（清华大学出版社）2004软件配置管理策略与Rational ClearCase（美）Brian A. White著尤克滨等译（人民邮电出版社）2003,现代软件工程的质量保证过程-1软件测试的组织与管理-2软件系统的可靠性工程-3配置管理方法与实践-4,第七部分 现代软件工程的质量保证,第一章 现代软件工程的质量保证过程 软件的质量要素与度量-1.1软件工程的质量保证过程-1.2软件工程的质量保证活动-1.3软件质量保证体系建设-1.4,第七部分 现代软件工程的质量保证,如何描述质量用人的健康做类比如何判断人是否健康？体检因素：身高、体重、心跳、血压、血液、体温等如何描述软件的质量软件系统功能齐全是不是就是质量好？用户界面友好是不是就是软件的质量好？没有BUG是不是就是软件的质量好？用户满意？运行正确的软件就是高质量的软件吗？不贪污的官就是好官吗？软件测试是不是软件质量的全部？回答全部是：NO！那么，什么是软件的质量？,什么是软件的质量？,现代软件工程的质量保证与软件测试有什么不同？技术经理、项目经理与质量经理有什么不同？什么是现代软件工程的质量管理？开发团队在质量保证方面，要做什么工作？ 我们就来回答这些问题！,什么是软件项目的质量管理？,软件质量,软件质量的定义：ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J. Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。质量特性及其组合，是软件开发与维护中的重要考虑因素为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。,软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。标准定义了一组开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。软件质量特性，反映了软件的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。定义一个软件的质量，就等价于为该软件定义一系列质量特性。人们通常把影响软件质量的特性用软件质量模型来描述。,软件质量,软件质量,软件质量的因素与度量有关直接度量的因素如单位时间内千行代码中所产生的错误数。间接度量的因素如可用性或可维护性,软件质量,软件质量的度量模型1976年，Boehm第一次提出了软件质量度量的层次模型。1978年，Walters和McCall等人提出了从软件质量要素、准则到度量的三个层次式的模型。1985年，ISO建议软件质量模型由三层组成：高层：软件质量需求评价准则（SQRC）中层：软件质量设计评价准则（SQDC）低层：软件质量度量评价准则（SQMC）,现代软件工程的标准体系ISO/IEC12207,1.1 软件质量的要素与度量1.1.1 软件的质量要素1.1.2 软件质量评价的准则1.1.3 软件质量的度量1.1.4 软件质量度量的实施,1.1.1 软件的质量要素,什么是软件的质量？ISO9000的质量定义：质量的定义：反映实体满足明确和隐含需要能力的特性综合定义的说明：明确需要：指合同中用户明确提出的要求与需要隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要,质量与等级的关系,等级的含义是：对功能用途相同、但技术特性不同的存在事务的一种分类或排序例如：高质量无错误、可读性强的用户手册 低等级有限的功能 低质量错误百出、编排混乱的用户手册 高等级大量功能确定质量和等级标准水平，是项目经理的责任,质量的要素讨论软件的质量定义，一般地从4个角度来看，即用户的角度、开发商的角度、产品的角度和价值的角度。1976年美国的B.W.Boehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。IEEE标准1061-1998以表格的形式，定义了有关确认和收集与软件质量需求有关一个模型，或称为一个框架。,可度量的软件的质量要素,IEEE定义的软件质量度量框架,IEEE定义的软件质量度量框架,第一层次：质量需求在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：（1）产品将在用户所在组织当前使用的平台和操作系统上运行。（2）产品将是可靠的并能防止数据丢失的机制。（3）产品将提供完成某些任务所必需的功能。（4）产品将易于使用。第二层次：质量特性在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成四类质量特性，这四个质量特性是软件的基本特征。IEEE的四个质量特性是：可移植性、可靠性、功能性、可使用性。,IEEE定义的软件质量度量框架,四层模型,1978年，Walters和McCall等人提出了从软件质量要素、准则到度量的三个层次式的模型。McCall选择的软件质量要素评价准则共21种，它们是：（1）可审查性(auditability)。检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度。（2）准确性(accuracy)。计算和控制的精度，是对无误差程序的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。（3）通信通用性(communication commonality)。使用标准接口、协议、规范的程序。（4）完全性 (completeness)。所需功能完全实现的程度。 （5）简明性(conciseness)。程序源代码的紧凑与简洁性。（6）一致性(consistency)。设计文档与系统实现的一致性。（7）数据通用性(datacommonality)。在程序中使用标准的数据结构和类型。（8）容错性(error-tolerance)。系统在各种异常条件下提供继续操作的能力。（9）执行效率(execution Efficiency)。程序运行效率。（10）可扩充性(expandability)。能够对结构设计、数据设计和过程设计进行扩充的程度。,1.1.2 软件质量评价的准则,（11）通用性(generality)。程序部件潜在的应用范围的广泛性，即部件可重用。（12）硬件独立性(hardware independence)。软件同支持他运行的硬件系统不相关的程度。（13）检测性(instrumentation)。监视程序的运行，一旦发生错误时，能明确地标识错误的程度。（14）模块化(modularity)。程序部件的功能独立性。（15）可操作性(operability)。操作一个软件的难易程度。（16）安全性(security)。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。（17）自文档化(sdlf-documentation)。源代码提供有意义文档的程度。（18）简单性(simplicity)。理解程序的难易程度。（19）软件系统独立性(software system independence)。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。（20）可追踪性(reacebility)。从设计表示或实际程序构件，追踪到需求的能力。（21）易培训性(training)。软件支持新用户使用该系统的能力。,McCall的软件质量评价准则,软件质量评价准则,1、正确性正确性是指软件按照需求正确执行任务的能力。 “正确性”的语义涵盖了“精确性”。正确性无疑是第一重要的软件质量属性。技术评审和测试的第一关都是检查工作成果的正确性。 机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。2、健壮性 健壮性是指在异常情况下，软件能够正常运行的能力。 正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。开发者往往把异常情况当成正常情况而不作处理，结果降低了健壮性。 用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。健壮性有两层含义：一是容错能力，二是恢复能力。,3、可靠性 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。 软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。 时隐时现的错误一般都属于可靠性问题，纠错的代价很高。,软件质量评价准则,4、性能性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。 性能优化的关键工作是找出限制性能的“瓶颈” 可以通过优化数据结构、算法和代码来提高软件的性能。 5、易用性易用性是指用户使用软件的容易程度。现代人的生活节奏快，图方便。所以把易用性作为重要的质量属性对待无可非议。 导致软件易用性差的根本原因 ：教育缺陷：没有开设人机工程学、美学、心理学这些必修课，大部分开发人员不知道如何设计易用的软件产品。开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就会满意。 软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好” 等词来评价软件产品。,软件质量评价准则,6、清晰性 清晰意味者所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。 开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。 可理解的东西通常是简洁的。一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。所以简洁是人们对工作“精益求精”的结果，而不是潦草应付的结果。 千万不要把在学校里“造文章”的手法用于开发产品！ 7、安全性 安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。 “道高一尺，魔高一丈” ，绝对安全的信息系统几乎不存在。开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。,软件质量评价准则,8、可扩展性 可扩展性反映软件适应“变化”的能力。 在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。 现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。可扩展性越来越重要。可扩展性是系统设计阶段重点考虑的质量属性。 9、兼容性兼容性是指两个或两个以上的软件相互交换信息的能力。兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。10、可移植性可移植性是指软件运行于不同软硬件环境的能力编程语言越低级，其程序越难移植，反之则容易。软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。,软件质量评价准则,1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别对应McCall等人的要素、评价准则和度量。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成。高层的8个要素为左表的行，中层的23个准则为下表的列。它们之间的关系如左表所示。,ISO/IEC9126-1产品质量-质量模型的软件质量模型,软件质量的另一种理解,内部质量的定义是：反映软件产品在规定条件下使用时，满足需求的能力的特性，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。了解软件产品的内部质量，可以预计最终产品的质量。外部质量的定义是：反映软件产品在规定条件下使用时，满足需求的程度。外部特性反映在预定的系统环境中运行时可达到的质量水平。,软件质量的另一种理解,使用质量的定义是：反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。对内部和外部质量特性的度量描述包括：功能性、可靠性、易用性、效率、可维护性、可移植性等；对使用质量特性的度量描述包括：有效性、生产率、安全性、满意程度等,软件质量的另一种理解,1.1.3 软件质量的度量,软件度量：分析模型的度量（对分析模型的度量以测试系统的大小）设计模型的度量（度量体系结构、数据和系统的复杂度）源代码的度量（度量程序的长度、层次、开发量、时间等）对测试的度量（度量测试的宽度、深度、错误的级别）对维护的度量（度量软件的稳定性）,软件质量度量,每个软件属性都有一套度量方法，选择度量方法时，必须考虑下列因素。1. 与软件属性的相关性相关性分为4个等级：A度量方法与相应的软件属性始终存在正相关AA几乎总是存在正相关U经常存在正相关S偶尔存在正相关,软件质量度量,2. 度量值的可理解性定量的度量方法所得到的值分为5种情况：AL通过一个自动算法很容易理解UR不需要受过专门训练的人员TR需要受过专门训练的人员ER需要专家EX需要执行程序3. 开发自动工具的容易性开发度量工具的难易程度分为3种情况E容易M存在困难D很困难,软件质量度量,4. 自动工具的完备性 所开发的自动工具是否完全等价于度量方法，有2种情况C完全等价P部分等价5. 潜在效益潜在效益分为5个级别：5、4、3、2、1,软件质量度量,软件质量度量,两个软件（程序）质量度量方法Halstead的软件科学基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。McCabe复杂性度量法程序的复杂性很大程度上取决于程序控制流的复杂性单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。,软件质量的度量和评价,软件质量特性度量有两类：预测型和验收型。预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数KLOC单位时间。第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等等。验收度量是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它是对开发过程中的预测进行评价。,尺度度量检查表,二元度量检查表,基于软件配置管理的度量和度量准则,SCM 提供软件产品的状态统计。统计提供寻找软件开发的瓶颈和解决办法，并据此衡量软件产品的成熟度。度量准则：平均严重程度严重程度级的分布平均关闭时间严重程度的图示各配置项或子系统的图示,SCM的度量和度量准则,软件产品成熟度数据要求： 软件变更（问题）数量 描述 计算机软件配置项标识（CSCI） 严重程度级 打开变更的日期（或发现问题） 关闭变更（问题）和实施日期,软件变更统计,SCM的度量和度量准则,图表分析,软件剩余问题,剩余变更和错误密度,1.1.4 软件质量度量的实施,在确定要对一个软件（系统）进行度量之后，一般，采取以下5个步骤，来实施对该软件的度量： （1）确定软件质量需求； 在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。但是，我们已经知道，软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。过程： 需求获取：首先，你要理解用户的需求，区分哪些是质量需求，把这些需求记录下来，获得用户的确认。 需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。,1.1.4 软件质量度量的实施,（2）确定直接度量 直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。 例如：对一个没有经过培训的用户，让他使用软件系统的某一功能，在界面提示、联机帮助、使用手册的帮助下，他学会掌握该功能所花的时间。而用户需求对此项指标的要求（目标）和现实系统所达到的实际值（比如：10个人次测量后统计意义上的）的比较，就是将提交质量评审的质量值。 在进行直接度量前，你应该有以下准备： （1）工具：有助于计算度量值的硬件/软件工具，如：缺陷跟踪工具； （2）应用：描述度量结果的希望值、度量值的意义、作用和对度量结果数据的使用方法； （3）数据：获得度量结果所需的数据、程序、过程等度量对象； （4）计算：度量程序、步骤和方法。 （5）费用：测试是要花钱（人力、物力、时间等）的。,1.1.4 软件质量度量的实施,（3）分析度量结果 对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。 （4）确认质量度量 在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。,一个系统集成项目的质量特性与度量可交付成果的质量采购的主机/存储/网络硬件/软件运输/安装/检验/调试/测试培训/服务/技术支持/维护/响应资料文档（手册）提供项目实施过程的质量项目的计划性组织准备的充分与周到性沟通与协调性操作与行为的规范性,案例分析,1、你已经确认的，你的项目的质量需求（质量特性）是什么？2、这些质量需求的（面向度量）的子特性是什么？3、如何进行这些子特性的度量（方法设计）？4、度量结果（度量值）的评价标准是什么？,问题1：,1.2.1 确认过程1.2.2 验证过程,1.2 软件工程的质量保证过程,软件质量保证,什么是质量保证它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。什么是软件的质量保证就是向用户及社会提供满意的高质量的产品。软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。现代软件工程的质量保证过程，主要包括软件确认与验证二个过程软件的确认（Validation）与验证（Verification）简称为VV 或V2，也是软件产品质量度量的具体方法。,软件确认的概念确认是这样一个过程，它评价“在软件开发过程期间（针对单元）或结束（针对系统）时，单元或系统是否满足用户特定的需求”。换句话说，是开发结束期间确认，我们的产品符合用户要求吗？因此，确认的产品质量。确认活动围绕三个基本过程来开展，测试、度量和软件可靠性增长软件验证的概念而验证是这样一个过程，它评价“在一个给定的开发阶段中，单元或系统是否满足在此阶段开始时确定的条件”。因此，它的意思是，我们正在制作的产品符合用户要求吗？因此，验证的是产品开发过程质量工作质量。验证活动也是围绕三个基本过程来进行，审查、度量和配置管理。,软件工程的质量保证过程,软件质量保证,传统的软件质量保证的活动技术方法的应用正式技术评审的实施软件测试标准的执行修改的控制度量记录和记录保存现代方法基于架构的迭代和增量开发配置管理,软件确认过程1：测试,根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：,V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。,测试与开发阶段的对应V模式,单元测试,单元测试的内容主要是： 算法逻辑、数据定义的理解和使用、接口、各种CASE路径、边界条件、错误处理等。 单元测试的目的通常是: 在开发环境中，程序设计工程师为了检查单元程序模块内部的逻辑、算法和数据处理结果的正确性等。单元测试通常由负责编码的工程师自己在代码完成后测试，也有在项目组内，由工程师相互交叉测试。 调试与测试的最大的不同点是二者的目的和视角的区别： 调试包括查找BUG、定位BUG、修改并最终确认BUG已经被修复的软件故障排除过程。 测试是在一个相对独立的环境下（测试应尽可能地模拟运行环境，调试是在开发环境），运行系统单元，观察和记录运行结果，对结果进行独立评价的过程。,单元测试（模块测试）,实际上，在单元测试级，一般项目组很难做到把调试与测试分开。因为二者的工作内容比较接近，担负人常常是一个人，环境区别并不大或者重新搭建环境在时间、成本和人力上，都比较困难。这些都是一般项目组并没有独立的单元测试的原因。 将单元测试与模块调试合并可能带来的问题是：（1）单元测试没有任何记录和文档。少有笔头勤快的工程师，会把他每天测了什么、改了什么，记录下来。软件工程师要的就是没有BUG的程序，任何中间结果都是垃圾。（2）由于调试的目标是获得没有故障的程序，因此，与功能无关的程序属性往往被忽略，或者要到集成测试、确认测试时才被发现。例如：命名标准、程序形式规范等。 不论怎么说，现实情况，单元测试与模块调试经常是混为一谈的，要想改变，也不太容易。 由于单元测试在项目组中，常常由编码工程师完成，项目经理的管理一般并不深入到单元测试层。,集成测试（子系统测试）,集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下列只有组装后才能发生和测试到的问题，进行检查：（1）组装后一个模块对一个模块的影响；（2）合并功能是否是预期的；（3）独立的误差在合并后的变化，是扩大还是减小，是否在可接受的范围内；（4）实际的接口测试；包括：模块之间对实际衔接的标准、时序（实时性）、应答响应、容错与错误处理等；（5）模块间的资源竞争等。 集成测试也很重视集成的阶段性。最坏的情况是系统只有一次集成，就是系统全部模块完成后进行集成。实际上，这就像一部汽车，直到要出厂时，才来一次总测试。而当你每天生产一部完全不同规格、型号的汽车时，这个时候的测试，可能是非常要命的。 比较好的办法是通常采用的增量组装法，包括自顶向下或自低向上的增量组装。分阶段的增量组装测试，可以解决一次集成，问题的隔离和区分不易的困难。,确认测试（系统测试）,确认测试的目的是按照与用户确认的软件需求规格说明书的要求，检查系统的需求实现。确认需求的测试依据是需求阶段产生的测试脚本（测试用例）。 国内项目组的现实情况有以下几种：（1）没有确认测试；（2）没有独立的确认测试，测试与设计、编码不分离；（3）有独立的确认测试，但测试用例是设计和编码人员写的，因此，独立测试人员相当于按设计和编码人员的设计思路再测一遍。 上述这些情况，就丧失了确认测试的大部分意义。正确的确认测试是独立的测试组中，具有相应知识的测试设计师，根据需求规格说明书，并依据该软件在用户方面将会是在什么环境下，用户将如何使用该软件，来设计测试方案和测试用例，安排测试人员进行测试。很显然，现实离理想的距离还比较遥远。 确认测试还包括软件经修改后的再测试（回归测试）。回归测试是对已测试并发现故障的部分，修改后进行再测试。回归测试不应修改测试程序、测试内容或测试标准。它与正常测试不同的仅是：它可能并不需要再完整地走一遍所有的确认测试，而是小心地选择部分确认测试程序，选择的标准是不减低原标准的整体要求。,测试和测试,为了实际检验软件的功能和性能，有时，常邀请特定的用户帮助试用（测试）系统正式发布前的版本，请用户对系统进行评价。这就是通常所说的测试和测试。测试是由一个用户在开发者的场所，在开发者指导下进行的测试。开发者记录下问题和错误，是在开发者“控制”下的测试。测试是用户的环境中，开发者可能并不在现场，由用户“活用”系统情况下的测试。用户记录下问题，报告给开发者。在商用套装软件中，这种情况比较多见，在行业应用系统中，由于现实环境并不允许不成功的软件直接投入使用，用户也没有参与测试义务、时间和资源的投入和配合的积极性，因此，这种测试很少发生。,验收测试,在行业应用软件环境中，验收测试是项目过程非常重要的一环，也是项目经理非常关注的一项工作。验收测试与确认测试非常相似，所不同的是，确认测试是项目组或组织内部的测试，验收测试是用户主导、现场参与、现场环境下的测试。验收测试通常由项目组先提出测试大纲，定义测试目的、范围、方法、测试用例、预期结果、验收标准等。经用户同意批准，可能包括用户的修改、增加后，确定测试时间，开始进入验收测试。用户在完成按测试用例的测试后，在测试记录上逐条确认、签字，最后，在测试报告上签字，完成验收测试。一般地、验收测试报告是项目初验、终验的依据和主要验收形式。,单元测试与验收测试,单元测试和验收测试没有什么区别？单元测试可以类比为一个建筑的质检人员对建筑进行的检测， 他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。验收测试可以类比为建筑的使用者来对建筑进行的检测。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。,测试方法,测试所处的阶段不同，方法也不同：白盒测试在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。黑盒测试在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。代码走查,测试类型,在不同阶段，测试的类型也不相同，常有的测试类型是：（1）功能测试：软件实现的功能是否符合需求规格说明书中定义的功能；（2）性能测试：软件在规定配置下的性能是否符合需求规定；（3）算法测试：确认实现的算法的正确性；（4）正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。（5）逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如：无效操作、错误的数据输入处理、非法进入等。（6）边界测试：按软件的限制、假设条件的边界输入，进行测试。（7）配置测试：对软件环境进行配置变化，软件需求实现，特别是性能实现是否能符合需求规定要求。（8）负载测试：在业务处理量、数据负载量、通讯负载量达到何种情况，系统的性能变化和承载能力情况。,测试计划,测试估计在拟定测试计划时，首先需要对以下情况，做出估计：（1） 完成测试设计所需要的工作量：（2） 完成测试设计所需要的工作时间：（3） 完成测试所需要的时间：根据以上三个部分的结果，我们已经知道了测试的范围、内容、任务分配、时间等，这样，项目经理可以能比较充分地规划资源，制订出一份比较全面和切实的测试工作计划。测试分配测试计划确定了测试的范围、内容和估计时间，根据WBS方法，测试计划还应说明具体测试任务的分解和测试工作的分配。测试组的成员根据分工，各自完成一部分测试任务。测试组与项目开发组还需要保持一定的同步，使测试与开发、修改在协调的步骤下进行，以节约宝贵的项目总时间。测试确认,测试用例： 测试用例由谁设计？ 设计测试用例的依据是什么？ 测试设计的重点是什么？,测试报告： 收集齐上述的所有测试用例，构成了测试报告的基本要件。 测试报告是对所有测试用例测试过程的总结。 在测试报告中，应反映： （1）测试中出现问题的统计汇总和分析； （2）未解决问题的汇总和解决方案建议； （3）回归测试的统计和分析（度量） ； （4）对测试计划的总结或修改。,测试过程组织,一个独立的测试小组为例，测试过程一般如下：（1）测试准备：制定人员、环境、工具、培训和外部支持计划。（2）测试计划：确定测试策略、建立测试计划。（3）测试用例：建立测试顺序树、确定测试的优先级、详细列出测试程序和测试数据，设计测试用例。（4）测试环境：了解需求、搭建环境、安装备份和恢复程序，记录初始环境、测试环境、恢复环境等。（5）测试执行：从测试计划复审测试计划进度表、恢复测试执行环境。（6）结果分析：执行结果分析、度量。（7）测试报告：错误趋势图、测试变动指示、产品检查点建议。,软件审查的概念,回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的三个过程是：审查、测量和配置管理。同时，我们也谈到，验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。 什么是审查，审查是一个正式的、严格的、具有深度的技术评审过程。因此，评审的目的是： （1）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题； （2）确保对需求保持一致的意见； （3）验证任何修改和变更满足预先定义的准则； （4）为组织提供产品在质量和过程方面是否有效的实际数据； （5）使团队成员之间在技术上建立相互的了解； （6）增加软件确认测试的有效性； （7）提高优秀软件工程师的水准。,软件评审,软件评审在软件开发的各个阶段，都要采用评审的方法，以便及早发现软件的缺陷。软件评审的必要性1. 从技术角度进行的审查是保证软件质量的重要措施由于人的认识不可能百分之百地符合客观实际，因此生命周期每个阶段的工作中都可能发生错误。由于前一阶段的成果是后一阶段工作的基础，前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会积累起来，如下图所示。,原始要求,正确的规格说明,错误的规格说明,需求分析,设计,正确的设计,错误的设计,对错误说明的设计,编码,正确编码,错误编码,对错误设计的编码,对错误说明的编码,测试,正确功能,可改正的错误,不可改正的错误,潜伏的错误,不完善的软件产品,软件评审,2. 技术审查也是降低成本的一个重要举措由于再后期改正一个错误比在早期改正同一个错误需要付出的代价高二至三个数量级，所以越在早期发现的错误越容易改正，代价越低。3. 在技术审查合格之后，再进行管理复审，可以使管理人员专心从管理角度对开发工作进行审查，而不必顾及技术问题,软件评审,软件评审的办法成立评审小组，组员包括：组长、作者、评审员1. 组长组长是小组的核心，最后由技术水平较高且没有直接参与这项工程的人担任。组长的任务是组织和领导技术审查的全过程，如安排会议日程，分发必要的文档资料，主持审查会议，确保审查全面、公正。2. 作者作者是被审查文档或程序的编写者。如果开发小组由一个小组集体完成，通常由技术小组负责人代表小组参加审查小组。作者的责任是回答技术上的问题3. 评审员评审员也应由技术专家担任。通常一个是前一阶段的技术骨干，另一个是后一阶段的骨干。评审员的任务是分别从各自的角度，公正客观地评价被审查的软件产品。,软件评审,软件评审的步骤准备简要介绍情况阅读被评审的文档（如检查表）开评审会返工复审软件开发的各个阶段，其检查表的内容不一样。,6.3.1 软件审查的准备,评审人：审查一般由一个审查小组或审查委员会负责进行，审查小组内，应有以下角色构成： （1）主持审查活动的主审员； （2）被审查产品负责人，包括产品经理、技术经理、质量经理等； （3）负责对被审查产品进行讲解和解释的主讲人； （4）来自各有关部门的审查员； （5）记录员； （6） 项目经理 项目经理应该参与软件的审查过程，关注审查结果，但不一定要参加审查会议。这要看审查的级别。如果是组织内的项目级审查，项目经理作为被审查产品的负责人，应参加审查会议，否则，应该由具体的产品、技术或质量经理去参加这样的会议。 被审产品的负责人参加这样的会议，不是为了解释审查中发现的缺陷，及其责任，进行辩解，而只是如实地向审查小组介绍产品为什么要这样做，和做了什么。审查的目的不是为了追究什么人的责任，而是为了改进过程。如果把评审，引入到人与人之间的斗争中去，则完全丧失了评审，作为过程改进手段的意义。,评审内容及要求，见下表：,系统确认及回归测试已经完成,审查内容,作为被审查对象的项目组，按照审查组的要求，提交被审查材料，接受审查。 作为审查员，应该做什么准备？ 首先，明确作为审查员的定角色位、职责。 审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的，但不一定就是直接从事相同岗位（有时，还特别需要交叉换位）的人员。在参加审查前，他必须花一定的时间和精力，来了解产品，并能通过阅读提交的资料，了解产品与文档、标准和规范之间的差异。 因此，他在审查中的责任是：（1）必须完全熟悉要审查的产品和产品所依据的文档和标准；（2）对照产品和文档，鉴别其中的差异；（3）客观地评价差异，识别是属于实现程度差别、缺陷，还是错误；（4）判断差异是实现的个体现象，还是过程问题；（5）以对产品而不是对人的态度，对差异进行评估和分析；（6）向主审员报告审查结果和分析意见。,审查员的职责,软件审查的过程,在审查开始之前，审查组与被审查项目的有关人员，产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的话，花一点时间介绍一下审查方法，使得审查员和被审查项目的有关人员，在审查过程中易于沟通和理解。当被审查有关人员知道（不是同意）审查的主要内容后，主审员把审查工作，按分工，分配给各审查员，并请项目组指定有关的配合人员。会议约定好完成分组审查的时间，即召开审查汇报会的时间。 获得审查资料的审查员，可以开始从看资料如手，进入审查阶段。如果需要实际测试和运行检查，项目组要配合安排机器时间、软件演示等与操作有关的环境。 审查员经过一段时间的工作，已经对所分工的部分，通过阅读资料、实际查看等，获得了必要的信息，有关的疑问，通过向项目组实际询问，解释了不清楚的地方。审查员对差异，已经做好了记录。主审员按时间和进度，可以招集审查汇报会。,在审查汇报会上，审查员汇报分组审查中发现的潜在的（还没有定论）的错误、缺陷和差异。审查小组对每一个问题进行讨论，并争取获得一致的意见。必要时，可以请项目组再做解释。记录员此时应详细记录讨论的过程和各自的意见，并确保这些记录的完整性、正确性和真实性。 如果一次会议不能解决争论的问题，或者需要再扩大参加人员的范围，或者需要再做测试，那就那样去做。或者审查组发现问题已经非常严重，已经超出了软件评审的范围，那么，应立即停止评审，向有关上级报告问题，以便上级做出重大改进的措施。 审查结果的发布是一个非技术的敏感问题。什么性质的结果可以发布，在多大范围内发布。审查结果如果比较满意，它的发布将对项目组是一个正向的激励，是相关人员能力的象征。负面的审查结果可能引来更大的争议和动荡。因此，审查小组和项目经理，要充分沟通，从积极的方面，使用审查结果。 任何审查结果都不是针对个人的，但是任何工作都是由具体个人来负责和承担相应责任的。因此，审查结果的难处，就在这句话的二面性。,软件审查的过程,需求审查,需求文档与需求属性（第二章已经介绍） 需求审查表（问题清单） （1） 需求是否定义了要向用户展示的全部信息？（2） 需求是否论述了系统对用户错误操作的反映？（3） 每一需求项的描述是否清楚、简洁和没有二意性？（4） 每一项需求是否都是可测试的？（5） 需求是否有隐含或暗示的功能理解？（6） 需求项之间是否有自相矛盾的地方？（7） 需求是否有应该论述但没有提及的地方？（8） 需求对实时性、精确度、负载能力等有没有定义？（9） 需求是否包括了性能需求、质量需求等非功能需求？（10） 如果需求涉及复杂的关联关系、复杂的算法、复杂的决策 机制，用户能完全理解吗？（11） 需求对软件升级、版本变更是否有明确的承诺？（12） 需求文档是否含有不必要的设计细节？（13） 是否可以根据需求，开发出适当的和完整的测试用例集？（14） 需求的假设和限制条件是否明确？,需求审查,需求审查过程 我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报告自己的发现和分析。 审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得一致的意见，并形成审查报告。 追踪与改正 审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。 关注项目组的改进，是项目经理比关注审查结果更重要的事情。,设计审查,概要设计审查表（问题清单） 详细设计审查表（问题清单） 设计审查的目标： 概要设计重点审查以下几个方面（概要设计针对需求） （1）概要设计对需求的完整实现； （2）概要设计与需求的一致性； （3）概要设计向需求的反向可追踪； （4）概要设计中，对系统结构设计的逻辑性、合理性和可扩展性； 由于概要设计是直接衔接需求的，因此，概要设计审查更多地是把设计与需求相衔接。 在详细设计中，应重点审查以下方面（详细设计针对实现） （1）设计应符合组织即定的标准； （2）设计结果对下一阶段的编码是可用的。 由于详细设计直接提供编码实现，因此，在组织内，应对详细设计的“粒度”做出规定。这样，即明确详细设计与代码实现的界面，同时，也是编码标准化的工作基础。在这方面，应结合实际，进行研究。,代码审查,代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。 代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。 走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力的工作。因为一个系统程序量之大，组织的规则和要求之多。审查员要做的是N的N次方的核对。现在也有一些计算机程序，按一定的规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛病，VB就有这样的程序。如果没有计算机程序的帮助，审查员会“疯”掉的。,测试审查,测试审查是对测试结果进行审查，它审查的内容包括： （1）对测试用例的审查：测试用例的哪些要素（用例名、测试日期、预期测试结果等）是否齐备？（宽度） （2）在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了？（深度） （3）测试过程（步骤、环境、用户模拟等）的设计是否正确、恰当？ （4）预期值与结果值的差异统计； （5）测试目的是否达到？,1、你的测试设计（单元、集成、系统）2、你的设计组织（过程）3、你的测试覆盖（宽度、深度）4、你的测试评审,问题2：,1