软件测试基础篇—测试用例的设计方法

目录

一，测试概念

1，软件测试的生命周期

 软件测试的生命周期：

软件开发的生命周期：

测试用例的概念和要素：

2,Bug

1），如何描述Bug：

2），bug的级别

3），Bug的生命周期

二，测试模型

1，V模型

2，W模型

三，设计测试用例的万能思路

四，水杯的测试用例

1，界面测试：

 2，功能测试

3，性能测试

4，兼容性测试

 5，易用性

 6，安全性

 五，设计测试用例的方法

1，基于需求设计的测试用例（大概的设计）

1，等价类

思想：

 概念：

设计步骤：

 2，边界值分析法

边界值分析法一般是等价类的补充

 3，判定表法

判定表法的设计步骤

例如：

 4，正交法

正交表：

正交表的特性：

 使用正交法编写测试用例的方法

5，场景设计法

 6，错误猜测法，依赖测试人员的经验和能力

---

一，测试概念

1，软件测试的生命周期

软件生命周期，软件测试的生命周期：

 软件测试的生命周期：

1，需求分析：

站在用户的角度：查看需求逻辑是否正确，是否符合用户的需求和行为习惯

站在开发人员的角度：思考需求是否可以实现，或者实现的难度大小

2，需求计划

制定测试计划（包括但不限于测试工时和人力安排。。。）

3，测试设计，测试开发

设计测试用例，经验丰富的测试人员可以开始进行白盒测试

 4，测试执行

参考测试用例来执行测试

5，测试评估

测试人员需要记录测试，做好缺陷管理，然后进行测试评估

软件开发的生命周期：

1，需求分析

测试也要参与需求分析，分析需求是否合理，需求是否符合用户的行为习惯，站在开发人员角度，分析需求实现的难度，根据难度来合理调整需求

2，计划

根据需求编写测试计划、测试方案

3，设计

测试人员适当的了解设计，合理的进行测试用例的设计和调整

4，编码

专业的白盒测试人员可以开始执行单元测试，完善，细化测试用例以及调整测试计划和测试方案

5，测试

参考测试用例来执行测试

6，运行和维护

测试人员进行产品演示和功能介绍，期间记录大家的反馈意见，最终反馈给产品经理，形成一个新的用户需求

测试用例的概念和要素：

根据需求设计的一组测试需求的测试例子，

要素：测试用例编号，测试项目，测试标题，重要级别，预置条件（测试环境等），测试用例，测试步骤，预期结果

2,Bug

Bug：导致程序出现问题的错误

1），如何描述Bug：

例如：

 Bug标题：谷歌浏览器打开首页后，二维码被登录控件覆盖，导致无法扫面

发现Bug的环境：Windows10  Chrome

发现Bug版本：Chrome版本 22.07.22 64位

发现Bug的步骤：1，打开浏览器，访问主页连接

期望结果：首页的二维码和登录控件分离，二维码可以通过扫描得到结果

实际结果：二维码被登录控件锁遮盖，导致手机无法扫描

其他：（Bug的类型：前端问题，Bug的级别：。。。）等

2），bug的级别

奔溃级别：阻碍开发和测试工作的问题；造成系统死机，奔溃，死循环，导致数据丢失的问题，与数据库连接错误，主要功能模块丧失，基本模块缺失等问题。

严重级别：系统主要功能部分丧失，数据库操作错误，用户数据丢失，一级菜单功能不能使用，但是不影响其他功能的测试

一般级别：功能没有完全实现，但不影响使用，功能菜单存在缺陷但不会影响系统稳定性

次要级别：一些优化的建议

3），Bug的生命周期

* new ：新发现的bug，未经评审决定是否需要开发人员进行修改

* open：确认是Bug，斌且认为需要确认修改，指派相应的开发人员

* Fixed：开发人员修改完成状态，需要测试人员进一步测试

* Rejected：拒绝修改，如果不是Bug

* Dalay：延后修改，暂时不需要修改或者暂时不能修改

* Close：Bug修改完成，测试验证通过，Bug关闭

* Reopen：如果修改后Bug依然存在，就会重新打开Bug，开发人员在次修改

二，测试模型

1，V模型

 需求分析 -> 计划 -> 设计 ->编码 ->测试

概要设计：设计整体的框架，架构

详细设计：模块与模块之间的设计

集成测试和单元测试通常由开发人员来完成

特点：

1，明确标准了测试类型

2，明确标注了测试与开发阶段的对应关系

缺点：测试后置

2，W模型

 测试用需求开始就介入

缺点：

上一阶段任务完成，下一阶段任务才能开始

开发模型和测试模型也保持着一种前后的线性关系

重文档，重过程，不支持敏捷模型

3，与开发人员产生争执怎么办

1，具备批判思维，多反思自己是不是Bug没有描述清楚

2，Bug等级一定要有理有据

3，不仅能提出问题，最好能够由解决方案

4，友好的沟通，站在用户的角度反问

5，组织Bug评审

产品代表，开发代表，测试代表

1），如何修复Bug，提出解决方案

2），如何避免Bug

三，设计测试用例的万能思路

万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

测试用例需要具备提高系统测试覆盖率，不是越多越好

设计测试用例的要素：测试环境，测试步骤，测试数据，预期结果等

脑图：naotu.baidu.com

四，水杯的测试用例

1，界面测试：

如果是软件的话，考虑软件的布局，图片，色彩搭配，是否合乎大众审美，关键信息能否被用户快速捕捉，界面模块设计是否划分明显

 2，功能测试

软件：用户需求是否满足，响应速度如何，多用户同时访问是否会出现问题等3， 

3，性能测试

软件：并发性，千万用户访问是否导致系统出现问题等

4，兼容性测试

在不同浏览器，不同版本，不同操作系统，软件的不同版本的兼容新

 5，易用性

软件：是否各个年龄段的用户都可使用，跨国家地区的使用，是否能够快速上手使用，等

 6，安全性

软件：SQL注入，XSS漏洞，越权等安全问题

 五，设计测试用例的方法

1，基于需求设计的测试用例（大概的设计）

        针对有需求的案例来设计测试用例

               需求分析——需求有那些功能——设计测试点——设计测试用例

通过穷举法来设计测试用例，若测试用例通过，则认为符合需求要求

1，等价类

分区分块——使用较少的测试用例达到符合系统测试覆盖

思想：

        将较大的模块划分成较小的模块，在各个小模块之间使用比较有代表性的测试用例来测试符合系统的测试覆盖

 概念：

       针对需求输入范围划分成若干等价类，从这些等价类中取出一些用例，若给类中的选取的测试用例全部通过，则说明该测试用例所在的等价类是通过的。

设计步骤：

        1，划分有效等价类（针对需求有效且有意义的集合）和无效等价类（针对需求无效且无意义的等价类）

                1），确定有效等价类

                2），确定无效等价类

        2，编写测试用例

 2，边界值分析法

边界值分析法一般是等价类的补充

 3，判定表法

一种表达逻辑判断的工具

适用场景：需要考虑不同输入之间的组合的关系，不同组合对应不同的输出结果

判定表法的设计步骤

        1，确认输入条件和输出条件

        2，找出输入条件和输出条件之间的关系

        3，画判定表

        4，根据判定表编写测试用例

例如：

 

 4，正交法

正交表：

因素数：输入条件

水平数：输入条件可能采取的结果（不是输出结果）

正交表的特性：

        1，每一列中不同的数字出现的次数相同

                

        2，任意两列排列的数字的排列方式齐全而且均衡

 使用正交法编写测试用例的方法

1，找出因素数和水平数

因素数：有几种要输入的东西

水平数：每种输入对应的可能结果个数

2，使用allpairs工具生成正交表

 

 

但是存在着出入，但是任然不影响我们使用allpairs生成正交表

3，根据正交表，编写测试用例

4，补充测试用例

5，场景设计法

        通过事件触发流程，同一事件不同的触发顺序和处理结果形成事件流，通过事件触发的场景将各个孤立的功能点联系起来，为测试人员建立整体业务的感觉，是测试用例更容易理解和执行。

主要分为基本事件流和多个备用事件流

 编写测试用例：

 6，错误猜测法，依赖测试人员的经验和能力

        对被测试软件有所了解，根据经验和个人直觉，推测软件可能在那些方面存在问题，从而针对性的设计测试用例