05_功能测试

目录

需求分析

在软件项目的开发过程中，软件需求规格说明书的编写是必不可少的，他能够使用户和软件开发者双方对该软件的初始规定有一个共同的理解，这是整个项目开发工作的基础

提取测试点是通过对需求的细化和分解，形成可测试的内容。测试内容应全部覆盖系统的业务流程，以及功能和非功能方面的需求。
非功能的需求，包括：用户体验，性能等其他需求，本课程先探讨功能性的需求。

  • 业务流程图
    业务流程图

  • 注册单个功能
    注册单个功能

在我们实际工作中，有些项目有需求文档，有些项目没有需求文档。那不管有没有需求文档，我们进行需求分析，目的都是一样的，都是要提取出我们的测试点。

通常我们做需求分析，会先熟悉整个产品/需求本身，按层次/模块整理出系统所有的单个功能，包括需要输入什么参数、每个参数有什么约束条件，以及各个功能之间数据流向，得到系统测试项；

说明：系统分解的层次是由系统的复杂程度决定的。复杂的需要三层到四层，比较简单可能只有一层。系统分解的最终目的是将整个系统划分为一个个独立的功能点。分解的过程中要注意粒度的均匀性和逻辑的合理性，相关的功能要划分到一个父节点下。将这个分解结果以树的形式展现出来就是RTM(需求跟踪矩阵)了。

如下给到一个实例，给一个新增用户的功能，提取测试点

  • 需求如下

  • 需求分析的结果

需求评审

在需求分析之后，会进行一个需求评审的会议，整个项目的成员会聚集在一起讨论一下各自对需求的理解，看看对需求的理解是否出现了不一致的地方，是否出现了遗漏的地方。

评审的内容：

  1. 完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
  2. 准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。

测试计划

在评审完成之后，会完成一个测试计划的编写，安排一下测试的进度与内容。

为什么要编写测试计划？

软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱地实施过程。为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划。

什么时间开始编写测试计划？

需求分析后编写测试计划，在整个测试工作过程中，不断修改

由谁来编写测试计划？

具有丰富经验的项目测试负责人

测试计划的内容

测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。

  • 测试项目的背景
    对测试对象及其目标进行简要说明，包括的信息有：主要的功能和性能，测试对象的架构和项目的作用。通常，项目的背景可以从需求文档中获取。

  • 测试范围
    简要地列出本次测试的主要功能模块。

  • 测试方式/策略:

    • 功能测试
    • 界面测试(UI测试)
    • 安全测试
    • 安装测试
    • 兼容性测试
    • 负载测试
    • 压力测试

  • 测试环境
    1、从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境和生产环境。

开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。
测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
生产环境：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。

2、“环境”，指的是被测试软件所运行的软件环境和硬件环境。

3、测试环境是测试人员为进行软件测试而搭建的环境，根据不同的测试阶段，测试环境可以分为冒烟测试环境，SIT测试环境，UAT测试环境等；根据不同的测试类型，测试环境可以分为功能测试环境，自动化测试环境，性能测试环境。

项目的mysql或者oracle用的什么版本？修改oracle的配置文件名叫什么？
参考答案：
mysql版本：5.7
oracle版本：11g
修改oracle的配置文件名叫:tnsnames.ora

2、linux用的是哪家的？具体什么版本？
Linux是：CentOS
版本是：6.8

3、linux系统用的cpu什么型号？内存多大的？
型号：英特尔 酷睿 i7
核数：6核
内存：32G
网络带宽：100M

  • 开始和结束条件

    • 启动条件：
      软件测试是在项目启动、需求分析开始时随之启动

    • 结束条件(项目上线的条件)：
      需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。

备注：每个公司流程不一样，制定的质量标准也是不一样的，不过大同小异。我以前工作过的项目组，标准是这样的：测试用例对需求的覆盖率达到100%；原则上，用例执行率要达到100%，但是如果时间紧，就执行优先级高的，低级别的用例就在下个版本执行；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是30%以下。

  • 进度安排
    进度安排，是指具体一个任务，要花多长时间完成，由谁负责。

  • 测试组织
    指在项目组中有哪些测试人员，担任什么角色，职责是什么。(如，测试角色有：测试经理，测试组长，其他测试人员，并列出他们的工作职责)

  • 风险

风险描述 规避措施 相关人 优先级
测试人力不足导致测试进度滞后 开发人员兼职测试 项目经理 高
测试人员经验不足导致测试结果分析不全面 多组织培训、多进行技术、经验交流 测试总监、TSE 中
需求变更 项目整体调整，项目组全员加班 项目组全员 高

  1. 项目中的人员比例情况是怎样的呢？（比如开发人员与测试人员）
    大概就是3:1 或者4:1这个比例

  2. 不同类型及规模的项目大概会有多少测试人员呢？
    一个开发小组人数在5到10人之间最为合适，如果项目规模很大，可以采取层级式结构，配置若干个这样的开发小组。

测试用例

测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
测试用例是软件测试团队的主要工作成果之一。
对测试用例的定义，业界没有一个统一的说法，个人认为，测试用例，就是用户对一个系统的使用场景的描述。

测试用例的主要构成要素

用例编号 用例名称 级别 预置条件 测试步骤 期望结果
QQ_登陆_001 输入正确的用户名和密码，成功登陆 高 1、注册一个QQ号 1.在登陆窗口，输入正确的QQ号；<br>2.输入QQ密码；<br>3.点击“登录”。 2、密码以加密方式显示，如：**** <br>3.登录成功，进入程序菜单列表
QQ_登陆_002 用户名为空，登陆失败 中 1、注册一个QQ号 1.进入登陆窗口；<br>2、输入QQ密码，QQ号码为空；<br>3.点击“登录” 3.登录失败，提示“请您输入账号后再登陆”

  • 用例编号
    用例编号(ID)，顾名思义，就是为用例导入用例管理系统(如：禅道)，或者与bug进行关联时，方便应用。用例编号通常为 项目简称+模块简称+顺序编号

  • 用例标题
    就像人的名字一样，给你书写的用例起一个名称。用例标题的书写，没有固定格式，原则是，让别人看到标题，就能联想到这个用例做了什么事情。用例名称尽量不要重复。通常用例标题包括 做什么操作，期望结果是什么

  • 用例级别
    测试用例级别的划分，一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定，比如，注册功能，对于一个系统来说，用户一辈子可能只注册一次，但是，直接影响到用户对系统的使用。
    根据公司不同，通常测试用例级别包含：
    1级(高)，影响很大，阻碍性的、流程性的用例。例如登陆功能，百度一下
    2级(高)，大的功能点，以及会阻碍少部分用例的执行。例如新增按钮，如不能通过，很多功能都不可测试
    3级(中)，小的功能点，例如刷新，刷新功能等
    4级(低)，小的UI的问题，位置，大小，验证，建议等等
    Ps：有些公司是，数字越高等级越高，有些则反过来。

  • 预置条件
    完成一件事，需要具备什么条件。

  • 用例的测试步骤
    测试步骤，为了验证某个功能，我们需要怎样的操作才能看到这个功能。

  • 预期结果
    测试用例期望结果，用例执行后要达到什么结果。

测试用例的颗粒度

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

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

用例评审

由于测试人员很可能对需求理解有误，场景考虑不全等原因，导致测试用例无法全面覆盖用户需求，场景缺失等，所以，测试用例编写完成后，都要经过严格的评审才能进行执行。
软件测试用例评审人员，一般会有哪些人呢？由于不同项目的实际情况不一样，参与评审的人员也会有所变动，但是，正常来说，都会有 测试人员，开发，还有产品经理(BA) 在场。

写好测试用例的关键 /写好用例要关注的维度

  1. 覆盖用户的需求；
  2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
  3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
  4. 用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
  5. 做好用例评审，及时更新测试用例。

怎样保证覆盖用户需求？

项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

执行结果

当用例还尚未被执行时，是No Test未执行状态
当执行结果与预期结果相符时，是Pass通过状态
当执行结果与预期结果不符时，是Fail失败状态
当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。

用例的整合

测试用例并不可能一开始就写得很完美，可能也有写错的，可能也有遗漏的测试点，因此，做好测试用例评审很关键。
随着软件的版本不断更新，软件本身的需求和规格以及设计都可能在不断地变更。
随着测试的不断开展，测试人员对产品的理解逐渐加深。
基于上诉，就使得我们完全有理由在测试用例执行的过程中，同时不断地优化我们的测试用例，使得用例的质量越来越高。

测试用例的设计方法

在编写测试用例时，掌握各种测试方法的使用场景，并能灵活使用。

等价类

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

关于等价类的划分，我们可以分为以下两个等价类

  • 有效等价类
    是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
  • 无效等价类
    与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时,要同时考虑这两种等价类。因为,软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。

划分等价类的方法

  1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。

例如：规定了用户名的长度为6-20个字符
那么可以确定一个有效等价类和两个无效等价类

  1. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
    例如：“用户名的第一字符必须是字母”，那么，所有以字母开头的集合构成有效等价类；以非字母开头的集合构成无效等价类。

  2. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
    布尔量的取值：真 或 假（True or False）

  3. 规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
    例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

  4. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
    例如，某注册框的用户名规定为6位小写字母。

设计测试用例

在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件

然后从划分出的等价类中按以下原则设计测试用例:

  1. 设计有效场景的用例，每个用例应尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
  2. 设计异常场景的用例，每个用例应仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
用例标题
性别输入“男”邮箱为空，其余信息正确填写，添加员工成功
性别输入“女”，其余信息均正确填写，添加员工成功
姓名为空时，其余信息正确填写，添加员工失败。
姓名大于11个字时，添加员工失败
工号小于7位数字，添加员工失败
工号大于7位数字，添加员工失败
工号含有非数字时，添加员工失败
工号为空时，添加员工失败
籍贯未选择时，添加员工失败
年龄未选择时，添加员工失败
性别输入的非“男”或者“女”时，添加员工失败
电话号码为空时，添加员工失败
电话号为大于12位数字时，添加员工失败
电话号码含有非数字时，添加员工失败
邮箱格式错误时，添加员工失败

边界值

边界值分析方法是对等价类划分方法的补充.

  • 边界值分析方法的考虑:
    大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况，应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

基于边界值分析方法选择测试用例的原则

  1. 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

    • 比如：如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。作为测试用例，我们应取10及50，还应取9.99，10.01，49.99，50.01等。

  2. 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

    • 比如，一个商品的标题长度限制为1到120个字符，那么，我们要测试标题为空，为1个字符串，120个字符，以及121个字符。

  3. 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

边界值分析法

编写测试用例

判定表

判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具。

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计。

判定表的建立步骤:

  • 步骤一：标识输入和输出
    逐项分析测试子项的测试规格，找出其中所有的输入和输出并标识出来，其中要注意以下几点：
    1、输入需要包括外部消息输入、内部预置的用户状态、数据配置等所有对系统输出有影响的因素；
    2、输入和输出项只涉及两种取值的，可以只做为一个标识出来。如果输入项涉及多种取值的，每个取值需要做为一个输入标识出来；
    3、标识符可以自己确定，但输入与输出需要独立标识。

  • 步骤二：构造判定表
    将标识的输入填入条件桩部分，将标识的输出填入动作桩部分。条件项部分的列数为2的n次方列，n为输入数(即条件桩的个数)。并从最右列到最左列从“NN…N”到”YY…Y”填入条件项的所有组合。

  • 步骤三：逐列分析条件项组合，填入其动作项
    分析每列的条件项取值情况，根据输入和输出逻辑关系，得到该列的输出值为“Y”或“N”，填入该列动作项，得到一条规则。一条规则就是一条测试用例。

判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表

场景法

场景法也叫流程分析法，是模拟用户操作软件时的场景，主要用于测试系统的业务流程。当我们拿到一个测试任务时，我们并不是先关注某个输入框的等价类、边界值是否满足要求，而是关注它的主要功能和业务流程是否实现，这就需要使用场景法来进行测试。当业务流程测试没有问题，就说明软件的基本功能没有问题，我们再重点从等价类、边界值等方面对软件的控件进行测试。
<br>

在冒烟测试时，就主要是使用流程分析法进行测试。

  • 在测试一个软件的时候，在场景法中，如果测试的流程是软件功能按照最短的事件流实现的一条正确流程，那么我们把这个流程称为该软件的基本流；而凡是出现故障或缺陷，或其他原因导致最终的目的不能被实现，或者实现的流程并非是最短的，那么该流程就叫做备选流。这样的话，备选流就可以是从基本流来的，或是由备选流中引出来的。

  • 每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，确定用例场景。

场景法设计步骤：

  1. 根据说明，描述出程序的基本流及各项备选流；
  2. 根据各种流程，生成正常和异常的测试场景；
  3. 对每一个流程生成相应的测试用例。

步骤一：描述出基本流及各项备选流

基本事件流：

  1. 用户向ATM提款机中插入银行卡，如果银行卡是合法的，ATM提款机界面提示用户输入提款密码；
  2. 用户输入该银行卡的密码，ATM提款机与MainFrame传递密码，检验密码的正确性。如果输入密码正确，提示用户输入取钱金额，提示信息为：“请输入您的提款额度”；
  3. 用户输入取钱金额，系统校验金额正确，提示用户确认，提示信息为“您输入的金额是xxx，请确认，谢谢！”，用户按下确认键，确认需要提取的金额；
  4. 系统同步银行主机，点钞票，输出给用户，并且减掉数据库中该用户帐户中的存款金额。
  5. 用户提款，银行卡自动退出，用户取走现金，拔出银行卡，ATM提款机界面恢复到初始状态；

备选事件流(考虑可能失败的地方)：

在基本事件流1中：

  • 如果插入无效的银行卡，那么，在ATM提款机界面上提示用户“您使用的银行卡无效！”，3秒钟后，自动退出该银行卡。

在基本事件流2中

  1. 如果用户输入的密码错误，则提示用户“您输入的密码无效，请重新输入”；
  2. 如果用户连续3次输入错误密码，ATM提款机吞卡，并且ATM提款机的界面恢复到初始状态。此时，其他提款人可以继续使用其他的合法的银行卡在ATM提款机上提取现金。
  3. 用户输入错误的密码后，也可以按“退出”键，则银行卡自动退出。

在基本事件流3中：

  1. 如果用户输入的单笔提款金额超过单笔提款上限，ATM提款机界面提示“您输入的金额错误，单笔提款上限金额是1500RMB，请重新输入”；
  2. 如果用户输入的单笔金额，不是以100RMB为单位的，那么提示用户“您输入的提款金额错误，请输入以100为单位的金额”；
  3. 如果用户在24小时内提取的金额大于4500RMB，则ATM提款机提示用户，“24小时内只能提取4500RMB，请重新输入提款金额”输入提取的金额超过了系统的设定的限制 ；
  4. 如果用户输入正确的提款金额，ATM提款机提示用户确认后，用户取消提款，则ATM提款机自动退出该银行卡；
  5. 如果ATM提款机中余额不足，则提示用户，“抱歉，ATM提款机中余额不足”，3秒钟后，自动退出银行卡。

在基本事件流4中

  1. 如果用户银行户头中的存款小于提款金额，则提示用户“抱歉，您的存款余额不足！”，3秒钟后，自动退出银行卡；
  2. 如果ATM提款机与MainFrame之间通讯超时10秒钟，则本次操作取消，提示用户“抱歉，链接超时，本次操作取消”，并且将银行卡退出；

在基本事件流5中：

  1. 如果用户没有取走现金，或者没有拔出银行卡，ATM提款机不做任何提示，直接恢复到界面的初始状态；

步骤二：根据基本流和各项备选流生成不同的场景。以下为部分场景。

步骤三：生成测试用例

错误推断法

  • 在软件测试中，人们可以靠经验和直觉推测系统中可能存在的各种错误，从而有针对性地编写检查这些错误的例子，这就是错误推测法。
  • 其基本想法是：根据以往的测试经验和对系统内部知识的了解，列出系统中各种可能有的错误和容易发生错误的特殊情况，再根据它们来设计测试用例。随着在产品测试的实践中对产品的了解加深和测试经验的丰富，使用错误推测法设计的测试用例往往非常有效，可以作为测试设计的一种补充手段，并且积累的经验越丰富，方法使用效率越高。
  • 错误猜测不是瞎猜，它需要依据对系统薄弱地方的了解和对开发人员盲点的了解。
  • 在实施错误猜测法时，要注意的是，此方法只能作为测试用例设计的补充而不能单独用来设计测试用例，否则可能会造成测试的不充分。也就是说，错误猜测法只是针对系统可能存在的薄弱环节的测试补充，而不是为了覆盖而测试。

错误推测法，就是靠经验，推测用户可能会有哪些比较特殊的操作场景进行测试
> 比如测试付款这个功能，一般我们都会想到直接付款，但是有些用户下单后，可能会一直不付款；退款中途，取消退款后，再次发起退款，我们之前就遇到过，取消退款后再发起退款，给用户退了双倍的钱；提交订单时，如果网络差，页面没有及时跳转，这个时候用户可能会多次点击提交按钮，我们之前也发现过这样的bug，连续点了7次提交订单按钮，下了7个一模一样的订单。这些测试场景，就是用错误推测法设计出来的。

测试方法选择的综合策略

  • 测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的。
  • 在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平。

以下是各种测试方法选择的综合策略，可在实际应用中参考。

  1. 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效方法。
  2. 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
  3. 用错误推测法再追加一些测试用例。
  4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
  5. 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

测试执行

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

测试执行过程注意事项

  • 搭建测试环境事项
    测试用例执行过程前，成功搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。
    如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

  • 测试环境怎么搭建的？

搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

  • 偶然性问题的处理
  1. 在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
  2. 确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
  3. 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，我们会跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
  4. 如果是很严重的Bug，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

  • 详细记录预期与实际的不一致
    如果不一致，要从多个角度多测试几次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输入和实际的输出，以及对问题的描述写到测试报告中。
    因为在一个项目组中，项目的开发时间是有限的，如果我们测试时能把问题描述的详细一些，那么开发人员就会很容易的重现这个问题，也就能更快的解决问题，节省项目时间。

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

    1. 坚持原则；
    2. 对事不对人，拿证据说话；
    3. 尊重对方的劳动成果，平时和开发人员打好关系，不要把关系搞僵。

  • 当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

  1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
  2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
  • 及时更新测试用例
    测试执行过程中，应该注意及时更新测试用例：
    往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；
    有些测试用例在具体 的执行过程中根本无法操作，这时候应该删除这部分用例；
    若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
    总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

缺陷的定义缺陷又名为BUG（臭虫）

1. 软件实现的功能和需求不一致的功能
2. 软件未实现需求和规格未明确提及但应该实现的内容
3. 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。

  • 产品在上线后用户发现bug，这时测试人员应做哪些工作？

    1. 测试人员复现问题后，提交问题单进行跟踪；
    2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
    3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
    4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

  • 集结（二八定理）
    缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。

  • 如何跟踪缺陷/Bug的生命周期
    当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试，如果回归通过，就关闭缺陷，如果不通过，就返回给开发继续修改。

  • 缺陷的状态
    激活,确认,已解决,关闭

  • 缺陷的等级
    致命，严重，一般，轻微

  • 缺陷单应该包含这些要素
    缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。

测试报告的主要内容

  1. 人力投入
  2. 用例统计
  3. 问题单分类统计
  4. 遗留bug情况
  5. 测试风险
  6. 测试对象评估
  7. 测试结论
posted @ 2020-08-06 13:47  简小虫  阅读(403)  评论(0)  编辑  收藏  举报