业务所在行业，IT 么还是那个鸟样

1. 在明确业务后进行
2. 根据实际情况，我们就是先单接口，再流程
3. 和功能测试一样，没啥特别流程

行业复苏，个人积极性没有复苏

首先搞清楚脏数据的概念：

如果按流程能造出来的数据，那叫正常数据。。。
如果是开发帮你做的辅助测试工具（比如直接数据库插入的，没管前后端验证），按流程（无论正常还是异常）弄不出来的数据导致的问题，你可以说是脏数据。

其次可以看出开发对你们测试的专业能力有怀疑，正常的开发看到问题是去发现问题，解决问题，而不是纠结你们测试数据哪儿来的，哪怕是因为你们因为非正常造的数据的原因导致你们提了缺陷，也应该是给正确的建议，帮助团队规避问题，什么你啊我喷来喷去的，世界如此美妙,他却如此暴躁,这样不好~！

很多论坛自动审核只是初筛，还是有人工审核的。

不明觉厉。。

合并代码前有人把关走查审核，合并代码触发自动构建，失败邮件 + 钉钉通知，成功发送提测邮件。
成功的构建基本无感，也不影响测试。

我们测试团队全部打散并入开发团队了，现在全看个人能力，哈哈

1.安全，后台异常处理没做好，绕过前端，接口会暴露很多信息，甚至引起严重的安全问题
2.接口正常来说比前端设计先出来，所以先测了
3.用户=正常用户 + 想搞你的用户 + 想钻空子的用户

由问题推动比较好

666

好有内容的文章~~可以做为团队质量体系建设的参考。已收藏，后面会多翻阅。

卷的过别人就去卷，卷不过就躺。只要你不焦虑，就不会焦虑。

以上都是废话，哈哈。小公司的测试想提高，最好的方式就是跳槽。有些公司的测试，其实也就是个 title，没有测试还是照样玩得转~在这种公司，你是没办法提高的。

评审大家都看得懂，通得过，可重用就行。别给自己找麻烦。

转对象之后，按对象是否 equal 来对比就行了吧，我记得 word 转的 document 是包含格式的，另外两个没用过。

先看需求，再看接口类型，对外提供的接口和内部使用的接口，测试策略和方案也不一样。

具体测试来说，先进行正向业务覆盖，把需求中的场景和隐含的正向场景都提取出来一一覆盖。再进行异常覆盖，必填参数验证算异常覆盖的一种。
其他测试根据需求和测试策略来。

接口测试数据，是否要枚举？——普通参数，划分等价类，比如特殊字符、中文，有时候他们是等价的，有时候又不同，根据实际处理逻辑来。（参数是枚举类型，一定要枚举，一般正常场景测试都会覆盖完所有枚举类型，如果发现枚举没有覆盖完，检查下场景覆盖是否有漏掉）

感觉可视化系统才是核心~

量化的东西，初期基本都怀着美好期望的，随着人员流动，团队变化，个人诉求转移，久了必失真，如何长期维持下去很考验水平。

参考劳动合同，可以起诉违约。建议咨询法律相关人员。

测试项目本身是本职工作，做的自动化这些，不就是为了项目本身做的嘛。

也要看绩效的导向是什么，如果本职工作做得再好，也比不上整花样的，他们这么做我觉得人之常情。

另外对项目本身来说，可能有些属于样子货范畴，但是对人来说，他们有自我实现的需要，有想进步，想不被淘汰，保持竞争力的需要，有技术储备的需要，花一些成本在上面，我觉得也是可以的，理想的情况是能落地，能验收，能持续用起来并进行改进，并且项目因此而受益。

个人觉得可以不用关注他们玩什么花样，只要对项目有益，关注这些花样落地、效果、持续改进方面即可。

现在打工人的新年心愿是身体健康，永无疫情。

内容很 OK，就是图片不够清晰。

有没有一种可能，就是行情不好。

一般 A 用例失败，B 用例都没法进行下去的，其实都是把 A 和 B 写到了一条用例中。

我以为我数学很差，原来比我想象的更差啊。。。