就吐槽一句，都 2023 年了，居然还有软件测试行业从业者，不会编写代码来实现基本的自动化测试，这个行业到底是怎么了？

大部分公司都在开发一些所谓的低代码自动化测试平台，目的是要为不会代码的测试同学服务，这普通的测试同学还能有啥代码能力呢（学了也用不上）。
既然认为这些低代码自动化测试平台能有接近代码水平的自动化测试开发效率，那还要学啥写代码呢。
现象就是这么个现象，说多了感觉也没用，学会写代码了，就会又开始开发起一些低代码测试平台了，感觉也没什么实际意义。（轻轻吐槽一下吧...）

元素在变大变小。。 怎么感觉像是和编程猫源码编辑器类似的产品呢。

对于问题一，我觉得可以建立一个兼容性测试模型，这个模型可以包括但不仅限于浏览器内核和版本、浏览器市场占比、本产品浏览器使用占比、操作系统平台、操作系统分辨率等要素。
然后在每个要素下罗列出收集到的相关数据，根据要素的权重和数据的排名进行浏览器和系统平台的组合，得出测试需要覆盖的情况，并再次进行分类，根据项目和测试资源情况得出优先级别由高到低的兼容性测试列表，这样便于根据不同的版本挑选出对应级别的兼容性测试列表，可以有效并且科学地节约兼容性测试成本。

个人浅见，要想科学地保证好一个模块的质量，或者是说测试好一个功能，方向上还是要通过质量模型去入手。
在我理解，功能测试和接口测试这两大类都是属于对质量模型的功能性进行的测试，只是功能的表现形式有所不同，分为和性能测试同级的两大类不太严谨，或是说这样分类没有科学的来源。
另外之所以要进行性能测试，是因为性能效率也是质量模型的一个方面。但当团队或业务需要时，考虑的不仅要有性能测试还应该要考虑到对质量模型的其它方面进行的测试。

加油

submit() 的具体用法我忘记了，但我猜测是应该和搜索框类型有关

从上面两张图大致可以看出：
百度首页的搜索框是个 form 表单，使用 submit() 方法应该没问题
百度新闻的搜索框是个 table 表格，应该是不支持使用 submit() 方法的

听说去了也没喜茶喝

2001 年（美）Ron Pattern 著的《软件测试》一书中对软件缺陷进行了定义，即一般情况下，只要软件出现的问题符合下列 5 种情况中的任意一种，就可认为是软件缺陷：

• 软件未达到产品说明书标明的功能；
• 软件出现了产品说明书指明不会出现的错误；
• 软件功能超出产品说明书指明的范围；
• 软件未达到产品说明书虽未指出但应达到的目标；
• 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

sed -i '' '1 a\
a new line' 1.txt 

a\ 后面按下回车键换行