如何做功能测试的：

功能测试基本流程：

1、对于一个新项目来说的话，熟悉需求，整理需求文档中有疑惑的点；

2、在需求评审时，与开发、产品三方达成一致；

3、根据需求编写测试计划与方案，以便后期有效的开展测试工作；

4、用Xmind梳理核心业务、核心功能，编写测试点；

5、根据测试点进行用例编写以及用例评审，以便测试执行中出现遗漏或者不全面的问题；

6、然后执行测试用例，提交缺陷，跟踪bug并验证，直到bug关闭；

7、最后，经过多轮迭代执行，完成所有测试后编写测试报告，对项目进行总结。

 

接下来我以投资模块为例，

首先，从功能方面来说，包含两方面

测试单个功能模块的测试点，主要从正向反向的维度进行测试。正向的话，输入符合要求的金额，投资成功；对于新手投资者输入符合要求的金额，投资成功。反向的话，投资失败，例如：输入金额小于最低投资金额、输入金额大于最高投资金额、输入金额大于账户余额、输入金额大于可投金额、输入金额大于新手投资的最高投资上限、选择已满标的标的投资、进入时未满标-但已被投满-输入金额投资失败、投资超过限制次数的标的-输入金额-投资失败；输入不符合格式的内容，投资失败。

测试业务流程，例如： 投资已满标的标的-投资失败；投资已进入封存状态的标的-投资失败；未满标提前进入封存状态-投资失败；正常满标后管理员审核不通过-投资失败；未做风险评估-投资失败；未充值金额-投资失败；

 

• 为了保证产品质量的全面性，需要考虑非功能测试，可以从质量模型思路出发，

兼容性：（用的用例的话是业务流程用例，在浏览器上进行冒烟测试，保证基本流程走通即可）：

浏览器兼容性，包含两方面，不同的市场占有率的浏览器（chrome、firefox、IE）等，其次，对同一种浏览器的不同版本也要测试；

操作系统：window系统window7、window10、包括新出的window11；mac也有不同的版本都需要测试；

分辨率：测试笔记本电脑常见分辨率、台式机电脑常见分辨率（常见的1920*1080）

注意：怎么看浏览器占用率高，很多浏览器可以在百度流量研究院全网站看浏览器的市场占用份额。

界面性：

主要是看界面是否合理、整体风格是否一致、控件放置的位置是否符合用户习惯。再看是否与开发设计的界面一致，主要测试业务流程即可。可以在不同的终端或者电脑上打开看界面的布局、颜色、风格大概一致即可。

易用性：

简单的来说就是用户体验，易学、易懂、吸引人，要关注使用人群，必须在一定用户群以及计算机水平的基础上用户使用软件是否感觉方便。可以考虑与同类产品的对比作为依据。例如投资的步骤不会太多，会有明确的操作提示。

可靠性：可以反复多次使用不会出现异常，能长时间无故障运行。

安全性：公司会有专门的安全类测试人员参与测试，主要看传输数据的安全和存储数据的安全。

性能：用jmeter模拟正常、异常的各项指标测试，主要是验证稳定性，在一定时间内，评估系统的稳定性是否可以满足要求。例如：5万用户同时对同一个标的进行投资，要求响应时间不超过3s。

 

穿插问题：

你会写测试计划与方案么？

答：会。测试计划是一个测试过程中的一个文档，描述了要进行的测试活动的范围、方法、资源与进度。核心内容包括：测试目标与测试范围、执行计划的角色和职责、

\任务的进度安排和资源分配、风险评估与应急计划、测试的准入转出标准。测试方案也是一个文档，主要是从技术的角度去分析需求，在方向上明确怎么测，分析重点在策略与技术的实现。核心内容包括测试策略、测试环境的规划、测试工具的设计与选择。

 

测试设计中如何避免测试遗漏？

答：首先与需求对比确认，进行覆盖需求；第二，与产品、开发、其他测试人员进行用例评审；第三，以用户使用场景的测试点进行完善（主要看测试的经验）。

 

测试用例编写后是不是就不能修改？

答：不是，是可以修改的。在项目过程中产品功能发生变更时，需要更改用例；在执行过程中，有新的测试场景补充。

怎么定位前后端bug？举例说？

答：投资，投资后在投资列表中未看到投资的记录。

首先，查看数据库信息，数据库是否有新增投资记录。

如果数据库有新增投资记录，对查看投资列表的请求进行抓包，首先查看请求的参数，如果请求参数有问题，说明是前端的问题；如果请求参数没有问题，查看响应，如果响应有问题，则是后端的问题；如果响应没有问题，则是前端显示问题。

如果数据库没有新增投资记录，则对投资的请求进行抓包，首先查看请求的参数，如果请求参数有问题，说明是前端的问题；如果请求没有问题，查看响应，如果响应有问题，则是后端的问题，如果响应没有问题，可能就是写入数据时出现问题。

当确定是后端问题是，可以进一步抓取日志，来检查出现问题的操作和对应的数据，协助开发更快的定位问题。

 

你提交bug开发不认为是bug如何处理？

答：首先要与开发沟通，确定范围是需求理解问题还是环境问题的原因。如果是需求相关的问题，就与产品一起讨论确定是否是bug；如果是环境问题，需要和开发进行沟通寻找差异点，确定问题，最终确定是否是最终bug；第四，我们通过bug判定的五条标准，确认是否是bug。（bug判定的五条标准：软件未实现需求(规格)说明书中明确要求的功能 –少功能 ；软件出现了需求(规格)说明书中指明不应该出现的错误 –功能错误；软件实现的功能超出需求(规格)说明书指明的范围 –多功能；软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –隐性功能错误；软件难以理解，不易使用，运行缓慢，用户体验不好 –不易使用）

 

不可复现的bug如何处理？

答：首先确定bug严重级，然后由内到外分析：第一，从内部出发，回想bug第一出现时与复现时的场景是否有差异（时间、环境），操作过程步骤等；如果还是不行，就向测试老员工寻求帮助；

第二，求助外援，与开发沟通联调，协助定位；开发打印调试日志，再次复现；

第三，如果多次跟踪bug还未复现，与开发、产品沟通后，确认bug放弃即可；如果复现成功，确定提交bug，进行跟踪验证。

 

Web的Fiddler抓包？（Fiddler）

答：

设置过滤：

模拟弱网：

打断点：

该项目的资源配比？

答：

项目周期：

web项目：新项目是6个月左右（可以分为多个迭代完成），发布一个可用版本；进行中的项目一般是两周左右迭代一次，即也会发布新的可用版本；

App项目：项目周期在4个月左右

开发测试比例：1:5左右

 

项目用例数量：

Web项目：tpshop级别项目测试用例是5000条左右，个人负责模块的1500条左右（）

App项目：tpshop级别的app用例约700条左右（个人负责350条左右）

 

Bug数量：用例和bug的数量大概是6:1左右

 

 

系统测试用例什么时候开始执行？执行几轮？

答：前后端写好，开发提测，冒烟测试通过后开始执行

系统用例执行一般有多轮：

第一轮：执行所有的测试用例，100%

第二轮：挑选重点的用例进行执行（根据bug挑选 优先级高的/模块bug多的/用例类型……）

——————————————————

可选

第三轮：交叉测试

正常分工：A负责模块1、2，B负责模块3、4

交叉测试：A负责模块3、4，B负责模块1、2

交叉测试过程中不是根据用例来执行，而是进行探索性测试

第四轮：上线前回归测试（冒烟用例执行一遍，保证基本功能可用）

第五轮：上线后跑下业务流程

测试环境如何搭建？

答：针对我这个投资理财的项目来说的话，刚开始安装时，需要申请服务器，公司的服务器是在云服务器的搭建的。

首先申请到服务器的话，我需要先检验网络是否与本地网络是否是通的，因为部署环境安装包可以问开发要，因此不需要外网连接，这时还需要查看apache（2.4）和mysql（5.7）的版本是否正确，然后将mysql服务器与apache服务器安装好。其次，将对应的项目文件包（java编写），在指定位置解压。

新部署的环境是空的，需要数据库初始文件，将文件导入（mysql中用source命令）。

因为我们服务器有默认的配置文件，需要告诉服务器项目代码的位置以及访问方式，就需要修改配置文件，修改保证能够通过特定域名访问，修改完成后，重启服务生效，在网页上可以进行域名访问即可。

在后期版本迭代过程中，若是有新的项目文件包上传到服务器解压；涉及到数据库表的表结构修改，可通过开发提供的sql语句，重新执行，修改表结构即可；若是域名或者工作目录发生改变，则需要修改配置文件，最后将服务重启生效即可。