【测试】-基础概念

当我们要学习测试时，需要对测试有一个基本的了解，了解基础概念以及常见的理论知识，对我们今后的学习打下良好的基础。本编对测试的概念，需求的理解以及什么是BUG进行简单学习。

---

什么是测试

测试是测试人员验证软件特性是否符合需求的过程，最常见的理解就是找BUG，发现缺陷。

软件测试的特点

软件测试只是一个样本试验，具有不可穷尽性。

软件测试与开发的区别

难易程度来说：开发广度小，专业度高。测试广度大，专业度低；
技能要求来说：测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理解，编程能力

软件测试与调试的区别

目的不同
——调试(Debug)：确保程序做了程序员想它做的事情
——测试(Testing)：确保程序解决了它该解决的问题
参与角色不同
——测试由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。
——调试由开发人员完成。
执行的阶段不同
——测试贯穿整个软件开发生命周期
——调试一般在开发阶段。

衡量软件测试结果的依据—需求

测试是测试人员验证软件特性是否符合需求的过程，所有我们也需要了解什么是需求以及需求的划分。

需求概念

需求：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

需求的划分

大多数的需求分为软件需求和用户需求
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

用户需求就是一句话，软件需求则是一个文档（详细描述用户需求如何实现），而我们日常工作通常使用软件需求进行开发测试

为什么要有需求

需求是测试人员开展软件测试工作的依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例

测试用例

我们理解了需求，分析出了每个软件功能需求点对应的多个测试需求点，接下来就需要对每隔测试需求点设计测试用例，接下来了解什么是测试用例以及测试用例的各个要素

什么是测试用例

测试用例是一组集合，测试环境，测试数据，预期结果，操作步骤

测试用例的作用

1.测试用例提高测试人员工作效率/减低测试人员工作的重复性问题
2.测试用例是建立自动化的基础

BUG（软件错误）

软件测试人员就是需要找BUG，发现缺陷。什么是BUG，BUG的的等级，如何描述一个BUG，BUG的生命周期。

什么是BUG（软件错误）

BUG（软件错误）的一般定义：程序与规格说明之前不匹配 。
准确的来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是BUG（软件错误）。

BUG（软件错误）的等级

1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4、Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

BUG（软件错误）的描述

可分为这几个方面：环境、测试数据、操作步骤、执行结果、优先级
注意：
1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述（操作步骤）
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。（执行结果，预期结果）
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

BUG（软件错误）的生命周期

 测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

产生争执后的处理

当我们测试时与开发人员发生争执时应该怎么做？

① 确保操作没有问题，确保自己对需求的理解的没有问题
② 好好说
③站在用户角度进行问题的思考
④发现问题的同时，提出解决问题的方案
⑤进行第三方会议（开会之前：明确问题的产生原因，问题是什么，解决方案是什么，开会之后：问题要不要解决，什么时候解决，谁解决）