https://docs.tenable.com/nessus/Content/GettingStarted.htm
官方文档里搜 token

bug 定性，就是缺陷类型。
分的维度：
1 业务维度
业务维度带来的缺陷类型可能有，业务功能，业务流程，
2 技术实现维度
可能有 前端问题 接口问题，服务问题，数据库问题 这是大类 可以把各个大类 比如前端问题再细化。比如前端 界面样式问题，前端脚本问题等等等等

自己根据实际统计缺陷的需求 或公司实际项目情况酌情增减， 多了没好处，少了统计不细。

分层看数据流。夹板思路看数据流。
前端 提交表单 是一种对 server 的输入 展示查询页面是对前端的一种输出。角度不同，输入输出是会互换的。

接口层面 就是提交的入参 是输入，它的输出，最近的输出就是接口的返回，较远的输出可以是落地的数据。这种就是广义的输出数据流。狭义一点的，就是 DB 里的一些不面向业务处理的字段 或接口里不面向业务处理的参数，这些是非业务处理的，一般我们较多关注业务处理的参数或 DB 字段，那么狭义的就是 哪些隐性参数 或 落地字段 是面向技术处理的判断字段。

另一种，就是 接口承载的 server 对象的，服务处理 log ,可以认为是接口的一种输出，因为它体现接口服务的内部处理逻辑，和技术处理异常。 可以当做接口的输出来做检查。

所以，不同夹板线下，的输入 输出 是可大 可小 可远 可近的，看你具体测试点 是关注前端交互 还是接口 还是服务处理逻辑 还是落地数据。 当然 全部大夹板的话，一个提交表单的输入 就是你提交的表单内容，输出可以是接口的返回，输出可以是 server 的 log ，可以是落地的 DB。按从前端 server DB 把处理串联起来来看的话，就是这些。

分层 分类写。聚焦点要原子性。
一 业务维度 就是经典的我图里的三层 纯按黑盒用例设计方法的一种分层思路。
二 技术实现维度 就是任何业务系统，实际都是三层，前端 服务 数据库

这种可以拿 testlink 或支持分类树写的都可以写成。 但不必拘泥于此。
实际建议 tesklink 的写清整理好，各层的业务规则，技术处理规则就好，实际按上面写，挺复杂的，如果思路分不清 摘不清 放不明白地方的话，你也写不好，这是时间淬炼下的功力，体验领会精髓，再慢慢写，慢慢改进吧，最终才会锻炼出很清晰的分层原则的。

实际，建议拿 xmind 脑图写，也能达到分层 分类 还能体现业务时序 或 服务处理时序 数据流时序 上的，而且比较直观 各层 title 命名好，每小节 也能很清晰的体现该层的测试目的，业务技术规则 时序 各层的要求。

看公司的接口测试是前置执行，有专一独立接口测试人员从接口开发完毕就介入第一轮接口测试，产生第一轮基线脚本。
然后前端开发联调结束后，第二轮接口脚本修正。然后业务手工测试人员介入进行全面的系统业务测试，这期间在和手工业务测试人员和接口开发接洽，第三轮接口脚本修正。
这是我个人设计的比较好的，全周期专人接口测试模式，最终接口脚本框架，是有原子性的基线脚本。和一定场景度的场景脚本两大模式。同时如果公司手工业务测试人员推广的好，有一定接口脚本自组装能力，可以用专人接口人员的接口脚本进行自我业务的复杂接口场景的场景化脚本组装。这样就打通了 纯接口脚本人员和业务测试的边界，更好的把握纯接口问题和业务方面的接口上的业务实现规则问题。

还是接口测试，如果不是上边的模式，就比较难办，会带来许多风险。
比如这个专业或不专职的接口测试，是完全滞后的在业务系统测试完，才独立去理解业务理解服务接口，整了一套。可能这种就是纯接口测试，完全相信手工业务测试是没问题或少量问题的。这样就比较麻烦，因为手工系统业务测试，又取决于这个手工业务测试人员的能力和测试水平能否完全测全服务端的接口问题，就比如数据的落地校验，是否在手工业务测试做了强检查强校验，完全熟知页面 -- 服务接口 -- 数据库表字段 的变化。这个各个公司的业务测试要求又不尽相同，笔者面试过程发现，许多无论是外包还是独立产品独立项目的公司，那真是千差万别，手工业务测试的套路和系统性规则性都完全不一致，外包好的给你数据库堡垒机去查，有的测试完全不熟悉业务表结构关联和字段与服务接口 前端界面的对应关系，可能只是依靠管理后台类的工具去验证前端的数据表单提交类接口。好点的独立产品项目型公司，就给足权限，自己反映射生成表拓扑结构图，各类数据表权限都给足。且该公司测试经理，有强要求关注 界面 接口 库的三者字段一致性。这种后期开展第一模式的接口测试就比较好。

所以这是一个，公司测试流程和对接口测试理解的一个流程性问题，阶段性问题，如果是第一模式，就可避免许多接口测试上的理解偏差。

第一模式下，业务手工测试 做到了 前端界面 服务接口 数据库表字段的强认证 关注，强校验，也可以后期第二轮 第三轮测试阶段中，和专职的接口人员沟通交流，来确保落地数据库验证的。
如果你非要做到剥离数据库验证，那么请先保证你们公司的业务手工系统测试人员，可以和你友好的交流 三端数据验证问题，和他确实保证所有业务的落地数据 提交类 查询类 都和数据库表关联查询验证过，完全熟知各种有服务接口交互的表查询。并可和接口专职人员指导交流和沟通。但实际上，很多公司是第二模式，没办法做到业务手工测试后的质量，这时候又是个只做专职接口的，可能就只是做做接口返回认证，但这是有风险的，接口是会欺骗你的，操作错相似表或字段的。

所以，我的建议是 如果是第一接口测试流程模式 且手工业务测试人员可以和服务接口人员一起参与接口测试的，可能越前期是需要数据库认证的，磨合好了后，接口的数据验证可以依赖接口返回验证了，再想办法剥离数据库验证。
如果，是第二接口测试流程的，比较麻烦，如果接口测试人员 对接口场景和业务更敏感，建议带上数据库验证，然后推广第一种测试流程。

@tester-yu
Puppeteer 了解一下。google 亲儿子。

大体上 只要是 符合 或者你能分为三层架构的系统 前端 服务 数据 都可以分层写。
针对不同测试层 比如 前端 我图上也列了 你的前端的测试对象 如果是重点测试业务流转组合 那实体物理对象 就是 页面 各个功能性页面 或弹窗 都可以 比如 注册页 登录页 支付页 或 登录弹窗 他们会形成业务流组合 你就把 这些物理页面对象 设计个流程组合即可。比如 今天还没有登录弹窗 后天加两个登录弹窗 只需要在 业务流测试层 加个登录弹窗的组合流程 覆盖到相关业务流组合。

具体的操作交互层，就写到单独一层，这一层主要是放，或模拟客户前端操作行为对页面控件带来的组合，主要是测前端 Js 实现的问题。 比如 注册页面 那么多输入项 和 输出项的组合操作逻辑 就用因果判断 进行组合就可以了，具体的物理对象 是各个页面控件 但不涉及具体控件的输入内容，具体的输入内容 是放在 数据层的。 这一层主要是放 操作模拟组合。 比如操作序列，什么都不填，直接提交表单，看页面 js 和服务接口是如何控制的。

最后 就是 等价边界 注册页面的具体输入内容。 这一层就是放 我们测试最熟悉的 等价边界值 那些个东西。

这样就拆开和低耦合了啊，每一层的 测试内容不同 测试对象属性不同 就决定了这一层是可以单独设计和维护的了呗。

1 点 线 面 的理解还算可以吧。 就是让你分的清 当前的测试对象 当前的测试层次 当前自己在测什么 可以测出什么问题。
测试对象的属性 决定了测试的类型 决定了可以测出的缺陷类型。 好比我举例的 由上往下 业务场景层（对象是页面）

操作交互层（对象是页面控件 各种元素） 数据出入层（对象是 具备输入性质的各种数据 可以是页面的 可以是接口的 也可以是数据库的）

场景层 有场景层的 业务组合问题 页面控制流转问题

操作交互层 有控件 和元素 之间的各种前端 JS 脚本控制业务逻辑 交互逻辑 业务规则的限制问题
数据出入层 有具体的问题 但要看数据是哪一层的数据 产生了什么交互 比如前端的 JS 校验 规则控制问题 这些都是纯前端的 js 问题。 到接口了 提交前端表单了 有接口的输入限制问题 和服务校验返回控制问题 到数据库了 有数据落地的正确啊 位数啊等等问题。

就是让你建立起 分类 分层 有层次 有系统性理解 测试。 当前我是测业务组合 还是测前端交互 还是测接口 还是测落地数据。
要分的清，拎得清。 不要混为一谈，要对这个数据的整个处理流转的细节梳理清楚，前端干啥了 服务接口干啥了 落地数据干啥了，分层次 分流程 分门别类的 去检查各自的 ” 输出” 输出就是检查上一个节点输入正确的 “预期结果” 分层的测完一整套 每一层的输入 输出 很明确。 用例写的也会有层次感 ，好摘的开，以后也好维护。 比如 你判断准确了 就是前端 Js 没做输入规则业务规则控制，那么在用例的 前端输入 这一块 你只需要改这一块就行了，如果发现是，构造绕过接口了，接口的输出 落地数据产生了非法数据，那么就是接口层没对前端提交的数据做出一些校验，这个问题在用例维护里只需要改 接口输入 这一块 就够了。

这种 业务思维 加 技术实现分层思维 不断的找类 找层次 找输入输出的思维 你要不断加强 强化 然后就会越做越顺，看问题就越会有努力的方向，问题类型缺陷类型就会越定位越准确，直接找到解决的开发角色。提高缺陷解决效率。 这个前提就是用例设计的好坏来决定的。

2 减少组合 具体思维 你可以参考 判定表因果图法 相关的理论讲解里的 如何去掉重复的 列 的方法，有具体业务规则 可以去掉，
具体的逻辑规则限制，可以去掉，和其他许多 技术限制 比如数据类型 大小限制 导致一些数据根本不可能产生。 就这样去掉。
或者 你看 图例 用例设计参考文件里的 业务需求 和技术实现 里有什么 可以去重的条件拿来去掉重复。

3 好的用例 就是 我图里 列的 “满足特性” 你写的用例 具备了这些特性 就基本上 合格了、

老用户之一，当初我也挺活跃，现在主要是照顾家庭和在准备转行的事情……
Me too 了 。哈哈，一起一起。 我还鼓捣过你的 github 项目。

@Fhaohaizi 你搬家呢？
还是 下来了 有时间创作了