测试理论基础（思惟导图）

1、软件测试基础

2、测试级别

3、系统测试类型

4、软件测试方法

5、软件质量

6、系统测试流程

7、测试用例格式

8、用例设计方法

 

1.什么是软件测试？
软件测试定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否知足规定的需求或弄清预期结果与实际结果之间的差异。或者：为了发现程序中的错误而执行程序的过程。

软件测试存在的意义：

①程序测试为了发现程序存在的代码或业务逻辑错误；

②软件测试为了检验产品是否符合用户需求（充分站在用户的角度）；

③软件测试为了提升用户的体验。

2.软件测试的原则
一、测试应该尽早介入。

二、全部的测试都应追溯到用户需求。

三、程序员应该避免检查本身的程序。除了单元测试。由于程序员对于本身的做品，思惟具备局限性。没法保证测试质量。交给第三方或者专业测试，运用各类测试技术，利用丰富的测试经验和对BUG的敏感，去提升软件的质量。

四、设计测试用例时应考虑到合法的输入和不合法的输入以及各类边界条件，特殊状况下还要制造极端状态和意外状态。

五、二八原则，测试发现的错误中80%极可能起源于20%的模块中。

六、对错误结果要进行一个确认过程（分清必现和偶然）。

七、制定严格的测试计划。

八、彻底测试时不可能的，测试须要终止。

九、妥善保存测试过程当中全部文档。

3.软件测试的分类
按测试阶段划分：单元测试（开发的自测行为）、集成测试（多个模块共同测试）、系统测试（完整的、全面的测试）、验收测试（正式验收测试、Alpha测试（开发和测试都不能参与，由用户进行测试，前期，非真实环境）、Bate测试（开发和测试都不能参与测试，由用户进行测试，后期，真实环境下测试））

按测试技术划分：白盒测试、黑盒测试（主流）、灰盒测试

按测试对象是否运行划分：动态测试、静态测试（文档检查、代码走查、界面检查）

按不一样的测试手段划分：手工测试、自动化测试

按测试包含的内容划分：功能测试（等同于黑盒测试，点点点）、界面测试（不会专门作，作功能测试时会同时作这个）、安全测试、兼容性测试（ios、安卓）、易用性测试（不会专门作，作功能测试时会同时作这个）、性能测试、压力测试、负载测试、恢复测试（灾备，若出现奔溃，须要多久自我修复）

其余测试：冒烟测试（在真正测试以前，会先进行主干测试，若主干测试都没法经过，则再也不进行测试）、回归测试（首先看bug是否真的修复，再次看bug修复后是否影响到与其有关的原本正常的功能）、探索性测试（测试思惟）（随机测试）

4.软件生命周期（十分重要）
        软件生命周期（SDLC,System Development Life Cycle）是软件开始研制到最终被废弃不用这整个过程叫作软件生命周期，整个生命周期包括问题定义及规划、需求分析、系统设计、软件编程、软件测试、软件维护等阶段。
1、问题定义及规划（参与人员：老板、产品经理（主导）、研发经理、项目经理、需求分析师）
       主要肯定软件的开发目的及其可行性。制定开发计划（软件需求说明书、原型图）。
2、需求分析/评审（原型图/软件需求说明书、主持—>产品经理 其余参与：研发 设计 测试）
        在肯定软件开发可行的状况下，对软件须要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书（原型图）。（关注一个问题：测试参与这个需求分析的目的是什么？产品用途，功能如何实现）
3、软件设计（属于开发的工做）
       把需求分析获得的结果转换为软件结构和数据结构，造成系统架构。
       概要设计：主要是架构的实现，指搭建架构、表述各模块功能、模块接口链接和数据传递的实现等项事务。（数据库、表等框架性的东西）
       详细设计：对概要设计中表述（伪代码的级别）
4、软件编码（开发编码，与测试无关）
5、软件测试

       在软件设计完成后要通过严密的测试，以及发现软件在整个设计过程当中存在的问题并加以纠正。测试的方法主要有白盒测试和黑盒测试两种。

   其中，开发：单元测试；开发or测试：集成测试、接口测试；测试人员：系统测试；客户or产品经理：验收测试（α测试、β测试）

   单元测试：主要测试程序代码，为的是确保各单元模块被正确的编译，好比有具体到模块的测试，也有具体到类、函数的测试等。----通常是开发来完成。

   集成测试：单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据可否正常传递。----好比说注册和充值这两个功能是否可以连通。

   系统测试：把软件系统搭建起来，按照软件规格说明书所要求，测试软件其性能功能等是否和用户需求符合，在系统中运行是否存在漏洞等。-----根据测试用例，进行完整的系统测试。

六：运行维护阶段（版本上线，产品上线；版本升级；bug修复）

5.软件测试的工做流程：
接触人员：开发，产品经理，客服（用户反馈问题），实施/技术支持/现场实施，设计师；
测试工做流程：
①需求分析：1.阅读需求/理解需求 2.整理需求 3.有疑问的地方须要讨论，弄明白为止；

②软件测试计划：一个文档，测试负责人/小组长制定计划；

文档包含内容：

目的：完成测试，什么时候终止，达成什么样的目标；

参与人员：谁参与，成为测试小组；

任务划分：谁负责哪一个功能模块的测试/用例的编写；

时间规划：何时写用例，何时测试，何时解释，何时上线；

出具的文档：用例bug表单 软件测试报告；

资源的申请/准备：申请一台服务器？我要作什么类型的测试？须要准备什么样的工具？ 

③测试设计阶段：写测试用例

评审（相互检查），修改：理解错误：改正；需求变动：修改，

④软件测试的执行阶段

1.测试前，进行冒烟测试，经过继续测试，不经过，打回

2.根据测试用例执行测试：发现bug提交bug管理系统；修复后，检验，再进行回归测试。

⑤评估阶段

测试完毕，出具测试报告：1.测试经过，上线； 2.测试不经过，打回，修改

6.软件生命周期模型
做为测试工程师，咱们最关心的三件事：

1.测什么？（最关注的问题）2.怎么测？3.何时测？

测试的计划是跟开发的计划走的

学习目标：

1.什么是软件测试需求？

2.软件测试需求的必要性

3.如何对软件测试需求进行分析（重点）

功能、易用、界面、权限

4.需求分析对开发和测试的影响

 

3.软件测试流程
设计、执行、总结

4.常见面试笔试题
测试结束的标准是什么：系统测试缺陷报告跟踪完毕，系统测试报告经过审批。测试用例执行完毕、用例经过率＞98%。不存在严重bug。

执行测试用例的时间：通常为3-6个月，起码3个月，但留给测试的可能只有7天。

 

软件测试用例的设计方法——四大金刚

1.等价类划分法

  1.等价类划分法的概念

       等价类划分法是一种典型的、重要的黑盒测试方法，是指某个输入域的子集合。在该子集合中，全部的输入数据对于揭露软件中的错误是等效的。

       等价划分分为有效等价类和无效等价类，有效和无效是根据条件划分的。

  2.错误推测法

      输入错误的信息进行检测，看测试程序对错误状况的处理能力。

  3.边界值分析法

 1.定义：边界值分析法是对等价类划分法的一个补充，边界值通常都是从等价类的边缘值去寻找。边界值分析的基本思想：正好等于、刚刚大于、刚刚小于边界的值作为测试数据。

注意：0和负数都是一个特殊值，咱们在考虑边界值的时候同时也要考虑特殊值。

4.场景法（功能作好了才用）（xmind）

整个流程的描述，例如ATM取款流程

7.什么是测试用例
   测试用例（TestCast）是为项目需求而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序是否知足客户需求。
   能够总结为：每一个测试点的数据设计和步骤设计。

7.1测试用例的重要性

  1.测试用例是软件测试的核心

        软件测试的重要性是毋庸置疑的，测试用例是测试工做的指导，是软件测试质量稳定的保障。影响软件测试的因素不少，如软件自己的复杂程度，开发质量，测试方法和技术的使用。但有些因素是客观存在，不可避免的，如IT团队的流动、环境、情绪等。

  2.评估测试结果的基准

       测试用例的经过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否经过，可否达到上线的标准。

  3.保证测试的时候不遗漏测试功能点。能够在测试人员疲累的时候起到引导做用。

  4.在编写测试用例过程，能够熟悉需求，对系统架构或者业务流程有一个总体的、深刻地了解。

  5.好的测试用例不只方便本身和他人查看，并且能帮助设计的时候考虑的更周全，所以测试用例的写做和设计同样，很重要。指导性。

7.2测试用例的八大要素

   1.用例编号：产品名-测试阶段-测试项-xxx

   2.测试项目：对应一个功能模块（细分功能）

  3.测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复(一句话说清楚测试点是什么)

  4.重要级别：高/中/低

  5.预置条件：须要知足一些前提条件，不然用例没法执行（用例可写也可不写）

  6.测试输入：须要加工的输入信息，根据具体状况来设计（跟步骤结合起来必定要具备指导性意义）

  7.操做步骤：明确给出每一个步骤的描述，执行人员能够根据该步骤完成执行工做。

  8.预期结果：根据与其输出比对实际记过，来判断被测对象是否符合需求。（预期结果惟一）

  9.实际结果：

7.3测试用例使用工具

excel和xmind（都要会用）

 

8.bug的生命周期（重点）

   8.1 bug的定义

      软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此以外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差别的功能实现等。

       测试工程师的职责是：发现BUG，并提交给开发，让开发去修改。

  8.2 bug的类型

      要肯定一个bug的类型，须要对项目（或产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对问题类型的统计就比较重要了。

      常见bug类型划分（禅道系统为例，可自定义）：

       代码错误 

       设计缺陷

       界面优化

       性能问题

       配置相关

       安装部署

       安全相关

       标准规范

       测试脚本

       其余

8.3bug的等级

      1,2,3,4级，1级最严重的bug;3属于正常bug。

（1）致命错误：

     1.常规操做引发的系统崩溃、死机、死循环，好比对话框输入信息形成程序崩溃；

     2.形成数据泄露的安全性问题，好比恶意攻击形成的帐户私密信息的泄露；

     3.涉及金钱的方面，例如：用户余额为零，却能消费

（2）严重错误：

      1.重要功能不能实现；（好比用户没法注册）

      2.错误的波及面广，影响到其余重要功能正常实现：功能交互

      3.很是规操做致使程序的崩溃、死机、死循环等；

      4.外观难以接受的缺陷；

      5.密码明文显示（界面+数据库）。

（3）通常错误：

       不影响产品的运行、不会成为故障原由，但对产品外观和下道工序影响较大的缺陷。

        1.次要功能不能正常实现；

        2.操做界面错误（包括数据窗口内列名定义，含义不一致）；

        3.查询错误，数据错误显示；（张冠李戴）

        4.简单的输入限制未放在前段进行控制；（格式限制）

        5.删除操做未给出提示；

（4）可忽略错误

       例如错别字，或测试人员以为软件设计不美观等。

8.4bug的生命周期
     测试(发现并提交bug至管理系统中)——>指派给对应开发人员

——>开发人员先确认是不是本身的bug，如果，确认；不是，打回测试；不是bug，不予解决，由于不是bug；或延期解决。设计如此；没法重现。——>对于打回的bug，测试再次肯定需求，若的确是bug，则再次激活发给开发。——>对于修复后的bug，测试进行回归测试或验证测试，若已经解决，就直接关闭。若还未解决，再次打回给开发。

     客服（客户反馈的问题）——>发给测试，如果bug,提交，若不是就告诉客服是客户的操做问题。

    测试（需求的肯定，需求的变动，和开发扯不清楚）——>产品经理
---------------------

缺陷状态说明

新建：测试中新建的软件缺陷，尚未提交给软件工程师。通常由测试负责人进行评估，若是属于缺陷，修改成“打开”状态；若是不属于缺陷，修改成“取消”状态。

打开：测试中新建的软件缺陷，已提交给相关软件工程师。

待讨论：存在争议，须要软件工程师、需求人员和测试工程师共同确认；该状态是临时状态，在进入最后一轮ST测试执行以前，必须进行处理。

已修复：软件工程师已修正缺陷，等待测试工程师进行验证。

已发布：软件工程师已提交修复版本，而且版本管理员已将修复版本发布到测试环境。

项目内暂不处理：因为各类缘由，提交的缺陷须要在后续版本才能修改，或者不修改。项目内暂不处理的缺陷须要由需求人员、软件工程师和测试工程师最终确认。对准备修改的缺陷，在进入最后一轮ST测试执行以前，测试工程师就必须和需求人员、开发人员讨论肯定是“转业务需求”仍是“转内部需求”，在后续项目进行修复，或者在本项目最后一轮ST测试执行前修复。对一致承认但不许备修复的缺陷，或者不能重现的缺陷，能够将“项目内暂不处理”做为终态。

已否决：软件工程师认为不须要修改，或者按照设计就应该是这样的。对于非本项目或者非本人缺陷，因为设计变动或者版本变动以前的问题如今没法重现，不可否决。无理由否决的，测试工程师一概从新打开。

已分配：转发给其余人处理。也能够转给本身处理，转给本身处理时，代表软件工程师已接受此项缺陷。

从新打开：测试工程师对已修复的缺陷进行验证，发现缺陷仍旧存在。或者测试工程师认为已被否决的缺陷确实须要修改。

已关闭：缺陷已被修复，且回归测试验证成功。

非问题关闭：对于软件工程师否决的缺陷，若是测试工程师认为确实不属于缺陷，则将缺陷状态标记为“非问题关闭”。

转业务需求：该缺陷与业务相关，须要解决，但在本项目中不处理，由需求人员在后续版本中做为业务需求提出。

转内部需求：该缺陷主要是设计实现的问题，不涉及业务需求的变动，须要解决，但在本项目中不处理，由软件工程师在后续版本中做为内部改进需求提出。

取消：测试中新建的软件缺陷，由测试负责人进行评估，确认不属于缺陷，则将缺陷状态标记为“取消”。

====================================================================================================================================================================================================

缺陷严重度说明—非性能测试项目域
1、致命 
该类缺陷若是发生会形成基本业务没法使用、或对其余业务形成严重影响、或对我行形成经济损失、法律纠纷、声誉影响等。

● 因为程序所引发的死机,非法退出或系统挂起。

● 死循环。

● 发生线程互锁、数据库死锁等严重资源争用状况。

● 数据转换错误，通信程序不稳定或通信程序错误。

● 主要功能缺失。

● 记帐错误。

● 严重的数值错误，好比数据库或回单上的客户信息，余额，利息，积数，日期等。
2、严重 
该类缺陷若是发生会形成部分业务功能没法使用、或对其余业务形成必定影响、部分功能实现形成较大的错误理解等。

● 影响业务进行的主要功能与需求不符。包括设计与需求不符，以及实现与设计不符。

● 非主要功能未实现。

● 程序引发的接口或数据通信错误，致使数据缺失，信息传输错误等。

● 致使资金或是帐务错误等关键字段的数值计算错误。

● 操做权限错误。

● 异常处理遗漏或错误。

● 存在严重性能问题。

● 显示或打印的关键信息格式与需求定义存在大的误差。

● 关键的输入限制未进行控制。
3、通常 
该类缺陷若是发生会对非主要功能形成影响、或者有较为快速方便的规避方式、有较小的错误理解等。

● 与设计文档不符的界面错误。

● 非主要功能实现不正确，但不影响业务进行。

● 非关键信息的计算错误，如页码的计算错误。

● 打印的非关键信息错误；因为内容超长致使的格式错误。

● 简单的输入限制未进行控制。

● 业务操做缺乏交互式的确认提示信息。

● 错误提示信息错误。

● 系统处理速度较慢，可能存在性能风险。
4、较小 
该类缺陷若是发生会使用户不方便或遇到麻烦，但它不影响执行工做功能或重要功能。

● 辅助说明描述不清楚。

● 显示格式不规范，界面有错别字。

● 长时间操做未给用户进度提示。

● 提示窗口文字未采用行业术语。

● 错误提示信息不清晰。

● 可输入区域和只读区域没有明显的区分标志。

● 界面布局不合理、用户体验效果不佳、操做界面与用户使用习惯不一致，但不影响系统正常使用。

● 建议。
5、建议及警告 
针对系统功能实现方式、组织方式、界面布局、用户体验、易用性等方面提出的修改建议（此类缺陷不会给系统带来直接的负面影响或安全隐患）。

====================================================================================================================================================================================================
缺陷严重度说明—性能测试项目域
1、致命(P1) 
该类缺陷若是发生会形成基本业务没法使用、或对其余业务形成严重影响、或对我行形成经济损失、法律纠纷、声誉影响等。

● 因为程序所引发的死机,非法退出或系统挂起。

● 死循环。

● 记帐错误。

● 应用服务器或数据库服务器出现崩溃或不可用。

● 交易错误率>10%。
2、严重(P2) 
该类缺陷若是发生会形成部分业务性能没法使用、或对其余业务形成必定影响、部分功能实现形成较大的错误理解等。

● 数据库出现严重锁等待、死锁。

● 严重线程阻塞。

● 5%< 交易错误率% <10%。

● TPS和响应时间严重不达标。

● 发现架构设计缺陷。
3、通常(P3) 
该类缺陷若是发生会对性能形成必定影响、部分功能会出现一些错误。性能指标：1）错误率<10%；2）TPS和响应时间不达标；3）操做系统资源消耗过大。

● 0.5%< 交易错误率% <5%。

● TPS和响应时间不达标。

● 服务器资源消耗过大。

● 非功能测试案例不经过。

● 参数设置不合理。
4、较小(P4) 
该类缺陷若是发生会不会影响到交易的性能，但客户体验上会相对比较差。

● 前端页面性能明显BUG。
5、建议及警告(P5) 
已达到预期性能指标，但还能够提高性能的建议。

=====================================================================================================================================================================================================

缺陷类型说明 
缺陷类型有三个一级类型分类，各个一级类型下有多个二级类型分类。提缺陷时，类型有二级类型时必须选择二级类型。
一级类型：01-功能性缺陷 二级类型：11-功能错误 
● 实现与提供的需求不一致

● 使用的计算方法或计算公式错误

● 影响帐务或可能致使法律纠纷的关键数据的计算错误，好比针对数据库和客户回单上帐户余额、利息、积数、冻结金额、可用余额、额度等关键信息的计算错误

● 变量初始数据错误

● 系统数据初始化错误

● 数组越界或缓冲区溢出

● 数据结构或数据库表结构设计有问题

● 写入数据库表的内容错误，好比出现重复记帐或表内帐单边帐

● 死循环

● 业务功能重复或缺失

● 业务功能实现与需求不符

● 流程控制不符合需求

● 流程实现不完整
一级类型：01-功能性缺陷 二级类型：12-用户界面错误 
● 控件布局、格式不统一

● 界面控制错误

● 界面布局与界面规范不一致

● 打印或输出格式错误
一级类型：01-功能性缺陷 二级类型：13-通信及接口错误 
● 通信接口不匹配

● 通信接口数据转换错误

● 通信程序不稳定

● 通信程序错误
一级类型：01-功能性缺陷 二级类型：14-信息提示错误 
● 提示信息重复

● 提示信息内容错误

● 提示信息内容模糊，不能准确判断错误缘由

● 提示信息出现时机不对，或焦点位置错误
一级类型：01-功能性缺陷 二级类型：15-异常处理错误 
● 程序未进行异常处理

● 异常处理不正确或者不合理
一级类型：02-非功能缺陷 二级类型：21-易用性错误 
● 不符合常识或不符合操做习惯

● 操做使用不友好，不易操做等
一级类型：02-非功能缺陷 二级类型：22-性能错误 
● 批量处理时间过长

● 联机业务响应时间过长致使资源争用，形成互锁或死锁问题，如线程同步问题或数据库锁等待
一级类型：02-非功能缺陷 二级类型：23-安全性错误 
● 用户和权限控制错误

● 有SQL注入漏洞

● 有跨站点攻击漏洞

● 有其余安全性漏洞
一级类型：02-非功能缺陷 二级类型：24-兼容性错误 
● 在不一样操做系统、不一样浏览器上的错误

● 与不一样版本匹配出现的错误
一级类型：02-非功能缺陷 二级类型：25-安全性错误 
● 数据错误

● 脚本错误

● 功能问题

● 硬件问题

● 环境问题

● 数据库问题

● 网络问题
一级类型：03-文档类缺陷 二级类型：31-评审类缺陷 
● 各种评审活动发现的缺陷
一级类型：03-文档类缺陷 二级类型：32-其余文档错误 
● 各种评审活动发现的缺陷

====================================================================================================================================================================================================
缺陷归属说明

项目内：表示该缺陷是因为该项目新增或者修改功能而致使的缺陷；

项目外：表示该缺陷不是因为该项目新增或者修改功能而致使的缺陷，是因为其余产品引发或该产品一直遗留的缺陷。若不在本项目解决，必须挂系统产品，状态设为项目暂不处理。若是项目外缺陷项目内修复，这缺陷归属需从新选择为项目内。

行外系统：表示该缺陷是因为行外系统致使的，可是若是该项目涉及到行外系统的再维护和开发，不属于此范畴。若是认定为行外缺陷，则系统产品栏位需选择事先定义好的虚拟行外产品。