作者简介：大家好，我是未央；

博客首页：未央.303

系列专栏：Java测试开发

每日一句：人的一生，可以有所作为的时机只有一次，那就是现在！！！

前言

今天我们将学习有关测试用例的划分问题；

一、 有关测试用例的回顾

万能测试用例设计公式：

---

如何根据需求去设计测试用例？

1、验证需求的正确性，合理性，无二义性（没有歧义），逻辑自洽。

2、分析需求，细化需求，从需求中提取出测试项，根据测试项找到测试点，再根据测试点去具体的设计测试用例。

---

根据需求设计测试用例分为哪两个方面？

1、功能性

1.1、界面的所有功能不能遗漏（技巧：从上到下，从左往右，一层一层的扫描）
  1.2、把多个功能串联起来，形成 场景 / 业务，对 场景 / 业务 进行测试。
  1.3、针对一个功能的多个输入进行测试，观察输出是否与预期结果一致。
  1.4、同一个系统下，不同功能的交互性
  1.5、功能的异常测试
  1.6、功能所用到的算法，也是需要进行验证的。

---

2、非功能性
 易用性，容错性，安全性，性能，可维护性，可靠性，可移植性，稳定性，兼容性等等；

注意：

不同类型的软件，非功能性测试的侧重点是不一样的。

面向客户端的软件：对 稳定性 和 兼容性 要求高，对 安全性 和 性能要求低。
面向企业内部的软件：对 功能性 和 可靠性 要求高，对 兼容性 和 性能 要求低。
大型商用软件：对 非功能性的各个方面的要求都很高！

---

具体的设计测试用的方法有哪些？

1、等价类【有效等价，无效等价】

2、边界值

3、判定表（因果图，使用场景较少）

4、场景设计法（不常见）

5、正交法（用的比较少）
6、错误猜测法 

二、 测试用例的划分

 2.1 按照测试对象来划分

 下面我们解释下上面提到的一些专业名词

2.1.1 可靠性测试

可靠性=正常运行时间 /（正常运行时间+非正常运行时间）* 100%
比如一节课45分钟，期间你上厕所5分钟、跑神10分钟，实际听课实际时间为30分钟。
则你课堂听课的可靠性为：30 /（30+5+10）* 100% = 66.7%

影响可靠性的因素：

1、网络
2、软件环境（安装环境）
3、硬件环境

不管是上面那个环境的异常，都会使 软件运行发生异常。

---

软件自身：

这里有一个问题：如果软件的自身没有问题，但是 软件部署的环境（网络 / 软件 / 硬件） 出了问题，使得软件不能正常运行的时间。
这个时间是否算入 软件非正常运行的时间里面？
也就是在问你：这个时间是否算入可靠性里面？
这个需要分情况讨论！

总的来说：上面的这四点，都是指 服务器那边 出现的问题 会导致 软件的可靠性降低。

就这么说吧：如果你和其他有人都用不了 微信，那肯定就是 微信服务器 那边出了问题。
而这个非正常运行的时间，需要算入可靠性里面的。

另外，前面也说过：不同的软件对于 非功能性 的 要求是不一样的。
也就是说：不同的软件对可靠性的要求是不一样的。

非时性软件可靠性的要求一般为 99.99 %。【实时性为 99.95 %】
 

---

另外，还有一些特殊的软件（军事系统）对可靠性的要求更高：99.999 %
如果按一年365天来算的话：
可靠性为 99.99 %：它的非正常运行时间大约为 52 min
如果是 99.999 %，则为 5 min；

---

那么，可靠性怎么去测试呢？

通常是将软件运行一周，将出现故障的时间记下来，去计算百分比。
【PS：测试可靠性，让软件运行一年肯定是不现实】

2.1.2 容错性测试

系统发生异常，或者由于用户的错误操作导致软件系统发生错误，软件自我消化掉错误，或者进行修改/修复，不让客户感知到系统内部的情况，就叫做 系统的容错性。

容错性和可靠性的区别：

2.1.3 内存泄漏测试

工作中：
1）人工检查；
2）借助工具进行代码静态扫描；

2.1.4 弱网测试

 那么如何计算上下行速率呢？

2.2 按照是否查看代码划分

黑盒测试
纯功能测试，不关心具体是怎么实现的；
白盒测试
关注程序的内部实现（单元测试）
灰盒测试
介于黑盒和白盒之间（继承测试）

为什么不能让灰盒测试（集成测试）取代黑盒测试和白盒测试？

灰盒测试没有白盒测试那么详尽，灰盒测试没有黑盒测试覆盖产品的广度大。
所以不能让灰盒测试（集成测试）取代黑盒测试和白盒测试；

面试题
那种测试方法用到多？

黑盒测试和白盒测试，测试人员都会使用到，在工作中根据具体情况来
结合黑盒测试和白盒测试。
通常情况下对于测试人员来说：使用黑盒测试要来相对多一些。

2.3 按照开发阶段划分

 冒烟测试：

开发人员完成开发任务后，交给测试人员进行测试的第一步，评估软件/系统是否具备测试的条件 

回归测试：

总结