不撸靠刷题应该也行，反正翻过去翻过来就那些花样。。。考试大纲里计算机硬件、操作系统、数据库、中间件、计算机网络、编程啥的，应该是软件设计师考的差不多

主要看测试需求和查询接口的逻辑。
如果查询接口有特别的逻辑，调用查询接口满足不了测试需要，就得自己查。
无脑把所有你要验证的数据查出来的查询接口，可以用来验证。

自己去查的话应该是不信任查询结果或者担心查询接口业务逻辑变动影响自动化测试稳定性吧，当然也可能是顺手把存储一起测试了下。

理解不了题干。“5 个点”，“每个点有起点和终点”，是五个运动的元素，每个元素有一个起点和终点？

新版教材还不错。我个人看下来，还是很有收获的，楼上说没有用的，一定是没看过。
另外计算机基础的考试大纲基本没变，新版教材主要是针对测试类的题。

当然收获最大的是系统学习的过程，而不是刷题考过。

可以详细介绍一下吗，比如什么是聚类算法，如何解决 200 多个类别分类，算法代码是怎么样的。
你这篇文章总体下来我的感受就是一句话——我用了 Kmeans 做了个分类。

自动化测试本来就不是盲目的。。。一些项目本来就不适合自动化测试啊。不稳定的自动化测试用例实现比没有自动化更糟糕。

另外自动化测试优缺点我按自己理解罗列了下，供参考。

八股文啊。你可以不用，但是的你得会。

这是个长期的、持续的过程，很难立竿见影。
观念不一致，没有质量共建的共识，绩效弄不好会起到反效果，搞得怨声载道，质量也没提高。

根据我个人的经验，绩效这个东西，很多就是瞎拍脑袋弄的，如果不持续优化改进，短时间起反效果的居多，如果实在要搞，指标尽量是间接指标（比如恒捷提到的提测超时率、提测打回率、压缩时间占比、压缩后线上缺陷遗留增长情况等），同时尽量以激励为主，如果出现线上缺陷，开发测试共同担责（这一点是质量共建的基础）。不过还是那句话，大家认为质量不重要，随便怎么搞，都没多大效果的。

另外，有时候确实是客观原因（实力不够、环境影响、没资源、人员流动）导致的，进度目标设置的时候，是不是合理呢？

没遇到过，
可以参考下这个
https://www.infopackets.com/news/10414/how-fix-openvpn-sslctxusecertificateca-md-too-weak

哈哈 给 tips 赞一个。

测试没话语权，不重视质量的团队就这样。解决这个需要从上到下的共识和制度的支持。

以下做法供参考：

1. 设置准入标准，未达标不进行测试。——这个常年因为产品进度压力妥协
2. 尽早介入，每个环节介入——这个可能因为任务堆积被迫放弃，形成恶性循环
3. 测试驱动开发，结对编程——没基础和一些基本条件不建议搞
4. 要求开发自测——这个需要研发支持
5. 尽可能小的分解任务，每个研发周期控制在 1-2 周。——这个还是可以做的，解决研发周期过长的问题

至于压测试时间，一方面可以从自身效率解决问题（工具等，没资源不建议大规模做自动化测试），一方面可以把计划做好，提测结点约定好，压了多少时间，每次回顾会做到有据可查，时间成本很影响质量的。

可以照着用人单位的需求来写

可以参考https://blog.csdn.net/vincetest/article/details/1466402?spm=1001.2014.3001.5501
讲得很清楚了。

转开发。
在资源有限的时候，领导们必然高举 “开发优先” 的旗帜的。

先把数据分类，其实有些导不导都没啥必要，有些又要脱敏，有些可能必须得没版本更新。不能一概而论。

哈哈 也可能回滚了

感觉自己能，和实际深入做过，是两码事，别被自己骗了。

“会做一些 Selenium 和 Appium 的 UI 自动化测试框架 Demo，用上了 PO 模式或者是数据驱动，能使用 Python、Postman 或 Jmeter 进行接口自动化，但去面试大脑就一片空白吹不起来”。
——我也曾有过这种感觉。现在回过头看，原因是学是学了，但是也就是个模仿着会的阶段，看见新的技术，就想去学下，但是浮躁让我从没有认真从头到尾实践过几次，没有总结，也对实践没有自己的要求和思考，说实话，跟没学差不多。

做开发不香吗

是没有环境，还是说要做自动化测试？
如果仅仅没有环境，是受限于资源，还是权限。没资源就本地搭个，没权限就申请。实在不适合就放弃。

“无自动化测试环境，搭建升级到自动化测试”，按需求来看，是有歧义且不明确的。

1. 先定目标——你想去哪家公司，就去看他们招聘信息的要求，去自己学相应内容。
2. 打基础——自动化方向，就把编码基础打好
3. 实践——能借助工作资源的，就用工作资源做，不能的自己用开源的。

需求不清，打回重写

嗯，而且我没想明白他那个通过计算覆盖距离优先是基于啥条件来说的。。。总之这个需求有点模糊，不符合准入条件，哈哈

现在的电梯基本都是那种可以看到电梯停留层数的吧。。。不然初始状态都不好了解。。。
转化一下问题，应该就是
输入：B1 按上 1 按上 1 按下 1 按上并且按下
输出：
A 停 B1 A 停 1 A 停大于 1
B 停 1 B 停大于 1
需求：测试下电梯调度算法

不知道是不是这个意图

我们是先约定了一个共识的覆盖率（40%），然后再根据实际情况增加或者减少覆盖率的要求，涨超过 5% 的有奖励。
最终的现象是好的稳定的团队（也可能是闲的），这个一直涨到 60-70% 左右就没涨了，当然也有原地踏步的团队（人员流动很大），以前是 0%，后面是 40%，万年不动。

2 年前做过，当时想的是给自动化回归测试当补充。后面弃用了。一个是用例规模不大，没这必要，全跑也多不了多少时间；另外就是用例质量不高，自动化测试覆盖都没到位，搞这个不合时宜。再后来公司搞开发优先，测试有点技术的要么干开发，要么跑路，已经没做下去的必要了。

大概方法是，在已经建设好自动化测试跑一遍，通过 javaagnt 把用例和用例覆盖的代码（到方法级）保存到数据库，然后提交代码的时候去拉取要跑的用例，达到精准测试的目的。

嗯代码还在内部 git 上