软件测试自动化方法与工具_第1讲 (概述)

1、软件测试自动化方法与工具主讲 吴取劲2016.4第1讲 软件测试概述本讲重点讨论以下内容： 相关知识概述； 软件测试的目标、活动和原则； 软件测试的流程； 软件测试的分类； 软件测试项目启动； 软件测试的基本活动。1.1 相关知识概述 做任何事，应从概念入手，才能少走弯路，才能对此概念相关的问题有一个正确的理解分析，最终解决问题。 软件测试是软件质量保证的一种手段，测试的目的就是发现错误以及避免这些错误的发生。 软件测试的对象-软件(定义、内容、生命周期) 软件测试的基本概念(定义、内涵、基本方法)1.1.1 软件的定义 软件是计算机系统中与硬件相互依存的一部分，它是包括程序、数据及其相关文档

2、的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。1.1.2 软件工程的内容 软件工程研究的主要内容是软件开发技术和软件开发管理两个方面。在软件开发技术中，主要研究软件工程方法、软件工程过程、软件开发工具和环境。 1.1.3 软件的生存周期 软件生存周期概念的出现可以帮助我们较为全面地认识软件开发。在1998年制订和公布的国家标准GB8566-88计算机软件开发规范中，将软件生存周期划分为八个阶段，即：可行性研究和计划、需求分析、概要设计、详细设计、实现、组装测试、确认测试、使用和维护。该标准为每

3、个阶段规定了任务、实施步骤、实施要求以及完成的标志。对软件生存期按此方式做八个阶段的划分大致符合也适应瀑布模型。1.1.4 软件测试的基本概念 软件测试是软件质量保障的一种重要的方法，是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，是为了尽快尽早地发现在软件产品中所存在的各种各种问题与用户需求、预先定义的不一致性。检查软件产品的bug，写成测试报告，交于开发人员修改。1.1.4 软件测试的基本概念 对软件测试概念的理解 保证软件质量的有效手段； 软件测试方法没有完全标准化和统一化； 软件测试是有局限性的； 调试与测试的区别。

4、1.2 软件测试的目标、活动和原则 目标、活动和原则，强调三维一体1.2.1 理解与分析 软件测试的目的决定了如何去组织测试。 如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。 如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。1.2.1 理解与分析 (1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 (2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 (3)程序员应避免检查自己的程序。 (4)在设计测试用例时，应当包括合理的输入条件和不合

5、理的输入条件。1.2.1 理解与分析 (5)充分注意测试中的群集现象。 (6)严格执行测试计划，排除测试的随意性。 (7)应当对每一个测试结果做全面检查。 (8)妥善保存测试计划，测试用例，出错统计和 最终分析报告，为维护提供方便。1.2.2 软件测试的方法 软件的测试方法有3种，即用试题测试、用新旧两个系统作平行处理测试和软件测试自动化工具测试。 1. 用试题检查法 2. 用新旧两个系统作平行处理检查 3. 软件测试自动化工具测试1.2.3 软件测试的任务 软件测试阶段有几方面的任务： 制定测试计划； 制作测试用例； 单元测试（程序测试）； 功能测试； 性能测试； 集成测试（子系统测试）；

6、系统测试； 验收测试； 制作测试报告。1.3 软件测试的分类 软件测试根据是否运行程序可分为静态测试和动态测试： 静态测试包括桌面检查、代码审查和代码走查等方法； 动态测试根据测试用例设计是否依据内部结构可以分为黑盒测试和白盒测试： 白盒测试包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖、线性代码序列及跳转测试等; 黑盒测试包括等价类划分、边界值分析、因果图分析、错误猜测、状态转换测试等。1.3 软件测试的分类 根据软件开发的不同阶段可以将软件测试划分为单元测试、集成测试、系统测试、验收测试、回归测试、验证测试、确认测试、测试、测试和测试等。1.3 软件测试的分类 根

7、据被测试软件的开发方法和应用环境的不同可以分为面向对象软件测试、面向方面软件测试、面向服务软件测试、构件软件测试、嵌入式软件测试、Web应用软件测试等,后面还要出现普适计算环境下的软件测试、云计算环境下的软件测试等。1.3 软件测试的分类 根据软件不同特性和方面的测试可以分为:负载测试、压力测试、性能测试、安全性测试、安装测试、可用性测试、稳定性测试、授权测试、用户接受性测试、一致性测试、配置测试、文档测试、兼容性测试和Playtest等。1.3 软件测试的分类 根据不同特殊的测试技术可以有:组合测试、蜕变测试、变异测试、演化测试、FUZZ测试、基于性质的测试、基于故障的测试、基于模型的测试、

8、基于操作剖面的测试、基于用例和/或用户陈述开发测试用例、基于规格说明的测试、统计测试、逻辑测试、随机测试、自适应随机测试、GUI测试、冒烟测试和探索测试等。1.4 软件测试的流程 软件测试的流程一般要考虑3点： 软件测试工作总体流程图 软件测试流程关系图 软件测试活动分布图1.4.1 软件测试工作总体流程图 软件测试的流程图分为软件测试工作总体流程图、需求阶段测试工作流程、设计与编码阶段测试工作流程、集成测试和系统测试阶段工作流程图。 如图1-3，图1-4，图1-5，图1-6所示。图1-3软件测试工作总体流程图图1-4 需求阶段测试工作流程 图1-5 设计与编码阶段测试工作流程图1-6 集成测

9、试和系统测试阶段工作流程图1.4.2 软件测试活动分布图 软件测试活动分布在软件开发的各个阶段，具体如图1-7所示。 图1-7 软件测试活动分布图1.4.3 软件测试流程关系图 软件测试流程与各个阶段有着密切的联系，如图1-8所示。图1-8 软件测试流程关系图1.5 软件测试项目启动 1.5.1测试工作组的组建 1.5.2工作计划与日程安排 1.5.3测试需求的收集1.5.1测试工作组的组建 测试组长(测试项目负责人)在项目启动开始时就应已经确定，测试组成员由测试组长来确定，或由测试组长与项目经理一起协商确定项目测试组人员。1.5.1测试工作组的组建角色角色姓名姓名具体职责或注释具体职责或注释

10、测试项目负责人管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理测试分析员确定测试计划、测试内容、测试方法、测试数据生成方法、测试（软、硬件）环境、测试工具，评估测试工作的有效性测试设计员设计测试用例，确定测试用例的优先级，建立测试环境测试员执行测试、记录测试结果1.5.2工作计划与日程安排 工作计划与测试计划有部分内容重叠，更强调人员的协调，项目组内部的沟通，具体体现在细化到每周的日程安排上。 实例：工作计划与日程安排WP_20120408_A.doc （链接）1.5.3 测试需求的收集 1）功能需求 需求文档、理论模型、设计文档、用户使用说明文

11、档 2）非功能需求 性能、有效性、可靠性、可维护性、可扩展性、可移植性 3）用户需求 所有功能的可用性 良好的GUI 数据安全 软件使用无时间障碍1.6 软件测试活动 1.6.1测试计划制订与评审 1.6.2测试用例设计与评审 1.6.3测试用例执行与记录 1.6.4测试结果分析与回归测试 1.6.5测试报告编制1.6.1测试计划制订与评审 1. 内涵：测试计划是为了解决测试目标、任务、方法、资源、进度和风险等问题，测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情况的变化不断进行调整，以便于优化资源和进度安排，减少风险，提高测试效率，并及时修改“测试计划书”。1.6.1

12、测试计划制订与评审 2. 内容：在测试计划过程中，主要做好下列各项工作： 确定软件功能性、非功能性的测试需求，以及各个阶段的测试任务。 进行测试范围分析，从而对测试工作量进行估算。工作量估算方法主要介绍了工作分解结构表方法，并给出实例。 测试资源需求、团队组建，包括培训。 测试里程碑和进度的安排。 对测试风险进行分析。 制定有效的测试策略。1.6.1测试计划制订与评审 3. 计划书要素即评审要点： 编写目的（含测试目标）、项目背景、测试范围、测试需求、参考文档、提交文档、进度安排、测试资源、测试策略、测试方法、管理方式。 在计划书中，有些内容是介绍测试项目的背景、所采用的技术方法等的，这些内容

13、仅仅作为参考，但有些内容(如人员组成、日程安排)也可以看作是一种结论，或者承诺，是必须要实施或达到的目标，如测试小组的结构和组成、测试项目的里程碑、面向解决方案的交付内容、项目标准、质量标准、相关分析报告等。 实例：参考国家标准测试计划(GB856788)中制定的测试计划模板（链接）。1.6.2测试用例设计与评审 1测试用例设计的主要影响因素 (1)需求目标，有功能性的需求目标也有非功能性的需求目标。功能性的测试比较清楚，正确与否的判断能一目了然。而非功能性测试，其相对性比较强，需要从不同的侧面进行比照。 (2)用户实际使用的场景。从用户的角度来模拟程序的输入，包括用户的操作习惯，使产品更能贴

14、近用户的需求。加强培养测试人员的用户体验意识，让他站在用户的角度去思考产品的每一个特性，确保为测试用例建立正确的判断依据。1.6.2测试用例设计与评审 1测试用例设计的主要影响因素 (3)软件功能需求规格说明书、产品设计文档等，是测试用例设计的主要参考文档。这些文档对产品特性的描述方法、格式和详细程度，也会影响到测试用例的设计。 (4)测试的方法对测试用例的设计影响非常大。在测试用例的设计思路上，白盒测试方法和黑盒测试方法是从不同的哲学思想宋解决问题的，前者从内部逻辑思路来考虑，后者从外部功能思路来考虑。1.6.2测试用例设计与评审 1测试用例设计的主要影响因素 (5)测试的对象。客户端软件和

15、服务器端系统、分布式系统和集中式系统、异步系统和同步系统等，其测试用例的侧重点或测试剖面是不同的，它们从不同的侧面去发现软件系统的弱点或薄弱环节。 (6)软件实现所采用的技术。不同的技术，要进行不同深度的挖掘，而且采用的测试工具也不同。1.6.2测试用例设计与评审 2测试用例设计的基本思想 (1)设计测试用例时，要寻求系统设计、功能设计的弱点。测试用例需要确切地反映功能设计中可能存在的各种问题，而不要简单拷贝产品规格设计说明书的内容。 (2)设计正面的测试用例，应该参照设计规格说明书，根据关联的功能、操作路径等设计。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的

16、需求功能，覆盖率达100。 (3)设计负面的、异常的测试用例，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷，这显得更为重要。1.6.2测试用例设计与评审 3测试用例的元素：测试用例是对测试场景和操作的描述，所以必须给出测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为5WlH。 测试目标：Why为什么而测?功能、性能、可用性、容错性、兼容性、安全性等。 测试对象：What测什么?被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。 测试环境：Where在哪里测?测试用例运行时所处的环境，包括系统的配置 和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网

17、络环境。1.6.2测试用例设计与评审 3测试用例的元素：测试用例是对测试场景和操作的描述，所以必须给出测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为5WlH。 测试前提：When什么时候开始测?测试用例运行时所处的前提或条件限 输入数据：Which哪些数据?在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。 操作步骤：How如何测?执行软件和程序的先后次序步骤等。如打开对话框、 点击按钮等。1.6.2测试用例设计与评审 3测试用例的元素 评判的依据：期望的输出结果。所期望的输出结果，实际就是测试的验证点，每个测试用例最好只有一个验证点。 辅助信息：所述模块、优先级、层

18、次。为了今后管理方便，还要加上其他信息，如测试执行的预估时间、关联的测试用例，是否为自动化测试类别、关联的缺陷等。1.6.2测试用例设计与评审 4测试用例评审要点 测试用例是软件测试的准则，完成编制后应组织专家评审，需通过后才可以使用。评审委员会可由项目负责人和测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。1.6.2测试用例设计与评审 4测试用例评审要点-可从下面几个方面评判测试用例： 测试范围的覆盖率。依据特定的测试目标的要求，覆盖所有的测试范围或内容。 测试用例设计能反向思维，有效地发现缺陷。测试是为了发现缺陷，能更快地发现缺陷或更有可能发现潜在缺陷的测试用例可提高测试效率。

19、易用性。设计思路容易被理解，测试用例的组织结构合理，测试用例的执行比顺畅，操作连贯性好。 易读性。前提条件、步骤和期望结果等描述清楚、准确。1.6.2测试用例设计与评审 4测试用例评审要点-可从下面几个方面评判测试用例： 易维护性。应该以很少的时间宋完成测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。 测试用例的评审，可以依据测试用例设计的基本思想从正、反两方面进行检查。正面测试用例要求全面，反面测试用例要有创造性，思路要开阔。 实例：参考ANSI/IEEE829-2983中与测试设计相关的编写规范制定的测试用例模板（链接）。1.6.3测试用例执行与记录 1

20、测试执行的准备 在测试执行前需要做些准备，包括环境建立、人员培训等，做好了测试执行的准备工作，实际的执行过程就会顺利，执行的效率和质量都会有保证。1.6.3测试用例执行与记录 1测试执行的准备 （1）培训和知识传递 测试用例执行一般难以到达较高的测试自动化程度。如果测试自动化程度不高，测试执行也必定要求更多的人员参加。因为有一部分将要参与测试的执行人员，不是从一开始就参加了项目的需求分析和设计的审查，以及测试用例设计，而是在测试用例设计快结束、代码完成之前的某个时间进入该项目的。这部分测试人员对项目背景不够了解，对产品特性不够熟悉，对测试策略和测试用例设计的要点还不清楚，这就要求对测试人员进行

21、相关的培训和产品知识的传递。 在实际操作中，让参与执行的测试人员尽早参与一些项目介绍会、技术讨论会，参与需求文档、产品规格说明书、设计的技术文档、测试计划和用例等的评审和复审工作。1.6.3测试用例执行与记录 1测试执行的准备 （2）测试任务安排 对于规模较大的项目，测试任务的安排需要考虑下列的问题或困难： 针对工程师个人的特点和特长来安排适合工程师的特定任务。例如，某些部分 简单但需要逐项测试，测试工作量大，就安排一个平时工作非常细心 的工程师来负责测试。而对于接口测试，需要安排技术强、思维开阔的工程师负责测试。1.6.3测试用例执行与记录 1测试执行的准备 （2）测试任务安排 不同的阶段可

22、以适当交叉互换测试人员，既能发挥每个人的不同思维空间，提高测试覆盖率，又能起着相互检查、督促的作用，更好地保证测试的质量。 任务安排均匀、公平，不要造成一部分人的任务过重，一部分人的任务过轻。这要求分配任务的测试组长非常了解被测试的各部分，对各个模块的测试难度和对应的测试用例数了解得一清二楚。另外一种方法是，为每个测试用例设定估计时间，有了这样的数据，就很容易获得测试的工作量。1.6.3测试用例执行与记录 1测试执行的准备 （2）测试任务安排 将关联性很强的若干个(子)任务安排给一个人。 任务不能安排太紧，适当留有余地。任务安排很紧，测试执行会被打折扣，或者测试中的一些细节、疑点会被忽略，测试

23、人员也会缺少思考，不会举一反三。1.6.3测试用例执行与记录 1测试执行的准备 （2）测试任务安排-步骤建议 1)在做测试计划时，对测试执行所需要的资源进行初步规划，一般会增加比较多的余量(15一20)，使测试资源有足够的准备。 2)在设计测试用例时，就预估每个测试用例执行所需的时间，并记录在测试用例 数据库中，为后期估计备用。 3)根据每个测试用例的预估时间，可以算出每个测试模块的工作量。1.6.3测试用例执行与记录 1测试执行的准备 （2）测试任务安排-步骤建议 4)分析软件模块之间的关系，然后根据模块的关联性和相应的工作量进行模块组 合。 5)根据每个人的特点，将组合的模块分配给各个测试

24、人员。 6)一轮测试结束后，交叉互换测试的模块组合。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 1)测试工具选择的标准 特有的功能特性要求，是选择测试工具最关注的内容。但并不是说，测试功能越强大越好，因为解决问题是前提，适用才是根本。选择测试工具，需要针对测试的实际需求，了解适合这一需求的各种产品，并做进一步的调查。然后从中选出34种成熟的、优秀的工具软件作为候选工具，通过使用完成一个实际的软件测试任务，对其进行评估和分析来做最终的决定。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 1)测试工具选择的标准 事实上

25、，测试过程中80以上的缺陷是手工测试发现的，仅有不到20的缺陷是靠工具测试发现的，而且这还得要求测试人员合理地使用工具。因而过分强调测试工具的作用，极力追求各种软件测试工具，是软件测试本末倒置的表现。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 1)测试工具选择的标准 成本的考虑也是必须的。项目开发有别于产品开发，项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求、用户界面变动都较大，这种情况下就不适合引入功能测试工具。因为对于变化大的需求和界面，录制或开发、修改脚本的工作量远远大于手工测试的工作量，又不能通过今后大量重复的回归测试收回成本，

26、这种情况下运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。这时，可以考虑引入白盒测试工具，特别是针对代码进行直接检查、分析的工具，用以提升代码质量。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 1)测试工具选择的标准-可供借鉴的几个指标： 跨平台和环境的兼容性； 易使用； 测试用例的管理能力； 支持脚本语言； 面向数据驱动(Data-Drivenoriented)的脚本； 对程序界面中对象的识别能力； 测试工具的集成能力； 图表功能。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 2）测试环境的建立 测试环

27、境包括被测试的软件系统环境，还包括执行测试用例的自动化环境或测试服务器的客户端环境。通常使用列表的形式给出测试运行所需的硬件和软件信息，如示例。1.6.3测试用例执行与记录 1测试执行的准备 （3）测试工具的选择与测试环境的建立 2）测试环境的建立-示例测试环境需求测试环境需求说明说明是否已准备是否已准备硬件：计算机10台(CPU 1+GB，内存512+MB，硬盘40+GB，网卡)测试用的客户机服务器2台(Dual CPU 2.8GB，内存2+GB)Web服务器、管理服务器，构造备份、故障转移机制服务器2台(Dual CPU 2.8GB，内存8+GB)中间件服务器、数据库服务器，构造备份、故障

28、转移机制。软件：Linux操作系统安装于被测软件系统的服务器端WindowsXP OS安装于测试用的客户机端JMeter性能测试工具C+test单元测试工具1.6.3测试用例执行与记录 2测试执行结果的记录 结果记录信息通常应该包括测试用例ID号、输入数据、期望结果、实际执行结果、测试人、测试时间、BUG关联信息等。 使用EXCEL表格记录便于统计。 实例：单元测试用例执行情况表（链接）、功能测试用例执行情况表（链接）。1.6.4测试结果分析与回归测试 依据测试执行结果的记录分析确定BUG，并形成缺陷报告文档提供给程序员进行程序修改。 实例：缺陷报告模板（链接）。 对缺陷的描述通常使用4大类2

29、0小项属性进行描述，见下表：类别类别项目名称项目名称含义说明含义说明可跟踪信息缺陷标识缺陷的唯一标识，用于识别、跟踪、查询、排序、存储管理等，可以使用数字序号表示基本描述信息标题对缺陷的概括性描述，方便列表、浏览、管理等详细描述包括前提、操作步骤、期望结果、实际结果等环境缺陷发现时所处的测试环境，包括操作系统、浏览器等所属项目/模块 缺陷所属哪个具体的项目或模块，要求精确定位至模块、组件级产品信息属于哪个产品、哪个版本等状态缺陷一旦被发现之后，其被跟踪过程中所处的状态，如“激活的、修正的、关闭的”等状态构成了缺陷自身的生命周期修正所需 信息严重程度指因缺陷引起的故障对软件产品使用或某个质量特性

30、的影响程度。其判断完全是从客户的角度出发，由测试人员决定。一般分为“致命”、 “严重”、 “一般”、 “较小” 等4种程度优先级缺陷被修复的紧急程度或先后次序，主要取决于缺陷的严重程度、产品对业务的实际影响，需要考虑开发过程的需求(对测试进展的影响)、技术限制等因素，由项目管理组(产品经理、测试开发组长)决定。一般分为“最高的、正常的、最低的”3种级别类型属于哪方面的缺陷，如功能、用户界面、性能、接口、文档、硬件等可能性缺陷产生的频率。大多数缺陷产生的频率是100，但也有一些缺陷产生的频率在1-90之间缺陷提交人缺陷提交人的名字(会和邮件地址联系起来)，即发现缺陷的测试人员或其他人员缺陷指定解

31、决人估计修复这个缺陷的开发人员，在缺陷状态下由开发组长指定相关的开发人员； 自动和该开发人员的邮件地址联系起来。当这缺陷被报出来时，系统会自动发出邮件来源缺陷产生的地方，如产品需求定义书、设计规格说明书、代码的具体组件或模块、数据库、在线帮助、用户手册等供事后分析 所需的信息产生原因产生缺陷的根本原因，包括过程、方法、工具、算法错误、沟通问题等，以寻求流程改进、完善编程规范和加强培训等，有助于缺陷预防构建包跟踪用于每日构建软件包跟踪，是新发现的缺陷，还是回归缺陷，基准(baseline)是上一个软件包版本跟踪用于产品版本质量特性的跟踪，是新发现的缺陷，还是回归缺陷，基准是上一个版本提交时间缺陷

32、报告提交的时间修正时间开发人员修正缺陷的时间验证时间测试人员验证缺陷并关闭这个缺陷的时间1.6.5测试报告编制 测试报告应具有如下结构： (1)产品标识。 (2)用于测试的计算机系统。 (3)使用的文档及其标识 (4)产品描述、用户文档、程序和数据的测试结果。 (5)与要求不符的清单。 (6)针对建议的要求不符的清单，产品未作符合性测试的说明。 (7)测试结束日期。1.6.5测试报告编制 主要内容集中在第四项内容中，即产品描述、用户文档、程序和产品描述中提供关于用户文档、程序以及数据(如果有的话)的信息，其信息描述应该是正确的、清楚的、前后一致的、容易理解的、完整的并且易于浏览的。更重要的是，

33、在测试报告中，产品的描述和测试的内容有着相对应的关系，也就是说产品描述还要包含功能说明和性能、易用性、可维护性、可移植性等的说明。1.6.5测试报告编制 特别是在功能说明中，包括安装、功能表现以及功能使用的正确性、一致性；不仅需要概述产品的用户可调用功能、需要的数据等，还要将系统相应的边界值、安全性要求描述清楚。易用性说明中，包括易理解性、易浏览性、可操作性等方面，具体描述对用户界面、所要求的知识、适应用户的需要、防止侵权行为、使用效率和用户满意度等。 实例：依据国标GBT 175441998中(附录C)对测试报告列出的具体要求，制定的测试报告模板（链接）。1.6.6测试版本管理 由于核电软件

34、的特殊性，在构建理论模型与形成软件开发需求文档和设计文档时既需要核技术知识又要有软件工程经验，交叉学科的融合必然带来不同专业技术人员的融合，需求设计阶段针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系，评审通过后建立设计基线；对于测试的配置过程应特别说明测试的版本与编码版本的对应关系，各阶段测试完成后建立测试基线；在交付前配置审核完成后建立产品基线（包含程序以及有关文档配置项）。1.6.6测试版本管理 针对实际工作中暴露出的问题，对软件版本管理提出两点建立： 1)当软件升版时，在文件头部注释部分和软件启动文件中（如main.cpp）一定要将版本信息标明，还应

35、标注升版过程中的改版信息； 2)进行传递过程中，应该将整个工程目录结构整体打包成RAR压缩文件，并且RAR压缩文件的名称应该包含软件名称、软件版本和文档版次等。 例：“SGEF(测试版本V1.01)_0.rar” 注意：测试工程中存在文档在多种角色中相互传递的需求，文档名称的统一规范将使工作更为有效。命名规则TDRE_20150113_A_0.doc1.6.7给程序员的几点建议 1需求问题，函数单元设计应该有设计流程图，这是单元测试的重要依据。 2函数单元设计中的输入与输出应该有明确的约束条件，前置条件和后置条件必须清晰明确。1.6.7给程序员的几点建议 3约束条件检查问题： 方案1：函数单元

36、设计中首先进行入口约束条件的检查（有利于代码重用）； 方案2：放在软件模块主流程之前进行检查（结构清晰，单函数单元的耦合性较高），需要在单元注释中进行入口的前置条件说明。 4程序设计中避免直接使用组合条件，改用if嵌套的方法代替（提高代码逻辑清晰度，避免或减少出现不可达代码的可能性）。 5推荐一本书：Boswell编写可读代码的艺术1.7自动化测试概述 自动化测试是人们在测试工作的过程中，为了提高工作效率，不断的对操作方法测试技术及测试工具进行改进，减少测试人员的手工劳动，节省时间和成本。软件测试技术研究组软件测试技术研究组 中国信息大学中国信息大学1.7.1自动化测试概念 自动化的概念是人们

37、在工业生产的过程中，为了提高工作效率，不断的对操作方法或者技术或者工具进行改进，减少人的手工劳动，节省时间和成本。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 软件测试技术研究组软件测试技术研究组 中国信息大学中国信息大学1.7.2 自动化测试的过程 1）自动化测试需求分析 2）测试计划 3）自动化测试框架的搭建 4）测试用例设计编写测试用例或开发测试脚本，并文档化； 5）测试调试测试（针对自动化测试脚本）； 6）评估评估测试结果并改进测试过程。软件测试技术研究组软件测试技术研究组 中国信息大学中国信息大学1.7.3 自动化测试工具选型的原则 实现自动化测试，测试工具的选择很重要，而目前还没有一个单一的测试工具能用来完成所有的测试需求。测试工具品种不一，功能性能各异。对自动测试工具的适当选择，很大程度上决定了该工具能否获得相应的投资回报 (1) 测试管理类工具：TestManager、QC (2) 功能测试工具：QTP、Marathon (3) 性能测试工具 ：IBM RPT、LoadRuner软件测试技术研究组软件测试技术研究组 中国信息大学中国信息大学1.7.4 自动测试的特点 能执行更多更频繁的测试，使某