软件测试入门

2.1    软件测试与软件质量

2.1.1    什么是软件测试

       “软件测试”的经典定义四在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。

2.2    软件测试目的

     早期的软件定义支出软件测试的目的是寻找错误，并且尽最大的可能找出最多的错误。

• 测试是程序的执行过程，目的在于发现错误；
• 一个好的测试用例在于能发现至今未发现的错误；
• 一个成功的测试是发现了至今未发现的错误的测试。

     测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

2.3    软件测试原则

• 所有的软件测试都应追溯到用户需求。
• 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
• 完全测试是不可能的，测试需要终止。
• 测试无法显示软件潜在的缺陷。
• 充分注意测试中的群集现象。
• 程序员应避免检查自己的程序。
• 尽量避免测试的随意性。    

2.4    软件测试对象

     根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。

• 在软件编码结束后，对编写的每一个程序模块进行测试，成为“模块测试”或“单元测试”；
• 在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，成为“集成测试”；
• 在集成测试后，需要监测与正式软件是否满足软件需求说明书中规定的要求，这就成为“确认测试”；
• 将整个程序模块即成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，成为“系统测试”。

2.5    软件测试分类

2.5.1    按照开发阶段划分

• 单元测试
• 集成测试
• 系统测试
• 确认测试
• 验收测试

2.5.2    按照测试实施组织划分

• 开发方测试（验证测试或α测试）
• 用户测试（β测试）
• 第三方测试

2.5.3    按照测试技术划分

• 白盒测试

      通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。

• 黑盒测试

     通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，他只是建成样序是否按照需求规格说明书的规定正常实现。

• 灰盒测试

     介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不想白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

2.6    软件测试过程模型

2.6.1    V模型

2.6.2    W模型

2.6.3    H模型

      

2.6.4    X模型

2.6.5    前置测试模型

2.7    软件生命周期测试策略

2.7.1    软件开发与软件测试

    

2.7.2    软件测试策略

       测试过程按4个步骤进行，即单元测试、集成测试、确认测试、系统测试。

（1）单元测试

      通常单元测试是在编码阶段进行的。

      模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

      驱动模块（driver）——相当于所测模块的主程序。它接受测试数据，把这些数据传送给所测模块，最后再输出实际结果。

      桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

      

      模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。

（2）集成测试

      集成测试也叫作组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

（3）确认测试

      确认测试的任务是验证软件的功能

（4）系统测试

       系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。

（5）验收测试

       验收测试是以用户为主的测试。

2.8    软件失效分类与管理

2.8.1    软件失效分类

• 软件错误（software error）
• 软件缺陷（software defect）
• 软件故障（software fault）
• 软件失效（software failure）

     ①软件错误：在可以预见的时期内，软件仍将有人来开发。在整个软件生存期的各个阶段，都贯穿着人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。

     ②软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现的软件故障，这时称软件缺陷被激活。

     ③软件故障：软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。

     ④软件失效：软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

2.8.2    缺陷与错误分布

2.8.3    缺陷与错误严重性和优先级

       给软件缺陷与错误划分严重性和优先级的通用是：

       ①表示软件缺陷所造成的危害的恶劣程度；

       ②优先级表示修复缺陷的重要程度与次序。

• 严重级

        ①严重：系统崩溃、数据丢失、数据毁坏。

        ②较严重：操作性错误、错误结果、遗漏功能。

        ③一般：小问题、错别字、UI布局、罕见故障。

        ④建议：不影响使用的瑕疵或更好的实现。

•  优先级

        ①最高优先级：立即修复，停止进一步测试。

        ②次高优先级：在产品发布之前必须修复。

        ③中等优先级：如果时间允许应该修复。

        ④最低等优先级：可能会修复，但是也能发布。

2.8.4    软件错误跟踪管理

     1.错误跟踪管理

         （1）Bug记录信息

           主要包括以下几项内容。

• 测试软件名称
• 测试版本号
• 测试人名称
• 测试事件
• 测试软件和硬件配置环境
• 发现软件错误的类型
• 错误的严重等级
• 详细步骤
• 必要的附图
• 测试注释

          （2）Bug处理信息

• 处理者姓名
• 处理时间
• 处理步骤
• 错误记录的当前状态

     2.软件错误的状态

• 新信息（new）：测试中新报告的软件Bug
• 打开（Open）：被确认并分配给相关
• 修正（Fixed）：开发人员已完成修正，等待测试人员验证。
• 拒绝（Declined）：拒绝修改Bug
• 延期（Deferred）：不在当前版本修复的错误，下一版修复
• 关闭（Closed）：Bug已被修复

     3.错误管理流程

• 测试人员提交新的错误入库，错误状态为“New”
• 高级测试人员验证错误

       ①如果确认是错误，分配给相应的开发人员，设置状态为“Open”

       ②如果不是错误，则拒绝，设置为“Declined”状态

•  开发人员查询状态为“Open”的错误，做如下处理。

       ①如果不是错误，则置状态为“Declined”。

       ②如果是错误，则修复并置状态为“Fixed”。

       ③如果不能解决的错误，要留下文字说明并保持错误为“Open”状态。

       ④对于不能解决和延期解决的错误，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

• 测试人员查询状态为“Fixed”的错误，验证错误是否已解决，做如下处理。

       ①如问题解决了，置错误的状态为“Closed”。

       ②如问题没有解决，则置状态为“Reopen”。

      4.错误流程管理原则

       错误流程管理遵照以下原则。

       ①为了保证错误处理的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

       ②每次对错误的处理都要保留处理信息，包括处理姓名、时间、处理方法、处理意见、Bug状态。

       ③拒绝或延期处理错误不能由程序员单方面决定，应该有项目经理、测试经理、设计经理共同决定。

       ④错误修复后必须由报告错误的测试人员验证，确认已经修复后，才能关闭错误。

• 加强测试人员与程序员之间的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

2.9    白盒测试

       白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是够按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

       常用软件测试方法有两大类：静态测试方法和动态测试方法。

2.10   黑盒测试

       黑盒测试也称功能测试，他是通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接受输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

       具体的黑盒测试用例设计方法包括等价类划分、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

       等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

       边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

       错误推测设计方法就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

       因果图方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

       正交试验设计法，就是使用已经造好了的正交表格来安排试验并经行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。