软件测试基础知识

目录

什么是软件？

什么是软件测试？

软件测试的分类

软件的生命周期

软件开发测试模型

瀑布模型

V模型

敏捷开发模型

软件测试工作流程

测试需求分析

用例评审

软件缺陷（BUG）

BUG生命周期

BUG等级

---

什么是软件？

        软件是计算机程序、程序所用的数据以及有关文档资料的集合。即程序+数据+文档。
        软件有系统软件和应用软件。系统软件如Windows、sql-server等；应用软件如微信app、客户端等。应用软件又分为C/S架构和B/S架构。C/S：需要安装客户端才能够使用的软件，如QQ、微信等，这中架构存在的一个缺点是软件每次更新，都需要更新服务端与客户端。而B/S架构如淘宝、京东的网页版，只需要一个浏览器就能够访问使用。

什么是软件测试？

        软件测试是使用人工和自动化手段来运行测试某个系统的过程，是软件开发过程很重要的一部分。软件测试的目的是检验软件是否满足规定的需求或搞清楚预期结果与实际结果之间的差别。具体如下：

                1. 为了发现程序（软件）存在的代码或业务逻辑错误，也就是找bug

                2. 为了检验产品是否符合用户的需求，从而提高软件质量（这里用户的需求由产品经理搜集，输出用户需求规格说明书，也就是“规定的需求”）

                3. 为了提高用户的体验

        根据以上软件测试的定义和目的，问：使用QQ时发现了一个错误，是否属于软件测试？——不是。这里目的是使用，与软件测试目的不一致。

        软件测试工程师的职责：

                (1) 接受测试任务，需求分析；

                (2) 编写测试计划、搭建测试环境、编写测试用例并执行、跟踪BUG，编写测试报告等；

                (3) 负责项目软件质量的把关，软件功能测试、性能测试、压力测试；

                (4) 参与审核其他测试工程师的测试用例和报告；

                (5) 收集日常遇到的或是通过检测出的错误，并进行归档整理，备查；

                (6) 具备软件工程的基本知识，熟练掌握各种测试理论和测试技术；

                (7) 学习和推广使用新的测试技术和工具。

软件测试的分类

       软件测试从不同维度可以划分为多种，具体如下：

  1、白盒测试静态分析法原则：

        语句覆盖每条语句至少执行一次

        判定覆盖每个判定的每个分支至少执行一次

        条件覆盖每个判定的每个条件应取到各种可能的值

        判定/条件覆盖同时满足判定覆盖条件覆盖

        条件组合覆盖每个判定中各条件的每一种组合至少出现一次

        路径覆盖使程序中每一条可能的路径至少执行一次

  2、功能测试

        包括业务流程测试（通过测试、失败测试）和功能点测试。通过测试是验证需求能否正确实现，打通流程；失败测试是模拟一些异常业务操作，测试系统是否具备容错性。

  3、性能测试

        通过⾃动化的测试⼯具模拟多种正常，峰值以及异常负载条件来对系统进行各项性能指标进行测试。主要包括应用在客户端、⽹络上、服务器端性能的测试。通常情况性能测试包括：

        · 时间性能：主要指软件的⼀个具体响应时间。（注册、商品购买等）
        · 空间性能：主要指软件运⾏时所消耗的系统资源，如硬件资源，cpu,内存，网络消耗等。
负载压力测试的测试指标：并发用户数、平均事务响应时间、吞吐量

  4、除了常见的测试分类，还有以下两种测试形式：

        灰度测试：先发布部分功能，根据用户的反馈再发布另外部分的功能，进行更新。

        A / B测试：先发布的功能A部分用户先更新使用，根据A用户反馈再对B用户对应的功能进行更新。        

软件的生命周期

        软件生命周期就是软件从开始验法到最终被废弃不用所经历的各个阶段，分别是：

        一、问题的定义及规划（确定开发目的，进行可行性分析）

        二、需求分析（输出需求规格说明书SRS、原型图）

        三、设计（概要设计、详细设计）

        四、编码

        五、软件测试（单元测试—>集成测试—>系统测试—>验收测试）

        六、运行维护（软件生命周期中持续时间最长的阶段，包括纠错性维护和改进性维护）

测试停止准则：

• 测试超过了预定时间
• 执行了所有的测试用例设计方案
• 查出某一预定数目的故障
• 单位时间内查出故障的数量少于预定值

       测试时间或者其他资源不足属于项目管理的问题，不能作为测试结束标准。

软件开发测试模型

瀑布模型

        特点：自上而下，有顺序性

        缺点：测试介入比较晚，回溯成本较高，测试周期长，工作效率较低，项目成本较高。

    

V模型

        V模型反映了开发过程和测试过程的关系，从左到右基本描述了开发和测试的过程。

        特点：测试人员从需求阶段开始介入

        缺点：当需求便更时将会导致反工量非常大，模型灵活性比较低。

       

敏捷开发模型

        该模型是以人为核心，迭代、循序渐进的开发模型。强调以人为本，专注于交付客户有价值的软件，一般用于开发和维持复杂产品。把大项目分为多个互相联系，又可以独立的小项目，分阶段完成。 互联网的特点是快速，以此模型开发，可以提早抢占市场。

        特点：弱化文档，通过人与人之间的沟通实现需求分析（会议）

        缺点：测试时没有完整的需求文档可以查看

       

        例：某聊天软件有以下功能：文字聊天、语音聊天、视频聊天、支付、动态、小程序......将这些功能分为多个版本完成：

                版本1：文字聊天、语音聊天、视频聊天（耗时3M）

                版本2：支付、动态（耗时2M）

                版本3：小程序...（耗时4M）

                ......        ......

                整个开发过程中根据用户需求不断维护更新软件     

软件测试工作流程

        测试计划一般由测试主管完成，主要是确定测试内容、测试人员、测试环境、测试工具等，完成任务分配以及时间安排；测试用例是具体怎么来进行测试的文档。

        版本发布的要求：

                1、剩余的bug数量很少（趋近于0%）

                2、用例执行覆盖率要求（趋近于100%）

                      由测试用例覆盖率（影响因素：测试点覆盖率）和测试用例执行率决定

测试需求分析

        测试需求分析主要解决“测什么”的问题，一般来自需求规格说明书中的原始需求，应覆盖已定义的业务流程以及功能和非功能方面的需求。功能需求即具体的业务流程（优先考虑），非功能需求包界面、文档、兼容性、易用性、性能、安全性等。

        测试需求分析是根据需求规格说明书明确测试的内容，初步熟悉被测软件的核心业务流程，再针对某个功能去细分需求，提取测试点（软件包含多个功能点，每个功能点包含多个子功能，这些子功能就是测试点。测试点是软件功能细分的最小单元），通过评审确认是否存在漏测和错测的测试点。

测试需求分析的目的：

        (1) 测试需求分析是编写测试用例的依据

        (2) 有助于保证测试的质量与进度

        (3) 测试需求是衡量测试覆盖率的重要指标

一个界面如何进行测试需求分析？（从正常、异常两方面分析）

        1. 进行界面检查：参考原型图，查看界面是否一致

        2. 输入项：按照从上到下、从左到右的顺序来分析（包括约束限制、是否必填、是否允许重复、隐形需求等）

        3. 按钮：根据业务逻辑的先后顺序依次分析（一般存在某些条件操作成功，某些条件操作失败的情况），需要验证按钮操作结果：验证交互功能是否正常（例：登录成功？—>能跳转首页）

例：列出微信朋友圈功能测试点？

一、只发送文本（长按相机图标进入）

        (1) 字符长度限制：纯数字/英文/字符/中文/表情(手机自带表情，微信表情)；数字+英文+字符+中文+表情；包含url链接；文本是否支持复制粘贴

        (2) 发送文本超出字符限制

        (3) 空

二、只发送图片

        (1) 本地相册选择，直接拍摄

        (2) 可发送图片数量验证

        (3) 支持的图片格式验证，jpg？png？gif？不支持哪些格式？

        (4) 图片尺寸、最大像素显示，超出后是否会压缩处理？

        (5) 图片大小限制，超限处理方式？

        (6) 预览：预览大图是否屏幕自适应，预览时图片左右切换

        (7) 新增、删除、替换

        (8) 空

三、只发送视频（点击相机图标）

        (1) 本地相册选择、直接拍摄

        (2) 时长、个数、大小限制

        (3) 预览、增删改

        (4) 空

四、组合发送是否支持

        (1) 文本+图片

        (2) 文本+视频

        (3) 图片+视频

        (4) 文本+图片+视频

五、内容显示（涉及敏感词内容是否限制发送）

六、位置显示

        (1) 不显示位置

        (2) 选择位置：搜索、定位、编辑

        (3) 取消：是否返回上一级界面

七、权限设置

        (1) 公开、私密、部分可见、部分不可见

        (2) 取消：是否返回上一级界面

八、提醒谁看

        (1) 单人、多人，人数上限？收到的消息内容？是否提醒？

        (2) 取消：是否返回上一级界面

九、同步QQ空间

        同步、不同步，默认状态？

十、取消发送朋友圈

        (1) 选择相机取消

        (2) 已选择图片、输入文本，保存

        (3) 是否存草稿

十一、每日朋友圈发送限制

十五、显示限制

用例评审

        目的：检验用例覆盖率，找出漏写、错写、漏测的内容

        流程：测试负责人发起—>评审计划（约会议，时间）—>评审（若不通过，补充测试点和用例）—>通过—>执行用例—>归档

        用例变更场景：（1）需求变更（2）执行中用例完善（3）评审后用例修改

软件缺陷（BUG）

        软件缺陷包括：（1）软件的漏洞/缺陷/可以改进的细节(建议、优化)；（2）与需求实现方式存在差异（不符合需求）

        缺陷类型：功能类、性能类、界面类、安全类、兼容性、脚本问题等。

BUG生命周期

1. New（新的）：第一次发现BUG，确认并提交。
2. Assigned（已指派）：指派给开发人员，认定是BUG并处理
3. Open（打开）：BUG处理中，未完成
4. Fixed（已修复）：处理完毕，返还修改后的BUG
5. Pending Reset（回归）：测试对修复的BUG回归确认
6. Reset(再测试)：回归测试中
7. Closed（已关闭）：确认BUG已解决
8. Reopen（再次打开）：再次测试发现bug，再次传给给开发
9. Pending Reject（拒绝中）：开发认为不是bug并拒绝
10. Rejected(被拒绝的)：测试确认不是bug
11. Postponed（延期）：延期处理BUG

BUG等级

致命

• 常规操作引起的系统崩溃、死机、死循环、闪退、中断
• 造成数据泄露的安全性问题
• 与数据库连接错误；数据库发生死锁
• 涉及金钱计算的功能错误
• 阻断性测试，测试工作进行不下去（冒烟测试）

严重

• 程序错误、程序接口错误
• 数据库的表、业务规则、缺省值未加完整性等约束条件
• 错误涉及面光，影响到其他重要功能正常实现
• 非常规操作导致的系统崩溃、死机、死循环、闪退、中断
• 密码明文显示（界面+数据库）
• 偶现的致命BUG
• 界面非常难以接受

一般

• 次要功能未实现
• 操作界面错误（窗口、列、按钮）
• 查询错误，数据错误显示
• 简单的输入限制未放在前段进行控制
• 删除操作无提示
• 偶现的严重BUG
• 数据库中有过多的空字段

细微

• 界面、输入输出不规范不规范
• 辅助说明描述不清楚
• 长操作未给用户提示
• 提示窗口文字未采用行业术语
• 可输入区域和只读区域没有明显的区分标志

优化

• 改进、建议