这么恐怖吗？那只能引入，第三方的审查接口了，自动审批，，要不然你们管理也累。

建议，多看一下写简历的技巧；
建议去查一下前端开发，后端开发，他们是怎么介绍项目的；

一定要突出项目，为什么要做这个项目，满足怎么样的需求场景，这个在面试过程中，一定会问到的；

项目有哪些难点，你是怎么解决的，你遇到了什么样的问题？

你在这个项目，获得了什么，成长了吗？学到了什么？

然后所有字体先全部，取消粗体，，只有哪些亮点的关键字，打上粗体，让面试官，第一眼就可以看到粗体的关键字 / 数据，提升简历筛选通过的成功率。

只要社区规则，明确各项条规，并且社区，及时处理，一般都没什么问题；
你想的这个问题，多虑了。
你说的这种情况，我相信，其他各大社区也会碰到，甚至更复杂，难道，他们就是人工一条一条审核？
一般像大公司，都是对接第三方的自动审查接口，审查一遍，然后就自动审批通过。

培训班的简历吗？怎么改都没用。

重写是最好的选择。

先看看你的任务安排，我不相信，你一天会没有事情做

如果没有事情做，就应该跟组长反馈，然后让组长给你安排任务；

你就按照你的任务走就行了，不需要关注组长的任务进度。

实现，脏数据，，可能是之前的接口有问题，产生的。

主要看你有没有访问数据库的权限，我们公司，测接口的时候，都会校验数据库的数据，看生成的是否正确；

其次是脏数据，测试的时候，发现的 bug，确实应该要校验一次，是不是因为脏数据导致的误报，这个跟开发无关；

其根本原因在于，接口测试的时候，发现会产生脏数据（错误数据），就应该提交 bug 了。

只能说，这种设计如此的 bug，是你对需求的不理解，本身就不应该是 bug，这种应该属于需求问题，所以，你不应该提交这种 bug，有这种问题，建议直接找开发沟通，沟通完再提。

我觉得，投入产出比，真的不划算

你还要部署云服务器，还要设计解决方案，还要开发人员进行开发，测试，部署，上线，调试，维护。

写个特定页面，每日公布对应的优惠商品 sku

为什么一定要生成优惠文章？

比如，你 1 月 10 号的优惠文章，你觉得，对于 1 月 20 号的用户，有作用吗？显然易见，即使 1 月 10 号的优惠文章里面的商品还有优惠，用户每一次还要去验证一次，是不是真的有优惠。

所以说，把需求搞复杂了，以至于，用越复杂的技术，解决越复杂的需求。

写的不错

你的经历，好乱，，感觉，每个阶段，似乎只做半年？

不过，你要转行了，不做软测，感觉还是挺可惜了；

不过，既然自己选择了，就不要后悔，永远相信自己；

请问测试 团队，就自己一个人，，如何搞垮自己？

测试环境，我们也是测试进行维护；

因为我们测试，需要第一时间测试系统，所以，通过 jenkins 进行构建，发布，测试可以第一时间知道，更新了哪些内容，进行复测，有问题的话，及时找错错误日志，联系开发解决；

如果由开发构建，测试则不知道更新了什么代码，开发还要每次通知测试？

所以，由测试进行 jenkins 构建，在某些方面来看，是合理的。

简单，封装好 requests 请求方式，用 session 请求，然后下面的所有用例，共用一个 session 即可

能找到更好的，肯定去啊，，人是不能太安逸的，否则，淘汰的第一批，一定是生活在安逸且舒适的这批人

你在哪个地方工作，具体需要看你在哪个城市吧。

很多时候，前端开发，都是组件，直接从别的地方复制过来，可能改都没改，所以，组件的问题，可能性还是很大的

先排除，是输入框，限制了输入内容吧，，，有的输入 ，只能输入数字什么的，你输入中文，当然不可以

第一个，开个用例评审会，把测试用例过一遍，比如：登录功能测试用例，就需要评审这些测试用例，是否对登录功能进行全面的覆盖，覆盖测试需求点，如果都覆盖了，那就符合标准的测试用例；
第二个，就是评审一下，操作步骤，预期结果，期望结果，是否便于执行，是否规范等；
第三个，最好做一个版本管理，一旦，确定测试用例了，就封存，然后，如果线上出现问题，就根据这些测试用例，来查找，是不是漏测，是不是哪个测试需求点没有校验到，还可以看出，是否按照测试用例严格执行；

这是转发哪里的

不写测试用例，直接测

你是开发吗？还是项目负责人，，我很好奇，有这样的一种需求场景，，是单独成立一个项目吗？然后你是怎么分配前端和后端的开发任务的？

1. 冒烟测试
2. 校验业务场景【重要】
3. 再校验关键字段的，边界值（最大，最小）
4. 看返回的字段，是否符合需求
5. 为空校验，一些关键参数，必填项肯定是要校验一下，比如，客户表，客户名，手机号，如果这两个字段的数据，都没有，那么后面的业务逻辑，可能会异常，所以，该校验还是要校验必填的
6. 对于数字，金额，是否可以为 0（购买数量），是否可以小于 0（金额）

提醒：

1. 类型校验，基本上没必要，输入，字段是数字类型，你输入个字符串，其实没有必要测试，因为前端那边几乎不可能传一个字符串，除非是通过接口测试工具调用的

另外，我个人觉得，你的执行能力很强，从需求场景的构思，再到方案的决策，再到具体的实现，最后的推行实施，离不开一个关键人物，就是这个体系搭建的负责人（你的文章，没有提及，所以，如果你是负责人的），我会觉得，你的能力真的很 OK。

哈哈，我觉得，现在越来越内卷了，，滑水摸鱼，似乎变的越来越难了。

这样做，对于团队，企业，提升，是有益处的，总之，优点大于缺点。

不过，我觉得，最难能可贵的是，从构思，到实现，再到落地，并能够在实际工作中展开，是非常不容易的。

离不开，每个小伙伴的支持与配合，我还是相信，你这套体系，会越来越完善。