网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
为什么会这样的原因很多，我们只能适当分析。 比如开发某个功能模块的程序员水平不行，引入了大量缺陷； 也可能是这个功能模块非常复杂，可能出现大量没有考虑到的因素。
原则3：尽早介入测试
一个软件越复杂，越有可能产生新 bug。 热力学第二定律指出：孤立系统自发地朝著热力学平衡方向──最大熵状态──演化，同样地，第二类永动机永不可能实现。
这个定律同样适用于信息系统。 当一个软件引入越多的信息，越多的功能，会让软件变得越来越混乱，从而产生越来越多bug。
如果要少产生bug，首先是要保持软件整体的简单性，还有就是尽早介入测试。 因为在一个功能被开发的早期，功能还足够简单，早期介入测试能更高效的找到bug，如果一个功能演化到后期，被更多其他的程序使用，变得越来越复杂，找到bug会难很多。 尽早介入测试，还可以让开发快速得到反馈，从而尽快修复bug，不会把bug带到更复杂的代码世界中。
原则4：抗药性原则
抗药性原则又叫杀虫剂悖论（Pesticide Paradox）。随着时间的推移，重复使用相同的杀虫剂消灭昆虫会导致昆虫对农药产生抵抗力，从而使杀虫剂对昆虫无效，这同样适用于软件测试。
如果进行相同的重复测试，则该方法将无助于发现新的缺陷。为了解决此问题，需要定期检查和更新测试用例，添加新的和不同的测试用例以帮助发现更多的缺陷。测试人员不能简单地依靠现有的测试技术。他必须不断寻找改进现有方法的方法，以使测试更有效。
原则5：要有精确的预期结果
测试用例中一个必需部分是对预期输出或结果的定义，这条显而易⻅的原则在软件测试中却是最常犯的错误之一，很多测试人员对程序应该产生的结果没有明确定义，只是凭感觉判断结果是否异常。
尽管“软件测试是破坏性”的定义是合理的，但人们在潜意识中仍然渴望看到正确的结果，所以当程序运行符合测试人员的心理预期时，他们会自以为程序是正常的。没有期望，也就没有所谓的意外。
克服这种倾向的一种方法，就是通过事先精确定义程序的预期输出，鼓励人们对所有的输出进行仔细检查。因此，一个测试用例必须包括两个部分：1.对程序的输入数据的描述。2.对程序在上述输入数据下的正确输出结果的精确描述。
原则6：测试显示软件存在缺陷
软件测试只能证实软件中存在缺陷，但是并不能证明软件中不存在缺陷，只能降低软件存在缺陷的可能性。
如果说公司的决策层想通过软件测试来证明软件中不存在缺陷，那是行不通的。测试人员只能证明软件中存在缺陷，但并不能证明软件中没有缺陷，软件完美。
软件测试人员可以通过软件测试活动，找出软件中大部分缺陷，避免软件在上线后给用户带损失，给公司带来风险。
原则7：无错就是好是谬论
无错，对软件测试人员来说可望不可即的。
那真的无错的软件就是好的软件么？
假设一个软件完全没有bug，完美无缺，但是不符合用户的需求，那能说这个软件是OK的么？
判断一个软件的好与不好，主要依据的还是用户需求，是否实现用户所期盼的结果，并不是仅仅依赖于软件中是否存在缺陷
有些伙伴会说测试理论没什么用，但博主觉得理论看似没用，但却能培养我们的测试思维，让我们对软件测试有更多的认识和了解，测试人员不要只去追求技术上的超越，而思维上的建立也是至关重要。
原则8:测试活动依赖于测试内容
在面试过程中有时总会遇到面试官部“做软件测试什么最重要”，想来做过测试的都知道“需求”最重要，对测试人员来说是需求，对公司来说就是业务。
根据业务的不同，软件测试内部也分不同的行业，比如游戏行业，金融行业，电商行业等等。
不同的行业，测试活动的开展都有所有不同，比如工具的选择，测试流程都不尽相同，所以软件测试活动的开展依赖于所测试的内容。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
cb)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
