软件测评能力提升方案(共34页)

《软件测评能力提升方案(共34页)》由会员分享，可在线阅读，更多相关《软件测评能力提升方案(共34页)（34页珍藏版）》请在装配图网上搜索。

1、精选优质文档-倾情为你奉上软件测评工程能力提升方案咨询方将在上述调研报告基础上，提出详细的测评工程能力建设方案。方案的主要包括以下方面：1 软件测试实用规程1.1 软件测试的认识如前所述，目前软件测试领域的理论体系仍然不算成熟，软件测评专业能力建设本身是一个复杂的系统工程，牵涉的人员和环节众多，从调研结果来看，部分研发人员对测试的认识存在一些偏差，这将给软件测评专业建设带来风险。软件测评工程能力，首先是测试意识的提升。技术保障，观念先行，一个研发项目涉及的人员尤其是大多数的开发人员的测试意识是决定性的，只有将软件测试放到软件全生命周期的大背景下来考察，使全体人员对软件质量全程保证的角度来重新认

2、识测试，具体的测试方法、测试技能提升才有普遍意义。基础理论和方法论的普及，软件测试的本质、含义、定位和作用的深入认识，将是项目能否顺利开展的前提。软件测试本质上是一个证伪而不是证明的过程。因此，从广义上来说，只要是对软件本身质量保证相关的，都可以纳入软件测试的范围。无论是在软件研发的需求分析、架构设计、详细设计、代码实现还是后面的测试阶段，都可以开展测试活动；无论是系统设计人员、软件编程人员或者验证人员、服务人员、市场人员，都可以成为测试人员；也无论是文档评审、代码审查、功能调试、系统验证等等活动，都可以是一种测试活动；无论是人工验证、形式证明、代码静态分析工具、单元测试工具还是自动化测试工具

3、等手段，都可以成为有效的测试手段。只要有确定的人员，采用某种确定的方法手段，按照确定的项目内容，对影响软件质量的相关文档、代码、程序、数据等进行验证，都是执行了有意义的测试。经过这些验证活动之后，我们得出有条件的结论，这个条件是在这些项目内容验证之下，我们判断软件通过或者不通过测试。不通过（证伪）的时候，我们是可以很肯定地说这个有问题；但通过的时候，这种通过是有条件的。从软件全程质量保证的角度来看待软件测试，测试活动包含以下几层要求：1. 软件质量是满足规定或潜在的用户需求的能力，因此软件开发过程中，从用户显式或隐含的意思表达到形成用户规格书、再到设计文档、变成代码并调试运行的过程，最重要的就

4、是保证在这样一个复杂的转换过程中，需求的不被异化。2. 软件作为一个产品，是用来满足用户需求的，从这个角度来说，需要测量的是在特定环境下运行达到其任务目标的程度，但软件本身是一组文档、数据和代码的总和，其中最直接的是代码，从这个角度来说，作为一个产品本身，也需要从机械的符号角度对其内生的质量进行度量和评价。3. 软件的生产过程是一个工程，对应的测试活动有其工程属性，既然测试活动本身不能证明，只能证伪，测试活动则更需要明确测试界限，给出工程上合理的进度、资源、方法和结束条件。采用的测试方法就必须回答如何保证需求不被异化，如何从动态和静态两个角度来评估软件质量，以及如何明确测试界限的问题，而这又必

5、然需要通过一定的技术手段才能得到有效地支撑。在这种广义的软件质量保证的含义下，我们来重新审视软件全生命周期尤其是研发周期，就会发现，专门的软件测试人员承担的软件质量保证职责是有限的，一个研发项目中占大多数的研发人员，他们的测试意识，对测试活动、测试方法的认识是很关键的。因此，测评工程能力的提升，首先要通过培训、宣传、会议等各种手段，让项目涉及的相关人员尤其是软件开发人员，重新认识软件研发过程，重新认识软件测试，包括测试本质、测试含义、测试定位、测试方法等等。1.2 软件测试方法对应上述测试活动的理解，测试方法也首先是一套逻辑严密的需求覆盖体系和分析设计方法，具体表现为测试阶段覆盖的完整性、每个

6、阶段测试分析的完整性、每个阶段测试分析的过程完整性保证，然后才是在此之上的一些操作手段和工具应用技能，同时在管理层面，需要有明确测试界限的一系列手段。一、 测试阶段划分如前所述，一个明确的软件测试项目包括前期的文档测试，按照软件开发过程包含软件需求分析说明书验证、软件设计文档验证；另外一个是后期动态的单元测试、集成测试、系统测试、验收测试，这时主要的测试对象是程序和数据，当然也涉及到文档。对于这些测试阶段，应制定规范，对其测试类型、测试技术要求等明确要求。这方面，在军方、航空航天等领域有许多规范就可供参考。实际实施时，规范应根据不同软件类型的重要性、安全性关键等级提供剪裁。对应每一阶段的要求分

7、别说明如下：1、文档测试文档测试的主要测试对象是软件需求规格说明书和软件设计文档。文档通常使用文字进行说明，因此不可避免地具有而二义性和不明确性。软件测试中的文档测试主要是对相关的设计报告和用户使用说明等文档进行测试，一般应符合以下的技术要求：l 对于设计报告主要是测试程序与设计报告中的设计思想是否一致；l 对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。l 对于其他文档，一般检查其有效性和无误性。2、单元测试单元测试的对象是软件单元。软件单元测试应根据软件单元的重要性、安

8、全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：l 在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试；l 应建立测试软件单元的环境，其测试环境应通过评审；l 对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试；l 软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 语句覆盖率要达到100%；l 分支覆盖率要达到100%；l 对输出数据及其格式进行测试。3、集成测试集成测试的对象是软件组件，软件组件由软件单元组成。软件集成测试可根据软

9、件组件的重要性、安全性关键等级、重用情况等对如下技术要求内容进行剪裁，但必须说明理由。集成测试一般应符合以下技术要求：l 应对构成软件组件的每个软件单元的单元测试情况进行检查；l 若对软件组件进行必要的静态测试，应先于动态测试；l 组装过程是动态进行的，应标明组装策略；l 应建立组件测试环境，其测试环境应通过评审；l 应逐项测试软件设计文档规定的软件组件的功能、性能等特性；l 软件组件的每个特性应至少被一个正常的测试用例和一个被认可的异常测试用例覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 应测试软件单元和软件组件之间的所有调用，达到要求的测试覆盖率；l 应测试

10、软件组件的输出数据及其格式；l 应测试软件组件之间、软件组件和硬件之间的所有接口；l 应测试运行条件在边界状态下，进而在人为设定的状态下，软件组件的功能和性能；l 应按设计文档要求，对软件组件的功能、性能进行强度测试；l 对安全性关键的软件组件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。l 发现有否多余的软件单元。4、系统测试系统测试的对象是完整的、集成的计算机系统（Computer System），重点是新开发的配置项的集合。系统测试是组成系统的多个配置项的测试，组成一个系统的多个相关的软件可以同时进行系统测试。系统测试一般应符合以下技术要求：l

11、应按系统/子系统设计说明的规定，逐项测试系统的功能、性能等特性；l 系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 应测试系统的输出及其格式；l 应测试配置项之间及配置项与硬件之间的所有接口；l 应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能；l 应测试系统的安全性和数据访问的安全保密性；l 应测试系统的全部存储量、输入/输出通道的吞吐能力和处理时间的余量；l 应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试；l 应测试人机交互界面提供的操作和显示界面，包括

12、测试界面的可靠性；l 应测试设计中用于提高系统安全性和可靠性的方案；l 对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。l 对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，且对每一类导致恢复或重置的情况进行测试。l 对软件系统的安装性进行测试；l 对不同的实际问题应外加相应的专项测试。5、验收测试验收测试是按照项目任务书或合同、供需双方约定的测试依据文档进行的对整个系统的测试，以决定是否接收或拒收系统。其基本要求和系统测试类似。二、 测试类型分析测试活动的每个阶段，都有不同的特点和要求，但至关重要的是保证测试分析方法

13、的完整性，需要理解测试对象、测试的基本特点，确定测试的基本特征，提取共性。例如，在军用测试领域就有一套已经形成完整的测试分析方法体系，包括22种测试类型，在测试设计时应首先对照其要求进行分析，分别简要介绍如下。l 文档审查：是对提交的文档的完整性、一致性和准确性所进行的检查。文档审查应确定审查所用的检查单，而且为适应不同的文档审查，需要用不同的检查单，检查单的设计或采用应经过评审并得到委托方的确认。l 可测试性审查：主要是对开发的软件文档、软件设计的可测试性进行审核，包括软件文档是否符合可测性、软件设计是否具有可测试性、代码是否符合可测性等方面的审查。l 代码审查：是检查代码和设计的一致性、代

14、码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审并得到委托方的确认。l 静态分析：是一种对代码的机械性和程序化的特性分析方法。l 代码走查：由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，沿程序的逻辑，逐步运行测试用例，查找被测软件缺陷。l 逻辑测试：主要测试程序逻辑结构的合理性、实现的正确性。逻辑测试应由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。l

15、功能测试：主要对软件需求规格说明或设计文档中的功能需求逐项进行的测试，验证其功能是否满足要求。功能测试一般需进行：l 性能测试：对软件需求规格说明或设计文档中的性能需求逐项进行的测试，验证其性能是否满足要求。l 接口测试：对软件需求规格说明或设计文档中的接口需求逐项进行的测试。l 人机交互界面测试：是指对所有人机交互界面提供的操作和显示界面进行的测试，检验是否满足用户的要求。l 强度测试：强制软件运行在不正常到发生故障的情况下检验软件可以运行到何种程度的测试。l 可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能测试。可靠性测试中必须按照运行剖面和使用的概率分布随机地选

16、择测试用例。l 安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，测试应尽可能在符合实际使用的条件下进行。l 恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后系统能否正常地继续进行工作，且不对系统造成任何损害。l 边界测试：对软件处在边界或端点情况下运行状态的测试。l 数据处理测试：对完成专门数据处理功能所进行的测试。l 安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。l 互操作性测试：是为验证不同软件之间的互操作能力而进行的测试。l 敏感性测试：是为发现在有效输入类

17、中，可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。l 标准符合性测试：验证软件与相关国家标准或规范（如国家标准、行业标准以及国际标准）一致性的测试。l 兼容性测试：主要是验证被测软件在不同版本之间的兼容性。有两类基本的兼容性测试：一类是向下兼容测试，向下兼容是测试软件新版本保留它早期版本的功能的情况；另一类是交错兼容测试，交错兼容测试是要验证共同存在的两个相关但不同的产品之间的兼容性，即验证软件在规定条件下共同使用若干个实体或实现数据格式转换时能满足有关要求能力的测试。l 国际化测试：验证软件在不降低软件原有能力的条件下，处理当地语言能力的测试。三、 测试分析过程和软件开发过程

18、类似，一个完整的测试阶段其软件测试过程也应包括：测试需求分析、测试策划、测试设计与实现、测试执行、测试总结（包括评价过程和总结）等。只有对测试分析过程从管理上和技术上提出明确的界限，才能真正判定测试用例设计是否达到设定目的，完全覆盖了测试需求，测试需求是否真正完全覆盖了软件需求、潜在的各类隐含需求。在设计分析完整的基础上，按照严格的测试过程执行，就能有足够的信息来给出整个项目测试是否达到预期目标的结论。下面对测试设计过程的技术要求加以描述。1. 测试需求分析测试人员应根据被测软件的需求规格说明书、软件设计文档等，对被测软件进行测试需求分析。通常，测试需求分析一般要求：l 确定需要的测试类型及其

19、测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试阶段、测试类型匹配；l 确定测试类型中的各个测试项及其优先级；l 确定每个测试项的测试充分性要求。根据被测软件的重要性、测试目标和约束条件，确定应覆盖的范围及范围所要求的覆盖程度；l 确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。测试人员应建立测试类型中的测试项与软件测评任务书、被测软件的需求规格说明、设计文档或其他依据文件的追踪关系。2. 测试策

20、划测试人员应根据被测软件的需求规格说明书、软件设计文档等进行测试策划，策划一般要求包括：l 确定测试策略；l 确定测试需要的技术或方法，如：测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等；l 确定受控的测试工作产品，并列出清单；l 确定用于测试的资源要求，包括：软硬件设备、环境条件、人员数量和技能等要求；l 进行测试风险分析，如：技术风险、人员风险、资源风险和进度风险等；l 根据被测软件的需求规格说明书、软件设计文档和被测软件的特点，确定测试任务的结束条件；l 确定被测软件的评价准则和方法；l 应根据测试资源和测试项，确定测试活动的进度；l 应根据测试的要求，确定需采集的度量及采

21、集要求，特别是用例度量、风险度量、缺陷度量等，并应明确相应的数据库测试需求度量。3. 测试设计和实现测试人员应根据测试需求规格说明和测试计划进行测试的设计和实现，应完成以下工作：l 按需要分解测试项。将需测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有的接口和要测试的接口；l 说明最终分解后的每个测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等；l 设计测试用例；l 确定测试用例的执行顺序；l 准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等；l 准备并获取测试资源，如测试环境所必须的软、硬件资源等；l 必要时

22、，编写测试执行需要的程序，如开发部件测试的驱动模块、桩模块以及测试支持软件等；l 建立和校核测试环境，记录校核结果，说明测试环境的偏差。测试人员应将以上测试设计的工作结果，按照所确定的文档要求编写测试说明，测试说明由测试用例组成，测试用例一般技术要求如下：l 测试名称和项目标识；l 测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项标识（编号）；l 测试用例说明。简要描述测试的对象、目的和所采用的测试方法；l 测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置

23、）的那个的初始化要求；l 测试用例的输入。每个测试用例输入的描述中包括： 每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等） 测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）； 测试输入是真实的还是模拟的； 测试输入的时间顺序或事件顺序。l 测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果；l 测试用例的测试结果评估准则。评估准则用以判断测试用例执

24、行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如： 实际测试结果所需的精确度； 允许的实际测试结果与期望结果之间差异的上、下限； 时间的最大或最小间隔； 事件数目的最大或最小值； 实际测试结果不确定时，重新测试的条件； 与产生测试结果有关的出错处理； 其它有关准则。l 实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括： 每一步所需的测试操作动作、测试程序输入或设备操作等； 每一步期望的测试结果； 每一步的评估准则； 导致被测程序执行终止伴随的动作或指示信息； 需要时，获取和分析中间结果的方法。l 测试用例的前提和约束。再测试用例中还应说

25、明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响；l 测试终止条件。说明测试用例的测试正常终止和异常终止的条件。确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。2 开发环境统型目前公司产品研发中用到的开发环境、开发工具比较繁杂，应予以一定程度的统一。这项工作考虑应结合调研情况分析，根据公司主型软件工作硬件平台、操作系统等发展趋势，确定一个合理的统型方式和过渡方案。方案影响深远，因此制定时需要通盘考虑：l 统型方案既要考虑到现有在研产品开发，更要关注未来产品预研，同时还要照顾已定型产品的维护。l 统型方案既要考虑到公司

26、未来产品发展趋势，体现出一定的前瞻性和先进性，又要从现状出发，考虑广大研发人员的实际使用需要和技术能力。l 统型方案应考虑到实施的平稳过渡，逐步推进而非强行划断，尽量避免震荡。 l 统型方案和测试工具选型结合，通过与统型目标的软硬件开发平台结合紧密的商购测试工具、二次开发工具和自行开发的实用小工具，自然引导。开发环境统型方案将从以下方面加以阐述：l 现状分析：环境分布、使用情况、发展趋势、人员技术能力分布等l 统型建议：统型的原则及据此提出的平台统型建议l 统型机制：提出结合项目立项、配置管理、缺陷管理等软件研发流程的统型管理机制l 工作计划：提出具体的进度表3 软件开发语言编码规范编码规范是

27、研发团队的统一语言，在提高研发团队整体效率方面，编码规范与秦始皇的“车同轨、书同文”具有一样重要的意义。编码的规范统一，也是建设更高层次的软件构件库的坚实基础。目前公司涉及的编程语言有很多种，主要的是嵌入式平台下的C/C+语言，其他还包括PC环境下的Java、Delphi、C+Builder等。这些目前都有一些工程上比较公认的编码规则，其实主要是根据经验和实际结合，权衡利弊，筛选出合理的规则集。我们将根据经验，在充分了解目前的代码风格的基础上，提出公司内部针对各种开发语言的编码规范，原则上新的编码规范将尽量吸收当前的普遍的代码风格，以减少程序员编码习惯过大改变可能带来的不适应。编码规范实际推广

28、的关键首先在于有一个有效合理的检查机制。如果纯粹通过人工走查或者同行评审的会议方式，推行的工作量太大，在目前的人员配比条件下，是不现实的。业界已经有一套非常成熟的做法：选择合适的代码规范检查工具，将编码规则嵌入到工具中，每个开发工程师在提交代码前必需提交对应的检查结果。经过一段时间的运作，编码规范的普及和推广效果就会自然显现。根据我们的实际推广经验，这对测试工具的规则定制能力有一定要求，也是测试工具选型必须考虑的内容。在实际中，每个项目应根据自身实际情况，在统一的编码规范基础上进一步明确规则，哪些是本项目不需要的，哪些是需要进一步统一的，例如命名规则就有必要做进一步的细化要求。因此，制定软件开

29、发语言编码规范方案包含：1. 形成符合公司实际的编码规范：根据公司的实际，我们建议分布实施，首先针对有一定基础且需求迫切的嵌入式平台C/C+语言，然后针对其他语言推出规范和相应控制措施；2. 配合规范实施的指导书：将规范应用推广形成规范，并固化到RDP体系和PLM中；3. 结合选定的代码规则测试工具，定制代码规则检查集。4 软件需求分析软件需求由用户需求转化而来，是软件设计和测试的源头。软件需求的一般都通过软件需求规格说明书文档来体现。公司现已在应用需求跟踪矩阵对需求进行管理，但目前管理到的只是在项目的立项和结项这两个头和尾上，研发过程中对需求的跟踪基本处于无人监控状态，需求的变更亦不能全方位

30、有效的控制，测试部门也会因需求的不明确导致测试针对性不足。一份好的软件需求规格说明书一般具有以下七大特性：完整性、正确性、可行性、必要性、按优先级管理、无二义性、可验证性等。因此，软件需求分析的工作也应该从这七个方面来推进，并进行质量评价。软件需求分析是软件工程业界多年来的研究热点，形成多种的方法体系如RUP等，涉及面非常广，但在工程上最关键的，也尤为测评人员关心的，就是软件需求分析得到的需求质量如何，是否可验证。软件需求规格说明书的质量，通常都通过制定详细的文档检查单，由各方人员预先审查，然后组织相关人员进行会议评审。这些都是非常有效地方法，但由于文字说明的二义性和不明确性特点，不可避免地存

31、在一些缺陷。另一个更致命的问题是，软件需求主要从用户角度阐述，而软件设计文件则主要从软件的系统结构、实现方法等角度描述，导致软件需求难以进一步追踪，只有到系统测试的时候，才能得到验证，这就给系统引入了许多与需求相关的缺陷。而且由于公司面对的是机构客户，具有需求变更频繁的特征，这就带来更多的管理困难、验证难度和软件隐患。传统的文档检查单和会议评审仍然是最有效地方法。但如何去设计文档检查单是关键，一般通用的检查单其本身就基于含糊的表述，只能保证模板格式，对实际内 容是难以把关的。基于多年来的实践经验，我们形成了一套借用敏捷开发（XP）的测试驱动设计（TDD）理念的检查方法，要求需求本身的有清楚的验

32、证方法和通过标准，由验收方法的清晰来保证需求的清晰。在这个阶段，就可以综合应用软件测试中的各种测试类型和方法，按照测试的要求和理念形成独到的检查项，这样的检查思路一旦形成一致的思维方法，将极大的提升需求分析水平。另一方面，软件设计文档与软件需求文档之间应建立起需求追踪的关系，避免原有的需求跟踪只管两头的弊端，这方面可以参考GJB-438B标准中相关要求。通过对设计文档的控制，将需求追踪的工作进一步细化，这样才更容易实现管理和验证。需求变更的控制也是调研中很多人员提到的问题。软件需求规格说明书编制是控制变更的一个开始，需求分析时应识别容易发生变更的部分，并在软件设计中对此加以体现。咨询通信与公司

33、类似，面对的是机构客户，生产的产品属于单品价值高，小批量多批次，多年的摸爬滚打提供了一个最好的实践案例。例如，咨询公司的无线电台和通信控制器等产品在验收时，通常都会由于不同部队首长、军代表的个人偏好而容易被要求更改，这类需求由于军队的特殊体制，难以在需求调研阶段得到充分确认，经过摸索咨询形成一套行之有效的解决办法：在需求分析阶段对这类需求进行识别和隔离，设计阶段基于MVC的设计思想，通过自主开发的获得广东省创新金奖的嵌入式图形开发平台工具，把嵌入式开发转化成VC环境下开发，使得易变的部分容易更改，有效控制了这类需求变更带来的问题。基于以上分析，我们从软件需求检验的角度，提出软件需求分析和软件需

34、求分析质量评价的方案，主要内容包括：1. 软件需求分析操作规范：重点为基于测试驱动设计思想的理念的需求分析验证方式，以及由此细化的软件需求检查单设计方法；2. 软件需求分析质量评价准则：基于软件需求特性综合形成的质量评价模式和操作方法；3. 软件需求分析说明书模板，同时配套地修改软件设计文档的模板，以便进一步实现需求的层层细化跟踪，避免设计过程中的需求异化。5 软件可测试性设计软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。一般来说可测试性很好的软件

35、必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。从测试设计的层面来说，要求软件需求分析阶段获得的需求在设计过程中易于追踪和进一步细化，这与前面软件需求分析中是一致的。软件设计文档中除了要体现出软件架构设计以便实现外，应该同时关注需求的分析和细化。通过参考各类相关标准，重新制定软件设计文档模板，并对应提出基于需求追踪的软件设计文档检查细则，大体可以解决这个问题。软件可测试性包含可操作性、可观察性、可控制性、可分解性、简单性、稳定性、易理解性等七大特性。针对这些特性，软件可测试性设计具有一些客观的评价标准和依据。从软件代码的层面来说，可以通过

36、对代码进行机械分析，提取出度量指标，通过这些指标指导开发人员改进自己的设计。我们将为公司在设计和编码规范表中制定相关的可测试性设计的度量标准，引导相关开发人员和测试人员自发地重构代码，提升可测试性设计水平。6 软件测试工具选型一、 测试工具的认识和定位测试首先要掌握逻辑严密的需求覆盖体系、分析设计方法，具备良好的工程管理基础，但“工欲善其事，必先利其器”，必须有与方法相适应的一些操作手段和工具应用技能，才能达到测试设计分析的预期的效果和目的。与手工操作相比，借助测试工具有一些显著的优点，包括提高测试效率、提高测试覆盖率、执行结果一致性、更好地利用资源等，尤其是对大量代码的度量和结构分析以及大规

37、模的负载压力测试和一些指标测试，没有测试工具协助是不可能完成的。但是针对测试工具，尤其是通常所说的自动化测试工具，存在一些普遍的错误认识，例如“自动化测试可以完成一切测试工作” 、“测试工具能使工作量大幅度降低”、“测试工具能够实现百分之百的测试覆盖率” 、“自动化测试工具容易使用”、“自动化测试能发现大量的新缺陷”，这样一些观点其实在前面公司的调研中，在部分研发人员中也有体现。事实上，虽然许多工具都宣传其背后的测试思想和自动化测试用例设计等，目前测试工具更重要的还只是一种测试手段而已，其用例设计层面以静态的语义分析为基础，对测试最重要的“保证需求不被异化”的要求是无能为力的。在测试中要发现缺

38、陷，起先决作用的还是测试需求理解和测试设计活动。工具层面，一般的测试活动包括测试用例设计、测试用例执行、测试结果记录、测试结果比较、测试报告产生这样五个主要步骤，测试自动化选型主要要解决定位问题：即我们想要进行哪个（些）步骤的自动化。定位准确的情况下，我们再针对性地选择合适的工具。目前按功能划分，软件测试工具一般可分为白盒测试工具、黑盒测试工具和性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具等类性。在软件测试的多个阶段均可引入测试工具进行辅助。相对来说，目前基于通用PC平台的系统测试工具发展比较成熟。就嵌入式平台而言，动态测试工具中，系统级的功能测试难以在

39、市场上直接采购到，录制/回放类的工具能否适用需要更进一步调研产品类型后才能给出建议；灰盒测试工具（即以灰盒方法进行测试，但工具提供白盒层面的代码覆盖数据支持）则需要比较高的使用技能。而就单元、集成测试工具而言，比较难以在市场上直接购买到的是那些调试（更别说测试）环境非常复杂的软件比如单片机软件的单元集成测试工具。相对比较完善的是针对C/C+/Java/Ada等应用广泛的代码静态度量、规范检查、代码分析等不需要在平台上实际运行的静态工具。由于嵌入式平台的多样性和有别于PC平台的一些特点，工具的引入必须在测试认识统一、测试方法形成体系的基础上，统筹考虑，以引入商用自动化测试工具为主，自主开发改进为

40、辅，形成比较完整覆盖各测试阶段，有效支撑测试方法体系的平台。以嵌入式平台为例，对应用广泛的代码静态度量、规范检查、代码分析等静态测试工具，可以考虑直接引进商用测试工具，对于动态的单元集成测试、灰盒测试、系统测试工具，可以考虑在引进商用测试工具的基础上，做一些适配等方面的自主二次开发，使工具适应测试实际需要。如前所述，工具的使用本身是有局限性的，而且工具的学习和掌握以及运用也是有许多的工作量在其中，嵌入式平台这些问题尤其突出。测试工具引进要想取得好的效果，在公司内部，也必须为有效地应用工具，更好地开展测试工作，推动嵌入式平台的统型、代码规范、人员技术储备等。总之，我们应根据测试的定位和需要来选择

41、合适的工具。只有首先明确哪些是提升能力的关键环节，才能在这些环节引入合适的辅助工具，帮助我们提升测试效果，使工具真正按照整个团队的目标来服务软件质量目标。二、 测试工具的选择面对市面上如此之多的测试工具，对工具的选择就成了一个比较重要的问题。在考虑选用工具的时候，主要从以下几个方面来权衡和选择：1. 功能功能当然是应该最被关注的内容，选择一个测试工具首先就是看它提供的功能。但这并不是说测试工具提供的功能越多越好，在实际的选择过程中，适用才是根本。事实上，目前市面上同类的软件测试工具之间的基本功能都是大同小异，各种软件提供的功能也大致相同，只不过有不同的侧重点。例如，同为常见的白盒测试工具的Lo

42、giscope和Testbed软件，提供的基本功能大致相同，只是在编码规则、编码规则的定制、采用的代码质量标准方面有不同。除了基本的功能之外，以下的功能需求也非常重要：l 报表功能；测试工具生成的结果最终要由人进行解释，而且，查看最终报告的人员不一定对测试很熟悉，结果报表能够以什么形式提供是应用时非常关键的。l 测试工具的集成能力；测试工具的引入是一个长期的过程，而我们希望的是通过统筹规划，引进的各类工具形成一个覆盖完整的平台。因此，测试工具的集成能力也是必须考虑的因素：首先，测试工具能否和开发工具进行良好的集成；其次，测试工具能够和其他测试工具进行良好的集成。l 和开发工具的兼容性；测试工具

43、可否跨平台，是否适用于公司目前使用的开发工具，这些问题也是在选择一个测试工具时必须考虑的问题。2. 价格除了工具的功能之外，其价格就应该是最重要的因素了。在功能基本等同、性能基本一致的情况下，完全可以选择其中价格较低的测试工具。3. 测试工具的连续性和一致性测试工具是测试自动化的一个重要步骤之一，在引入/选择测试工具时，必须考虑测试工具引入的连续性。也就是说，对测试工具的选择必须有一个全盘的考虑，分阶段、逐步的引入测试工具。这同时也有助于保持公司开发团队开展工作的连续性和一致性，有助于进一步规范软件开发、测试的管理和流程。三、 测试工具的评估通过以上分析，可从众多软件测试工具中缩小选择的范围，

44、划分一个大致的选择品牌、型号，仍需要对各个候选测试工具从各个方面进行评估，考察其功能、性能、费用、易用性等方面是否符合公司实际。一个比较合理的方法就是对期望引进的工具预先设定评价的各个方面，分配不同的权重级别，组成一个评价模型，在试用后进行打分确定。例如，待引进的自动化录制/回放测试工具，可以用以下的一张表来进行评估录制/回放功能、数据功能、测试/错误恢复能力、对象名映射、对象识别能力、脚本语言扩展能力、环境支持、与其他工具的兼容、价格费用、易用性等方面进行评估。四、 测试工具选型方案基于我们对软件测评工具的现状和未来发展趋势的深入把握，根据公司公司的现状和项目的具体需求，应把握全面性、实用性

45、、适用性等原则，以下是工具选型一些考虑：1. 明确测试工具引进范围统一测试工具选型的认识，明确测试工具选型的定位，制定详细的测试工具引进的计划，对工具覆盖的平台、类型、数量明确规定，并对试用人员和评估方法预先设定：l 工具应用平台综合考虑到公司实际项目情况、测试人员、测试资源、本项目推进进度等，建议一期引入试点工具以嵌入式平台为主，在二期重点引入系统应用软件测试工具。l 工具类型试用工具引进应形成比较完整覆盖各测试阶段，有效支撑测试方法体系的平台。建议一期嵌入式平台应覆盖代码静态度量、规范检查、代码分析等静态测试，同时应适当考察动态的单元集成测试、灰盒测试、系统测试工具，并引入合适的测试管理工

46、具。l 工具数量建议对期望引进的测试工具，分别引入2类，最多不超过3类的测试工具进行试用，以将评估工作量控制在合理的范围。2. 对引入的测试工具进行充分的试用一般确定购买一款测试工具前，产家会提供一段时期的试用期。虽然在购买工具前经过了充分调研、评估和选择，但仍有可能所选择的工具无法满足自身需要或存在其他方面的问题，这就需要公司尽量在测试工具的试用期发现存在的问题。因此需对引入的测试工具进行充分的试用，通过完整的实际试点项目是不错的做法。3. 针对测试工具使用调整相关研发流程有时，引入的测试工具符合实际需要，却没有形成一个良好的使用测试工具的环境，换句话说，就是没有能够形成一种机制让测试工具真

47、正能够发挥作用，也会导致工具起不到应有的效果。例如，白盒测试工具的一般使用场合是在单元测试阶段，而单元测试是由开发人员完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。在这种情况下，就必须形成一种有约束力的机制来强制对测试工具的使用。我们建议的一种较好的方式是，将测试工具的使用明确定义进公司的开发流程中。具体的做法如：在开发流程中明确说明，在项目里程碑提交的文档中必须包括测试工具生成的报告，该报告中的数据是决定项目是否合格的依据。4. 进行有效的测试工具的培训测试工具的使用者必须对测试工具非常了解，在这方面，有效的培训是

48、必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，对于测试工具使用者的积极性是很大的打击。一般来说，测试工具厂商会提供一定程度上的工具培训；其次，公司自身可开展测试工具的培训，还可进一步进行一系列的培训和交流，如：可全公司开展从针对开发高层的测试工具基本概念培训，到针对测试工具实际使用者的测试工具使用培训，再到交流性质的测试工具应用交流研讨会，再到定期发出的测试工具应用问答等培训与交流，在这方面付出较大精力，使测试工具的应用成为开发人员和测试人

49、员的基本功。7 嵌入式软件测试环境建设根据公司软件测评环境建设相关需求，以及未来向行业第三方测评实验室发展的可能，咨询通信基于自身的软件测评实验室建设经验，形成对公司软件测评环境建设建议。本期软件测评实验平台建设主要基于嵌入式软件测评进行搭建。我们将针对性地形成软件测评实验室建设指导书和软件测评实验室管理办法，下面分别从实验室综合环境建设、测试环境建设、实验室专业建设、实验室管理等四个方面进行说明。7.1 设施和环境条件建设实验室的设施和环境条件是保证软件测评结果正确性的重要条件。设施和环境条件建设应满足所依据的技术标准或技术规范的规定，还应满足所使用的仪器设备、被测件等方面对设施及环境条件的

50、要求。软件测评工作对设施和环境条件的要求包括：1. 所从事的软件测评工作所遵循的技术标准/规范对设施和环境条件的要求。2. 软件测评工作所使用的测试设备对设施和环境条件的要求。3. 被测软件对设施和环境条件的要求。4. 软件测评人员的防护措施对设施和环境条件的要求。5. 在固定设施以外的场所进行软件测评时的特殊要求，保证结果的有效性不受到影响。设施和环境条件建设内容包括（但不限于）能源、照明、采光、取暖、通风等基础设施和软件测评实验平台搭建所需的网络、服务器等设备的建设，以及对上述设施和环境条件的管理规定。7.2 测试环境建设结合嵌入式软件特点，软件测评实验平台建设包括软件静态分析环境建设、软

51、件单元/集成测试环境建设、软件系统测试环境建设以及软件测试管理平台建设等部分。1. 软件静态分析环境建设静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书等文档的评审就是最常见的静态方法，其常见方法是检查单和评审会。而代码的静态测试可以由人工进行，也可以借助软件工具自动进行。对于人工代码检查来说，在检查前除应准备好需求描述文档、程序设计文档、程序的源代码清单等外，需要的测试方法只有代码编码标准和代码缺陷检查表等。代码静态测试是测试工具研究非常深入的领域，编码规则检查、静态结构分析、代码质量度量、代码分析（错误检测

52、）等领域都有非常成熟的商用产品。l 编码规则检查：在嵌入式软件中，尤其是汽车行业，国际上目前流行的C语言编程规则为MISRA-C。常见的编码规则检查工具有 Testbed、Logiscope等。都具备根据要求定制规则的能力。l 代码质量度量：根据ISO9126质量模型，例如衡量软件的可维护性，可以用可分析性（Analyzability）、可改变性（Changeability）、稳定性（Stability）以及可测试性（Testability）来度量。而具体到软件的可测试性，则通过提取的圈复杂度、输入/输出的个数等指标来考察。在具体的实践中，专门的质量度量工具是必须的。常见的专业工具有Testb

53、ed、Logiscope等。l 代码分析（错误检测）：通过静态分析代码并根据一定规则进行演算，静态发现代码缺陷，常见的如数组越界、空指针操作、缓冲区溢出、野指针操作等，可能造成。常见的工具有Klocwork、PolySpace、Coverity等，类似的静态工具未来会成为市场的主流。软件静态分析环境建设相对来说比较易于开展，通过制定选择合适的测试工具，掌握其使用方法，形成基本的静态检查表，应用环境可以满足通常的测试要求。2. 软件单元/集成测试环境建设由于测试是一门相当新兴的学科，测试的许多概念在不同的书本中有不同的定义。单元测试与集成测试是相对的概念，我们把一个独立的单元（没有调用其他自定义

54、函数的函数）称作原子级模块，严格地说，对一个非原子级模块的单元测试意味着需要将该模块中对其他函数（模块）的调用以变量代替，以消除该模块对被调用模块的依赖。而对非原子级模块的集成测试则不需要消除对被调用模块的依赖。为了简化我们的单元及集成测试，我们将建立的单元测试及集成测试定位在对原子级模块的单元测试和对非原子级模块的集成测试上，即当一个模块内部调用另一个模块时，不需消除对被调用模块的依赖。相比软件静态分析环境，软件单元/集成测试环境建设相对复杂，一方面其测试工具相对不够完善，一方面其必然涉及硬件平台的建设。对于嵌入式软件，单元测试、集成测试可以采用仿真的方法在PC机上执行，也可以在目标机上执行

55、；即使同是在目标机上执行单元测试或者集成测试，当单元或者模块输出涉及硬件时，也可以有两种方法来记录测试结果，一种方法是通过测量或者观察软件所控制的硬件的反映来记录测试结果，另一种方法则是通过记录逻辑或物理上对应于硬件的变量或者地址的值来记录测试结果。为了切实可行地推动软件测评实验平台建设，建议软件单元测试及集成测试定位为：l 在目标机上执行测试；l 当单元或模块涉及硬件时，以硬件对应的变量或者地址的逻辑值为输出结果。对于嵌入式软件，就单元、集成测试工具而言，比较难以在市场上直接购买到的是那些调试（更别说测试）环境非常复杂的软件比如单片机软件的单元集成测试工具。灰盒测试工具（即以灰盒方法进行测试

56、，但工具提供白盒层面的代码覆盖数据支持）则需要比较高的使用技能。常见的如C+Test、RTRT、CodeTest等工具均有各自的优势和一些缺点。建议在引入商用工具的同时，应鼓励自主创新开发一些小工具提高效率。而由于单元测试/集成测试必然会涉及的硬件中断、时序控制等和硬件相关的内容，纯粹通过静态分析、软件仿真是不能完全解决问题的，而从测试工程师能力培养角度，也必须有相应的调试平台。因此，在引入测试工具的同时，也根据开发平台统型的要求，引入主流的开发调试平台、开发软件环境，并在技术能力规划中制定相应的学习培养计划。3. 软件系统测试环境建设软件系统测试对于通用PC类软件，系统测试工具发展相对比较成

57、熟，基于黑盒测试原理的性能测试工具如Loadrunner、功能测试（自动化测试）工具如QTP等，应用非常广泛。但是在嵌入式测试领域，由于其应用的特点，在系统测试领域，对这类通用测试工具的需求没有如此强烈，一般所谓的系统测试工具也都是和软件单元/集成测试工具混合，号称对系统测试提供各类支持。因此，我们建议在系统测试环境构建上，首先还是综合开发平台统型的要求，引入主流的开发调试平台、开发软件环境，并在技术能力规划中制定相应的学习培养计划。建议分两步走，第一步是将商用工具的系统测试辅助功能成分利用，未来应根据硬件运行平台、软件运行平台、软件开发平台统型的情况，确定针对性的系统测试工具的开发。4. 软

58、件测试管理环境建设建议统一信息管理平台，摆脱多系统独立运行的现状，将测试管理、需求管理与研发过程管理固化到统一的平台（PLM），通过PLM的质量管理模块CAPA实现产品研发过程的缺陷捕捉、记录、跟踪和质量信息传递。7.3 软件测试管理平台建设实验室的项目活动主要通过测评过程来实现，组织人员等在后续软件测评专业机构建设中将有详细描述，以下主要是从测试环境管理、设备管理、记录管理、持续改进等方面进行描述。对应的内容我们将分别形成管理规范，构成完整的软件测评实验室管理办法。1. 测试环境管理为确保环境条件不会影响软件测评人员发挥其技术能力水平，需要对设施和环境条件进行控制，控制内容包括以下方面：l

59、影响软件测评结果的设施和环境条件的技术要求文件化l 环境条件监控和必要时采取有效的隔离措施或控制措施。l 软件测评质量区域出入控制l 内务管理的措施。l 环境影响出现危害测试结果情况的应急措施和影响消除措施2. 设备管理设备管理主要是对于测评相关的仪器仪表、测试工具、计算机等的管理，具体内容包括：l 设备的校准和核查l 设备的标识管理l 设备的管理和维护l 设备的档案管理3. 记录管理记录管理主要是对实验室的质量记录和技术记录在内的记录进行识别、收集、索引、存取、存档、存放、维护和清理等方面的控制，具体内容包括：l 记录的标识、归档l 记录的借出归还控制l 记录的索引和保存控制l 电子记录的配

60、置管理和备份控制4. 持续改进l 改进是一种持续的活动，实验室应在测评体系的所有过程和各个环节中，贯穿持续改进的要求。改进的方法和途径可以通过日常的改进活动，也可以是突破性的。l 进行信息分析、内部评审等，寻求改进的机会，安排改进的活动；l 实施纠正措施和预防措施实现改进目标；l 对实施改进的结果进行监测、验证、分析和评价，确认改进的目标是否已经实现；l 通过定期的总结、评审等，评价解决方法和改进的效果，确定进一步改进的方向和目标。8 软件测试用例库管理咨询公司将在深入调研基础上，参考国际、国内、军方以及咨询自身经验，从以下方面来进行测试用例库建设：1. 根据调研获得的公司现有的主型产品软件设

61、计架构和细分需求类型，进行归纳提炼，确定用例库建设范围和步骤，用例库的提取有两个维度，一个是功能细分，例如用户管理的通用功能，另外一个是具体指标检测等技术层面；2. 制定软件测试用例库管理规范，对软件测试用例的收集、整理、重用和管理的工作进行规定，明确奖惩，以奖为主;3. 修订不同阶段测试分析过程技术规范、测试分析方法技术规范，将用例库建设内容纳入技术规范；修订测试流程规范，将测试用例提取入库工作纳入到测试说明评审和测试总结评审中来。测试用例库建设，需要具备一批比较成功的测试项目，测试工具应用相对成功，人力比较充沛，此时配合研发部门的软件构件库建设，以及目标平台统型工作，进行规范和推广，才能事

62、半功倍，因此建议作为本项目二期目标和一个方向。9 软件测试技术培训9.1 概述我们将按计划、分步骤实施对相关员工的专业知识培训、专业技能提升工作，提供系统详尽的、有针对性的软件测评专业知识及技能提升培训课程计划，每项课程培训前将提供详细教程供参加人员预习，培训中充分互动和注重实例、经验和技巧讲解演示，培训后将组织考试对学员的学习效果进行评估。培训实施过程中，我们将配合公司组织对培训讲师、课程内容和课程培训实施效果的调查，并根据反馈进行改进和提升。培训课程包括软件测试基础、测试需求分析、文档审查、代码审查、单元测试、集成测试、系统测试、验收测试、软件测试工具、软件测试管理等10个专题，重点是各专

63、题的实践经验、技巧及方法论。以下分别简要介绍各课程的培训目标和培训内容.9.2 软件测试基础培训目标：统一软件设计开发人员、测试人员对软件测试的认识和理解，达成共识，为后续各个软件测试专题工作的开展奠定基础。培训内容：l 软件测试基本理念和概念。l 软件测试体系全面的认识和了解。l 澄清软件测试中常见的误区及错误认识。l 软件测试工具分类和作用介绍。9.3 测试需求分析培训目标：软件测试人员掌握测试需求分析的过程，文档编写和需求提取和分解的过程。培训内容：l 软件测试需求分析过程：准备、要求和基本过程。l 软件测试需求来源和提取方法。l 软件测试需求分析方法。l 软件测试项分解方法。l 软件测

64、试需求分析质量评价标准。9.4 文档审查培训目标：软件开发人员、软件测试人员掌握文档审查方法。培训内容：l 文档审查过程：准备、要求和基本过程。l 文档审查检查单编写。l 文档审查常用技术与方法。9.5 代码审查培训目标：软件开发人员、软件测试人员掌握代码审查方法。培训内容：l 代码审查过程：准备、要求和基本过程。l 代码审查检查单编写。l 代码审查常用技术与方法。9.6 单元测试培训目标：软件开发人员、软件测试人员掌握单元测试基本概念、常见方法，并通过常见嵌入式工具实操。培训内容：l 单元测试过程：准备、要求和基本过程。l 单元测试常用技术与方法。l 常见嵌入式单元测试工具介绍。l 测试工具实操。9.7 集成测试培训目标：软件测试人员掌握集成测试基本概念、常见方法，并通过常见嵌入式工具实操。培训内容：l 集成测试过程：准备、要求和基