呜呜呜，好想回上海， 虽然 10 年测试经验，but 之前都不是 java，嘤嘤嘤~

有发瑟图的，这么厚颜无耻嘛？ 请拉我进群！

考试就是考试， 不用太纠结题目里的内容和现实情况是否符合， 自己觉得不合理的部分， 背背答案就好， 考官不会听你的理解如何如何的，他只看你是否选对了答案

对不合理的需求说不，对不合理的排期说不，对不能在计划内完成全部功能的测试的情况及时反馈给领导， 预警！
以我之拙见， 功能测试都完不成， 自动化测试也要花时间去写脚本嘛， 哪有时间来搞。

我本来想回复这个帖子的，但是看到了你的评论，还是借个楼，吐槽下我前公司哈。
首先，你说的情况，按照正常情况下，是非常正确的，自研公司的业务部门对招聘人员有话语权。 我前公司是能源数字化行业，然后招聘一个测试， 我去面的， 一个硕士， 人家专业类似神经网络， 和我们岗位一点都不匹配。面试结束后， hr 先发话了， 说这个挺好的，要了吧。。。。。。 前公司是个自研公司，但是招聘都是 hr 说了算，很奇葩的~

即使我很菜，我也想提供一份力量。

老哥，有最新版本的 link 嘛， 这个 link 里面介绍的方法啊什么的，在我用的 postman 里面都找不到， 例如 certificate，这个方法。 可以告诉下，如何从 postman 官网上，一步一步的走到 link 界面嘛，自己找了好几天也没找到哦

checkList 的推广对团队成员的要求是啥，或者说 checkList 的推广是否存在局限性?--要求：规范的模版和成员的认可/应该也有局限性吧。
答：（1）checkList 的推广对团队成员的要求是啥？我个人的理解哈。首先，要推广 checklist 这个环节，势必会增加一定的工作量，如何让大家能接受这个事情，就要告诉大家 checklist 在工作中，为大家带来的好处、便捷，让成员了解对 checklist 的付出，是有积极的回报的（例如便于梳理逻辑，梳理思路，大功能点拆分小功能点），让大家享受到 checklist 带来的红利。其次，就是一个规范的模板，设计一个通用的模板，填写的内容不冗余还可以清晰表达 check point，让测试工程师只需要填写内容，而不需要太关注形式（因为模板就是规定好了形式，让大家填写即可）
（2）checkList 的推广是否存在局限性？我个人的理解哈，可能是有局限性的。 例如楼主提到的 3 星期一次迭代，一次功能迭代，测试工程师要做的事情大致有：需求学习与分析 -- 测试环境准备 -- 编写测试用例（checklist&review）-- 测试执行 -- 测试 bug 管理 -- 回归测试 -- 测试 report--产品发布。 如果 3 星期不能完成这些环节的话，checklist 可能就是一个鸡肋的环节了，因为来不及做这么规范的一个测试环节。再有一个我能想到的就是，产品！如果说产品很单一，很简单，迭代的功能大多数很相似，例如 Page One 有个 button， 迭代 Page Two 加个 button，这种的话就可以仿照之前的测试用例修修改改直接拿来使用了， 就没必要搞 checklist 环节了。

这个应该算是 manual 了吧， 真是太棒了，就是我寻找的东西！

我也来参与讨论一下，欢迎大家指正！
1、checkList 由谁去编写？ ---测试经理或者高级测试工程师（类似的岗位）
答：checklist 里面记录的是新开发的功能当中，需要 check 的点。首先这个人选应该是一名测试 title，其次应该拥有几年的测试经验，对新开发的功能有相对完整的了解。一些公司可能没有类似高级测试工程师的岗位，所以一般也可以由测试工程师来编写。至于 checklist 的遗漏问题，那么就来到的第二个问题。
2、checkList、用例都写完了，是由谁来进行检查，什么时间进行检查？---测试组（项目组成员），checklist 完成后 2-3 天。
答：不管 checklist 是由谁来编写，也有一定概率导致 check 点遗漏。所以，需要 checklist review 环节。以我们之前敏捷开发举例，team 中有 1 个 Scrum master, 4-5 developers, 4-5 testers。checklist 完成后，即刻通知组内，每个人 review 一遍，问题少，则私下沟通，保留痕迹。问题多，则 book meeting，统一过一遍。 至于时间嘛，当然越早越好，但是也要给 team member 一点时间，让他们也先 review 一遍，所以我们一般留有 2-3 天时间。