软件测试实战_测试cnds

软件测试实战

按照测试流程，理论+实战

需求评审

需求评审的流程

产品经理组织会议

• 会前：预约时间，发会议通知。测试提前熟悉需求文档，提出问题
• 会中：产品经理宣讲需求，项目组成员提出问题，产品经理解释澄清
• 会后：产品经理更新需求文档，接下来的测试和开发就以新的需求文档作为输入

测试人员参与需求评审的目的

• 理解需求，为后续测试设计做准备
• 尽早介入，提前发现需求的问题

评审的内容

• 完整性审查

  应保证需求能充分覆盖软件需求的各种特征、重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时关注是否覆盖开发遗漏的，系统隐含的需求。

• 准确性审查

  应保证所描述的内容能够得到相关各方的理解一致，各项需求之间没有矛盾冲突，各项需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。

案例

功能：政府网站需要支持在线留言功能。

1. 需求明确性：
   • 请确保需求文档中明确定义了在线留言功能的范围，包括用户可以执行的操作和预期的结果。
   • 验证是否提供了与在线留言相关的详细描述，如用户应该如何提交留言、系统应该如何处理留言等。
2. 用户界面：
   • 确保需求文档中包括与在线留言相关的用户界面设计，包括表单字段、按钮和交互元素的布局和样式。
   • 验证界面是否易于导航和使用，是否与政府网站的整体风格一致。
3. 功能交互：
   • 检查需求中是否明确规定了用户如何提交留言，是否包括必填字段、上传附件等功能细节。
   • 确保需求描述了用户如何查看已发布的留言，以及如何进行回复和互动。
4. 权限和访问控制：
   • 询问是否有需求规定了留言的权限管理，包括哪些用户可以发布留言，是否需要登录等。
   • 确保只有授权用户能够执行特定操作，如修改或删除留言。
5. 安全性：
   • 确保需求中包括安全性考虑，如防止恶意留言、XSS攻击和数据保护。
   • 提出是否需要实施验证码、审核机制或其他安全措施来确保留言的合法性和安全性。
6. 通知和反馈：
   • 验证是否包括通知机制，以通知用户留言状态的变化，如审核通过或被删除。
   • 考虑用户反馈渠道，如用户能否报告问题或提供反馈。
7. 性能和容量：
   • 确保需求中包括性能和容量要求，如最大留言数量、响应时间和系统负载等方面的考虑。
   • 提出是否需要进行性能测试，以确保系统在高负载下仍能正常运行。
8. 多平台和多浏览器兼容性：
   • 询问是否有需求规定了在线留言功能在不同浏览器和设备上的兼容性。
   • 建议进行跨浏览器测试，以确保在各种浏览器上的一致性和稳定性。
9. 测试计划和验收标准：
   • 询问是否有计划进行相关测试，并提出您的测试建议。
   • 确保需求文档中包括验收标准，以确定何时在线留言功能被认为是成功实施的。
10. 用户培训和支持：
    • 询问是否有计划为用户提供培训或支持，以确保他们了解如何使用在线留言功能。
    • 提出是否需要编写用户文档或提供在线帮助。

测试计划

为什么写测试计划

领导能够根据测试计划做宏观调控，进行相应资源配置等；测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；便于其他人员了解测试人员的工作内容，进行有关配合工作

定义

描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面

作用

1. 指导作用（最大）
   • 测试目标
   • 测试内容
   • 测试方法
   • 时间周期
2. 改善测试任务与测试过程的关系
3. 提高测试的组织、规划和管理能力

测试计划原则

5W1H

1. why：为什么要进行这些测试
2. what：测试哪些方面，不同阶段的工作内容
3. where：相应文档，缺陷的存放位置，测试环境等
4. when：测试不同阶段的起止时间
5. who：项目有关人员组成，安排哪些测试人员进行测试
6. how：使用什么方法工具

测试开始/结束

1. 启动条件
   • 测试环境搭建完成
   • 系统的功能测试已经完成，并且功能测试报告通过了内部评审
   • 进行了冒烟测试，系统的性能测试是可测的
   • 不存在影响系统流程的缺陷
2. 结束条件
   • 需求覆盖率100%
   • 用例执行100%
   • 缺陷遗留率85%

测试风险与措施

H：high M：middle L：low

测试设计方法（面试重点）⭐️

黑盒测试的特点

• 从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误
• 实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。完全测试是不可能的

等价类划分法-化无限为有限

• 等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试输入数据
• 使用少数测试数据检验程序在一大类情况下的反映

1. 等价类

• 某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不能导致问题发生，那么集合中其它输入条件进行测试也是不可能发生错误

2. 有效等价类

• 有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合
• 在具体问题中，有效等价类可以是一个，也可以是多个

无效等价类

• 指对程序的规范是不合理的或无意义的输入数据所构成的集合
• 对于具体的问题，无效等价类至少应有一个，也可能有多个

等价类划分方法

1. 方法一：

   • 如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类

     例：程序的输入项 n 应满足“1-999”

     则可取有效等价类：1 <= n <= 999

     无效等价类：n < 1 or n > 999

2. 方法二：

   • 输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类
   • 如某标识符，条件规定“以字母开头”则“以字母开头”作为有效等价类。“以非字母开头”作为无效等价类

3. 方法三：

   • 如果已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类

     如：-10<n<10

     有效等价类 -10<n<10

     无效等价类： <=-10,>=10

     算法m/n

     有效等价类（ -10,0 ）（ 0，10 ）

     无效：小于-10，大于10,0

4. 方法四：

   • 在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类

     例：

     界面输入只提供单选框，是与否

等价类表

等价类划分的局限性

• 该方法孤立地考虑各个输入数据的测试功效，而没有考虑多个输入数据的组合效应，可能会遗漏了输入数据易于出错的组合情况，可以采用因果图设计法弥补上述不足
• 多个输入数据孤立的测试，导致测试用例数量非常庞大，不利于维护和执行，可以采用边界值法解决上述不足

边界值法

• 边界分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例，包含全部边界值的方法
• 采用边界值分析法来选择测试用例，可使被测程序能在边界值及其附近运行，有效的保证程序正常

边界点

• 边界点分为上点，内点和离点
• 上点：边界上的点
• 内点：区间内的点
• 离点：离边界值最近且与上点不属于同一等价类的点
• 对于小数，没有离点，不可取

边界值分析方法的原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值得个数，则用最大个数、最小个数、比最小少一，比最大多一作为测试输入数据。
• 如果程序规格说明书中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试数据。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据。

等价类和边界值比较

• 等价类法的测试数据是在各个等价类允许的范围中任意选取的
• 边界值分析法的测试数据必须在边界附近选取

错误推测法

• 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
• 错误推测法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们设计测试用例。

因果图法

1. 等价类划分法的局限性

   • 没有考虑输入情况的组合
   • 这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略
   • 采用因果图方法能帮助我们考虑输入条件的联系、相互组合等情况

2. 因果图法的使用

   • 分析需求规格说明中的描述中哪些是原因，哪些是结果
   • 原因是输入条件，结果是输出条件
   • 因果图最终生成判定表，它适合于程序输入条件的各种组合情况，如果有N个条件，每个条件有2个取值，那么将产生2的N次方条路径

3. 因果图法的适用范围

   • 如果在测试时考虑输入条件的各种组合，可使用一种适合于描述多种条件的组合，相应产生多个动作的形式来设计测试用例

4. 因果图法生产测试用例的基本步骤

   • 分析程序规范描述中哪些是原因，哪些是结果。原因常常是输入条件或是输入条件等价类，结果是输出条件
   • 分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”
   • 由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用特殊的符号标明约束条件。把因果图转换成判定表。把判定表的每一列写成一个测试用例

5. 判定表

   • 判定表是分析和表达多条件下执行不同操作的情况下的工具

   • 判定表由以下四部分组成：

     条件桩：列出问题的所有条件

     动作桩：列出问题规定可能采取的操作

     条件项：列出特定条件的取值

     动作项：列出在条件项目的各种取值情况下应该采取的动作

   • 判定表图示

     

   • 创建判定表的步骤

     确定规则的个数

     列出所有的条件桩和动作桩

     填入条件项和动作项

     合并相似规则

场景法

1. 场景法概述

   • 运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法
   • 模拟特定场景发生的事情，通过事件来触发某个动作的发生，观察时间的最终结果，从而来发现软件存在的问题

2. 场景法路径

   场景法一般包括基本流和备选流。从一个流程开始，图中经过用例的每条路径都可以用基本流和备选流来表示。直黑线表示基本流，是经过用例的最简单路径

   

3. 场景法设计步骤

   • 根据说明，描述出程序的基本流程及各项备选流
   • 根据基本流和各项备选流生成不同的场景
   • 对每一个场景生产相应的测试用例
   • 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

4. 场景法实战（用户登录操作流程）

   需求如下：

   • 用户执行程序，弹出登录对话框
   • 用户输入用户名
   • 用户输入密码
   • 确定登录，系统验证用户登录
   • 取消登录，退出系统、

5. 用户登录操作流程（用户名规范）

   用户输入用户名，格式要符合如下规范：

   • 2-16个字长，英文或数字
   • 用户名中不可出现空格符
   • 可以使用这些字符：“横线-”，“下划线_”, “点.”
   • 不可以使用“&，%，￥”等其它字符。

   用户名出错处理

   • 用户名为空：提示用户：“请输入用户名”
   • 用户名错误：提示用户：“用户名错误，请重新输入用户名”

6. 用户登录操作流程（密码规范）

   用户输入密码，格式要符合如下规范：

   • 密码为字符串
   • 字符串为0~9之间的阿拉伯数字组合，密码长度为6位

   密码出错处理：

   • 密码为空：提示用户：“请输入密码”
   • 密码错误：提示用户：“密码错误，请重新输入密码！”

7. 提取需求信息，得到流程图

   

测试用例

1. 测试用例的构成要素

   • 测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
   • 测试用例是软件测试团队的主要工作成果之一。
   • 测试用例的质量与写该用例的测试人员的水平关系极大。
   • 执行测试用例：当一个软件版本被测试时，测试人员会使用一整套的测试用例（或者筛选其中的一部分），将这些用例逐个在被测的软件上执行，并判断其结果是否和预期相符，并以此评价软件版本的质量。

2. 测试用例编号的命名规则

   项目名称_模块名称_xxx，作用：唯一标识每一条用例

3. 用例级别

   • 高：核心模块+正向用例
   • 中：核心模块+反向用例、一般模块+正向用例
   • 低：一般模块+反向用例、显示类测试

4. 用例注意事项

   • 用与简洁清晰，但不能过于简单
   • 用语无歧义，尽量少用过长的句子
   • 用例的各个基本要素要齐备，不能缺失
   • 用例的步骤应该足够详细，操作应该明确
   • 容易被其他测试工程师读懂，并顺利执行

5. 用例粒度

   • 粒度：指的是粗细程度。粒度大，说明用例包含的内容比较多，反之同理
   • 用例的粒度大，则总的用例数就少，用例看起来也简洁
   • 用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计

   掌握一个度

   粒度该大该小，如何把握，其实不难。一是看你这个用例写出来会不会测试好几个小时都没能测试完。二是看你这个用例会不会被另一个人执行的时候只执行了涵盖了一部分的测试点而遗漏了另一部分。

6. 测试点和测试用例

   可以一对一、多对一，保证每个测试点都有对应的用例

7. 好的用例

   • 整体完备性：用例的基本要素要齐全，覆盖度要高（需求覆盖100%）
   • 准确性：用例的标题要简洁明了、步骤尽量详尽，用例的可读性好
   • 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。

测试执行

1. 测试执行

   根据已有的测试用例，按照里面的步骤一步一步地执行，查看预期结果与实际结果是否一致

   测试执行的注意事项

   1. 搭建测试环境事项

      测试用例执行过程前，成功搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。

      如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

   2. 注意用例的前提条件和特殊说明

      有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。

      比如要测试某个软件的登陆功能，那么测试前必须创建用户，并为用户分配一定的权限等。如果前提条件和特殊说明没有注意，会导致测试用例的无法执行。

   3. 测试用例要全部执行

      因为编写测试用例时，它考虑了测试覆盖率的问题，每条测试用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。

      我们执行测试前要认为待测试软件的每条功能点都是未实现的，每个功能点我们都要测试一遍，才能保证待测试软件能正确满足用户需求。

   4. 不要忽视任何偶然现象

      我们在执行某条用例时，软件会出错，但是当再次执行时这个错误就不再重现。这种情况，一般大家就会认为是偶然现象，就会忽略过去。其实，这种错误才是隐藏最深的，最难发现的错误。

      遇到这种情况时，要仔细分析这种情况，不要忽视任何小的细节，多测试几次，尽可能准确的找出问题的原因。

   5. 加强测试过程的记录

      测试执行过程中，一定要加强测试过程记录。执行过的用例做好对应标记，发现了缺陷应及时提交确认。

      一般软件产品提供 了日志功能，比如有软件运行日志、用户操作日志。如果发现比较复杂难定位的问题，一定要在测试用例执行后记录相关的日志文件，作为测试过程记录，这样开发人员可以通过这 些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

   6. 详细记录预期与实际的不一致

      如果不一致，要从多个角度多测试几次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输入和实际的输出，以及对问题的描述写到测试报告中。

      因为在一个项目组中，项目的开发时间是有限的，如果我们测试时能把问题描述的详细一些，那么开发人员就会很容易的重现这个问题，也就能更快的解决问题，节省项目时间。

   7. 提交缺陷时与开发的关系处理

      测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。

2. 缺陷的定义

   • 软件未实现需求和规格要求的功能(如软件要完成+，-，*，/功能)
   • 软件出现了需求和规格指明不该出现的错误
   • 软件实现了需求和规格未提及的功能（软件只让你实现+，-，*，/ 功能，结果你实现了求余功能）
   • 软件未实现需求和规格未明确提及但应该实现的内容
   • 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。
   • 测试用例执行中发现的与预期结果不符的现象
   1. 缺陷的来源

   

   2. 缺陷的修复成本

   

   3. 并不是所有的缺陷都要修复

      有一些原因，使得有些缺陷我们不修复：

      • 没有足够的时间（评估影响可控）

      • 缺陷的级别过低

      • 修复的风险太大

   4. 缺陷的生命周期

      当一个缺陷被发现了之后：

      • 测试工程师填写《缺陷跟踪单》

      • 提交给开发人员定位问题

      • 开发人员定位错误后修复缺陷转给测试人员

      • 测试人员对该修复进行验证，确认是否正确修复，确认是否有引 发 新问题，是否影响了原有正常的功能

   5. ⭐️缺陷管理流程

   

   6. 缺陷相关计算

      缺陷密度=缺陷权值/代码行（KLOG）

      *缺陷权值DI计算：*致命问题权值为10，严重问题为3，一般问题为1，提示问题为0.1。

      这里的代码行（KLOG）是指每千行代码。

      缺陷修复率=累计关闭缺陷数/累计发现缺陷数*100%

      缺陷类型分布：按照软件产品质量模型的不同方面进行测试时，各自发现的缺陷分布的百分比。

   7. 缺陷状态

   缺陷状态	描述
   New	测试中新报告的软件缺陷，等待分派
   Open	已确认的缺陷，等待开发人员修改
   Fixed	已经被开放人员修改的缺陷，等待测试人员校验
   Rejected	不是缺陷或者不需要修复
   Reopen	没有修复，重新打回开发人员
   Closed	已经被测试人员确认得到正确修复，可以关闭

   8. 缺陷等级

   缺陷严重程度	描述
   致命	软件无法运行，或者软件的主要功能丧失，或者很大可能会造成严重的不良后果
   严重	软件的次要功能丧失，或者主要的功能在一些特定的情况下会出错，比如金额计算等
   一般	软件在某些特定情况下会出错，但是造成的后果影响不大
   轻微/提示	在某些情况下会出错，但是造成的后果影响很小

   9. 缺陷单案例

   待补充

3. ⭐️ 测试报告(面试常考)

   1. 什么是软件测试报告

      软件测试报告是测试人员在完成整个系统测试工作后必须要撰写的一份文档，这份文档反映了测试过程和测试结果，是对阶段性测试任务的总计

   2. 测试报告有什么用

      • 通过测试报告可以评估项目的当前状态和产品质量
      • 测试报告是确定产品是否准备好发布的最终文件

   3. 测试报告之人力投入

      投入项	测试人员	工作量（人天）
      测试用例的编写	XXX	1.5人天
      测试执行	XX、XXX	9.5人天（XX：5.5天、XXX：4天）
      合计	XX、XXX	9.5天/人

   4. 测试报告之用例覆盖度

      用例总数	通过用例数（OK）	未通过用例数（NG）	尚未测试（NT）	无测试条件、暂时不能测试（NC）	尚未开发（ND）	通过率（％）	备注
      ２６３	２５１	０	０	１	１１	１	新增加１０个用例