软件测试计划

[TOC]

1. 引言

1.1. 编写目的

对基于格覆盖的布尔表达式可视化系统的测试做出详细的测试计划

1.2. 被测系统

基于格覆盖的布尔表达式可视化系统

1.3. 术语

1.4. 参考资料

2. 测试资源

2.1. 测试环境

• 硬件：CPU：英特尔酷睿i5和i7；内存：16g和12g

• 操作系统：windows 10

• JAVA：JDK 11

• node：12.16.3

• 数据库：Mysql8.0.19

• Redis：5.0.9

• 浏览器：Google Chrome

3. 测试的范围

3.1. 功能类测试范围

测试基于格覆盖的布尔表达式可视化系统的主要功能，如卡诺图绘制、单缺陷诊断、同项双缺陷诊断、双项双缺陷诊断、降维、缺陷动画历史回放等功能。

3.2. 非功能类测试范围

非功能类测试主要是对系统安装、内容、导航、界面、接口和配置进行测试。

3.3. 不需要的测试范围

不对安全(页面拦截/数据库SQL注入)、性能、数据库进行测试。

4. 测试的方案

4.1. 安装测试

4.1.1. 概述

确保软件能够按照安装文档正常安装使用。

4.1.2. 目标

测试按照安装文档配置好运行环境后是否能正常安装。

4.2. 导航测试

导航图(状态机,触发机制)

4.2.1. 概述

导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等。或在不同的连接页面之间。

4.2.2. 目标

(1)保证任何用户可以使用的路径都处于可工作状态;

(2)确认每个导航语义单元都可被适当类型的用户使用。

具体测试用例

页面	动作	评价
主页	登录链接跳转
	登录前个人信息页面跳转到登录页面
	开始链接跳转
	登录前后系统功能页面跳转
登录注册	注册账号链接是否正常，注册后跳转到登录页
	忘记密码链接是否正常
	登录按钮是否正常，登录后是否跳转到功能页
个人信息	登录后能否进入个人信息页面
历史记录	登录前能否进入历史记录页面
	登录后能否进入历史记录页面
功能页面	各功能页面之间的跳转（缺陷诊断、变体生成等）
	功能展示后跳转到历史记录页面是否能马上展现历史
	功能页到个人信息和主页等链接是否正常

4.3. 界面测试

4.3.1. 概述

界面测试就是指，布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

4.3.2. 目标

(1)找出与特定界面机制相关的错误;

(2)找出在界面实现导航语义、Web应用功能或内容显示方法中存在的错误。

具体测试用例

检查项	测试人员评价
界面是否美观，排版是否规则
导航链接到达恰当内容或者实现相应功能
选择菜单是否可以正常工作、并与实际执行内容一致
菜单是否有错别字、中英文混合
使用safari、firefox等其他浏览器是否能兼容
文本框、按钮、滚动条等控件功能是否正常
功能展示的表格和图像是否正常
评价系统是否易用

4.4. 内容测试

4.4.1. 概述

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。确保可视化系统文本、图像展示和排版等没有错误。

4.4.2. 目标

(1)发现文本文件、图像展示和其他媒体的句法错误(如排版错误，语法错误等);

(2)发现当进行导航时呈现在任何内容对象中的语义错误(即信 息准确性和完整性的错误);

(3)找出呈现给最终用户的内容组织或结构上的错误。

具体测试用例

检查项	测试人员评价
所有页面是否有乱码，错字，排版等句法错误
页面中的功能是否容易被用户找到
是否有完整的引用说明
所有页面是否侵犯其他版权或者商标
页面中超链接是否正确
页面信息是否容易被用户理解
卡诺图绘制图像展示是否有错误
测试用例功能展示是否有错误
缺陷动画展示是否有错误
变体生成可视化展示是否有错误
韦恩图是否有错误
历史记录是否展示完全

4.5. 功能测试

4.5.1. 概述

确保可视化系统各功能正常,如卡诺图绘制,缺陷诊断,缺陷动画,降维等功能正确.

4.5.2. 目标

利用有效的和无效的数据来执行各个用例流,以核实以下内容

1. 在使用有效数据时得到预期的结果
2. 在使用无效数据时显示相应的错误消息或警告消息

具体检查项目:

检查项	测试人员评价
卡诺图绘制功能正确吗?
单缺陷诊断功能正确吗?
双项双缺陷诊断功能正确吗?
单项单缺陷诊断功能正确吗?
操作日志正常吗?
缺陷动画历史回放功能可用吗?
降维功能正常吗?
存储数据功能正常吗?

4.5.3. 怎么检查

• 人工检查项目与判断

可以选择Selemium来录制测试脚本,但是我们的测试用例不多,故采用人工检测的办法.

4.5.4. 生成测试用例

4.5.4.1. 测试用例生成方法

测试用例主要来源于:

1. 等价类划分法
2. 边界值分析法
3. 错误推测法
4. 因果图法
5. 判定表驱动法
6. 正交试验法
7. 功能图法
8. 场景图法

本测试选择

• 等价类分析
• 边界值分析

4.5.4.2. 测试用例生成

测试用例编号	TEST1
测试项目	卡诺图绘制功能
重要级别	高
预置条件	系统启动
输入	ab+cd
操作步骤	1.缺陷诊断页面输入表达式ab+cd 2.点击提交按钮 3.生成卡诺图
预期输出

4.5.4.3. 缺陷诊断

4.6. 接口测试

4.6.1. 概述

理论上UI界面到数据库之间，数据流经过的所有接口都需要测试:

• Web 浏览器 到 Web 服务器:Web 接口测试，测试 请求和响应
• Web 服务器 到 应用服务器:契约服务，WebService，JavaAPI，WebAPI等
• 应用服务器 到 数据库服务器：测试数据处理与把数据读取到数据库

依据本次测试需求,我们主要关注Web接口测试.Web接口一般利用http协议，通过路径来区分调用,请求报文基本为key-value形式，返回报文一般是json或xml，支持get和post等方法.

4.6.2. 具体测试内容

Web 接口的定义决定了测试内容,通常关注业务流程(服务器逻辑验证)/输入参数/输出返回/性能/安全等内容,如下:

测试用例主要来源于:

1. 等价类划分法
2. 边界值分析法
3. 错误推测法
4. 因果图法
5. 判定表驱动法
6. 正交试验法
7. 功能图法
8. 场景图法

本测试选择

• 等价类分析
  • 随机取样

因为缺少软件需求开发文档,所以也没有选择因果图法.

4.6.3. 怎么测试

通过工具或代码模拟http请求的发送与接收,主要有以下两种方法:

• 接口自动化来实现,发送请求用断言来判断。
• 工具postman和java+httpclient/crul等

4.6.4. 接口测试用例

请求:

http://localhost:3000/userInfo/logout

返回

{
"result": "success"
}

图片示例

4.7. 配置测试

4.7.1. 概述

配置测试是在各种硬件和软件平台类型以及不同设置情况下检查软件运行的过程

4.7.2. 目标

保证系统在不同浏览器及其不同配置下能正常运行

配置测试的检查项

检查项	测试人员评价
系统可以运行在不同的操作系统下吗?
系统可以运行在不同的浏览器下吗?
系统可以运行在不同的处理器下吗?
系统运行在不同的RAM下有何影响?

4.7.3. 生成测试用例

4.7.3.1. 资源配置

小组共有两台电脑,一台16GMac,一台12GWindows,可勉强满足不同的操作系统/浏览器/处理器/RAM要求.

4.7.3.2. 生成步骤

1. 考虑前后端和软硬件分别：

• 前端：浏览器类型，屏幕分辨率
• 后端：CPU，RAM

后端硬件如图: 因为目前可视化系统只能在Windows平台上运行，不将操作系统纳入因子范围。限于设备原因,屏幕分辨率采用自行调节的方式.

2. 因素状态表

状态/因素	A浏览器类型	B屏幕分辨率	C CPU	D RAM
0	Safari	1920*1080	苹果	16g
1	Chrome	1680*1050	i5	12g

3. 将中文转换为字母,便于设计

状态/因素	A浏览器类型	B屏幕分辨率	C CPU	D RAM
0	A1	B1	C1	D1
1	A2	B2	C2	D2

4. 使用正交组合的方法生成测试用例

参数是4因素,2水平.选择正交表时尽量让其与因素数和水平数吻合,因素数要一致,水平数考虑出现最多的水平数.这里选择$L_8(2^7)$: 用字母代替正交矩阵,5,6,7列去掉没有意义

行\列号	1	2	3	4	5	6	7
1	A1	B1	C1	D1
2	A1	B1	C1	D2
3	A1	B2	C2	D1
4	A1	B2	C2	D2
5	A2	B1	C2	D1
6	A2	B1	C2	D2
7	A2	B2	C1	D1
8	A2	B2	C1	D2

所以最后生成了以上8组测试用例,如第一组测试用例是:

测试用例编号	TEST1
执行人员	王艺辉
测试项目	内配置测试
重要级别	高
预置条件	RAM16g,CPU苹果,Safari,1920*1080
输入	/
操作步骤	1.打开可视化系统界面,观察是否能正常运行; 2.输入原表达式,观察是否能正常绘制卡诺图; 3.输入待测表达式,观察是否有动画生成
说明输出	可以成功运行

4.8. 回归测试

测试过程中如果发现bug,提交并解决后判断修复bug对系统带来的影响,保证不引入新的缺陷.如果选择完全重复测试,将要重新执行全部测试用例,必然拖累项目进度.因而选择选择性重复测试,具体策略:

1. 针对发生错误的模块,选取这个模块的全部用例进行测试.
2. 将周边与上述模块有关系的模块测试用例也执行一遍.

5. 项目任务分配

初步分配:

测试人员	项目任务分配
黄佳威	测试计划1-4.4节及对应后续任务
王艺辉	测试计划4.5-9节及对应后续任务
所有人	讨论汇总

6. 测试进度

利用teambition的时间线工具作出初步安排如下图所示:

7. 测试结束准则

以下为业界常用的测试结束准则:

1. 根据特定的测试用例技术来定义准则
   • 规定通过了某些来源的所有测试用例后结束
   • 测试用例生成的质量—覆盖情况很重要
2. 以确切的数量来描述结束测试的条件
   • 需要预测可能的错误总数,错误比例,错误产生和被发现的阶段等
   • 经验数据
3. 通过描绘每单位时间内发现的错误数量曲线,判断当前测试效率.当判断下一阶段测试效率已经很低不值得继续测试时,测试结束.

具体的测试准则选取

• 安装测试:对于安装文档提到的情况,依据安装文档可顺利安装,测试结束
• 导航测试:选择3,深度遍历导航图路径
• 界面测试:选择3
• 内容测试:选择3
• 功能测试:选择1,保证测试用例的覆盖率
• 接口测试:选择1,保证测试用例的覆盖率
• 配置测试:选择1,保证测试用例的覆盖率
• 回归测试:选择1，即在回归测试策略下,执行完相关所有测试用例未发现错误,测试结束

8. 软件缺陷报告

8.1. 概述

在测试过程中发现了软件的缺陷,需要对其记录并正确地报告,并监视其修复的全过程.以下由4个我们采取的报告软件缺陷的基本原则:

1. 尽快报告软件缺陷;
2. 有效的描述软件缺陷;
3. 报告缺陷同时不做评价;
4. 坚持跟踪软件缺陷

8.2. 软件缺陷报告格式

BugID
Bug标题
软件版本		测试环境
测试人员		开发人员
创建时间		Bug状态
测试阶段	接口测试、 集成测试、 系统测试、 验收测试
Bug严重程度	紧急、 严重、 一般、 轻微
问题优先级	高 、 较高 、 一般 、 低
问题来源	测试、升级、其他
问题类型	功能问题、版本问题、遗留问题、新需求、配置错误、性能问题、设计问题、偶发性错误、其他
缺陷的触发条件
操作步骤（简）
实际结果
预期结果
附图	(如果语言不清楚可附图，图过多可附件)

 

9. 风险与问题

1. 小组成员皆是测试新手,并不一定能保证相关测试正确执行
2. 测试人员只有两人且时间有限,测试计划中的测试内容并不一定能完全执行
3. 由于缺乏经验与相关背景知识,可能测试用例设计不但
4. 回归测试难以运行全部测试用例,可能导致测试不完全
5. 各个科目都有大作业,且成员面临找工作的压力,可能导致测试进展缓慢
6. 一些突发情况如局部疫情,包括某些不可抗力也构成风险因素

10. 测试提交产物

11. 附录

11.1. 总结

本次待测系统的名称为”基于格覆盖的布尔表达式可视化系统”.该系统利用布尔表达式来自动化生成测试用例,并且可以将测试用例可视化,显示其在卡诺图中的对应位置.以下为本次软件测试使用到的软件测试技术总结: