Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML 等
当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要
除了HTML 的版本问题外，不同的脚本语言，例如Java、JavaScript、ActiveX、VBScript 或Perl 等，也要进行验证
　　在设计Web 系统时，使用不同的脚本语言给系统带来的影响也不同，如HTML 的不同版本对Web 系统的影响就不同
关于设计语言的测试，应该注意以下几个方面：　　(1)与浏览器的兼容性
由于不同的浏览器内核引擎不同，导致不同的开发语言与浏览器的兼容情况不同，当前主流浏览器的引擎有Trident、Tasman、Pesto、Gecko、KHTML、WebCore 和WebKit
　　(2)与平台的兼容性
不同脚本语言与操作系统平台的兼容性也有所不同，测试过程中必须考虑对不同操作系统平台的兼容，即脚本的可移植性
　　(3)执行时间
由于不同脚本语言执行的方式不同，所以其执行的时间也不同
　　(4)嵌入其他语言的能力
有一些操作脚本语言无法实现，如读取客户端的信息，此时即需要使用其他语言来实现，即测试过程中应该考虑当前脚本语言对其他语言的支持程度
　　(5)数据库支持的程度
考虑系统数据库可能升级的问题，测试时需要考虑脚本语言支持数据库的完善程度
接下来我们说说回归测试：回归测试是软件测试中不可忽视的一部分，回归测试是对旧代码修改后，重新进行测试并确认修改没有引入新错误，或者导致其他代码出现错误
自动化回归测试将大大降低系统测试、维护升级等阶段的成本
作为软件生命周期的一部分，回归测试在整个软件测试过程中占据着相当大的工作量，在软件开发的每个阶段都要进行多次回归测试
　　为了提高回归测试的效率和有效性，选择正确的回归测试策略是非常有意义的，选择回归测试应兼顾效率与有效性两方面，那么常用的方法有哪些?　　1.重新测试整个案例　　从基线测试用例库中选择全部测试用例组成回归测试包，这是一种比较安全的方法，再次测试所有用例具有较低的遗漏回归错误风险，但测试成本较高
　　2.根据风险选择测试　　从基准测试用例库中选择回归测试包，基于一定的风险标准
从运行更重要的、关键的和可疑的测试开始，而忽略那些不重要的、低优先级的或者高稳定性的测试用例，这些测试用例在只有三到四级甚至更严重的情况下进行测试
　　3.基于作业面选择检验　　若基线测试用例库的测试用例是根据软件操作曲线开发的，测试用例的分布情况反映了系统的实际使用情况
通过测试预算，回归测试使用的测试用例的数量可以确定回归测试，回归测试可以优先选择那些具有重要或经常使用功能的测试用例，并且能够降低和减轻高级风险，帮助尽早发现那些影响可靠性的故障
　　4.重新检验修改部分　　如果测试者对修改的局部化有足够的认识，那么通过相关分析就可以识别软件的变化并分析修改的影响，将回归测试限制在被修改的模块及其界面上
常常，回归错误必须包含新的、修改的或删除的代码片段
如果条件允许，回归测试尽可能覆盖受影响
最后，关于软件测试学习，offer选择等等，都可以通过后台私信交流
需要学习资料或者帮忙修改简历也可以私信

也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”，里面涵盖很多精彩免费视频或干货知识