软件测试原则
测试原则
测试证明软件存在缺陷
测试的本质是证明软件存在缺陷，而不是软件没有缺陷。
人无完人，只要是人写的代码，肯定不能保证百分之百正确，除非特别简单的功能。即便如此，也会存在各种环境问题，网络问题等，更何况现在软件原来越复杂，缺陷更是难以避免。
不可能执行穷尽测试
举个很简单的例子来说明，比如测试一个计算器功能里的加法，你可以尝试1+1,1+2 ,1+3 ...你能把所有数组相加的情况都测试吗，所以穷尽测试时不可能的，更别提是实际情况中，项目进度还有明确时间节点。截止日期。
测试应尽早启动，尽早介入
这条很重要，但是对测试的要求也会更高。
先来讲为什么要尽早启动，举例说明，软件工程和盖房子一样，先也得设计，打好地基，试想假如设计阶段，或者地基没打好，你后面楼房盖得越高，推到重来，或者回头再去修改所耗费的成本也就越大，所以，测试要尽早介入。
系统测试阶段
什么时候介入呢，对着需求文档设计测试用例的时候，就开始测试了。软件此时还在设计阶段，测试站在质量和安全性角度，应该多多思考功能本身的可测试性，可靠性，完善用例的同时也可注意下 整个业务流程是否能形成完整的闭环。是否存在明显的需求错误。
集成测试阶段
还有一个场景，比如开发app时候，往往后端工程师 服务器先开发完成，此时无论ios还是android工程师都在开发中，等待更多接口完成，等待接口文档。测试工程师此时便可以对着接口文档，先进行服务器端的接口测试了。这样联调之前就可以先找到部分服务器缺陷，减少了前后端开发调试和纠错时间。
单元测试阶段
这个对测试来说有一定难度，多半还是开发人员自己完成，也就是每一个方法，类完成之后。自己对软件的最小组成单元编写测试代码进行验证。这就好像你盖楼房，组成楼房的每一层阶梯，每一块砖头质量先保证是好的。
缺陷存在群集现象（二八原则）
这个也是经验之谈了，一般认为，百分之80的缺陷集中出现在百分之20的核心功能区域。一旦你在某个功能模块找到缺陷，相关附近功能多半也会存在问题。实战中如何使用呢，写缺陷报告的时候，做横向对比，比对类似功能，相近模块，版本，机型。指定回归测试策略的时候，也可以重点测试。
杀虫剂悖论
杀虫剂悖论，很简单，意思就是相同的功能，相同的用例，多次执行，后几轮就慢慢找不到缺陷了。仿佛软件对你的测试用例产生了抗药性。所以，用例在每次执行完之后应该及时进行更新和维护，升级你的装备。
不同测试活动依赖不同的测试背景
举个例子来说明，你在金融公司测试，安全性就是第一位。电子商务测试，功能性则更加重要。
不存在缺陷的谬论
假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。