原则1:测试说明缺陷的存在,而不能说明缺陷不存在。
- 即使在测试过程中没有发现缺陷,也不能证明证明没有缺陷。
- 所有的软件都是有问题的,只是这些问题是否一经发现了。
原则2:穷尽(穷举)测试是不可能的
- 穷举:将所有的可能都测试一遍
随着系统业务变多,代码规模变大,算法逻辑复杂程度越来越高。要让所有可能测试的测试一遍是不可能的,难道不测可以采取以下方法,当然还有更多。
- 精准测试:改什么测什么。
- 二八原则:只测重点。
- 分类测试
- 可以被正常搜索到的:也就是可以正常显示的哪些,比如家电啊、衣服啊、手机等等。
- 不能正常搜索到的:也就是哪些不应该被显示的东西,比如各种违禁品。
- 特殊情况:带有特殊符 、空格、什么也不输入等。
原则三:尽早介入测试
- 及早发现问题,及早解决,降低后期修复成本。
- 为软件开发的下一阶段做好准备。只要生成产品需求或文档,测试人员甚至就可以开始测试。
- 测试的尽早介入有时也称为测试的左移,测试尽早介入,可以减少项目时间和成本。
原则四:缺陷的群集效应、二八原则
- 一个项目中80%的缺陷会集中在20%的功能模块中。
- 简单、容易的模块或功能是很少引入过多Bug的,而对于存在复杂逻辑的一些关键模块往往会引起系统80%的错误,越是有问题的地方,这里往往会有很多其他的问题
- 出现这种问题的现象可能会是以下几点。
- 如果复杂且核心模块在项目的后期才开始执行测试,而且负责这个复杂模块的程序员技术一般(或者是刚加入的新人)。
- 模块本身功能复杂。
原则五:杀虫剂悖论
- 就像杀虫剂在一段时间后对杀死昆虫不再有效,如果多次重复同样的测试,最终这些测试将不再能够发现任何新的缺陷。
- 这个时候可以进行交叉测试,就是交互测试人员。测试人员在经过一段时间后会进入自己的固有的思维意识,很难在测试出其他的bug。
原则六:测试活动依赖于测试的周境
- 测试在不同周境下是不同的。所以不应该以完全相同的方法去测试两个不同的系统。
- 比如偏向安全性相关的测试对象和一般的商业对象、娱乐软件,测试 ,测试活动是不完全一样的。
- 程序的架构:B/S C/S
- B/S架构:Broswer/Server,通过浏览器访问服务
- C/S架构:Client/Server,通过客户端程序访问服务
- 测试B/S架构准备三款浏览器:谷歌、火狐、IE【苹果、欧鹏、QQ、360、搜狗】
- 测试C/S架构准备:
- PC:win7、8、10,mac,linux
- 手机:安卓、苹果、鸿蒙
原则七:无错误谬论、不存在缺陷谬论
同第一条重复
- 补充:期望仅仅发现并修复大量缺陷就能确保系统的成功,这是一个谬论。
- 软件测试不仅仅是为了找出Bug而存在的活动,而是还需要确认软件是否满足用户的期望和需求,如果产品不能满足用户的需求,即使没有出现任何缺陷,这个产品也是失败的。
- 便多次测试都没有发现任何缺陷,也不能证明软件是完美的。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!