软件测评能力提升方案-.doc

-精品word文档 值得下载 值得拥有-软件测评工程能力提升方案咨询方将在上述调研报告基础上，提出详细的测评工程能力建设方案。方案的主要包括以下方面：1 软件测试实用规程1.1 软件测试的认识如前所述，目前软件测试领域的理论体系仍然不算成熟，软件测评专业能力建设本身是一个复杂的系统工程，牵涉的人员和环节众多，从调研结果来看，部分研发人员对测试的认识存在一些偏差，这将给软件测评专业建设带来风险。软件测评工程能力，首先是测试意识的提升。技术保障，观念先行，一个研发项目涉及的人员尤其是大多数的开发人员的测试意识是决定性的，只有将软件测试放到软件全生命周期的大背景下来考察，使全体人员对软件质量全程保证的角度来重新认识测试，具体的测试方法、测试技能提升才有普遍意义。基础理论和方法论的普及，软件测试的本质、含义、定位和作用的深入认识，将是项目能否顺利开展的前提。软件测试本质上是一个证伪而不是证明的过程。因此，从广义上来说，只要是对软件本身质量保证相关的，都可以纳入软件测试的范围。无论是在软件研发的需求分析、架构设计、详细设计、代码实现还是后面的测试阶段，都可以开展测试活动；无论是系统设计人员、软件编程人员或者验证人员、服务人员、市场人员，都可以成为测试人员；也无论是文档评审、代码审查、功能调试、系统验证等等活动，都可以是一种测试活动；无论是人工验证、形式证明、代码静态分析工具、单元测试工具还是自动化测试工具等手段，都可以成为有效的测试手段。只要有确定的人员，采用某种确定的方法手段，按照确定的项目内容，对影响软件质量的相关文档、代码、程序、数据等进行验证，都是执行了有意义的测试。经过这些验证活动之后，我们得出有条件的结论，这个条件是在这些项目内容验证之下，我们判断软件通过或者不通过测试。不通过（证伪）的时候，我们是可以很肯定地说这个有问题；但通过的时候，这种通过是有条件的。从软件全程质量保证的角度来看待软件测试，测试活动包含以下几层要求：1. 软件质量是满足规定或潜在的用户需求的能力，因此软件开发过程中，从用户显式或隐含的意思表达到形成用户规格书、再到设计文档、变成代码并调试运行的过程，最重要的就是保证在这样一个复杂的转换过程中，需求的不被异化。2. 软件作为一个产品，是用来满足用户需求的，从这个角度来说，需要测量的是在特定环境下运行达到其任务目标的程度，但软件本身是一组文档、数据和代码的总和，其中最直接的是代码，从这个角度来说，作为一个产品本身，也需要从机械的符号角度对其内生的质量进行度量和评价。3. 软件的生产过程是一个工程，对应的测试活动有其工程属性，既然测试活动本身不能证明，只能证伪，测试活动则更需要明确测试界限，给出工程上合理的进度、资源、方法和结束条件。采用的测试方法就必须回答如何保证需求不被异化，如何从动态和静态两个角度来评估软件质量，以及如何明确测试界限的问题，而这又必然需要通过一定的技术手段才能得到有效地支撑。在这种广义的软件质量保证的含义下，我们来重新审视软件全生命周期尤其是研发周期，就会发现，专门的软件测试人员承担的软件质量保证职责是有限的，一个研发项目中占大多数的研发人员，他们的测试意识，对测试活动、测试方法的认识是很关键的。因此，测评工程能力的提升，首先要通过培训、宣传、会议等各种手段，让项目涉及的相关人员尤其是软件开发人员，重新认识软件研发过程，重新认识软件测试，包括测试本质、测试含义、测试定位、测试方法等等。1.2 软件测试方法对应上述测试活动的理解，测试方法也首先是一套逻辑严密的需求覆盖体系和分析设计方法，具体表现为测试阶段覆盖的完整性、每个阶段测试分析的完整性、每个阶段测试分析的过程完整性保证，然后才是在此之上的一些操作手段和工具应用技能，同时在管理层面，需要有明确测试界限的一系列手段。一、 测试阶段划分如前所述，一个明确的软件测试项目包括前期的文档测试，按照软件开发过程包含软件需求分析说明书验证、软件设计文档验证；另外一个是后期动态的单元测试、集成测试、系统测试、验收测试，这时主要的测试对象是程序和数据，当然也涉及到文档。对于这些测试阶段，应制定规范，对其测试类型、测试技术要求等明确要求。这方面，在军方、航空航天等领域有许多规范就可供参考。实际实施时，规范应根据不同软件类型的重要性、安全性关键等级提供剪裁。对应每一阶段的要求分别说明如下：1、文档测试文档测试的主要测试对象是软件需求规格说明书和软件设计文档。文档通常使用文字进行说明，因此不可避免地具有而二义性和不明确性。软件测试中的文档测试主要是对相关的设计报告和用户使用说明等文档进行测试，一般应符合以下的技术要求：l 对于设计报告主要是测试程序与设计报告中的设计思想是否一致；l 对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。l 对于其他文档，一般检查其有效性和无误性。2、单元测试单元测试的对象是软件单元。软件单元测试应根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：l 在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试；l 应建立测试软件单元的环境，其测试环境应通过评审；l 对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试；l 软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 语句覆盖率要达到100%；l 分支覆盖率要达到100%；l 对输出数据及其格式进行测试。3、集成测试集成测试的对象是软件组件，软件组件由软件单元组成。软件集成测试可根据软件组件的重要性、安全性关键等级、重用情况等对如下技术要求内容进行剪裁，但必须说明理由。集成测试一般应符合以下技术要求：l 应对构成软件组件的每个软件单元的单元测试情况进行检查；l 若对软件组件进行必要的静态测试，应先于动态测试；l 组装过程是动态进行的，应标明组装策略；l 应建立组件测试环境，其测试环境应通过评审；l 应逐项测试软件设计文档规定的软件组件的功能、性能等特性；l 软件组件的每个特性应至少被一个正常的测试用例和一个被认可的异常测试用例覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 应测试软件单元和软件组件之间的所有调用，达到要求的测试覆盖率；l 应测试软件组件的输出数据及其格式；l 应测试软件组件之间、软件组件和硬件之间的所有接口；l 应测试运行条件在边界状态下，进而在人为设定的状态下，软件组件的功能和性能；l 应按设计文档要求，对软件组件的功能、性能进行强度测试；l 对安全性关键的软件组件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。l 发现有否多余的软件单元。4、系统测试系统测试的对象是完整的、集成的计算机系统（Computer System），重点是新开发的配置项的集合。系统测试是组成系统的多个配置项的测试，组成一个系统的多个相关的软件可以同时进行系统测试。系统测试一般应符合以下技术要求：l 应按系统/子系统设计说明的规定，逐项测试系统的功能、性能等特性；l 系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；l 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；l 应测试系统的输出及其格式；l 应测试配置项之间及配置项与硬件之间的所有接口；l 应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能；l 应测试系统的安全性和数据访问的安全保密性；l 应测试系统的全部存储量、输入/输出通道的吞吐能力和处理时间的余量；l 应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试；l 应测试人机交互界面提供的操作和显示界面，包括测试界面的可靠性；l 应测试设计中用于提高系统安全性和可靠性的方案；l 对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。l 对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，且对每一类导致恢复或重置的情况进行测试。l 对软件系统的安装性进行测试；l 对不同的实际问题应外加相应的专项测试。5、验收测试验收测试是按照项目任务书或合同、供需双方约定的测试依据文档进行的对整个系统的测试，以决定是否接收或拒收系统。其基本要求和系统测试类似。二、 测试类型分析测试活动的每个阶段，都有不同的特点和要求，但至关重要的是保证测试分析方法的完整性，需要理解测试对象、测试的基本特点，确定测试的基本特征，提取共性。例如，在军用测试领域就有一套已经形成完整的测试分析方法体系，包括22种测试类型，在测试设计时应首先对照其要求进行分析，分别简要介绍如下。l 文档审查：是对提交的文档的完整性、一致性和准确性所进行的检查。文档审查应确定审查所用的检查单，而且为适应不同的文档审查，需要用不同的检查单，检查单的设计或采用应经过评审并得到委托方的确认。l 可测试性审查：主要是对开发的软件文档、软件设计的可测试性进行审核，包括软件文档是否符合可测性、软件设计是否具有可测试性、代码是否符合可测性等方面的审查。l 代码审查：是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审并得到委托方的确认。l 静态分析：是一种对代码的机械性和程序化的特性分析方法。l 代码走查：由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，沿程序的逻辑，逐步运行测试用例，查找被测软件缺陷。l 逻辑测试：主要测试程序逻辑结构的合理性、实现的正确性。逻辑测试应由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。l 功能测试：主要对软件需求规格说明或设计文档中的功能需求逐项进行的测试，验证其功能是否满足要求。功能测试一般需进行：l 性能测试：对软件需求规格说明或设计文档中的性能需求逐项进行的测试，验证其性能是否满足要求。l 接口测试：对软件需求规格说明或设计文档中的接口需求逐项进行的测试。l 人机交互界面测试：是指对所有人机交互界面提供的操作和显示界面进行的测试，检验是否满足用户的要求。l 强度测试：强制软件运行在不正常到发生故障的情况下检验软件可以运行到何种程度的测试。l 可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能测试。可靠性测试中必须按照运行剖面和使用的概率分布随机地选择测试用例。l 安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，测试应尽可能在符合实际使用的条件下进行。l 恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后系统能否正常地继续进行工作，且不对系统造成任何损害。l 边界测试：对软件处在边界或端点情况下运行状态的测试。l 数据处理测试：对完成专门数据处理功能所进行的测试。l 安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。l 互操作性测试：是为验证不同软件之间的互操作能力而进行的测试。l 敏感性测试：是为发现在有效输入类中，可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。l 标准符合性测试：验证软件与相关国家标准或规范（如国家标准、行业标准以及国际标准）一致性的测试。l 兼容性测试：主要是验证被测软件在不同版本之间的兼容性。有两类基本的兼容性测试：一类是向下兼容测试，向下兼容是测试软件新版本保留它早期版本的功能的情况；另一类是交错兼容测试，交错兼容测试是要验证共同存在的两个相关但不同的产品之间的兼容性，即验证软件在规定条件下共同使用若干个实体或实现数据格式转换时能满足有关要求能力的测试。l 国际化测试：验证软件在不降低软件原有能力的条件下，处理当地语言能力的测试。三、 测试分析过程和软件开发过程类似，一个完整的测试阶段其软件测试过程也应包括：测试需求分析、测试策划、测试设计与实现、测试执行、测试总结（包括评价过程和总结）等。只有对测试分析过程从管理上和技术上提出明确的界限，才能真正判定测试用例设计是否达到设定目的，完全覆盖了测试需求，测试需求是否真正完全覆盖了软件需求、潜在的各类隐含需求。在设计分析完整的基础上，按照严格的测试过程执行，就能有足够的信息来给出整个项目测试是否达到预期目标的结论。下面对测试设计过程的技术要求加以描述。1. 测试需求分析测试人员应根据被测软件的需求规格说明书、软件设计文档等，对被测软件进行测试需求分析。通常，测试需求分析一般要求：l 确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试阶段、测试类型匹配；l 确定测试类型中的各个测试项及其优先级；l 确定每个测试项的测试充分性要求。根据被测软件的重要性、测试目标和约束条件，确定应覆盖的范围及范围所要求的覆盖程度；l 确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。测试人员应建立测试类型中的测试项与软件测评任务书、被测软件的需求规格说明、设计文档或其他依据文件的追踪关系。2. 测试策划测试人员应根据被测软件的需求规格说明书、软件设计文档等进行测试策划，策划一般要求包括：l 确定测试策略；l 确定测试需要的技术或方法，如：测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等；l 确定受控的测试工作产品，并列出清单；l 确定用于测试的资源要求，包括：软硬件设备、环境条件、人员数量和技能等要求；l 进行测试风险分析，如：技术风险、人员风险、资源风险和进度风险等；l 根据被测软件的需求规格说明书、软件设计文档和被测软件的特点，确定测试任务的结束条件；l 确定被测软件的评价准则和方法；l 应根据测试资源和测试项，确定测试活动的进度；l 应根据测试的要求，确定需采集的度量及采集要求，特别是用例度量、风险度量、缺陷度量等，并应明确相应的数据库测试需求度量。3. 测试设计和实现测试人员应根据测试需求规格说明和测试计划进行测试的设计和实现，应完成以下工作：l 按需要分解测试项。将需测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有的接口和要测试的接口；l 说明最终分解后的每个测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等；l 设计测试用例；l 确定测试用例的执行顺序；l 准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等；l 准备并获取测试资源，如测试环境所必须的软、硬件资源等；l 必要时，编写测试执行需要的程序，如开发部件测试的驱动模块、桩模块以及测试支持软件等；l 建立和校核测试环境，记录校核结果，说明测试环境的偏差。测试人员应将以上测试设计的工作结果，按照所确定的文档要求编写测试说明，测试说明由测试用例组成，测试用例一般技术要求如下：l 测试名称和项目标识；l 测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项标识（编号）；l 测试用例说明。简要描述测试的对象、目的和所采用的测试方法；l 测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）的那个的初始化要求；l 测试用例的输入。每个测试用例输入的描述中包括： 每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等） 测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）； 测试输入是真实的还是模拟的； 测试输入的时间顺序或事件顺序。l 测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果；l 测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如： 实际测试结果所需的精确度； 允许的实际测试结果与期望结果之间差异的上、下限； 时间的最大或最小间隔； 事件数目的最大或最小值； 实际测试结果不确定时，重新测试的条件； 与产生测试结果有关的出错处理； 其它有关准则。l 实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括： 每一步所需的测试操作动作、测试程序输入或设备操作等； 每一步期望的测试结果； 每一步的评估准则； 导致被测程序执行终止伴随的动作或指示信息； 需要时，获取和分析中间结果的方法。l 测试用例的前提和约束。再测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响；l 测试终止条件。说明测试用例的测试正常终止和异常终止的条件。确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。2 开发环境统型目前公司产品研发中用到的开发环境、开发工具比较繁杂，应予以一定程度的统一。这项工作考虑应结合调研情况分析，根据公司主型软件工作硬件平台、操作系统等发展趋势，确定一个合理的统型方式和过渡方案。方案影响深远，因此制定时需要通盘考虑：l 统型方案既要考虑到现有在研产品开发，更要关注未来产品预研，同时还要照顾已定型产品的维护。l 统型方案既要考虑到公司未来产品发展趋势，体现出一定的前瞻性和先进性，又要从现状出发，考虑广大研发人员的实际使用需要和技术能力。l 统型方案应考虑到实施的平稳过渡，逐步推进而非强行划断，尽量避免震荡。 l 统型方案和测试工具选型结合，通过与统型目标的软硬件开发平台结合紧密的商购测试工具、二次开发工具和自行开发的实用小工具，自然引导。开发环境统型方案将从以下方面加以阐述：l 现状分析：环境分布、使用情况、发展趋势、人员技术能力分布等l 统型建议：统型的原则及据此提出的平台统型建议l 统型机制：提出结合项目立项、配置管理、缺陷管理等软件研发流程的统型管理机制l 工作计划：提出具体的进度表3 软件开发语言编码规范编码规范是研发团队的统一语言，在提高研发团队整体效率方面，编码规范与秦始皇的“车同轨、书同文”具有一样重要的意义。编码的规范统一，也是建设更高层次的软件构件库的坚实基础。目前公司涉及的编程语言有很多种，主要的是嵌入式平台下的C/C+语言，其他还包括PC环境下的Java、Delphi、C+Builder等。这些目前都有一些工程上比较公认的编码规则，其实主要是根据经验和实际结合，权衡利弊，筛选出合理的规则集。我们将根据经验，在充分了解目前的代码风格的基础上，提出公司内部针对各种开发语言的编码规范，原则上新的编码规范将尽量吸收当前的普遍的代码风格，以减少程序员编码习惯过大改变可能带来的不适应。编码规范实际推广的关键首先在于有一个有效合理的检查机制。如果纯粹通过人工走查或者同行评审的会议方式，推行的工作量太大，在目前的人员配比条件下，是不现实的。业界已经有一套非常成熟的做法：选择合适的代码规范检查工具，将编码规则嵌入到工具中，每个开发工程师在提交代码前必需提交对应的检查结果。经过一段时间的运作，编码规范的普及和推广效果就会自然显现。根据我们的实际推广经验，这对测试工具的规则定制能力有一定要求，也是测试工具选型必须考虑的内容。在实际中，每个项目应根据自身实际情况，在统一的编码规范基础上进一步明确规则，哪些是本项目不需要的，哪些是需要进一步统一的，例如命名规则就有必要做进一步的细化要求。因此，制定软件开发语言编码规范方案包含：1. 形成符合公司实际的编码规范：根据公司的实际，我们建议分布实施，首先针对有一定基础且需求迫切的嵌入式平台C/C+语言，然后针对其他语言推出规范和相应控制措施；2. 配合规范实施的指导书：将规范应用推广形成规范，并固化到RDP体系和PLM中；3. 结合选定的代码规则测试工具，定制代码规则检查集。4 软件需求分析软件需求由用户需求转化而来，是软件设计和测试的源头。软件需求的一般都通过软件需求规格说明书文档来体现。公司现已在应用需求跟踪矩阵对需求进行管理，但目前管理到的只是在项目的立项和结项这两个头和尾上，研发过程中对需求的跟踪基本处于无人监控状态，需求的变更亦不能全方位有效的控制，测试部门也会因需求的不明确导致测试针对性不足。一份好的软件需求规格说明书一般具有以下七大特性：完整性、正确性、可行性、必要性、按优先级管理、无二义性、可验证性等。因此，软件需求分析的工作也应该从这七个方面来推进，并进行质量评价。软件需求分析是软件工程业界多年来的研究热点，形成多种的方法体系如RUP等，涉及面非常广，但在工程上最关键的，也尤为测评人员关心的，就是软件需求分析得到的需求质量如何，是否可验证。软件需求规格说明书的质量，通常都通过制定详细的文档检查单，由各方人员预先审查，然后组织相关人员进行会议评审。这些都是非常有效地方法，但由于文字说明的二义性和不明确性特点，不可避免地存在一些缺陷。另一个更致命的问题是，软件需求主要从用户角度阐述，而软件设计文件则主要从软件的系统结构、实现方法等角度描述，导致软件需求难以进一步追踪，只有到系统测试的时候，才能得到验证，这就给系统引入了许多与需求相关的缺陷。而且由于公司面对的是机构客户，具有需求变更频繁的特征，这就带来更多的管理困难、验证难度和软件隐患。传统的文档检查单和会议评审仍然是最有效地方法。但如何去设计文档检查单是关键，一般通用的检查单其本身就基于含糊的表述，只能保证模板格式，对实际内 容是难以把关的。基于多年来的实践经验，我们形成了一套借用敏捷开发（XP）的测试驱动设计（TDD）理念的检查方法，要求需求本身的有清楚的验证方法和通过标准，由验收方法的清晰来保证需求的清晰。在这个阶段，就可以综合应用软件测试中的各种测试类型和方法，按照测试的要求和理念形成独到的检查项，这样的检查思路一旦形成一致的思维方法，将极大的提升需求分析水平。另一方面，软件设计文档与软件需求文档之间应建立起需求追踪的关系，避免原有的需求跟踪只管两头的弊端，这方面可以参考GJB-438B标准中相关要求。通过对设计文档的控制，将需求追踪的工作进一步细化，这样才更容易实现管理和验证。需求变更的控制也是调研中很多人员提到的问题。软件需求规格说明书编制是控制变更的一个开始，需求分析时应识别容易发生变更的部分，并在软件设计中对此加以体现。咨询通信与公司类似，面对的是机构客户，生产的产品属于单品价值高，小批量多批次，多年的摸爬滚打提供了一个最好的实践案例。例如，咨询公司的无线电台和通信控制器等产品在验收时，通常都会由于不同部队首长、军代表的个人偏好而容易被要求更改，这类需求由于军队的特殊体制，难以在需求调研阶段得到充分确认，经过摸索咨询形成一套行之有效的解决办法：在需求分析阶段对这类需求进行识别和隔离，设计阶段基于MVC的设计思想，通过自主开发的获得广东省创新金奖的嵌入式图形开发平台工具，把嵌入式开发转化成VC环境下开发，使得易变的部分容易更改，有效控制了这类需求变更带来的问题。基于以上分析，我们从软件需求检验的角度，提出软件需求分析和软件需求分析质量评价的方案，主要内容包括：1. 软件需求分析操作规范：重点为基于测试驱动设计思想的理念的需求分析验证方式，以及由此细化的软件需求检查单设计方法；2. 软件需求分析质量评价准则：基于软件需求特性综合形成的质量评价模式和操作方法；3. 软件需求分析说明书模板，同时配套地修改软件设计文档的模板，以便进一步实现需求的层层细化跟踪，避免设计过程中的需求异化。5 软件可测试性设计软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。从测试设计的层面来说，要求软件需求分析阶段获得的需求在设计过程中易于追踪和进一步细化，这与前面软件需求分析中是一致的。软件设计文档中除了要体现出软件架构设计以便实现外，应该同时关注需求的分析和细化。通过参考各类相关标准，重新制定软件设计文档模板，并对应提出基于需求追踪的软件设计文档检查细则，大体可以解决这个问题。软件可测试性包含可操作性、可观察性、可控制性、可分解性、简单性、稳定性、易理解性等七大特性。针对这些特性，软件可测试性设计具有一些客观的评价标准和依据。从软件代码的层面来说，可以通过对代码进行机械分析，提取出度量指标，通过这些指标指导开发人员改进自己的设计。我们将为公司在设计和编码规范表中制定相关的可测试性设计的度量标准，引导相关开发人员和测试人员自发地重构代码，提升可测试性设计水平。6 软件测试工具选型一、 测试工具的认识和定位测试首先要掌握逻辑严密的需求覆盖体系、分析设计方法，具备良好的工程管理基础，但“工欲善其事，必先利其器”，必须有与方法相适应的一些操作手段和工具应用技能，才能达到测试设计分析的预期的效果和目的。与手工操作相比，借助测试工具有一些显著的优点，包括提高测试效率、提高测试覆盖率、执行结果一致性、更好地利用资源等，尤其是对大量代码的度量和结构分析以及大规模的负载压力测试和一些指标测试，没有测试工具协助是不可能完成的。但是针对测试工具，尤其是通常所说的自动化测试工具，存在一些普遍的错误认识，例如“自动化测试可以完成一切测试工作” 、“测试工具能使工作量大幅度降低”、“测试工具能够实现百分之百的测试覆盖率” 、“自动化测试工具容易使用”、“自动化测试能发现大量的新缺陷”，这样一些观点其实在前面公司的调研中，在部分研发人员中也有体现。事实上，虽然许多工具都宣传其背后的测试思想和自动化测试用例设计等，目前测试工具更重要的还只是一种测试手段而已，其用例设计层面以静态的语义分析为基础，对测试最重要的“保证需求不被异化”的要求是无能为力的。在测试中要发现缺陷，起先决作用的还是测试需求理解和测试设计活动。工具层面，一般的测试活动包括测试用例设计、测试用例执行、测试结果记录、测试结果比较、测试报告产生这样五个主要步骤，测试自动化选型主要要解决定位问题：即我们想要进行哪个（些）步骤的自动化。定位准确的情况下，我们再针对性地选择合适的工具。目前按功能划分，软件测试工具一般可分为白盒测试工具、黑盒测试工具和性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具等类性。在软件测试的多个阶段均可引入测试工具进行辅助。相对来说，目前基于通用PC平台的系统测试工具发展比较成熟。就嵌入式平台而言，动态测试工具中，系统级的功能测试难以在市场上直接采购到，录制/回放类的工具能否适用需要更进一步调研产品类型后才能给出建议；灰盒测试工具（即以灰盒方法进行测试，但工具提供白盒层面的代码覆盖数据支持）则需要比较高的使用技能。而就单元、集成测试工具而言，比较难以在市场上直接购买到的是那些调试（更别说测试）环境非常复杂的软件比如单片机软件的单元集成测试工具。相对比较完善的是针对C/C+/Java/Ada等应用广泛的代码静态度量、规范检查、代码分析等不需要在平台上实际运行的静态工具。由于嵌入式平台的多样性和有别于PC平台的一些特点，工具的引入必须在测试认识统一、测试方法形成体系的基础上，统筹考虑，以引入商用自动化测试工具为主，自主开发改进为辅，形成比较完整覆盖各测试阶段，有效支撑测试方法体系的平台。以嵌入式平台为例，对应用广泛的代码静态度量、规范检查、代码分析等静态测试工具，可以考虑直接引进商用测试工具，对于动态的单元集成测试、灰盒测试、系统测试工具，可以考虑在引进商用测试工具的基础上，做一些适配等方面的自主二次开发，使工具适应测试实际需要。如前所述，工具的使用本身是有局限性的，而且工具的学习和掌握以及运用也是有许多的工作量在其中，嵌入式平台这些问题尤其突出。测试工具引进要想取得好的效果，在公司内部，也必须为有效地应用工具，更好地开展测试工作，推动嵌入式平台的统型、代码规范、人员技术储备等。总之，我们应根据测试的定位和需要来选择合适的工具。只有首先明确哪些是提升能力的关键环节，才能在这些环节引入合适的辅助工具，帮助我们提升测试效果，使工具真正按照整个团队的目标来服务软件质量目标。二、 测试工具的选择面对市面上如此之多的测试工具，对工具的选择就成了一个比较重要的问题。在考虑选用工具的时候，主要从以下几个方面来权衡和选择：1. 功能功能当然是应该最被关注的内容，选择一个测试工具首先就是看它提供的功能。但这并不是说测试工具提供的功能越多越好，在实际的选择过程中，适用才是根本。事实上，目前市面上同类的软件测试工具之间的基本功能都是大同小异，各种软件提供的功能也大致相同，只不过有不同的侧重点。例如，同为常见的白盒测试工具的Logiscope和Testbed软件，提供的基本功能大致相同，只是在编码规则、编码规则的定制、采用的代码质量标准方面有不同。除了基本的功能之外，以下的功能需求也非常重要：l 报表功能；测试工具生成的结果最终要由人进行解释，而且，查看最终报告的人员不一定对测试很熟悉，结果报表能够以什么形式提供是应用时非常关键的。l 测试工具的集成能力；测试工具的引入是一个长期的过程，而我们希望的是通过统筹规划，引进的各类工具形成一个覆盖完整的平台。因此，测试工具的集成能力也是必须考虑的因素：首先，测试工具能否和开发工具进行良好的集成；其次，测试工具能够和其他测试工具进行良好的集成。l 操作系统和开发工具的兼容性；测试工具可否跨平台，是否适用于公司目前使用的开发工具，这些问题也是在选择一个测试工具时必须考虑的问题。2. 价格除了工具的功能之外，其价格就应该是最重要的因素了。在功能基本等同、性能基本一致的情况下，完全可以选择其中价格较低的测试工具。3. 测试工具的连续性和一致性测试工具是测试自动化的一个重要步骤之一，在引入/选择测试工具时，必须考虑测试工具引入的连续性。也就是说，对测试工具的选择必须有一个全盘的考虑，分阶段、逐步的引入测试工具。这同时也有助于保持公司开发团队开展工作的连续性和一致性，有助于进一步规范软件开发、测试的管理和流程。三、 测试工具的评估通过以上分析，可从众多软件测试工具中缩小选择的范围，划分一个大致的选择品牌、型号，仍需要对各个候选测试工具从各个方面进行评估，考察其功能、性能、费用、易用性等方面是否符合公司实际。一个比较合理的方法就是对期望引进的工具预先设定评价的各个方面，分配不同的权重级别，组成一个评价模型，在试用后进行打分确定。例如，待引进的自动化录制/回放测试工具，可以用以下的一张表来进行评估录制/回放功能、数据功能、测试/错误恢复能力、对象名映射、对象识别能力、脚本语言扩展能力、环境支持、与其他工具的兼容、价格费用、易用性等方面进行评估。四、 测试工具选型方案基于我们对软件测评工具的现状和未来发展趋势的深入把握，根据公司公司的现状和项目的具体需求，应把握全面性、实用性、适用性等原则，以下是工具选型一些考虑：1. 明确测试工具引进范围统一测试工具选型的认识，明确测试工具选型的定位，制定详细的测试工具引进的计划，对工具覆盖的平台、类型、数量明确规定，并对试用人员和评估方法预先设定：l 工具应用平台综合考虑到公司实际项目情况、测试人员、测试资源、本项目推进进度等，建议一期引入试点工具以嵌入式平台为主，在二期重点引入系统应用软件测试工具。l 工具类型试用工具引进应形成比较完整覆盖各测试阶段，有效支撑测试方法体系的平台。建议一期嵌入式平台应覆盖代码静态度量、规范检查、代码分析等静态测试，同时应适当考察动态的单元集成测试、灰盒测试、系统测试工具，并引入合适的测试管理工具。l 工具数量建议对期望引进的测试工具，分别引入2类，最多不超过3类的测试工具进行试用，以将评估工作量控制在合理的范围。2. 对引入的测试工具进行充分的试用一般确定购买一款测试工具前，产家会提供一段时期的试用期。虽然在购买工具前经过了充分调研、评估和选择，但仍有可能所选择的工具无法满足自身需要或存在其他方面的问题，这就需要公司尽量在测试工具的试用期发现存在的问题。因此需对引入的测试工具进行充分的试用，通过完整的实际试点项目是不错的做法。3. 针对测试工具使用调整相关研发流程有时，引入的测试工具符合实际需要，却没有形成一个良好的使用测试工具的环境，换句话说，就是没有能够形成一种机制让测试工具真正能够发挥作用，也会导致工具起不到应有的效果。例如，白盒测试工具的一般使用场合是在单元测试阶段，而单元测试是由开发人员完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。在这种情况下，就必须形成一种有约束力的机制来强制对测试工具的使用。我们建议的一种较好的方式是，将测试工具的使用明确定义进公司的开发流程中。具体的做法如：在开发流程中明确说明，在项目里程碑提交的文档中必须包括测试工具生成的报告，该报告中的数据是决定项目是否合格的依据。4. 进行有效的测试工具的培训测试工具的使用者必须对测试工具非常了解，在这方面，有效的培训是必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，对于测试工具使用者的积极性是很大的打击。一般来说，测试工具厂商会提供一定程度上的工具培训；其次，公司自身可开展测试工具的培训，还可进一步进行一系列的培训和交流，如