软件测试学习体会Vol 10文档格式.docx

软件测试学习体会Vol 10文档格式.docx

《软件测试学习体会Vol 10文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试学习体会Vol 10文档格式.docx（13页珍藏版）》请在冰豆网上搜索。

这些覆盖评测通过以下公式计算：

测试覆盖（已执行的）=Tx/RfT

Tx是用测试过程或测试用例表示的已执行的测试（Test）数。

成功的测试覆盖（已执行的）=Ts/RfTTs是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试（Test）数。

如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：

x%的测试用例（上述公式中的T（p，i，x，x））已经覆盖，成功率为y%

2、基于代码的测试覆盖

基于代码的测试覆盖，评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。

具体而言代码覆盖率分析是这样一个过程：

●找出程序经过一系列测试而没有执行的部分代码

●创建一个附加的测试用例来增加覆盖率

●决定代码覆盖的定量度量。

针对代码的测试覆盖率有许多种度量方式，例如：

语句覆盖（StatementCoverage）：

也称为行覆盖（linecoverage），段覆盖（segmentcoverage）和基本块覆盖（basicblockcoverage）。

它度量每一个可执行语句是否被执行到了，这个覆盖度量的主要好处是它可以直接应用在目标代码上，不需要对源代码进行处理，主要缺点是对一些控制结构很迟钝。

判定覆盖（DecisionCoverage）：

也被称为分支覆盖（branchcoverage），所有边界覆盖（all-edgescoverage），基本路径覆盖（basispathcoverage），C2覆盖，判定路径覆盖（decision-decision-path或DDPtesting）。

它度量是否每个BOOL型的表达式取值true和false在控制结构中都被测试到了。

这个度量有语句覆盖的简单性，但是没有语句覆盖的问题，缺点是忽略了在BOOL型表达式内部的BOOL取值。

条件覆盖（ConditionCoverage）：

它独立的度量每一个子表达式，报告每一个子表达式的结果的true或false。

这个度量和判定覆盖（decisioncoverage）相似，但是对控制流更敏感。

不过，完全的条件覆盖并不能保证完全的判定覆盖。

路径覆盖（PathCoverage）：

也称为断言覆盖（predicatecoverage），它度量了是否函数的每一个可能的分支都被执行了。

路径覆盖的一个好处是：

需要彻底的测试。

但有两个缺点：

一是，路径是以分支的指数级别增加的，例如：

一个函数包含10个IF语句，就有1024个路径要测试。

如果加入一个IF语句，路径数就达到2048；

二是，许多路径不可能与执行的数据无关。

?

；

循环覆盖（LoopCoverage）：

这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次（连续地）。

对于do-while循环，循环覆盖报告你是否执行了每个循环体只有一次还是多余一次（连续地）。

这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。

三、总结

测试覆盖分析是一种对测试阶段度量及测试工作情况分析的很好的方法，可以使测试程度更为明确，阶段进度一目了然，其统计值也便于管理部门对当前测试状态进行了解与把握。

===分割线===

===分割线===件测试外包发展展望

在软件外包的大潮中，作为软件外包产业的一个很容易的切入点，软件测试外包将有一个什么样的发展，我们这里进行一个简单讨论。

多种业务模式并行

从为客户提供外包测试服务的业务模式，软件测试外包可分为现场测试模式和公司内部测试模式。

现场测试模式是人员外派模式，主要是指供应商把自己的人员派到客户的现场进行现场测试，可派整个测试团队进行独立测试，也可以将测试人员分散在客户的测试团队中。

现在国内很多提供测试外包服务的公司都在按照这种方式提供服务，该业务模式还将持续一段时间。

公司内部测试模式指的是测试外包方承接客户的测试服务，在公司内部进行软件测试工作，按照约定提交测试工件或测试报告，软件测试费用按照软件测试外包的工作量来进行计量。

该模式具有降低成本、降低风险、强化核心能力、扩大经济规模等作用，越来越多的跨国公司将该模式作为国际化的重要战略选择。

这种模式在国内出现得较少，但有逐步朝这个方向发展的趋势。

外包市场日趋扩大

目前，全球软件外包的发包市场主要集中在北美、西欧和日本等国家。

由于语言、对外关系、地理位置等多种因素，国内对日外包具有众多优势，对于日本外包市场，国内外包占有重要地位，并在将来会不断的巩固和增强。

在对美软件外包市场上，中国软件企业则没有优势可言，语言、文化等方面的差异导致对美软件外包市场不容易开拓。

对于美国软件外包市场，印度占用主导地位，中国软件企业与印度软件企业存在明显差距。

但是，通过对日外包，中国软件企业不断积累。

更重要的一点，我国从事软件本地化服务的软件公司在为美国大型软件公司提供软件本地化服务的过程中已经积累了丰富的项目管理经验，得到美国客户的信任和长期合作，而且随着企业规模不断扩大，技术实力不断增强，完全有能力从美国市场承接更多的软件测试外包服务，扩大外包市场。

因此，对于美国的软件测试外包市场将不断扩大。

随着中国经济的不断发展，国内的外包市场也不断扩大。

据有关研究，未来中国将超过日本成为继美国、欧洲之后全球第三大服务外包需求市场。

目前，对于国内市场，国内软件测试外包企业占有绝对主导地位，随着国内外包需求市场的不断增大，国内的软件测试接包市场会不断扩大。

外包服务商规模日趋扩大

随着不断的积累，国内的软件外包服务商的规模不断增大，出现多个超过千人的公司。

同时，外包市场竞争愈来愈激烈，而发包方也对外包商的规模要求也越来越严格，这也迫使国内的服务商不断扩大规模，培训更多的专业人才，不断提高自身的竞争力。

另外，作为世界第一的软件外包服务大国，印度并不满足现状，印度的外包企业正在不断的扩大自己。

作为印度软件外包的"

航母级"

企业，塔塔咨询服务公司（TCS）、信息技术系统公司（Infosys）、威普瑞公司（Wipro）、萨蒂扬公司（Satyam）纷纷进入中国，在中国设立了办事处，或与中国的IT企业进行外包合作。

中印软件外包的竞争战火已经由国际市场燃烧到了我们的"

家门口"

。

因此，为了避免被国外大公司的吞并，迫使国内软件测试外包企业不断扩大自己的公司规模来壮大自己。

可以预见，随着时间的推移，行业格局逐渐清晰，逐渐会出现一些龙头测试外包企业。

外包服务日趋规范

随着外包市场的不断发展，国内外包企业自身不断积累，在测试流程控制、测试管理、测试质量控制等方面不断完善，测试外包服务日趋规范。

同时，发包方对软件的质量要求越来越高，对外包服务商的服务质量要求越来越高。

因此，不论是内因还是外因，都促使外包服务商不断完善业务流程，进一步提升客户信任度，并逐渐达到专业化、规模化、规范化，逐渐形成自己的品牌，完成从政策引导向品牌战略升级发展。

云测试外包成为趋势

在云计算的浪潮下，基于"

云"

平台和"

模式的外包服务已经出现，并日趋成为外包行业发展的主流和趋势。

云外包的出现对外包企业的服务模式和业务模式都将带来根本性的变革，同时也给外包企业带来了千载难逢的机遇。

基于云的外包测试，将成为软件测试外包的一个热点。

===分割线===对数值计算程序的测试方法

1.书写是否符合规范（国家软件标准或规范），至少应符合本公司的标准；

2.注解是否充分，其他人员能够很容易的看懂所写的程序；

3.数组的上下界是否规定清楚；

4.程序的输入输出参数的定义是否准确；

5.所开发的程序是否方便客户的使用；

6.程序是否完全实现了软件的规定；

7.数字转换为其字符串表示形式的数值格式化方法，是否完全地实现了软件所规定的内容，没有错误；

8.检查以参数的形式传递对象的接口，是否完全地实现了软件所规定的内容，没有错误；

9.检查参数以合法的方式提供格式化服务，是否完全地实现了软件所规定的内容，没有错误；

10.检查数据库自动生成数值序列功能，是否完全地实现了软件所规定的内容，没有错误；

11.检查布尔型对象转换值：

NULL、未定义、0、或FALSE均转换成布尔对象的方法，是否完全地实现了软件所规定的内容，没有错误；

12.检查数值函数对象是否完全地实现了软件所规定的内容，没有错误；

13.检查将非字母、数字字符转换成ASCII码编码函数，是否完全地实现了软件所规定的内容，没有错误；

14.检查将ASCII码转换成字母、数字字符译码函数，是否完全地实现了软件所规定的内容，没有错误；

15.检查不同进制（二、八、十六）的数值转换成十进制整数的转换函数，是否完全地实现了软件所规定的内容，没有错误；

16.检查将数值字串转换成浮点数转换函数，是否完全地实现了软件所规定的内容，没有错误；

17.检查/除号、小于、=小于等于、不等于、=等于、大于、=大于等于、and逻辑与、not逻辑非、or逻辑或，是否完全地实现了软件所规定的内容，没有错误；

18.Null转化，在设置值对象VO时，在VO内部是否将空串"

"

转化为null，数值型数据（整数、浮点数等）null转为0；

19.检查控件数据类型的转换，编辑控件数据类型是否与表中对应字段数据类型一致；

20.检查单精度实型ffloat（8位）、双精度实型double（16位）控件的范围控制是否正确；

21.检查小数位数的设置是否符合规范；

22.检查禁止输入字符的设置是否符合相应要求；

21.检查变量的交叉引用表：

检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况；

22.检查标号的交叉引用表：

验证所有标号的正确性；

23.检查子程序、宏、函数：

验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致；

24.等价性检查：

检查全部等价变量类型的一致性；

25.常量检查：

确认常量的取值和数制、数据类型；

26.比较控制流：

比较设计控制流图与实际程序生成的控制流图的差异；

27.选择、激活路径：

在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错；

28.补充文档：

根据各检查项目，可以编制代码规则、规范和检查表等作为测试用例；

29.对照程序的规格说明，详细阅读源代码，并与实际的代码进行比较，从差异中发现程序的问题和错误。

===分割线===缺陷漏测分析：

测试过程改进（下）

◆捕获概率

在数据库中有"

捕获概率"

的属性项（在前面小节进行了详细解释），这是对实施过程变更后防止同类问题再次漏测的效果的一项估计指标。

该估计是计划预期效果的基础。

通过对各变更的捕获概率取总后求平均，可以得到过程变更后的整体预期效果，这样就能对产品发布后用户问题数的降低程度进行合理的预期。

四、总结

进行漏测缺陷分析的主要目的就是提高产品质量和用户满意度、降低修复用户发现缺陷的成本。

这是通过推动尽可能在软件开发过程的早期发现缺陷来实现的。

进行漏测分析活动的软件测试组将会帮助软件开发组改进质量，他们的测试过程将更加完善，测试环境也将更加符合用户实际环境。

从漏测分析过程中收集的数据能为测试环境补充硬件等改进活动提供充分的理由。

此外，漏测分析过程鼓励项目组间的交流和合作，开发更高质量的软件产品。

它还能预测未来的漏测缺陷数，评价自身的效果，来证明所投入的资源是值得的。

===分割线===以知识为核心的ALM之测试管理篇

测试管理：

以知识为核心

多年来，我们一直倡导"

以知识为核心的ALM"

，在测试项目实施过程中，也不能回避知识管理的问题。

这不是简单的文档管理，而是对整个开发和测试过程中所有知识（包括各类文档、链接、Email、附件等）的有序记录，以及有效的积累和查询，以备当前和未来项目之用。

知识库中的需求能够与测试模板以及测试任务链接，确保所有需求都得到妥善的测试。

以知识为核心的测试管理，体现为以下三方面：

●及时更新测试计划

通过中心知识库，测试团队可以查看最新的项目文档，如业务需求和规范点等，这些文档都是测试部经理制定测试计划的重要依据。

当项目文档更新时，测试部经理也能与开发团队同步查看，有利于及时更新测试计划、重新分配资源、或调整测试策略。

●提高测试计划效率

基于知识库，测试团队可以轻松地创建、保存、管理和再利用测试模板。

测试人员可以根据先前的测试结果，分析相关的缺陷和bug数据，从而计划、分配测试任务。

另外，测试团队还可以从知识库中调用原来的测试范围，或依据知识库中的历史记录更准确的估计测试范围，以此提高测试计划的效率。

●促进项目团队沟通

项目相关人员能够查看每个测试模板的变更历史和背景信息。

每个测试用例都能直接与相应的文档关联，包括测试计划、业务需求、日程等，测试人员通过将产品功能与这些文档对比，能更准确地理解测试任务，完成测试工作。

全面的测试管理方法

全面的测试管理涉及到方方面面的内容，从测试用例、计划和团队管理，到测试结果分析。

有效的测试管理方法不仅要能创建、管理产品版本的整个测试周期，还需要制定测试计划、分配测试任务、管理测试范围以及提交产品缺陷。

测试模板（TestTemplate）和测试任务（TestTask）是TechExcel测试管理模型中的两个重要概念。

测试模板是测试任务的蓝图，包含了测试的内容、步骤和测试点。

一个测试模板可以用于多个产品或版本的测试。

举例来讲，设计一个测试IE浏览器是否可以保存当前页面的测试模板，该模板就应该可以用于IE6.0和7.0等多个版本。

通常一个软件产品会在多个环境中运行，如一款软件有英语、汉语和法语版本，需要对三个版本的产品测试，又如某软件要在Linux、WindowsVista、WindowsXP上运行。

这就需要在测试模板中设置一个或多个环境变量，提供多种供选择的值，一个测试模板与多个环境变量的组合就产生了多个测试任务。

测试任务是测试模板的一个实例，每个测试任务包含执行的过程、历史、状态信息。

例如，环境变量"

Web浏览器"

可设3个值：

IE、Firefox和Safari；

一个包含该环境变量的测试模板则可产生3个测试任务：

IE测试任务、Firefox测试任务和Safari测试任务。

图1显示了TechExcel测试管理方法的总体流程。

首先，QA经理从测试模板库中选择已有的测试模板或由资深测试人员创建新的测试模板，将测试模板有序的组织起来，就形成了测试模版树（图中模板视图）。

测试部经理或项目经理以测试模板树为依据来规划测试周期和发布周期。

在测试任务的执行过程中，失败的测试任务还可直接生成缺陷，提交到缺陷及任务跟踪工具（如DevTrack）中进行跟踪修复。

测试计划及任务分配

测试计划分为两大部分，首先是设计产品的发布周期和测试周期，一个发布周期包含多个测试周期；

之后通过测试模板在对应的测试周期中生成测试任务，此为测试计划的重要步骤，测试模板树形结构是QA经理或项目经理做测试计划的重要依据。

如图2所示，针对游戏产品的测试工作，左边部分为测试部经理所设计的测试范围，涉及音效、人物、级别三大部分，每个文件夹中包含对应的测试模板。

图中右边部分为根据测试模板所制定的测试计划，SpeedRacer和Football2008两款游戏能共用大部分测试模板。

针对SpeedRacer游戏，有1.0和1.1两个发布周期，对应游戏的1.0和1.1版本，1.0版本包含了两个测试周期，分别为TestCycle1和TestCycle2，每个测试周期中都有对应的测试任务。

结合常用的测试方法和TechExcel的全面测试管理，测试计划和任务分配通常按以下步骤进行：

●冒烟测试。

发布周期中的第一个测试周期通常为基于产品功能的自动冒烟测试。

如不能通过冒烟测试，就不需要马上投入人力来开展接下来的测试工作了。

●设定初始测试周期计划。

对于每个测试周期，测试团队都会对以下内容做好计划：

环境变量、测试模板、测试人员或团队。

●增补测试周期。

通过查看之前的测试周期中通过和失败的测试，针对bug比较多的功能点和运行环境，可以增加测试周期。

●确定测试目标。

测试团队可以制定每个发布周期所需要达到的各项指标，如测试任务完成数量、发现缺陷的数目和整个发布周期所需花费的时间等。

执行测试任务、记录测试缺陷、跟踪测试结果

有效的测试管理工具不仅需要全程跟踪每一个测试任务的执行情况，而且还能自动提交缺陷。

在测试任务完成或者缺陷提交的第一时刻，测试管理工具将其结果记录下来，使测试和开发人员都能了解到最新状况。

与缺陷及任务跟踪工具的紧密关联是高效测试管理的重要保证之一。

当测试任务失败时，测试管理工具会自动提示测试人员提交产品缺陷。

通过与缺陷及任务跟踪工具（如DevTrack）的集成，测试人员在提交bug时可在DevTrack中自动创建新的任务，该任务不仅与测试任务相关联，也与DevTrack中该bug对应的开发任务关联。

这就有利于开发人员查找相关信息，准确跟踪和修复bug。

测试外包管理

在快速发展的中国离岸外包市场中，软件测试外包占到了相当比例。

因此，测试工具不仅需要适用于传统意义上的测试管理，还应更好的服务于测试外包企业。

综合考虑国内测试管理和外包行业的特点，测试外包管理至少需要解决以下问题：

●ALM工具的整合科学的项目规划

日趋激烈的行业竞争使得ALM工具的整合成为必然。

需求仍然是根本，可以作为项目计划、任务或测试的输入数据。

例如，一个新需求既可以被导入监控整个开发过程的任务执行工具内，也可能被导入产生测试用例及测试任务的测试工具内。

对于测试外包项目，通过项目规划工具，发包方既可以为承包方制定项目规划，又能够实时监控承包方的项目进展情况，发现问题能够及时处理，避免了项目延期和资源浪费等现象发生。

●流程自动化

测试流程的管理是整个测试外包中的关键问题，根据管理的内容不同，可以分为文档管理、配置管理、缺陷管理、进度管理、质量管理、资源管理、成本管理、变更管理等方面。

每个项目和测试团队若能根据需要自定义工作流程，且每一个状态都有专人负责，保证任务有始有终，将会大大提高测试工作的效率。

另外，一些自动化的机制，如邮件自动通知和任务自动升级等，也能够添加到流程里。

●支持分布式团队

离岸外包的全面发展必然带来大量的分布式开发和测试模式。

当数据量大或沟通频繁时，分布式团队的协同工作益形困难。

使用分布式系统让各个团队有其本地数据库，运行起来速度快又可靠。

这种特殊性决定了适合测试外包项目（尤其是离岸方式）的解决方案最好能够支持分布式团队。

===分割线===软件测试流程概述

一、新产品或工程管理流程

1、需求调研

在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；

同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2、制定测试计划

进行每一种测试之前，测试负责人要根据"

产品定义书"

及"

总体设计说明"

和"

详细设计文档"

制定"

测试计划"

，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，"

经过审查通过，才能实施。

3、需求Review

开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。

4、设计Review

在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。

设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。

5、测试设计

在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。

然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。

每个测试用例必须包括以下几个部分：

（1）标题和编号

（2）测试的目标和目的

（3）输入和使用的数据和操作过程

（4）期望的输出结果

（5）其他特殊的环境要求、次序要求、时间要求等

6、开发测试工具和准备测试数据

在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。

7、测试执行

当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。

在测试过程中发现的任何与预期目标不符的现象和问题都必须