软件系统测试用例-系统用例模型

引言

在软件测试工作过程中或者在面试过程中经常会被问到一些看起来简单但是总是有些回答不上的问题，比如你说说“黑盒测试和白盒测试的区别？”，“你们公司做灰度测试么？", ”α测试和β测试有什么不一样？“，“说说 AB test 的目的什么？”...

诸如此类的一些问题，总有些同学回答不上来，今天给大家总结一下所有的测试类型以及其使用场景。也给大家送400页面试题解析的福利，需要的朋友关注+转发+私信【软件测试】

测试类型详解黑盒测试

软件对于测试员来说就是一个黑色的盒子，测试不知道里面的代码实现，只能看到对软件的输入和以及软件的输出结果。

比如你陪女朋友去逛街，你在外面等着，看着女朋友拿着你的银行卡进去，然后看着她拎着满满的商品出来，你对商场的里的具体情况以及钱具体如何花掉的并不知情。商场对于你来说就是一个黑色的盒子，你不需要知道里面具体情况，只需要知道你女朋友进去然后出来的结果是你的工资卡空了。

白盒测试

沿用我们上面的例子，白盒测试就相当于你陪着女朋友走进去商场里，路线和商品你看得一清二楚，其中逛得过程可能遇到的各种突发问题你也可以知道来龙去脉，虽然结果也是你的这个月工资没了，但是心里敞亮，知道具体怎么没的。

所以，白盒测试就是软件对于你来说是个白色透明的盒子，里面的结构可以一清二楚的展示出来，而你也需要对里面的实现逻辑有一定了解才能进行白盒测试。

灰盒测试

基于黑白之间，不需要具体看每一行代码，但是又需要知道具体实现的逻辑和实现。一般我们的接口测试采用的就是这种测试方法。

功能测试

就是对软件的基本的业务流程和功能的测试，保证软件可以实现用户的基本需求。这是一个最基础要保证的测试。

界面测试

也叫 UI 测试，其实就是看产品的外形好不好看？设计是否合理？排版是否清晰美观？

那关于界面美观的测试标准是什么呢？先问一个问题，这个界面设计是谁定的？没错，是产品设计出来的原型图和 UI 设计师设计出来的 UI 切图。所以，我们测试需要确保软件界面跟最终的效果图一致；其次，也可以站在用户角度上，体验这种界面风格，如果觉得不合适，也可以提 bug。

兼容性测试

一般分为软件和软件之间兼容，软件和系统软件之间的兼容，以及软件不同版本之间的兼容。

比如 B/S 架构的应用，就需要考虑浏览器的兼容，包括浏览器的类型（Chrome，Firefox，IE，360，等），浏览器的版本之间的兼容；

比如 APP 应用需要考虑手机型号的兼容，手机系统版本的兼容，还有不同屏幕大小的兼容等；

比如 PC 端应用，需要考虑操作系统版本（win7,win10,32bit,64bit 等）；

易用性测试

主要测试软件测试是否符合用户使用习惯，以及是否让用户体验便捷和简单。

比如我们一般 windows 的软件关闭按钮都在右上方，如设计出来的软件在左上方就是不符合用户的使用习惯的。当然这个的易用性测试主观性比较强，所以我们需要站在大部分用户的角度去思考，而且也可以多收集不同用户的反馈去做调整和修改。

性能测试

大家在生活中应该有类似的体验，比如双十一或者双十二的集中某个时间付尾款的时候，就经常会出现页面很卡或者打不开的情况，这其实就是一种性能测试的范畴里的现象。

我们在进行功能测试的时候，使用的数据和流量就是普通的流量，所以我们需要确保在极限条件下，数量多、时间长，依然正常。这就是性能测试。这个初级测试人员做的比较少，而且需要借助一些工具或者代码来做。

安全测试

对应用软件的安全性进行测试，比如登录账号的防护，连接的安全出性，扫描系统存在的一些漏洞和安全隐患，这个就需要测试人员对产品有充分的了解，也需要具备丰富的基础知识体系和各种工具、代码的使用能力。所以，一般也是建议从事了测试行业 3 年左右之后再做安全测试。

回归测试

回归测试一般就是指 Bug 被修正之后，或软件功能、环境发生变化后，以及代码被修改或者设计重构之后，需要带原来测试过的功能进行重新测试，确保修改部分不会影响其他的模块。注意这个不是 bug 验证或者修改的功能本身的测试，而且测试其余没有被修改的功能模块会不会受影响。

冒烟测试

这个测试概念来自于硬件测试，电路板的测试人员为了验证一个电路板是否好用，就先给电路板通电，如果一通电就电路板就冒烟了，说明电路板被烧坏了，那么后续详细的测试就不需要就不需要再做了，直接打回给开发重新做一个新的就好了。

这个概念引用到软件测试里，就是针对每一个新的软件版本，会先进行基本主要功能的覆盖测试，确定这个软件版本是可测的，再进行后续的详细测试；如果版本的基本功能都不能用， 那么就直接打回开发重做就好了，不用继续后面的正式的测试。

探索性测试/自由测试

探索性测试是没有详细的需求，也没有具体的方法，更没有测试用例作为依据，全靠测试人员的经验和知识储备去发散测试。

所以软件系统测试用例，这种测试对测试人员有很高的要求，需要丰富的经验积累和自我知识沉淀，所以在公司里基本不会作为一种单独的测试方法进行覆盖，可以作为一种补充。

单元测试

一般是在开发阶段，开发自己做完了一个小模块，自己做的单元测试。所以单元测试需要开发人员对代码进行测试，很多公司都是由开发人员自己进行，也是软件测试第一个阶段要做的一种的测试。

集成测试

如果说刚刚第一阶段做的单元测试是针对单个单元进行的测试，那么集成测试就是进行了简单的拼接之后的测试。测试单元之间的交互和传输。我们常说的接口测试就是一种集成测试。

系统测试

系统测试就是整个软件已经完整可见了，所有的单元都组合在一起，成为一个完整的软件了，可以看到界面并可以操作。这种测试测试测试人员首要包保证的一种测试，因为这是最贴近用户场景的一种测试。

系统测试的结束也就意味着测试人员的工作结束了。

验收测试

验收测试就是最后来验证软件是否达到最开始的需求的一种测试，所以这个测试一般不是测试做的。具体由谁来做可以分情况说：

1.项目如果是由甲方爸爸（客户）驱动的，那会有客户那边做验收测试，看是否满足了他们的需求

如果不是客户驱动的，由公司内部产品和老板自主研发的，那么验收测试就是由产品或者老板自己做的。

不管验收由谁来做，如果验收没有通过，会打回到测试部门，重新进行系统测试。

α测试

这个测试不是所有的公司有，一般是大型的公司大型项目才会有，而且是在系统测试之后，产品基本没有什么 bug 之后做的。α测试不是测试人员自己做的，是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。它还是在公司里内部进行，尽量模拟用户使用的场景进行的测试。

一般开发者和测试人员可以在测试现场，可以随时记录下错误和使用中出现的问题及时修复，但是测试不由测试人员进行。

β测试

β测试也一般是较为大型项目才会有的，跟α测试的区别就是不在测试环境下测试了，而是到真实用户使用环境下进行，或者在客户现场做的测试。一般开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。

在软件临近发布的最后阶段，公司会找一些合作方，把产品部署进去 beta 几个月之后，再正式上线，避免严重问题。或者直接发布一个 bata 版本召集用户进行公测，让用户帮忙发现问题。

灰度测试

系统测试通过后，将测试版本发布到线上环境，替换部分的线上服务器进行预测试。在灰度测试结束后，如果没有问题，线上版本实现会统一。所以灰度测试，本质上是上线前的测试，收集用户的反馈。

AB 测试

AB 测试跟灰度测试差不多，也是指的是系统测试通过并发布后，同一个软件功能针对不同的用户进行分组：A 组用户和 B 组用户，不同组的用户会看到不同的实现方式软件系统测试用例，目的也是收集每个用户对新版本的反馈。如果没有问题，再实现统一。

动态测试

测试对象在运行的测试，比如微信在使用，就是一种动态测试。我们做的大部分的软件测试都是动态测试。

静态测试

程序没有在运行，比如代码走查，或者软件文档测试，就都是静态测试。

手工测试

就是测试人员手动的点点点测试。

自动化测试

使用工具或者代码的方式替换手工测试，释放人力的一种测试方法。