软件测试技术（二）

因果图/判定表法的测试步骤

被测系统：一卡通充值模拟系统

  1. 步骤二：分析需求，找出所有的输入条件（因）

    1. 投币50元
    2. 投币100元
    3. 充值50元
    4. 充值100元

  2. 步骤2：找出输出结果（果）

    1. 充值成功并退卡
    2. 找零
    3. 错误提示并退卡

  3. 步骤三：分析输入条件中有哪些组合和限制关系

    组合：1,2,3,4,1-3,2-3,1-4,2-4
    限制：1-2,3-4

  4. 步骤4：确定每个输入组合对应的输出结果，画因果图，填判定表。（在实际应用中因果图有时可以省略不画）

    • 充值成功并退卡
    • 找零
    • 错误提示并退卡

    选择：T (True 真)或1
    不选：F (False 假)或0

    总结：

    1. 因果图只是一种辅助分析的工具，如果通过判定表就可以分析清楚组合及对应结果并且编写用例，那么因果图是可以省略不画的。
    2. 判定表的缺点:在判定表中限制关系在表中不容易表示。

    解决办法：在判定表中添加备注信息，通过文字的方式说明限制关系。

  5. 步骤5：根据判定表，编写测试用例。

每1列表示1个组合，编写1条测试用例。

判定表

判定表的测试用例

正交排列法

说明：正交表是数学统计学专业的科研成果，由于该表可以从大量数据中抽取最优最少的数据，能够契合测试思想，而被测试专业借鉴应用。

注意：测试人员只需要研究如何挑选合适的正交表，以及如何应用正交表就可以了，不需要研究正交表是怎么填写的，也不需要背正交表。

  1. 应用场合

    界面中有多个控件，控件中有不同数据，不同控件之间存在不同组合，但是组合数量较多，不需要测试所有组合，利用正交排列法可以挑选最优、最少的组合进行测试。（提高效率）

    问题：判定表法和正交排列法的异同?

    1. 都用于测试控件之间的组合情况。
    2. 正交排列法适合测试控件之间组合数量大的情况。（一般>20种）
    3. 判定表法适合测试组合数量较少的情况（一般少于20种）
    4. 判定表法要分析控件之间的组合和限制关系，但是正交排列法只需考虑控件之间的组合关系即可。

  2. 解析正交表

    表达式：\(L_n(m^k)\)

    \(L\)：line 行

    \(n\) ：表示行数 代表当前正交表有多少行

    \(m\) ：表示在正交表中，每列取值的最大值。

    ​ \(m\)值确定---在测试时由控件的取值个数决定

    \(k\) : 表示在正交表中有几列---在测试时k值的确定由几个控件参与组合决定

    正交表23

    然后在正交表中找到对应一张表进行测试

  3. 正交排列法的测试步骤:

    字符属性设置

    1. 步骤1：分析需求，将参与组合的控件和控件的组成取值，填入Excel表格
      控件组合

    2. 步骤2：挑选合适的正交表要点：

      1. 挑选合适的正交表就是确定m值和k值的过程。

        1. m值：由每个控件的取值个数决定。

          m=3

        2. k值:由参与组合的控件个数决定。

          k=4

        最终要找:3的4次的正交表

        正交表34

      2. 步骤3：应用正交表于测试（映射）

        控件和控件取值与正交表进行对应的替换。

        1. 将控件名称与正交表的列标题（因子部分）进行替换。

        2. 控件的取值与对应列的数值（状态部分123）进行替换。

          正交映射表

      3. 步骤4：编写测试用例

      每一行是一个组合情况，编写一条用例。

      正交映射表测试用例

    3. 总结正交表

      1. 正交表理论上测试的是最优、最少的组合，测试效率极高，但是毕竟没有测试所有组合，有可能有遗漏缺陷的风险，所以测试时间允许应该进行合理的补充测试。（正交表已经是最少的组合，不要再删组合）
      2. 正交表的局限
        1. 正交表数量有限。（9个）
        2. 每个控件的取值要求个数一样，但是实际应用中控件取值不一定一样。
      3. 正交表的特征（了解）--平均
        1. 每一列中不同数值的出现次数均等。
        2. 任意两列，每一行会形成1个有序数对，有序数对出现的次数均等

    4. 正交排列法的强化应用

      如果没有合适的正交表如何处理?

      1. k值（控件的个数）不合适。

        解决：挑选k值最接近的，并且大一点的。用不到的列删除即可。

      2. m（代表每个控件的取值）值不同。

      3. 解决方法：

        1. 少数服从多数

          分析：m值=3（3个取值个数最多），k=4 所以：挑选正交表是3的4次幂

        2. 最大值（推荐）

          分析：k值=4，m=4（最大）

          应该挑选4的4次幂，但是没有，最终挑选4的5次幂，用不到的1列，删除处理。

    5. 总结：

      1、如果有多余的列，可以删除

      2、先替换能替换的数据，然后再考虑处理不能替换的部分。

      3、如果有多出的测试机会（空白处），应尽量均匀的分配给该列的不同取值。

      4、最后检查是否有完全相同的两行，如果有适当处理（删或改（建议））

      5、最优先选择正合适的正交表，如果没有正合适的再去想别的处理办法。

测试大纲法

  1. 应用场合

    在程序要有多个窗口，窗口中有若干操作，不同窗口操作之间存在联系，为了理清窗口之间的关系，使用测试大纲法。常用应用有：

    1. 测试窗口之间的跳转关系
    2. 测试软件的安装、删除程序
    3. 理清需求间的层级关系

  2. 测试步骤

    1. 步骤1:分析需求，列大纲

      列大纲：将窗口和窗口中的操作按照层级关系列出。

      说明：可以用不同方式列大纲，不要拘泥于形式。（文字、画图等都ok）

    2. 步骤2：分析大纲，理清窗口间关系，编写用例。

      说明：

      1. 在测试窗口跳转关系时，如果某个跳转路线中所功能点,在之前都已经测过（没有未测功能点），那么该路线可以省略。如果时间充足，最好还是测。

      2. 在测试下拉列表或列表框控件时，至少要测试3项：第一项（最小值） ，最后一项（最大值），中间某项（有效等价类）

        问题：有时会测试超过3项。

        例如: 测试月份。要考虑:1月（最小min），12月（最大max），2月（闰月），小月（30天），大月（31天），如果有为空应单独测。

      3. 在测试过程中，如果测试用例的测试过程基本一致，那么可以考虑复用（重用--重复使用）该用例。（节省测试时间）

场景法

  1. 应用场合

    1. 在软件中当测试软件的业务过程和业务逻辑时，常用场景法。
    2. 场景法是基于软件业务的测试方法。
    3. 测试人员将自己看成是最终用户，模拟用户使用该软件时的各种情景：

    模拟两种情景：

    1. 模拟正确的业务过程--验证功能是否能正确实现
    2. 模拟错误的业务过程--验证程序的异常处理能力

    扩展： 场景法的使用思路

    在接到一个测试任务时，通常会先使用场景法对主要业务过程和逻辑进行测试，当主要功能实现没有问题后，再对细节进行测试（等价类、边界值、判定表等）。（先整体,后细节）

  2. 场景法的两个要素

    1. 业务层面（更重要）

      对于测试人员的相关软件业务熟悉程度有要求，最好能成为该行业中业务方面的“专家”；

    2. 技术层面

      1. 基本流，也叫有效流或正确流，模拟正确的业务操作过程的情景，叫基本流。
      2. 备选流，也叫无效流或错误流，模拟错误的业务操作过程，叫备选流。

  3. 场景法的测试过程

    案例：ATM取款

    1. 步骤1：熟悉需求，整理业务过程，列出基本流和备选流。

      基本流：(成功取款的流程)

      插卡-->验证卡通过-->输入正确密码-->选“取款”功能-->选择正确的取款金额-->点击“确定”，给出提示，出钞，更新账户和ATM余额

      备选流：取款失败的各个场景

      1. 验证卡无效
      2. 输入密码错误（3次以下 ：提示输入密码错误、请重新出入密码）
      3. 输入密码错误（第三次 ：吞卡）
      4. 余额不足
      5. 取款金额超出当次的限额
      6. 超出当日取款上线
      7. ATM余额不足

    2. 步骤2：生成场景，填写《场景表》

      ATM场景法

    3. 步骤3：根据场景，设计测试用例。

      说明：场景和用例不一定是1:1的比例。有可能1个场景需要多条用例也有可能1条用例能测试多个场景

      ATM场景法测试用例

软件测试基础理论

  1. 软件的开发阶段划分

    1. 需求分析阶段
      由需求分析人员完成
      《需求规格说明书》
    2. 概要设计阶段
    3. 详细设计阶段
      由系统架构师(分析师）完成
      《概要设计说明书》、《详细设计说明书》
    4. 编码阶段
      由开发人员完成
      程序

    问题：哪个阶段产生的bug最多？哪个阶段最少？
    需求分析阶段引入的bug最多，其次是设计阶段，编码阶段引入的bug最少。
    由此得出结论：测试时文档和程序都必须要测；测试工作应该要尽早介入，并且要贯穿整个开发周期始终（尽早测试原则，不断测试原则）

  2. 软件测试的阶段划分

    说明：这四个阶段中没有涵盖文档测试部分的内容。

    1. 单元测试

      1. 单元测试是最小的测试单位，通常1个方法（函数）、窗口、功能模块、类等都可以是一个测试单元。
      2. 单元测试的主要依据是详细设计文档。
      3. 单元测试阶段主要采用白盒测试方法。（也有可能要辅助以黑盒测试的方法）
      4. 在企业的实际应用中，单元测试通常由程序员完成，这样可以节省成本，但是测试质量得不到保证，所以企业通常会采用交换测试，两轮测试（程序员1轮（白盒），测试人员第2轮（黑盒））的方式来加强单元测试的质量。
      5. 桩模块和驱动模块
        在单元测试中，有可能要求测试者编写“桩模块”和“驱动模块”
        驱动模块：模拟被测模块的上一级模块（调用被测模块）
        桩模块：模拟被测模块的下一级模块（被“被测模块”调用）
        驱动模块-->被测模块-->桩模块

    2. 集成测试（组装测试）

      1. 集成测试也叫组装测试，是在单元测试的基础上，将模块逐步组装的测试过程。

      2. 在集成测试阶段，功能模块要逐步组装形成多个临时版本。

      3. 集成测试阶段参考概要设计文档

      4. 集成测试阶段主要采用黑盒测试的测试方法，重点、难点、核心模块会辅助以白盒测试方法。

      5. 冒烟测试

        当测试方拿到一个新的软件版本时，一般会先做“冒烟测试”（版本验证测试）：使用较少的测试人员（1-3人，经验丰富），花费较少的时间（0.5-3天），对软件版本中的核心功能进行测试（一般不写用例），如果核心功能没有问题，全组再展开全面测试；如果核心功能问题较多，版本不稳定，就将该版本软件返回开发组。

      6. 集成测试阶段，当测试组拿到一个新的软件版本后，工作的思路：
        首先：

        冒烟测试--确认测试组是否接受测试该版本。
        接下来：
        返测--对于已修复的缺陷，进行测试--确认缺陷是否修复成功！
        回归测试--对于上一个版本测过的功能，再测试一遍。
        最后：

        该版本中新功能的测试。（但是有的版本是专门用来修复bug的，没有新功能）
        说明：在实际工作中，不一定工作思路中的内容都要做，要具体情况，具体分析。

    3. 系统测试

      1. 在功能全部完成后，对于集成了硬件和软件的完整系统进行的模拟真实环境的全面测试。

      2. 系统测试阶段的测试重点：（1）整个系统的正确性（2）系统的兼容性

      3. 系统测试阶段参考需求文档

      4. 系统测试阶段采用黑盒测试方法

      5. 确认测试：在系统测试之前，一般会安排一次“确认测试”，主要确认：

        1. 软件是否可以进入全部的系统测试中。
        2. 软件的相关文档是否准备齐全（尤其是交付给用户的和参与认证的）

        说明：确认测试一般时间较短，参与人员较少，所以一般不把确认测试与单元、集成、系统、验收测试所并列。

    4. 验收测试
      UAT:User Acceptance Testing 用户接受度测试

      1. 验收测试理论上是由用户参与的软件检查过程。

      2. 验收测试阶段分成两个小阶段：

        1. alpha测试

          在软件公司的指定环境中（在软件公司的指定环境中，会是软件研发方对bug有更强的控制力），由用户对软件进行检查。（一般经常由软件公司替代用户进行验收，也有可能请第三方公司验收。）

        2. beta测试
          在用户的实际环境中（此时软件公司对缺陷的控制力明显减弱），由最终用户对软件进行检查的过程。
          例如：公共类软件的beta测试
          公共类软件（输入法、QQ、os等）将软件免费发放给最终用户，收集用户在使用软件中发现的问题（bug）。

  3. 软件测试模型

    1. 软件测试模型可以表明软件的开发阶段和测试阶段（级别）的对应关系。测试模型有：v模型，w模型，H模型等

    2. v模型（常见面试题）

      1. 会画--v模型

        v模型

      2. v模型的优点和缺点
        优点：

        1. v模型中开发阶段和测试阶段（级别）划分清楚，并且开发阶段和测试阶段（级别）的对应关系也清晰明确。
        2. v模型中既包含了单元测试（专业级、代码级），又包含了验收测试（用户级）。

        缺点：
        v模型中缺少软件开发前期需求和设计阶段的测试内容，不能体现出文档和程序都需要测试的内容，不符合尽早测试原则和不断测试原则，让人产生测试只是开发完成后的收尾工作的错觉。（测试和开发应该是同步的工作过程）

    3. w模型

      1. w模型可以被看成是双v模型，第一个v是开发活动，第二个v是测试活动

      2. w模型的特点：w模型包含了需求和设计阶段的测试内容，体现了文档测试，并且符合尽早测试和不断测试原则。体现出开发和测试是同步进行的。

        w模型

  4. 软件测试分类

    1. 按测试技术分类
      1. 黑盒测试：又称为功能测试，是不考虑程序内部结构特征，只考虑输入数据和输出的情况下进行的功能的测试。
      2. 白盒测试：又称为结构测试，只考虑程序内部结构，而不考虑程序功能的测试。
      3. 灰盒测试：是结合和黑盒测试和白盒测试的要素，对软件进行测试。一般先做黑盒测试，发现缺陷，再通过白盒测试对缺陷进行进一步的调查。（在集成测试阶段中经常采用灰盒测试）
        扩展：白盒测试说明
        1. 白盒测试测试质量较高，白盒测试成本较高，白盒测试效率较低。
        2. 白盒测试一般是对风险较大，难度较大的核心模块进行补充测试。
        3. 白盒测试人员要懂代码，白盒测试也需要编写测试用例。
    2. 按是否需要运行代码进行分类
      1. 动态测试：需要使程序运行起来，进行的测试
        例如：通常功能测试都是动态测试。
      2. 静态测试：不需要运行程序就可以进行的测试
        例如：
        文档测试
        部分界面测试
        （静态）代码测试：检查代码是否符合相应的标准和规范。
        白盒测试有可能是静态测试，也有可能是动态测试。
        面试问题：白盒测试和（静态）代码测试的区别？
        白盒测试主要关注的是代码的逻辑实现，测试者必须要懂代码，白盒测试要求写用例。代码测试主要关注代码的规范和标准，测试者不需要懂代码，不需要编写用例，只需要对照代码检查单进行代码检查即可。
    3. 按软件的特性分类：
      1. 功能测试
        1. 任何软件必须要先做功能测试，保证其功能正确。
        2. 功能测试既可以手工测试，也可以自动化测试（工具：QTP,selenium）
      2. 性能测试
        1. 分布式软件（C/S,B/S）需要进行性能测试。
        2. 性能测试必须要借助工具，通过自动化的方式实现。（loadRunner，Jmeter）
    4. 其它（名词）
      1. 返测：对程序员修改的缺陷进行测试，验证缺陷是否被修复。
      2. 回归测试：对上个版本中的所有功能重新测试一遍；验证在新版本中，程序原有的功能是否依然正常；回归测试中存在大量的重复性工作（重复执行用例），所以可以使用自动化测试来提高回归测试的效率。
      3. 随机测试（猴子测试）：
        在测试用例执行完成后，对软件进行的随意测试的过程。随机测试只是时间允许时，对正常测试用例之外的补充。
      4. 兼容测试：
        兼容测试指所设计的软件与硬件、软件之间的兼容性测试，兼容性测试主要分成3大类：
        1. 与硬件兼容
          与整机兼容
          与外设兼容
        2. 与软件兼容
          与操作系统兼容
          与其他应用软件兼容
          与浏览器兼容
          与数据库兼容
        3. 数据兼容
          指软件的不同版本之间的数据兼容。
      5. 功能测试方法的测试策略
        等价类划分+边界值
        因果图、判定表、正交排列法
        测试大纲法
        场景法
        回答的思路：将每个（每组）测试方法的应用场合和特征回答清楚。
        最后强调：在测试时一个功能可能需要2-4种测试方法综合应用进行测试。
      6. 软件项目的测试流程（步骤）?
        1. 需求分析
        2. 制定测试计划
        3. 测试的设计
        4. 执行测试，记录测试结果（对测试结果的分析和记录）
        5. 记录缺陷，跟踪和管理缺陷
        6. 测试总结（报告）

作业：
1、简介软件测试模型，什么是v模型，它的缺点是什么？
2、软件测试的阶段如何划分？
3、系统测试阶段的测试重点是什么？
4、什么是回归测试？
5、什么是黑盒测试？白盒测试？

禅道项目管理软件

  1. 介绍

    禅道是青岛易软天创网络科技有限公司研发,是一款B/S结构,国产开源免费,可跨平台(操作系统),安装简单的测试管理工具,主要功能模块有:组织视图、后台视图、产品视图、项目视图、测试视图等。

  2. 禅道的安装

    ZenTaoPMS.8.2.5_windows

    ZenTao----禅道
PMS---项目管理系统
8.2.5---版本
Windows---系统
    1. 去官网下载禅道安装包 zentaopms
    2. 将禅道安装文件拷贝(复制)到D盘根目录下(D:\ C:\ E:)
    3. 选择文件,右键单击,选择“以管理员身份运行”
    4. 在xampp文件中,选择“启动禅道”,右键单击,选择“以管理员身份运行”
    5. 在“禅道集成运行环境”中,单击“启动禅道”按钮

    说明:如果出现“禅道正在运行,点击“访问”按钮来使用

  3. 禅道的访问

    1. 访问本机电脑(学习)

      步骤:

      1. 在“禅道集成运行环境”中,单击“访问禅道”按钮

      2. 在“欢迎页面”中,单击“开源版”按钮

      3. 在“用户登录”页面中,输入用户名和密码单击“登录”按钮

        说明:系统初始用户名和密码是 admin/123456

    2. 访问服务器(工作)

      准备工作:

      1. 本机IP地址

        开始>搜索程序和文件>cmd>Enter>DOS界面>输入: ipconfig 172.166.0.212

      2. Apache端口号

        在“禅道集成运行环境”中,查看apachezt端口:80

      3. 访问格式

        格式1:http://本机IP地址/zentao ----80

        格式2:http://本机IP地址:端口号/zentao

posted @ 2020-03-22 15:28  jwxdzxj  阅读(274)  评论(0)  编辑  收藏  举报