单元测试与白盒测试的区别
测试技术:
1. 白盒测试和单元测试的区别:
l 单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
l 另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
l 不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2. 功能测试边界测试\越界测试技术详述
Ø 边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值 速度 字符 地址 位置 尺寸 数量
同时,考虑这些类型的下述特征:
第一个/最后一个 最小值/最大值
开始/完成 超过/在内
空/满 最短/最长
最慢/最快 最早/最迟
最大/最小 最高/最低
相邻/最远
Ø 越界测试
通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1
l 另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：485187702【暗号：csdn11】
3. 状态测试技术
Ø 软件可能进入的每一种独立状态;
Ø 从一种状态转入另一种状态所需的输入和条件;
Ø 进入或退出某种状态时的设置条件及输入结果.
l 具体测试方法可以参考如下:
Ø 每种状态至少访问一次;
Ø 测试看起来最常见最普遍的状态转换;
Ø 测试状态之间最不常用的分支
Ø 测试所有错误状态及其返回值
Ø 测试随机状态转换
4. 竞争条件测试技术
l 竞争条件典型情形参考如下:
Ø 两个不同的程序同时保存或打开同一个文档
Ø 共享同一台打印机,通信端口或者其他外围设备
Ø 当软件处于读取或者修改状态时按键或者单击鼠标
Ø 同时关闭或者启动软件的多个实例
Ø 同时使用不同的程序访问一个共同数据库
5. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
l 软硬件的测试环境提供上也对测试结果有很大的影响。
l 测试团队的水平，经验，合作效果等
l 整个开发流程对测试的重视程度，测试的进入时间等
l 由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
6. 软件缺陷的原则
l 软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
Ø 软件未达到产品说明书标明的功能。
Ø 软件出现了产品说明书指明不会出现的错误。
Ø 软件功能超出产品说明书指明范围。
Ø 软件未达到产品说明书虽未指出但应达到的目标。
Ø 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
7. 文档测试
l 产品说明书属性检查清单
Ø 完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
Ø 准确.既定解决方案正确吗?目标明确吗?有没有错误?
Ø 精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
Ø 一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
Ø 贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
Ø 合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
Ø 代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
Ø 可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?
l 产品说明书用语检查清单
说明 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
Ø 总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
Ø 当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
Ø 某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
Ø 等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
Ø 良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
Ø 已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
Ø 如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 希望能帮助到你！【100%无套路免费领取】
