软件测试入门

1 如何认识测试

    测试是一个方法论而不是一个技术论；

 2 软件测试的误区

  * 软件开发完成后进行软件测试；

  *软件质量问题是测试人员的错误，软件发布后如果发现问题，那是软件策划四人员的错；

  *测试技术要求不高比编程容易，随便找一个人就可以完成；

  *测试跟着开发动，有时间就多测试，没时间就少测。

  * 测试是测试人员的事，与开发人员无关；

软件测试从这里开始

 * 需求测试和设计测试也是软件测试的一种；

 * 软件测试应该涵盖整个软件生命周期。同时软件测试本身也应被测试。

 * 测试要执行所有可能测输入；

在测试中，穷举测试工作量太大，实践上行不通，一般采用等价类和边界值分析等措施来进行实际的软件测试；

* 好的测试一定要使用很多的测试工具。

 工具所能发挥的作用依赖于使用工具的人，因此，对工具的过分依赖将降低人的能动性，并最终使测试本身受到损害。适当的使用测试工具能够减轻策划人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。

3 测试工程师的素质

 3.1基本素质

 沟通能力，自信心，幽默感记忆力，耐心，怀疑精神，自我督促，洞察力；

广泛的经验；

表达能力，问题描述能力；

会提问，会寻求help；

逻辑思维能力；

团队协作能力；处理日常事务的能力和处理突发事件的能力；

3.2基本素质

对于系统测试，把握需求是第一位，对产品熟练，能够快速熟悉新的产品需求，很强的需求理解能力显得很重要。

测试基础：明确测试流程中各个阶段的工作，对测试的认知程度，决定了测试流程管理的规范性，测试工作的质量；

测试方案的分析设计能力，测试案例的设计能力；

测试工具的使用；

编程你呢管理，数据库知识，网络知识，操作系统知识；

团队协作能力，与各个小组之间的沟通能力；

测试管理，管理决定了工作质量，尤其是测试经理，需要管理团队的测试能力。

4测试工程师的分类

测试工程师一般分为两类：测试工具软件开发工程师和软件测试工程师。

测试工具软件开发工程师主要负责编写测试工具代码，并利用测试工具对软件进行测试，或者开发测试工具为软件测试工程师服务。

软件测试工程师主要负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误，决定软件是否具备稳定性，并写出想要的测试规范和测试案例。

按照测试类型分类：功能测试工程师，自动化测试工程师，性能测试工程师等。

按照测试对象分类：web测试工程师，数据库测试工程师，数据库测试工程师，c/s测试工程师，个人软件测试工程师；

6测试工作的未来

bug 预防和早期检测

因为现在把重点放在产品交付的质量上来，预防实践和静态分析仪这样的检测工具将成为主流。

                      第2章软件质量体系

2.1 软件能力成熟度模型：cmm

cmm为企业的软件过程能力提供了一个阶级式的进化框架，接替工五级。

第一级：初始级，第二级：可重复级；第三极：已定义级；第四级：受管理级； 第五级：优化级；

第二级：可重复级；第三极：已定义级；第四级：受管理级；第五级：优化级；

初始级：工作方式处于救火状态，不断的应对突如其来的危机；

工作组：软件开发组，工程组；

需要建立项目过程管理，建立各种计划，开展qa活动；

2.2可重复级

人们总结出软件开发的首要问题不是技术问题而是管理问题。因此第二级的焦点集中在软件管理过程上，一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括需求管理，项目管理，质量管理，配置管理和子合同管理5个方面

关注点：引入需求管理，项目管理，质量管理，配置管理，子合同管理；

引入工作组：测试组，评估组，质量保证组，配置管理组，合同组，文档支持组，培训组；

2.3 在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三极则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去，所有开发的项目需求根据这个标准过程，剪裁出与项目适宜的过程，并且按照过程执行，过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。

关注点：文档化，标准的一致化；软件过程标准话文档化，质量可以得到控制；工作组：sepg软件评估组。提高：对软件过程定量分析，加强质量管理。

                                                 第三章  软件的生命周期

3.1 需求管理：

需求应当具备一下特点：

完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确滴陈述其要开发的功能。

一致性：一致性是指与其它软件需求或者高层需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量巴

每项需求用简洁明了的用户性的语言表达出来。

致二义性：所以尽量巴每项需求用简洁明了的用户性的语言表达出来。 

健壮性：需求的说明中是否对可能出现的异常进行分析，并且对这些异常进行了容错出来。

必要性：可以理解为每项需求都是用来授权你编写文档的根源，要使每项需求都能回溯至某项客户的输入，如use case或者别的来源。

可测试性：每项需求都能通过设计测试用力或者其他的验证方法来进行测试。

可修改性：每项需求只应该在srs中出现一次，这样更改时易于保持一致。另外，使用目录表，索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟中性：应能在每项软件需求与他的根源和设计元素，源代码，测试用例之间建立起连接连，这种可跟踪要求每项需求以一种结构化的，粒度好的方式编写单独标明，而不是大段大段的叙述。

3.2需求建模

需求的建模包括巴需求转换成图形模型或者形式语言模型。需求的图形化分析模型包括数据流图，实体关系图，状态转换图，对话图，和类图，这些图形化模型一般都需要借助一定的工具，选择好的分析工具应该有助于获得需求质量特性，包括有效性一致性可靠性 可存活性可用性 正确性 可维护行 可测试性  可扩展性 可交互性  可重用性 可携带x带性等。

3.3审查

需求必须经过产品经理，软件经理 系统测试组，软件工程组，系统工程组，质量保障组，软件配置管理组，文档支持组等小组审查。

通过静态手工方法进行需求测试中最常用的手段是同行评审。

3.4执行

建议需求文档，分配需求文档 修改需求。

需求的管理需求在应用领域和软件工程方面经验比较丰富的人来担任。

建议使用配套的需求管理工具

除了建立相关的文档，还需要对所有软件工程组人员进行项目应用领域的培训。

3.5需求变更

变更审查：

变更对现有约定的影响；

提出需求变更引起的后续软件活动变更，评估风险，建立文档，全程跟踪。

3.6交付工件

程序陈述和需求说明书；

需求文档的分类：用户需求cr,技术需求tr,项目需求pr;

需求的状态：已批准已分配已实现。。

3.7 软件项目计划

为软件工程的运作和软件项目获得的管理提供合理的基础和可行的工作计划。

 3.8 设计阶段

包括功能的描述和设计

交付工件：设计说明书和功能说明书

3.9编码阶段

包括实施源代码，对目标代码进行单元测试

交付工件：软件，文档和产品信息

3.91  核实阶段

包括各种测试行为

      第二节 软件开发过程中常见的问题

需求说明差

不切合实际的时间表

测试不充分

不断的增加功能

交流问题

                  第三节  流程中的组及工作

3.31 流程中的组

系统分析人员

提出测试需求并跟中，确定测试的对象/方法和范围。

软件开发人员

提供开发计划sdp,参与制定和评审测试计划；

提供软件功能需求规格/需求分析/测试建议等文档，参与制定和评审测试方案和案例；

响应测试需求，跟踪解决缺陷。

配置管理人员

对测试文档测试代码及相关配置项进行配置管理。

质量保证人员

质量保证，参与相关评审，由于质量保证和测试关系比较密切，多谢一点

保障软件组织流程体系得到遵守，促使软件组织过程改进，指导项目实施流程，增加卡发货的透明度，评审项目活动，审核工作产品，协助工作产品问题解决，度量数据采集，分析，提供决策参考，进行缺陷预防，实现质量目标。

组织和协调产品开发组对标内部的软件技术和开发标准，流程的培训和教育。

部门的和特定的产品的软件开发过程量，以及软件产品质量的度量

指出产品开发过程中应该准寻的有关软件开发的标准和流程，并监督开发过程标准和流程的符合度。

软件质量管理，采用inspection review audit技术

通过软件开发流程及标准的推行以及对软件开发过程的不断总结和优化，使软件开发过程得到持久不断的优化和提高

                                         第四章  软件测试基础

4.1.1测试定义：IEEE中对测试的定义：使用人工或者自动手段来运行或者测试某段系统的过程。其目的在于检验他是否满足规定的需求或者是弄清语气结果与实际结果之间的差异。

4.1.2测试前提

软件可测试性：是一个计算机程序能够被测试的容易程序。

软件可测试性检查表：

可操作性--运行滴越好，被测试的效率越高。

可观察性--所看见的，就是所测试的。

可控制性--对软件的控制越好，测试越能够被自动执行与优化。

可分解性----通过控制测试范围，能够更好滴分解问题，执行更灵巧的在测试。

简单性--需要测试的内容越少测试的的速度越快。

稳定性--改变越少，对测试的破坏性越小。

易理解性--得到的信息越多，进行的测试越灵活。

4.1.3测试的目的

目的：发现程序中的错误，提高产品的可靠性。

4.1.4 测试规律

规律：木桶原理/八二原则。

4.1.4.1木桶原理

产品质量的关键因素是分析，设计和实现，测试应该是溶于其中的补充检查手段，其他管理，支持，甚至文化因素也会影响最终产品的质量，应该说，测试是提高产品质量的必要条件，也是提高产量质量的最直接的最快捷的手段，单绝不是根本手段，反过来说，如果将提高产品质量的却吗全部压在测试上，那将是一个恐怖而漫长的灾难。

                                             第二节测试生命周期

4.2.1测试生命周期

对测试人员进行业务培训

测试需求分析

编写测试计划

编写测试案例

测试执行

编写测试报告

4.2.2流程中的文档

4.2.2.1测试计划

测试计划和产品开发紧密相关，有多个部分组成，所以大型的商业软件都需要完整的测试计划，需要具体的每一步骤，并且每一部分都要符合规范要求。

测试计划包括内容：1，概述；2测试目标和发布标准，3计划将测试的领域，4测试方法描述5测试进度表6测试资源7配置范围和测试工具；

4.2.2.3测试案例

测试案例是指描述如何测试某一个领域的文档。这些文档负荷测试规范中的需求说明，根据测试规范的测试想定开发，根据测试反馈信息，对于没有考虑的心问题，不断增加测试案例。测试案例没有固定格式，只要清楚表名了测试步骤和需求验证的事实，使得任何一个测试人员都可以根据测试案例的描述完好成测试。

测试报告

测试管理人员以测试报告的形式向整个产品开发部门报告测试结果及发现的缺陷或者错误。撰写测试报告的目的为了让整个产品开发部门了解产品开发的进展情况，以使缺陷或者才错误能够迅速得到修复，测试报告的格式并无定式要求能够完整清楚的翻页当前的测试进展情况 要易懂不要使人迷惑或者产生误解

4.4.1测试分类

白盒测试   黑盒测试

4.4.2黑盒测试的测试用力设计方法：

等价类化分方法

边界值分析方法

错误推测方法

因果图方法

判定表驱动分析方法

正交实验设计方法

功能图分析方法

4.4.3系统测试类型

恢复测试；

完整>安全>性能测试；

强度测试

容量测试

结构测试

性能测试

配置测试

安装，卸载测试

用户界面测试

功能测试

比较测试

可移植性

接口间测试

数据库测试