测试日常讨论

简介：作为测试人员，日常经常就测试过程和测试经验进行讨论，以下是我和朋友日常聊天时的技术讨论记录，希望能对测试人员更好的理解测试和对日常测试工作有所帮助。

讨论内容
江云：测试还有哪些方面需要复习的么？
志招：基础知识
志招：风险识别
志招：测试左移右移
志招：就是的技巧
志招：要熟练
志招：芜湖
江云：还有测试计划，项目流程，风险管理

江云：(发文件)
江云：这是我之前面试时写得希望对你有用

志招：为什么要用到抓包工具？①从功能角度抓取分析隐藏字段
志招：要什么要分析隐藏字段呀
志招：配置项，白名单这些
志招：是吧
江云：是的
志招：⑤通过抓包工具可以很好的分析和理解整个系统
志招：怎么去分析理解呢
江云：单从页面上很难看出系统的逻辑，而通过抓包工具代理抓取接口和接口数据，能很好的分析接口，能更好的理解整个系统的逻辑关系
志招：可以看到数据链路是吧
江云：嗯嗯

志招：网络七层架构？
志招：答~
江云：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层
志招：我是这样理解的
志招：从服务器，到网线，到网络，开始传输，建立会话，前端展示，用户应用
江云：需求评审是怎么进行的？
志招：由产品经理发起评审，测试提前进行预审，总结需求中疑惑点和分析风险点，测试、开发、产品一起参会，产品讲解需求，过程中大家一起讨论需求的可行性，以及提出解决疑问，最后定稿
志招：我自己写的...
江云：嗯嗯，说得挺好的
志招：u+x 是什么权限呀
志招：不是给777这些嘛
江云：可操作权限
志招：u 代表用户,g代表用户组，o代表其它，a代表所有
江云：嗯嗯
江云：直接给chmod 777最方便了，如果就一个人使用的话
江云：你感觉你写的用例覆盖全面么？或者说如何保证用例覆盖100%？
志招：如果拿到一个比较大的功能需求我会按照一下顺序去写测试用例以及执行
①功能的连通性，即冒烟测试，正常流程是否走得通
②页面元素的检查，即检查页面字段内容、格式、边界值、数据类型、特殊字符、样式、布局等等跟业务没关系的检查，适用于所有系统
③接口测试，通过工具传参看接口是否正常响应，包括输入一些异常的数据，看接口是否有校验
④业务逻辑检查，这个需要充分解读需求文档上的每一句话，逻辑判断控制，以及有耦合关系的模块，前置、后置等相关联的业务模块是否正常，而不是检查当前功能模块没问题就可以了
⑤数据库表检查，即前台提交的表单是否在对于的每一个表单都有正确的写入。例如前台支付成功以后，数据库可能有更多张表，商品表、订单表、统计表、日志表等等，不是支付成功就代表这个功能没问题了
⑥异常类测试，例如系统在弱网或者断网情况下页面是否有提示或相关的判断，或者是一些交易类的功能可能会有回调超时，超时代码是否有重发机制等等，具体要看你测的是什么领域的业务，都有一些特殊的场景或者异常操作，往往这些就是测试的盲点
⑦兼容性测试，即你的系统或者是APP等是否能在不同的浏览器、系统版本、手机、Pad等各种终端都能够正常运行，一般关注主流的即可
⑧性能测试，本次功能根据实际用户体量是否有并发的场景，或者有批量上传、下载、大量查询等，这些可能引起CPU、内存、IO、带宽、数据库等性能问题，这个是需要提前预判的，因为一般性能问题都是大问题，如果用户体量很小，可以暂时忽略
⑨安全性测试，一般使用专业的工具对系统进行扫描，检查系统权限、网络、端口、敏感字、加密信息、配置管理等是否有安全隐患
⑩易用性测试，即开发的产品是否通俗易懂，容易操作，如果你的产品学习成本很高，业务逻辑很复杂，一个大学本科生看了半天都不会用，搞不明白，那么没人用的产品就是最大的Bug
11.回归测试，以上测试都完成之后，bug修复完，需要对系统进行一个全量的测试，至少相关的功能都要去执行一下。
以上就是写测试用例或者是界定测试范围的思路，基本适用于很多场景，当然这样也不能保证100%覆盖，只能说，做到上面几点，基本覆盖的差不多，如果还有bug就是你任职之外的东西了，你想不到所以才有遗漏了

江云：你们测试的准入和准出标准是什么？或者说项目出现什么问题时不能上线？
志招：真别说，这个牛逼
江云：嗯嗯，我们作为最后的把关者，寄托着很多人的希望，这个可不能马虎
志招：准入：开发提测，冒烟测试通过
志招：准出：无严重，一般级bug,建议类bug修复率90%，bug总修复率达到某个标准
江云：如有一般性bug，又急着上线，开发没时间进行修改，你该怎么做？
志招：可根据紧急程度，如果实在紧急，判断是主要功能还是分支功能，主流功能不给上，分支功能先看是否能屏蔽此功能入口，若不能屏蔽，可以判断此功能对用户的影响，对公司产品口碑的影响，决定要不要上线
志招：还有么？上面这问题
江云：答的挺好的，其实有三方确认这么个概念，就公司是大佬的，应该由他来决定。通告测试经理，项目经理，产品经理，经三方讨论决定有该bug,版本是否允许上线。也就是有不能解决的bug时，需经过产品经理(或业务方)、项目经理、测试经理确认，若是讨论后确认可以忽略不改或其它原因要在以后的版本中实现，则本次测试可以认为通过。
志招：6
江云：准出标准有个点需要补充，就是用例执行100%，得把我们的工作干完，别工作还没干完，就允许上线了。哈哈
志招：啊哈

志招：输入框输入html语言会有什么典型的bug嘛？
江云：兼容性问题
江云：前端是html5写的
志招：有些标签会让前端组件展示，数据渲染出错是吧
江云：是的
志招：上线标准补充为：
1.测试用例覆盖率达到95%以上。

2.测试输出结果与预期输出之间的符合率：95%以上。

3.所有发现的BUG都已提交到TAPD并修复：一、二级BUG修复率为100%，三、四级BUG修复率达到95%。

4.本期不修复或者产品确认非BUG的需在TAPD备注（所有遗留问题都有解决方案）。

5.开发和测试有争议的缺陷需要经项目产品经理、项目经理、业务方）确认，若经讨论后确认可以忽略不改或因其他原因要在以后的版本中实现，则本次测试可以认为通过。

6.产品UAT通过。

江云：你是怎么判断bug严重等级？
志招：致命：系统崩溃、重要数据错误、功能设计和需求严重不符、产品无法运行、内存泄漏
志招：严重：模块功能问题、一般数据错误、部分功能未实现
志招：一般：分支功能问题、界面操作错误、提示类错误、边界值错误
志招：建议：产品易用性、界面的美观度、产品说明不明确、界面拼写错误
志招：性能测试在没有性能指标情况下怎么测试，以及注意什么性能参数
江云：业务方面：①事务成功率、②平均TPS每秒事务数、③平均响应时间、④并发数、⑤吞吐量
江云：资源方面：①CPU、②内存、③磁盘、④网络
江云：这些性能参数值指标是多少？
志招：平均TPS指标和平均响应时间要产品和业务需求方参考协商吧
江云：你上面说没有性能指标的
志招：哈哈，那能用就行
江云：业务方面：①事务成功率(大公司达到99.6%，小公司达99%)，②平均TPS指标(业务逻辑和代码决定着TPS指标，可以让开发给你个大概值)③平均响应时间(一个接口的响应时间在1000毫秒以内，PC端混合测试的总接口响应时间在3秒以内，APP端在6秒以内)
江云：资源方面：①CPU、②内存、③磁盘、④网络(字眼指标大公司在80%以内，小公司在85%以内)

志招：平时听说的性能响应时间是指的平均响应时间么？
江云：如果性能需求方没有特殊说明是最大或最小响应时间，那么就是平均响应时间了

志招：安全性测试是什么？用什么工具？如何测试？
江云：安全性测试是严重内部用户或外部用户，在没有授权的情况下，对系统进行数据查看，数据修改，或恶意破坏，系统是如何反应的，是否能有效的阻挡这些攻击。
江云：可以使用APPScan扫描工具，分别在未登录和已登录状态下进行扫描，如无严重，一般的安全性警告，轻微警告未超公司规定指标即可通过
志招：这个还要钱呀
江云：常规扫描不需要费用

江云：对了，你是如何确定并发数的啊？
志招：如何确定
江云：如果是旧接口，就参考过去并发数进行压，如果是新接口就从基准测试上阶梯式的加并发数了
志招：先10-20-30这样压
志招：看能承受多少并发是吧
江云：看是什么类型的性能测试了
江云：压力测试，那就可以死劲加并发，看系统能承受的最大并发(超过这个数，系统就会崩溃，或者TPS下降，或者事务成功率不达标)，如果是负载测试就找最佳并发数
江云：最佳并发数的表现是TPS增速慢，响应时间增速快,最佳并发数和最大并发数也是系统性能的拐点

志招：为什么超过最佳并发后，系统吞吐量和响应时间必然会此消彼长？
江云：最佳并发前，资源可以看成无限的，吞吐量很浮动，不准确;最佳并发后，资源变得有限，一共就要吃那么多馒头(一定数据量)，张大口(吞吐量大)，吃的速度自然快(响应时间少)，小口吃(吞吐量少)，吃的速度自然慢些(响应时间长)
志招：旧接口会不会随着公司用户增长，平均负载已经大于之前的最佳并发了。
江云：这个很有可能，但旧接口的各种数据只是作参考值，这非常有必要，所以有一个测试叫基准测试，做这种测试专门就是为之后的测试做参考的
志招：基准测试怎么做，要得出什么结果
江云：单用户，或者低并发下，进行测试，记录响应时间，tps,hps，吞吐量等业务性能数据。
志招：有什么参考意义，怎么做参考
江云：之后的高并发响应时间、tps、hps、吞吐量都可以参考基准测试的指标，是否存在响应时间极速增加或tps增速缓慢
江云：存在则是达到了最佳并发数了
志招：嗯，有道理
志招：hps是啥，只听说过qps
江云：tps是每秒事务数，hps每秒点击率，qps每秒查询数
江云：如何保证自动化脚本的稳定？
志招：多做异常捕获，pytest中装饰器，设置失败重跑
志招：
1.数据尽量不要写死，固化的数据容易被别人修改，尽量目前的执行单元做到数据的可配置化，做到集中维护，也可以通过依赖其他接口的动态生成，这样避免原来写死的数据失效。
2.降低用例的耦合性，不要过度依赖其他用例集，避免其他用例失败影响后续用例执行。很多自动化测试一跑几小时，出了问题两眼一抹黑，我更提倡大家的用例能够做区分，很清楚这次用例的执行路径，出了问题可以快速锁定。
3.提升环境稳定性，包括自身环境稳定性和第三方系统环境稳定性，对于自身环境的稳定性更多在于构建的规范和周期，用的同学说自己在执行过程中代码就被重新发布了，这明显流程就没有控制了，关于第三方的依赖建议优先使用mock。
4.脚本异常处理，多考虑可能出现的异常，避免脚本报错直接退出。UI的自动化测试元素识别等考虑多配置元素选择方法。
5.持续验证，保持一定的运行频率，比如每日巡检等，避免因长时间未运行和自身脚本成熟度不够高，导致阶段性维护时间过长。
江云：嗯嗯，挺好的，还有不稳定的本质是页面加载不及时导致的，可以设置不完全加载，或者设置等待，显示等待+强制等待会挺好的
江云：Selenium自动化的POM三层架构你有了解么？
志招：第一层，获取元素位置，第二层业务流程，第三层封装用例用pytest管理用例；后加一个run方法，作为功能入口
江云：嗯嗯，挺好的

江云：你是如何把控测试风险的？
志招：首先做好策划和设计的预审，提前识别需求中的风险；用例评审环节需覆盖到这写风险点；提测前确认测试环境稳定；测试过程中如果存在风险及时向项目组上报
江云：你们的测试风险有哪些？
志招：①软件需求不清楚，对产品需求特性理解不准确②需求变更风险③测试人员，开发人员的能动性④测试环境不稳定，和测试数据不准确
志招：3W1H方法制定测试策略：
WHY 深刻理解项目的目标是什么，这决定着我们测试策略的粒度、方法、范围
WHAT 根据PRD，推荐使用Xmind梳理出项目范围和P0级关键模块，做测试范围思维导图。根据测试对象和目的梳理出需要做的测试类型
WHEN 测试阶段的拆分，范围时间的制定
HOW  在测试策略中，推荐梳理P0级关键模块的测试办法和测试全流程（包含上下游系统的检测）
梳理最关键的功能清单P0级别，做重点跟踪，重点管理（核心业务、业务入口、与金钱相关等）
产品、研发、测试三方联动的用例评审，校验用例质量。
高频风险点：
1)软件需求不清楚，开发商对产品需求特性理解不准确。
2) 需求变更风险。
3) 测试人员，开发人员的能动性。
4) 测试环境，和测试数据不准确 
每日站会帮助梳理、上报、解决风险
通过测试人员评估以及测试难题分析，尽早发现风险点并将其影响降到最低

江云：把控测试风险?
①测试左移，测试尽早参与项目，熟悉需求文档。
②写测试方案，规划好测试目标。
③有第三方依赖时，及时联系相关人员，保证测试时第三方稳定。
④让熟悉该项目的测试人员进行测试，能提高测试质量，降低测试风险。
⑤测试排期时，测试排期要充足，要加预留时间，若发生意外也能从容处理
⑥经常和开发保持沟通，有问题时及时联系相关方沟通。每天提交测试日报，每周提交测试周报。
⑦下班学习专业测试知识，从多角度进行测试，提高测试覆盖度。
江云：我的拙见
志招：大拇指

江云：你的测试方案具体包含了哪些内容？你最关注的是哪些内容？
志招：包括：项目北京，项目介绍，项目需求点，人员分工，测试范围，测试进度计划，参考文档，风险分析，测试策略等几部分。

志招：你说的方案策略还是计划？
江云：是计划，测试方案和测试计划内容差不多，不过测试方案是测试小组长写的，测试计划是测试经理写的

江云：你们一般版本的测试策略有哪些？
志招：页面测试，功能测试，接口测试，性能测试，安全性测试，兼容性测试，用户体验测试，合规测试，数据测试

江云：数据测试你们是怎么做的啊？
志招：页面新增，编辑后对比数据入库是否正常，按钮中新增埋点的查看埋点数据是否正确。如果存在主从数据库，查看数据同步。
江云：嗯嗯

江云：你是怎么做接口测试的呢？
志招：~
江云：可以从入参方面、出参方面、落库方面、响应时间上、安全性上、异常场景上、兼容性上等等
入参方面：
①参数类型校验
②参数必填值校验
③参数枚举值校验
④参数长度校验
⑤参数类型校验
⑥默认值处理
出参方面：
①返回校验码校验
②必定返回字段校验
③返回字段类型校验
④返回字段长度校验
⑤必定返回字段校验
数据读写方面：
①校验mysql数据库落库正常
②校验缓存数据和DB数据一致
多数据量方面：
①单条数据的处理及时性及正确性
②多条数据的处理时效性和正确性
安全性方面：
①上送字段的加密处理
②下送字段的加密处理
③日志信息的加密处理
④存储信息的加密处理
⑤前端交互的加密处理
⑥逻辑身份校验
⑦cookie、token等的校验（使用多个浏览器）
⑧SQL注入（C端产品需要关注）
特殊场景方面：
①幂等性校验
②接口的异常校验(网络，高负载)
③事务一致性校验
④新老接口兼容(处理逻辑兼容，数据兼容)

志招：数据库常用的引擎有哪些？
江云：InnoDB、MYISAM。我们这边是开发来决定用哪个引擎，我们自动化的数据是使用的InnoDB
志招：InnoDB功能非常丰富，MYISAM没有事务处理功能，MEMORY放在内存里面的，稳定性不好，但是快。

江云：python中你用到了哪些模块，这些模块主要解决了哪些问题？
志招：ui自动化：selenium用来对浏览器进行操作，yaml模块用来做配置化，json模块用来做参数化，re模块，jsonpath模块自动化测试中用来匹配参数，logging模块用来打印对步骤打印日志，做错误分析，pytest用来对测试用例进行管理，allure模块用来美化生成的测试报告
志招：还有哪些模块嘛？
江云：os模块，可以对文件和目录进行操作，random生成随机数，md5模块可以对文件和数据进行md5加密，ddt模块可以进行数据驱动，xlwt操作Excel，time模块获取当前时间，requests模块发送get和post请求，urllib模块发送http请求，Flask模块进行mock测试等等
志招：嗯嗯，这个适用于接口自动化

志招：requests已经可以发送http请求了，为什么还要urllib?
江云：urllib它是比较老的东西，它没requests好用，但是有时候使用requests无法完成你的任务时，可以考虑用urllib作为备选方案
江云：我之前做过一个自动化项目，从文件存储系统上下载文件到本地，然后和其它文件夹的文件进行对比，其中下载时使用requests无法下载，但是使用urllib就行。
志招：嗯嗯

江云：你在做测试时遇到的最大困难是什么？是如何解决的？
志招：产品喜欢把东西分得很细，然后每个细的内容都列了一个版本，使我们测试每天几个版本并排的测，导致手忙脚乱，当时我就把这个问题上报上去，给他们提出了小版本并入一个大版本进行测试的建议，得到了项目组的认可和采纳，避免做很多没必要的重复的事，便于测试的管理，提高了测试的质量。
志招：你呢？
江云：从我做测试以来遇到的最大的困难是测试技术的提升，从一个初出茅庐的菜鸟，经过四年的不断摸爬滚打，遇到事时不断的查阅资料，不断的虚心请教别人，事后不断的总结经验，一步一个脚印，走到今天，学习了很多，也深知测试技术的不易，经理了各种磨难后也更加坚定了要继续走测试的道路，坚信自己能在测试行业做出一番事业来。
志招：笑脸

江云：你们平时的测试方法有哪些？
志招：界面测试，功能测试，自动化测试，接口测试，性能测试，兼容性测试，可用性测试，易用性测试，安全性测试，数据库测试，文档测试等等
江云：嗯嗯，666

本篇测试日常聊天篇结束，欢迎到我主页查看其它技术类文章~~