软件测试有哪些类别
软件测试分类有两种分类，一种是按运行状态，一种是按知晓状态。
- 运行状态有两种：静态和动态
- 知晓状态有三种：白盒、灰盒、黑盒
下面从俩个方面来说明：
对应现实场景（陪老婆逛商场）、测试用例场景
黑盒测试
- 对应现实场景：
老婆从商场的某一个入口进入，按约定她必须在某个固定的出口出来。
你在商场外面等待，并不知道商场内发生了什么，只知道正确的结果是，老婆带着一堆商品从某一个出口出来。
-
测试用例场景：
测试用例
前置条件
测试用例的开始环境
- 星期三晚上7点的沃尔玛超市
- 老婆带着充足的现金
- 非冻结的花旗银行黑卡
- 电量100%、话费1000+移动、联通卡双待的IPhoneXR
步骤
1、开车送老婆到沃尔玛超市
2、从南门送老婆进入超市
3、在北门等待老婆
预期
晚上9点，老婆会提着大包小包商品从北门出现
允许商品（信息）携带量±5%
时间偏差±10%
现象
......
这就是常规操作的黑盒，你不知道里面发生了什么，可能老婆空手出来，可能老婆在里面开了一辆坦克出来，也可能不出来。
你无从知道出现这个结果是什么原因，是老婆与人争执、老婆在商城里面中大奖了、还是你老婆在里面和别人打起了求生之路。
你能做的只能是：“嗨~老婆，要不你再进去走一趟？”
测试用例的多元条件操作
白盒测试
白盒也可以称为代码级测试，这种测试要求大面积开源，测试人员需要有一定的能力和权限，获得开源代码，并且处理开源测试。
这种测试
- 对应现实场景：
这次你是你老婆的丈夫，还是这个商场的建造者&总经理，你要做的不单止要开车送老婆到商城入口，还要开放、调节商场的建筑、商店、设施，运营商城的店铺，管理商城的员工。
当前场景下，你需要陪同你老婆从商场的某一个入口进入，观察老婆行走速度、路径，手上携带的商品，现金、信用卡余量。
观察老婆选择购买商品的时候，对商品进行了什么比较。
检查老婆停在某处的原因，是老婆的问题，还是商店的问题，还是整个商城的问题。
你可以看到你老婆购物、商城运营的每个细节（当然取决于你愿不愿意去看），研究他们运行的规律，并探究出现问题的可能。
然而这样太过全面，工作量很大，所以会划分成几种针对性更强的，小型的软件测试。
- 端元测试
- 压力测试
- 性能测试
- etc.
单元测试
- 对应现实场景：
陪同老婆进入商场，专门吩咐老婆盯着BerBerry扫货。
查看所有新品、查看单一新品、查看活动、查看库存
每周都去，1周3天，1天3次
检查导购员业务流程、查看商店设施
- 测试用例场景：
测试要点
1、银行柜台数量，出口位置，金库门类型
2、银行内部及周边摄像头分布状况
3、银行内外安保力量分布
4、银行客流量及时间段
5、周边街道
6、城镇警力分布
7、团伙武器装备、拆迁爆破装备、跑路车辆
8、团伙分工事项
9、etc.
测试记录
1、银行向西面普通柜台8个，南面普通柜台4个，VIP柜台2个，大堂经理1名，流动接待2名，VIP座位业务专员2名，大堂保安一名，内室保安一名。
2、。。。。。。
【吉米：总督被逮捕了】
压力测试
- 对应现实场景：
克隆两万个老婆，有组织、无组织的同时涌入商场进行扫荡，每天进行，持续一段时间。
看商场是否顶得住，是否会出现断货、服务员暴走、刷卡机宕机等问题。
性能测试：
这个概念比较广，商场稳定性，如能否做到每天开业、24小时开业；商场安全性，保安能否保护顾客安全、防火防盗措施如何。
因此，其实软件测试并不是什么新鲜的概念，我们在现实生活中，一直在对各大商场进行“集成测试”，那么多的商场被各种苛刻的测试所淘汰。各位都是伟大的测试人员，并且，测试是永久存在的，不要幻想产品发布那天的到来。
所以，不要以为测试工作只属于软件工程，太天真了，测试的魔爪是谁也逃不脱的！
测试用例
一、 定义
测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
二、 测试用例的分类
根据测试过程中具体涉及到问题类型及测试需求，可将测试用例分为如下：
●功能性测试用例
●界面测试用例：适用于所有测试阶段中的界面测试
●数据处理测试用例：适用于所有测试阶段中的数据处理测试
●操作流程测试用例：适用于所有流程性的测试
●安装测试用例：适用于所有安装测试
三、 测试用例管理
●编写用例：测试工程师根据需求规约、概要设计、详细设计等文档编写测试用例。
●用例评审：原则上用例像程序一样，要经过多次的修改才可以通过，实际工作中通常进行一次。
●用例修改：评审结束后，您需要根据评审意见进行修改，修改后通常不再进行评审。
●使用用例：执行测试用例，并记录到测试用例执行报告中。
●用例升级 / 维护：随着软件产品不断修改、升级，对应的用例也需要升级维护。
针对同一个项目，可以根据需求的变更不断进行维护；如果是产品，用例的维护更加重要，要达到用例和产品的版本一一对应。
什么是BUG？
英文单词，本意是臭虫、缺陷、损坏、犯贫、窃听器、小虫等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。
我们知道，只要有软件就会有bug。再严格测试也只是抽样活动，总会有bug被遗留下来。基于以上两种原因，软件或者系统发布时总会或多或少带点bug。对于这些bug，我们要看它的影响程度是什么样的。对于生命周期比较长的系统，这些bug只要产生了影响都是要修改的。
BUG测试注意的一些问题
1.清晰地描述Bug：
描述Bug时要用简短的陈述句并能准确指出问题所在。描述中可能需要提供一些步骤来重现这个Bug，同时这个简短Bug描述必须能够准确地表达出问题的本质所在。
2.不要放过你判断：
你主要的目标应该是让你的Bug报告令人信服，以支持你发现的Bug，唯一的目的是让Bug最终关毕。在Bug报告中试着使用外交的表达方式，而不要使用官方的表述来赞成这个Bug，这样你的报告反而会令人不愉快。最好的方法是使用建议的方式。愉快的方式总能被采用。
3．重现的步骤：
如何利用对条件设置的解释以重现并获得Bug的精确点，这必须要在Bug报告中讲述清楚
4.使用简洁的语言：
人们不喜欢读包含复杂的专业术语和绕口的大段的段落。一个好的Bug报告要包含短的但是表达清晰的语子。它应该只包含与Bug有关的论述。不必要把Bug报告做的过于复杂和写太多事实而篇幅过于长。
5.引用相关的例子：
大部分情况下，要重现一个特殊的Bug，必须输入一些特殊的数据。但是不要做模糊的表述，像提供一个联系表中无效的人名并保存，应该说在名字域中输入像035bbb@$%这样无效的输入并点击保存。为了使Bug能快速得到处理，测试人员必须努力提供所有相关的、关键的信息来帮助开发人员。
6.提供参考信息：
以防一个特殊的Bug与说明文档或其他的关于工程的文档相冲突，Bug报告必须得供充分的关于这种特殊情况的参考信息或与文档中相冲突条款的数目。
7.为Bug分配优先级和严重等级
没有为Bug设置严重级别和优先级别的Bug报告是不完整的。
Bug严重级别：
指的是这个Bug破坏系统的危险程度，Bug严重级别说明了这个Bug的破坏程度。Bug的严重级别分为四类，下面进行分别描述：
致命级（P0）：影响程序运行的bug，程序无法跑通，系统无法运行，造成用户完全无法完成操作的bug。例如：崩溃或应用模块无法启动或异常退出、循环报错、无法退出、支付漏洞、重点功能点击无效等
严重级（P1）：造成用户完全无法完成操作的bug。例如：功能无法实现、数值计算错误、普通功能点击无效等
缺陷级（P2）：这类BUG对应用程序的性能没有影响，用户可完成操作，但操作受到阻碍的bug。例如：操作被遮盖，内容显示不全，以及其他界面问题。
任何BUG应当在当前版本发布之前努力去修正他们，如果由于时间的限制，无法修正，可以等到在下个版本中修正。
网友评论