哈哈，发现高飞兄每次发言必定谈及 k8s

接口测试工具可以试用一下国产的接口测试和接口文档生产工具 apipost：https://www.apipost.cn/?dt=2020

“比如，有时候有些场景自己总是想不到，到了线上出问题了才发现”
对于这一点，我建议可以多复盘整理。
个人的习惯是会整理这些内容：代码层面出现该问题的原因（了解下合作开发代码上的问题，在其他需求里多多注意）、为什么测试的时候没有发现 (是本来就没覆盖到还是其他修改引入)、未覆盖到的根本原因 (这儿主要是分析下写用例时的想法，点解我会没测到啊!)、后续的改进措施（主要是用例编写层面的改进&接入脚本避免重复踩坑）

就喜欢看评论 学到啦 归功于楼主抛出的好问题 还有各抒己见的诸位大佬

是的，
很感谢，茅塞顿开

也有过一家公司只有我一个测试的经历。给出的建议是：
1、多用脑图，梳理业务的主次场景，基本要做到每次新增、更新业务功能都知道是哪些业务枝干受到影响；
2、需求要做需求分析、测试分析，这里缺少不了和业务、产品、开发沟通；需要和他们确认好测试范围和相应文档落地，方便追溯总结复盘。
3、提高逻辑能力，扩大技术视野。有很多问题不是只看需求的呈现结果，也需要理解逻辑的技术实现。“表面没有问题，不代表实际上没有问题”；
4、对于出现线上问题，做复盘，做分析，做总结，补充遗漏的 case 是最基本的做法。

感谢

爬完楼。
测试面向的不仅仅包含 prd 的，也包含开发设计文档，交互设计稿，之类的东西。
所以看不懂 prd 就去学业务，看不懂设计文档就去学技术。目标都是保障产品质量，没有啥矛盾的。
对于提高业务能力的话
1.多跟产品聊吧
2.脑图真的是个好东西
3.学逻辑

到位

果然还是小姐姐发的帖子回复的人最多

就喜欢你们畅所欲言，各抒己见的讨论，思想碰撞，学习了哈哈

我觉得我自己的能量没大到能改变测试这个职位的， 我只想输出一下自己的观点和经验， 让多一点的 QA 能多拿点工资，少加点班，多被人尊重一点。 认可我观点的能有方向去努力就好了， 不认可的话我也接受。 尽人事， 其他的随意了。

我的观点：
因人成事，而不是因事成人。
技术不会是测试的门槛，测试方法论和业务深入理解才是。你说的这些技术都仅仅是 QA 之间的门槛。
同时不同行业，不同客户对质量的要求是不同的，你不能用高端 B 端用户的标准来要求低端 B 端用户的产品。这样会大量增加软件周期和成本。你们是 TOB，还是 TO 银行吧？和普通厂商是不一样的，做架构是需要取舍的，不是高端的就一定要用。

我是觉得你挺有梦想的。你想改变测试这个职位，最好从多数老板、研发总监到底是怎么看待测试的去看问题。然后多想想公司的核心是什么，你能参与改变什么，改变一个职位最终是市场推动的。而个体最好是能适应这些改变，共勉。

我非常赞同飞哥的观点，懂业务并且更懂项目技术框架，好处很多，

这个事情其实是很简单的一个问题， 咱们都是拿最终结果说话的， 用户看的也是最终结果， 用户不会管你用的第三方组件有没有 bug， 他只管你给他用的产品有没有 bug。 所以如果第三方组件有 bug，那也是你们自己选的， 也要承担相应的后果，这个没什么好说的。

而且就拿 kafka 来举例子吧， 怎么能保证 push 消息的时候不丢数据，不重复数据？ kafka 是给了方案的，但是需要启动 broker 的时候启动参数是有一定的设置， 并且在调用 producer 的 client 的时候把幂等和分布式事务打开， 并且在 consumer 端把 uncommited read 设置为 false。 并且不同的场景设置的方式不同， 比如官方 client， spark 流式对接 kafka， flink 流式对接 kafka，调用的时候怎么设置参数，怎么写 client 的代码都不一样，甚至相同的 client 但是产品不同，场景不同调用的方式也不同。 那这里面研发就容易出错， 所以虽然 kafka 是公认的解决了这种问题的，我们暂且相信他自己没问题，但是他只提供方案，怎么用是研发自己写的代码，所以你是测还是不测？ 只要它放到了产品里， 产品就得负责， 只不过如果你选择相信研发，相信第三方组件，你不测了，也是 OK 的，这是你的测试策略的选择， 策略上选择降低人员学习成本不去测试这些高难度场景，那相应的也得承担万一这里面出了 bug 所带来的风险。 出问题了就得为你选择的策略买单。

我也同意能力不是一蹴而就的，它是一个循序渐进的过程。 但是质量标准不因为能力而降低。 而且如果 QA 都由于自己能力的问题而理所应当的放弃大量的测试场景， 那么这个 qa 这个职位就永远放弃进步了。

从开发角度来看。
如果三方软件，能力差的开发会甩锅三方，可能是三方的问题。能力强的开发会去尝试从开源去找问题，但是大概率不会再从开源去思考怎么测，实际修了就 OK 了。那到底是不是第三方问题？应该怎么测试呢？
如果这时候测试去问开发为什么，怎么测。如果测试基础差，开发基础差，再问也是白问，然后互相吐槽菜鸡。如果测试基础差，开发能力强，会觉得和测试基础差的沟通完全是浪费时间。
这种事情多了。如果你是刚毕业的，可能还会教你一下;如果年纪大技术能力弱态度差的，那好了，就敌对了。
为什么老说测试背锅。。。这是需要思考的。

同时能力也不是一蹴而就的。你想在一个高难度的方向深耕，可能需要数年的比较简单的技术工程积累，同时还要想着办法挑战自己。

我也没理解

没有理解为什么会成为受害者

你说的没错

解释这个东西呢要从以下几个方面讲。

• 中间件是第三方产品， 但也同样是你们产品中的一部分， kafka 是开源的第三方产品， redis 也是，memcached 也是，mysql 也是， 甚至连你们开发用的框架 react，vue，spring，连开发语言本身都是开源的第三方产品。 难道 java 出 bug 了造成用户的损失他们得去起诉 oracle 么？ kafka 出 bug 了用户要去找开源社区索赔么？你们研发用的所有的语言，框架， 中间件全是第三方开源产品， 那所以你们的所有 bug 都需要用户找他们去索赔么？ 这就好比有个人拿这菜刀砍人了， 然后他说这把刀是 XXX 造的，你去抓他去， 你猜法律会不会同意？
• 即便是第三方产品，但是用的人是你们自己， 怎么用是没问题的怎么用是有 bug 的是一门很专业的学问。 即便是启动参数的错误也会招致很严重的后果。 所以你不测试，那就等着用户来承担后果。
• 调度规范从来不是 k8s 自己的出的， 也不是什么云厂商的的规范。 这个就是单纯的自己的产品要搞定的。 你的服务要怎么运行， 要怎么调度，是你自己在使用 k8s 的时候自己编写的配置文件， 还是那个问题， 你自己编写错误导致的后果你让 k8s 或者运营商来买单， 这不是耍流氓么？

我们怎么评审 test plan？ 这个太复杂了， 但我们的 test plan 的原则是一切为了保证质量， 保证最终用户拿到的是质量合格的产品， 而不是在做 test plan 的时候就想好了，如果开发调用 kafka 的时候出 bug 了就甩锅给阿帕奇社区。

桃花过处寸草不生，金钱落地人头不保！
希望你不会成为 “受害者”。

1. 中间件是第三方产品，为什么会成为你们的 test target 呢？
2. 调度规范由中间件供应商来保证质量，为什么会进入你们的 test scope 呢？
3. 你们是怎样评审 test plan 的呢？

问题还需从根源解决吧。

这个结论是测试前辈经过反复的论证 推导出来的，但是万事没绝对。只是相对正确的，这组数字里面的这个数处理正确，不代表这个组的其他数正确，毕竟没有验证过

所以我也是坚持方法论不是万能的，理论能力再强没有足够的技术支撑也是苍白无力的。这也是为什么我在这篇帖子里回答的第一个答案就是要对产品足够熟悉。 这个对产品熟悉，不仅仅是业务上的，也有对研发架构上的。有了足够的理解才能设计出更完善的测试场景。这也是测试人员的分水岭，非常多的 qa 会被卡在这个分水岭上不得寸进，这是测试人员职业生涯中的一个大坎。 只关注业务的人是很难能体会那些已经熟悉研发架构的人所看到的天空的。 这就像我很难能体会我们公司那些做算法的人所看到的天空一样。 所以实在劝不动了就算了吧。 别影响你们同事之间的关系。 能不能迈过这个坎看他自己的命吧。

有一次听我们 CEO 和我老大聊天，我觉得他表达的还是很准确的， CEO 的意思是大多数互联网产品是不重视质量的， 出了什么事线上直接处理也是可以接受的， C 端用户对错误的容忍度也高。CEO 说我们的 QA 不能学那些互联网的做法，我们要测试的足够深入。

我觉得 CEO 描述的这个不重视质量的现状造成了大量的 QA 在整个职业生涯内都是只对着业务功能进行测试的。 所以他们自然而然的就会觉得这些就是测试的全部了。 这个倒是很正常的， 没见过的东西自然就很难理解。 就像上面的那个哥们说产品经理不需要很懂技术一样， 因为他只见过业务型的产品和业务型的产品经理， 没接触过技术型产品和技术型产品经理。 所以他就以为产品经理都是不需要懂技术的。 这个是大环境造就的结果。 只要他们有机会经历过一次这样的经验，就会转变想法的。

所以我们要坚持在测试圈子里推广技术型的 QA，转变很多人的这种思维。 也转变圈外人对 QA 行业没技术含量的误解。

因为这个观点，下午跟同事争论了两个小时。这种只测产品最终形态的观点太害人了

不知道实现哪种技术的话， 那我们怎么测试高可用和稳定性？ 比如怎么能测试出来产品中的消息是不会丢的， 不会重复的？ 因为都不知道有消息中间件这么个东西。 那到时候线上只要一个网络抖动，用户下单的时候消息丢了， 或者消息重复了， 导致点了下单但实际没下单，或者只下一次单却花了两份钱。 这个 bug 算谁的？

或者再给你举个例子， 如果一个产品有离线任务来计算数据，而这个产品所有的服务和任务都运行在 k8s 集群里， 集群调度领域是有调度规范的， 比如离线任务不能和产品服务一起被调度到同一个机器上，为什么呢，比如离线任务很可能是 io 密集型或者 cpu 密集型的大数据任务，如果和产品服务调度在同一个节点上会造成离线任务占用大量资源而影响产品服务的稳定性甚至会造成产品服务的崩溃。这种极端情况一般在测试环境是不会触发的，只有在线上极其复杂的流量和大量的压力下才有一定的概率触发。 所以我们团队有个测试用例是检查所有批处理离线任务的调度策略是否是正确的，会不会跟产品服务混部。 这种测试场景是不可能出现在 prd 里的，正如你所说 pm 只关注业务，他不关心底下是怎么实现的。 甚至不少研发都不懂集群调度的规范的，因为他也只关注业务开发，不懂集群的猫腻。 所以如果 qa 不懂 k8s 这门技术， 这个场景怎么测？ 都不是怎么测的问题了，而是有几个人能想到这个测试用例

这就好像之前飞机挡风玻璃在飞行中碎裂的那个事故。 我记得原因是一个螺丝离标准差了 0.1 毫米。 这种螺丝应该达到什么样的规格肯定不会出现在飞机的设计图里的。 如果只根据设计图来测试飞机，这样肯定是不行的。 而是在针对组成这架飞机中的每个部件进行测试。 设计图就是这架飞机的 PRD， 除了要测试这些外，也要保证针对每个部件进行测试。

我觉得这个道理还是比较好懂的，测试不是只有业务上的功能测试和性能测试。大量的不存在于 PRD 中的非功能性测试都是需要 QA 来保障的。

为什么产品经理不在 PRD 里直接要求使用某种具体的技术？因为产品经理不懂技术也不需要很懂技术。开发团队实现了他的产品需求，他甚至不知道开发团队使用了哪种技术，他关心的是产品需求的各项指标是否得到实现和满足，包括但不限于功能、性能、易用性和兼容性。
同样的，测试团队也不需要知道开发团队使用了哪种技术，测试团队关心的也是产品需求的各项指标是否得到实现和满足。实现分布式消息系统可以有多种技术，测试团队要做的是站在产品经理和最终用户的角度，对不同条件的输入去验证系统的对应输出，是否达到了产品经理的设计。至于测试方法，万变不离其宗，等价类划分、边界值、因果图…
这解答听起来就是照搬书本，呵呵。

不同的人有不同的理解，开发和测试去理解同样的需求，有时难免产生分歧。分歧产生的时候，不要一方试图说服另一方，因为存在双方都理解有偏差或有误的可能，正确做法是要求产品经理给予澄清说明。黑盒测试不需要参考代码逻辑，理解代码对测试团队要求偏高，会造成用人（有代码能力的人）成本和时间（理解代码需要不少时间）成本上升，这种成本是没必要的，也不会带来足够的收益。
这解答听起来就是照搬书本，呵呵。

这个具体得问你们项目经理了，一般就是用 git 啦

我现在主要是功能测试，请问看代码的权限是要找项目经理吗？需要我准备一些什么呢，比如说账号之类的。

有用这个，这次的项目比较大，我虽然用了脑图全部梳理了一遍，后面测得时候还是感觉用例很多都没有写上，一个人一次性写了将近八九百条用例，感觉脑袋有点晕

明白了，我下次搞完了直接去找产品在对一遍

回复了 +1 后，居然还自动点赞了。新功能吗

+1

前提是，你得对自己的业务足够的熟悉。熟悉了整个业务流程、甚至是实现方式，这样才能够考虑的更为周全

知己知彼，百战不殆。
知己：自己业务水平，测试体系自己要清楚
知彼：要很了解你要测试的东西，了解用户要怎么用

其实业务深耕多年，多总结，一般都不差。才开始总是难免错漏百出的。

我们假设一个场景， 如果我们的团队的消息中间件是 kafka 的话， 我们怎么设计这块的测试用例？ 产品经理是不懂 kafka 的， PRD 里是肯定写不来这里面的逻辑的， 他只会写业务上的数据流向，属于功能上的设计， 他甚至不知道底下用的是 kafka， 这种情况下， 在不了解开发使用的技术的前提下， 我们怎么测试？ 我们怎么知道分布式消息系统的测试点？

有区别的，代码实现考虑的不仅仅是业务逻辑的实现，还有一些技术层面需要考虑的点，比如调用 service 的顺序、数据一致性、如何加锁等等等等。我个人的理解是，PRD 什么的，与实际的实现可能会出现出入，而且同样的需求，可能不同的人理解会有误差。但是代码不会。
有能力的话，两手抓，我觉得还是更有优势。

开发团队能了解到，测试团队就也能了解到。与其跟进开发团队或代码，不如多跟进产品经理或 PRD。

我之前是手工测试完成后，选择去看开发代码，找自己有没有没想到的逻辑，逐步补充自己的业务思维

先看下等价类划分的百度百科。
等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现 “合理的” 覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。

其实作者此处只是表述不当，其本意是等价类划分就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现 “合理的” 覆盖。
一组测试数据是否足够？这就牵涉到 “可信度”（不太记得这个专业词汇了，加个引号）问题。仅使用一组测试数据验证某个功能点且验证通过，我们是否可以 100% 相信这个功能点就是正确的呢？不是的。有多大可信度呢？统计表明这个数字是 86%--87%（小数点后不太记得），这是个很不错的可信度，但同时离完全可信又有差距。增加为两组测试数据，注意这里并不增加测试用例，可信度上升至 92%--93%；接着增加为三组测试数据，可信度还不超过 93%；继续增加，四五六组数据都能通过，则可信度上升非常缓慢，近似平直。结论就是：验证一组测试数据通过已有较高的可信度，多设计几组测试数据可以得到更好的保证，一般五六组即可，视项目 workload 而定，再多则投入产出比急剧下降。
对于你担心的冗余问题，其实等价类划分法目的之一就是为了避免冗余（降低测试的数目）。

主要是等价类的划分，不同的 QA、通过不同的维度、思考方式、划分粒度，划分出来的等价类也不同。怎么样的划分算是准确的，没有量化的指标去衡量的话，总会有主观的因素在里面。

很多处理逻辑是通过 PRD，交互这些了解不到的，如果需要提高测试用例的深度，还是需要参与技术评审，对代码逻辑有一定了解的。

真正掌握黑盒测试方法后，是不需要参考代码逻辑的。

我觉得一般是找不到所有的等价类的， 太多的隐含逻辑藏在代码里是 qa 不知道的。

举例：数字输入框，你可以定义分为数字，字符等。但是数字还要考虑小数，长度，0 的位置个数，是否会自动去除 0 等。所以测试用例的写法，通常都是这样说的，通过多方面综合 xxxx。
测试用例第一永远是保证覆盖率，冗余性一般是通过经验以及好的工作分配来避免。

有效等价类、无效等价类，均选取一组对应数据不就可以了吗？
每个等价类输入，只要一个输入测试正确，其他输入也一定会测试通过，这样是否存在冗余的测试用例呢？

里面提到的第二点：每个等价类输入，只要一个输入测试正确，其他输入也一定会测试通过
测试同学有没有对这一点提出异议的？

1、熟悉整个系统的业务流程越熟悉越好，太多则可以熟悉自己负责的模块和相关的模块
2、熟悉需求背景、需求不明确的要先明确
3、可以了解开发是如何开发的和如何解决 bug 的（了解他的思路相当于多了一个人想场景，有时候开发考虑的场景更多，了解后你会想到更多场景）
4、保持怀疑精神，感觉数据不对，场景未测试过得，抽空一定要验证一下你怀疑的，说不定有新发现
5、习惯写总结，经验会越来越多的

用脑图梳理还是挺有用的

我理解的测试架构师，我自己还是新手。。

有感：在测试架构师的角度来说，测试没必要纠结业务还是技术，两者都是必须的。
1.作为一个测试新人，第一件要做的事永远事业务。因为一个不熟悉业务的测试，我觉得都不能算合格测试，至少不能算大佬级别的测试
2.在业务熟悉后。可以试着用技术来创造数据。为什么要创造数据呢，第一点：熟悉业务数据流程，第二点：为自动化做好数据基础与流程铺垫。————>熟悉程序基础,java se ，或者 Python
3.尝试为系统和业务，搭建通用的自动化测试用例 . ————> 了解简单自动化架构，熟悉架构的方法及思想
4.集成自动化测试，尝试搭建自动化平台 ————>继续深入了解语言，以开发的标准搭建适用面广的测试平台
5.也就是上面所说的去完善测试 ————>形成自己的测试思想及流程，并能够用程序实现出来

参考：https://testerhome.com/topics/25667 的话

1.流程越多，用例越难写，越难覆盖业务流程
2.用例基于需求，需求越详细周全，写用例就容易，想办法在需求上做异常判断
3.不要过多的精力放在增加用例数量上面，点到为止就行了
4.系统测试执行者就是苦活累活，可能还要背锅，需要时间人力，要想尽办法流足够的测试时间

推荐看一下茹炳晟的极客时间上的课程：

我感觉就是只要对产品足够的熟就行。