“框”起软件测试-建立软件测试管理的体系课件

1、七、“框”起软件测试 建立软件测试管理体系 让软件测试走向规范 软件产品的监视和测量 对不符合要求的产品的识别和控制 产品设计和开发的验证 软件过程的监视和测量 第1页，共41页。七、“框”起软件测试 建立软件测试管理体系 建立测试管理体系 测试规划 测试设计 测试实施 配置管理 资源管理 测试管理 第2页，共41页。 测试规划 确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。 测试规划与软件开发活动同步进行。在需求分析阶段，要完成验收测试计划，并与需求规格说

2、明一起提交评审。类似地，在概要设计阶段，要完成和评审系统测试计划;在详细设计阶段，要完成和评审集成测试计划;在编码实现阶段，要完成和评审单元测试计划。对于测试计划的修订部分，需要进行重新评审。 第3页，共41页。测试规划 如何指定成功的测试计划？ “工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。第4页，共41页。测试规划产品基

3、本情况调研 目的 重点描述如何使测试建立在客观的基础上，定义测试的策略、测试的配置，粗略地估计测试大致需要的周期和最终测试报告递交的时间 变更 说明有可能会导致测试计划变更的事件。包括测试工具是否改进，测试环境是否改变，或者是否添加了新的功能。 技术结构 可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试要达到什么样的目的，每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。 产品规格 就是制造商和产品版本号的说明。 测试范围 简单描述如何搭建测试平台以及测试

4、的潜在风险。 项目信息 说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。 第5页，共41页。测试规划测试需求说明 功能的测试 理论上是测试所要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 设计的测试 对于一些用户界面、菜单的结构、窗体设计是否合理等的测试。 整体考虑 这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。第6页，共41页。 测试设计 根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行，其结果可以作为各阶段测试计划的附

5、件提交评审。第7页，共41页。 测试实施 使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件缺陷，最终得到测试报告。 第8页，共41页。 测试实施如何配置软件测试环境？ 配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。 测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大

6、多数指标的主要环境。第9页，共41页。 测试实施如何配置软件测试环境？ 一般来说，配置主测试环境可遵循下列原则： 1.符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。 2.选用比较普及的操作系统和软件平台。例如，一个软件若声称支持“Windows9X/ME/NT Workstation/2000 professional”和“MS Office 97/2000/XP”，一般我们会采用如“Windows 2000professional+MS Office 2000”的流行环境。 3.营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软

7、件影响测试实施。 4.无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。第10页，共41页。 配置管理 测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。 第11页，共41页。资源管理 包括对人力资源和工作场所，以及相关设施和技术支持的管理。如果建立了测试实验室，还存在其他的管理问题。 第12页，共41页。测试管理 采用适宜的方法对上述过程及结果进行监视，并在适用时进行测量，以保证上述过程的有效性。如果没有实现预定的结果，则应进行适当的调整或纠正。 此外，测试系统与软件修改过程是相互关联

8、、相互作用的。测试系统的输出（软件缺陷报告）是软件修改的输入。反过来，软件修改的输出（新的测试版本）又成为测试系统的输入。 第13页，共41页。八、成功测试管理的九大原则 许多测试管理者是从技术部门进到管理阶层的。尽管他们有可能受过很多测试或软件工程的培训和指导，但他们还是很难经常从失败和错误中学到管理技巧。作为一个管理者，你有两项基本工作：找出为你工作的最好的员工并且建立一个能够使员工完成工作的环境（使他们最好地完成工作）。总是那些人帮助人们最好地完成工作。 第14页，共41页。1. 为工作雇佣最好的员工；2. 安排每周与你的每个小组成员在不被打扰的环境进行谈话；3. 假定员工知道如何完成他

9、们的工作的人员；4. 对待你的员工要用他们能接受的方式,而不是你可以自己可以接受的方式“对待别人要用你愿意接受的方式”（己之不予，勿施于人）这条黄金法则可能会对 多生活中的纯的社交因素有效，但是并不是总对工作有用； 5. 重视结果而非时间；6. 承认自己的错误；7. 决定承担一个项目必须首先问你的组员是否有能力完成。8. 计划定期的培训；9.计划测试。第15页，共41页。九、软件测试的基本方法 从测试人员角度看，可分为手动测试和自动测试。 从源代码的角度，可分为单元测试和功能测试。 从理论定义来分，可分为黑箱测试，白箱测试和灰箱测试。 从测试实际的前后过程来分，可分为单元测试、组装测试（集成测

10、试）、确认测试和系统测试。 第16页，共41页。九、软件测试的基本方法 有六个有关软件测试方法的基本概念是很重要的：白箱测试，黑箱测试，灰箱测试，有效用例和无效用例，边界条件以及等价类测试。 第17页，共41页。九、软件测试的基本方法 白箱测试或白盒测试（White-boxtesting或glass-boxtesting） 是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。第18页，共41页。九、软件测试的基本方法 黑箱测试或黑盒测试（Black-boxtesting)是通过使用整个软件或某种软件功能

11、来严格地测试，而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。 第19页，共41页。第20页，共41页。黑盒测试方法揭密一、黑盒测试在快速应用开发（rad）环境中的重要作用 随着rad环境的发展，软件工程面临新的挑战，其中包括：1.应用系统的规模越来越庞大，结构越来越复杂；2.开发团队人员越来越多，分工越来越细；3.项目投资日益提高，导

12、致投资风险增大。 随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展,对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。第21页，共41页。 二、黑盒测试的操作步骤 在传统的软件开发生命周期当中，测试工作往往被搁置到整个开发过程的后期进行，也就是说,当应用程序的编码工作已经基本完成,才开始进行测试，这样做的缺点在于： a）由于应用程序庞大而复杂，测试工作千头万绪,测试人员难以组织科学、全面的测试用例，从而大幅度提高了测试成本，并严重影响测试的全面性和有效性；b）由于缺陷所涉及的模块从开发到测试之间的时间间隔较长,使得

13、程序员的修改和维护工作要付出更大的代价；c）由于受到分发日期的限制，测试工作往往是在忙碌中结束的,而将大量的缺陷遗留给最终用户，也就是说，真正的测试工作实际上是由最终用户来完成的。因此，为了保证测试工作科学、精确、全面、有序地进行，应该采取一边开发一边测试的策略，使得开发工作与测试工作平行进行，这也就是俗话所说的“越早测试越好”的概念。第22页，共41页。一套完整的测试应该由五个阶段组成： 1测试计划 首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即

14、是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。2测试设计 将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。3测试开发 建立可重复使用的自动测试过程。4测试执行 执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。5测试评估 结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

15、 第23页，共41页。三、手工测试与自动测试的比较手工测试无法保证黑盒测试的科学性与严密性，这是因为：1.测试人员要负责大量文档、报表的制订和整理工作,会变得力不从心；2. 受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试；3. 对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含混不清,没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率；4. 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一，测试花费的时间越长，测试的严格性也就越低；5. 难以对不可视对象或对象的不可视属性进行测试。因此，自动测试成为最佳的解决方案。所谓自动测试,实际上

16、是将大量的重复性工作交给计算机去完成,一个优秀的自动测试工具，不但可以满足科学测试的基本要求,而且可以节约大量的时间、成本、人员和资源,并且测试脚本可以被重复利用（包括被不同的项目所利用）。第24页，共41页。九、软件测试的基本方法 灰箱测试或灰盒测试（Gray-boxtesting）： 灰箱测试就像黑箱测试一样是通过用户界面测试但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于：如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测

17、试它的各项性能。第25页，共41页。九、软件测试的基本方法有效用例(Validcase)或者叫合法输入用例：是那些已知软件程序能正确地处理的测试用例。一般是指软件输入的测试用例。比如说,在MicrosoftExcel中，用键盘输入“=1+1”,看到的结果是“2”，这里输入的有效用例是“=1+1”，无效用例（Invalid case有人叫不合法输入用例）或者出错用例(error case)：是那些事先就知道软件程序不支持处理的测试用例。比如说在MicrosoftExcel中，用键盘输入“=a+1”,看到的结果是“#NAME?”,这里输入的“=a+1”既是无效用例同时也是出错用例。第26页，共41

18、页。九、软件测试的基本方法 边界条件（BoundaryCases）： 环绕边界值的测试。通常意味着最大值，最小值或者所设计软件能够处理的最长的字符串等等。比如说某软件字体的字号支持范围是:从8到72。那么边界测试用例应该包括：小于8,等于8,等于72和大于72。 第27页，共41页。测试用例的设计-边界值法 边界值分析也是一种黑盒测试方法，适度等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。 第28页，共41页。测试用例的设计-边界值法一、如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，

19、以及刚刚超过这个范围边界的值作为测试输入数据； 二、如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数做为测试数据； 三、如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；四、如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例； 五、分析规格说明，找出其他可能的边界条件。 第29页，共41页。九、软件测试的基本方法 等价类（equivalentclasses）： 等价类测试用例指的是如果有很多测试用例执行再多也不会找到新的缺陷。因为虽然输入和输出结果有所不同，但是

20、它们都通过同样的软件的源代码路径。通常只要一个源代码程序的路径是用于处理一定数值范围内的所有数值，那么除了边界值以外，在边界值范围以内的所有数值一般都属于等价类。因为如果软件程序能正确处理一个值，也就意味着该程序能正确处理在这个范围内的除了边界值以外的其他任何有效输入值。我们来用以上软件字体的字号来举例说明。软件支持的字号范围是：从8到72。那么8和72之间的所有支持的字号都可以被认为是等价类的测试用例。再比如：测试超链接时两个用例yahoo/和yahoo2/也是等价类的测试用例。 第30页，共41页。第31页，共41页。十、软件测试的误区 人们对测试存在着一些误区，例如：1 、测试是想象到可

21、能出现的问题，然后试图验证这些问题。实际上能想象到的只是一部分的情况，随意性太大，还要取决于开发人员的经验，对业务的熟悉程度和他想象到的程度。2 、让时间有富裕的员工去做一些测试。表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业

22、的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。3、测试是相对简单的工作。实际上并非如此，要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题，也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。 第32页，共41页。十、软件测试的误区4、使用了测试工具，就是进行了有效的测试 5、存在太多的无法测试的东西 6、测试代码可以随意写 7、单元测试和验收测试没有什么区别 结论：测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一

23、件非常困难的事情，这也决定了有效的测试决不是简单的依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识；还要是软件测试规范化，只有这样，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。第33页，共41页。十一、软件测试的复杂性和经济性 测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下： 、系统的目的 、潜在的用户数量 、信息的价值 第34页，共41页。十二、测试中常见问题分析及对策 我们一般把发现的错误bug(我们也称为缺陷d

24、efect)按严重性分为4类：死机(系统崩溃或挂起)、致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。 我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优先级越高。第35页，共41页。形象类问题：不专业、用户不信任 1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。 2、不够专业，缺乏基本知识，而又没有高手检查。 3、界面中英文

25、混杂，经常弹出莫名其妙的信息，而且还拼错单词。 4、缺省认为用户使用某种分辨率； 5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则 6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件) 。 7、界面元素参差不齐，文字不能完全显示。 第36页，共41页。 可用性问题：用户无法使用或不方便使用 “用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品有用的方面。” 下面是一些用户界面错误的例子： 1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可预料的后果。 2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值。 下面是一些低效的用户界面的例子： 1、表达不清或过于模糊的信息提示。 2、要求用户输入多余的、本来系统可以自己得到的数据。 3、为了