软件测试-手工测试

项目测试流程

搭建测试环境(重点)

快速的熟悉项目

编写测试计划

编写测试方案

设计、编写、执行测试用例(重点)

生成测试报告

W模型（双V模型）

搭建测试环境

环境

PHPEnv

phpEnv-专业优雅强大的php集成环境

项目

商城源码免费下载-iWebShop (aircheng.com)

安装

访问

http://www.web.com/

• 勾选我同意，点击下一步

• 按照下图填写

 

快速熟悉项目

1、了解项目架构

C/S架构

C/S 代表的是客户端/服务器（client/server），这类软件的使用者需要在本地电脑安装客户端程序，例如：QQ。

• 优点:安全性高。

• 缺点:一旦软件有更新，用户需要手动下载，较为不便。而且在没有安装客户端的电脑上，用户无法使用系统。

B/S架构

B/S 代表的是浏览器/服务器(broswer/server)，是一种通过浏览器访问服务器端数据的软件形式,例如：天猫、jd等。

• 优点:用户不用在本地安装软件，只要有一个浏览器即可使用产品，而且用户不用关心软件的升级更新等问题。

• 缺点：安全性低。

2、项目调研

可以用调查表的形式来展示：

注意: 调查表自己留着即可(可以不写)

项目组织架构图反映的是一个项目组织系统中各子系统之间和各元素之间的组织关系，反映的是各个模块以及各个模块下面的子模块，子模块下面的子模块之间的组织关系。

• 价值：对项目有一个全局的认识

4、测试范围列表

需求名称(编号) 功能 测试类型 PATH(路径) 优先级

• 价值：保证测试用例不遗漏

测试计划和测试方案

测试计划

1 测试计划的定义

  所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、测试任务、谁执行任务和风险控制等。 测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。

2 测试计划主要内容

  进行测试任务划分；进行测试工作量估计；人力资源分配；明确任务的时间和进度安排；风险估计和应急计划；测试失败/通过的标准。

3 测试计划的编写目的

制定测试计划目的：按照所制定的测试计划可以有效的计划、执行、跟踪、组织和管理测试项目。

具体从以下三方面来说：

• 领导能够根据测试计划做宏观调控，进行相应资源配置等；
• 测试人员能够了解整个项目测试情况及项目测试不同阶段所要进行的工作等；
• 便于其他人员了解测试人员的工作内容，进行相关配合工作。

测试方案

1 测试方案的定义

  所谓测试方案是指描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。 测试方案是技术层面的文档，从技术的角度对一次测试活动进行规划工具的设计、测试用例的设计、测试数据的设计。

2 测试方案主要内容

测试策略选取；测试子项细分；测试用例的规划；测试环境的规划；自动化测试框架的设计；测试工具的设计和选择。

3 测试方案的编写目的

设计测试方案目的：软件测试方案的作用非常类似于产品设计说明书（软件概要设计和软件详细设计），开发工程师根据产品功能需求和设计说明来编码实现功能，而测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例。

测试方案是从测试的角度去分析或者说分解需求，在方向上明确要怎么测，分析结果就是测试点和测试方法。

	测试计划	测试方案
组织方式	组织文件	技术文件
目的	强调做什么	强调怎么做
具体要求	组织架构、工作任务分配、工作量估计、人力资源分配、风险的估计和规避、各任务通过准则等。	测试需求的细化、自动化测试框架的设计、测试数据和测试脚本的设计、测试用例的设计原则等。

测试计划和测试方案内容重合度很高，中小型公司普遍只编写其中一种。具体参见课程资料《iwebshop测试方案》及《iwebshop测试计划》。

UI测试

页面初始化数据验证

UI考虑的点

• 跟原型图进行比对
• 用户的使用习惯
• 界面整体测试
• 页面内容等

页面初始化数据的正确性验证

以iwebshop前台首页为例，步骤：

1 先查看首页页面内容（按照一定规律排列）

2 去后台找到各模块相应的数据库中表是（后台-工具-数据库备份查找相应的表，然后使用navicate连接数据库进行验证）

用例及缺陷

3 去编写SQL语句和测试用例

4 执行用例并缺陷报告

独立功能点测试

独立的功能点

什么是独立功能点？

能够完成一个独立的功能

举例：登录、注册

思路

在黑盒测试中，我们关注输入与输出之间的对应关系

黑盒测试又叫功能测试，也叫数据驱动测试。

案例: 前台注册功能

• 可能的输入：邮箱、用户名、密码、确认密码、验证码

• 可能的操作：点击提交

• 可能的输出：注册成功、注册失败

1 独立功能分析

输入

• 可见的输入：页面上直接能看见的

• 不可见输入：自动加入的一些数据

处理

• 正常处理

正确数据+正确的操作

• 异常处理

正确的数据+不正确操作

不正确的数据+不正确的操作

不正确的数据+正确的操作

正确数据+正确的操作+不正确的环境

输出

• 可见输出

页面跳转

相应数据的变化

成功提示

• 不可见输出

对数据库的一些影响

2 构造测试数据

思路

• 有效规则--->有效数据

• 无效规则--->无效数据

• 根据分析及数据设计测试用例

• 重点关注非法数据和非法操作

3 执行用例并提交缺陷报告

注意

实际工作中，整体用例设计完毕，经过评审以后才会执行用例

执行用例时发现缺陷要及时记录提交

 业务场景测试

什么是业务场景？

多个功能间组和就构成了业务场景

注册-登录-搜索-下订单这样的流程就是一个业务场景。

为什么做业务场景测试？

从客户角度

用户不可能只使用某一个功能，所以要模拟实际用户的操作。

从测试人员自身

每个测试人员只测试某一个或某几个功能模块，功能模块之间的组合并没有考虑到。

 1 从用户角度设计测试用例

从用户常用功能的业务组和 测试---模拟用户行为

步骤

确定项目中角色（iwebshop为例）；
根据用户角色罗列常用功能；
根据功能点组合成常见的业务场景（每个功能至少使用一次）；
编写测试用例：一条业务场景就是一条测试用例。

适用情况：功能比较多，测试时间短，项目周期比较紧急

2 从项目本身角度设计测试用例

步骤

确定项目中功能个数；(举例：ATM机---登录、取款、存款、转账、查询、修改密码、退出)
形成N*N的矩阵；
确定功能间的可达性（可达（一步可达）√、不可达×）；
根据可达性画广度图和深度图。
编写测试用例：每一条从开始到结束的路径就是一条测试用例。

适用范围：测试周期较长的项目

3 广度图

步骤

任意选取一个功能点作为开始点；
画出该功能所有可达功能；
从左至右依次画出每个功能的可达功能；(注意：每个功能的可达功能画一次即可)
其他的功能和画过的功能直接结束即可。

画图时注意事项：

开始标记--->流程图开始符号
流程标记---->矩形框
结束标记---->流程图终止符号
对内容进行说明--->流程图文档

4 深度图

画深度图的步骤：

任意选取一个功能点作为开始点；
画出该功能的所有可达功能；
逐层从最左侧开始依次向下画；（注意：每个功能的可达功能画一次即可）
其他的功能和画过的功能直接结束即可。

 例：ATM机深度图

 

 非功能测试

功能测试涉及了软件在功能上正反两面的测试，而非功能测试就是所有其他方面的测试，包括 效率性、可靠性、可移植性、可用性……

1 效率性

什么时候考虑？

用户量大、业务多的项目

关注点

访问项目时的时间，即浏览器发送一个请求到服务器，从服务器获取数据并解析显示完整的页面所耗费的时间。

2 可靠性

软件使用者期望软件能够无误运行。可靠性是度量软件如何在主流情形和非预期情形下维持它的功能，有时也包括软件出错时的自恢复能力。

什么时候考虑？

与人身、财产安全相关的---金融、保险、医疗系统

关注点

安全性：登录时密码是否进行加密以及密码是否容易破解

3 可移植性

可移植性指一种计算机上的软件转置到其它计算机上的能力。

什么时候考虑？

项目要求在不同的操作系统、不同浏览器、不同的平台下操作时

关注点

不同的操作系统

Windows、Linux、mac、Android、ios 相同的操作系统不同的版本 win7、win8、win10

不同的浏览器

三大主流: IE、Chrome、Firefox

相同的浏览器不同的版本: IE8、IE9、IE11

其他常用的浏览器，如：搜狗、360 注意不同的版本：高速模式（Chrome）、兼容模式(IE)

不同的网络

Wifi、有线、2G、3G、4G、5G

不同的设备

ipad/kindle

4 可用性和易用性

• 易用性测试

易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。

• 可用性测试

让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察、聆听、做记录。

关注点

项目难易程度

适用人群

用户的计算机水平

注意

易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用

５易维护性

易维护性指维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。

接口测试和fiddler

1 接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

简单理解

接口测试就是验证入参和对应出参信息是否满足或符合要求。 接口测试主要检查接口返回的接口数据是否正确、是否和接口文档中定义的一致。

接口测试步骤

1. 获取接口地址(根据接口文档/根据抓包工具抓取)
2. 分析接口请求数据(入参、处理、出参）
3. 构造接口数据
4. 编写测试用例
5. 根据工具或者代码执行接口，比对结果即可

1.1 常见的接口

接口是指外部系统与系统之间以及内部各子系统之间的交互点。

程序内部接口

功能和功能之间、模块和模块之间

登录和发帖、登录下订单

用户界面

系统外部接口

第三方登录

QQ登录、微信登录、手机号登录

第三方支付

支付宝支付、微信支付、银行卡支付

1.2　接口的组成

接口地址可以通过接口文档获得，也可通过抓包工具获得。 以微信公众平台API接口文档为例

 2 Fiddler

2.1 Fiddler的安装

基于Miscrosoft .Net Framework软件，必须先安装，一路下一步即可

Fiddler安装一路下一步即可

2.2 fiddler基本应用

2.2.1 设置过滤

Filters菜单--->勾选Use Filters

在第二个下拉框中选择Show only the following Hosts--->只显示以下地址的请求和响应数据

Actions--->Run Filterset Now立即执行

2.2.2查看请求和响应数据 

判断GET请求和POST请求

【<>】符号的为GET请求

绿色向右的小箭头为POST请求

选中请求，右侧Inspectors

• 请求

在Headers和Raw中可以查看请求行和请求头部信息

在Textview或者WebForms中查看请求实体数据

• 响应

在下面的Headers/Raw中查看响应行和响应头部信

在下面的Textview中查看响应实体部分数据

2.3 fiddler修改接口请求数据

原理：越过界面验证，测试服务器端

举例：会员添加功能中手机号的正确性验证

在Fiddler中做过滤（断点） 点击【会员添加】按钮---->并填写相应参数 点击【确定】按钮 选中拦截的请求（红色的T） 选择Inspectors--->找到请求要发送的数据--->对其进行修改 重新发送接口请求：Run to Completion 关闭断点：Disabled

2.3.1 过滤数据

选择 Fiddler 菜单中 Rules--->Automatic Breakpoints--->Before Requests，设置断点，也可以使用快捷键 F11；

如果底部显示一个红色标识，证明设置断点成功了

修改数据并发送

2.4 Composer的应用

可以通过Composer模拟发送接口请求和数据，不用特意先拦截下来再去修改数据

点击右侧Composer--->Options--->Tear off 让它单独显示

 

点击Parsed，可以手动输入，也可把我们抓到的包拖动到Composer中，进行相应的修改；

点击【Execute】发送请求。

编写测试报告

  测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

  测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力。

  一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

主要内容

测试概要（测试方法、范围、环境、工具）
测试结果与缺陷分析（功能、非功能）
测试结论与建议（测试结论、改进建议）

意义

对于测试的意义

总结测试阶段发现的问题，提交给测试经理，审核项目是否可以发行
形成一份可以参考的材料（依据）
对于整个测试过程或设计方法的一些建议（也就是需要改进的地方）
测试结束的一个标志

对于整个项目及团队的意义

把关
预防
报告
改进