测试基础总结

学习软件测试我们需要弄清楚软件测试的目的和原则，需求，BUG,测试用例等等

什么是软件测试？

主要就是两点：
（1）找bug
（2）对功能的正确性进行验证，看功能是否符合用户的需求

---

研发和测试的区别是什么呢？
研发：完成任务的开发，功能的实现
测试：验证研发的功能的正确性

软件测试的目的和原则

软件测试的目的：验证软件有或没有问题
软件测试的原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

---

还应该弄清下面几点：
（1）好的测试方案是尽可能发现迄今为止尚未发现的错误的测试方案。
（2）成功的测试是发现迄今为止尚未发现的错误的测试。
（3）测试并不仅仅是为了找出错误，通过分析错误产生的原因，阶段及错误发生的趋势。
 （1）帮助管理者了解当前软件开发过程中的缺陷，以便及时纠错改进。
 （2）帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。
 （3）让开发人员知道错误产生的重灾区，加强自测试。
 （4）让客户清楚我们专业的质量保证团队
（4）没有发现错误的测试也是有价值的，完整的测试是评估软件质量的一种方法。
（5）从测试的目的出发，大概可以分为两类：为了验证程序能正常工作的测试； 为了验证程序不能正常运行的测试。

什么是需求？

需求可以分为用户需求和软件需求
用户需求：可以简单理解为甲方提出的需求
软件需求：也可以叫功能需求，详细的描述了开发人员必须实现的软件功能，是测试人员进行测试工作的基本依据。

什么是BUG？

bug就是与正确的需求不一致或者与用户期望不一致，（要保证是正确的需求）

BUG（缺陷）的描述（如何描述）

下面是一个完整的bug:

一个合格的bug描述应该包括以下几个部分：

（1）发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
（2）问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
（3）错误重现的步骤
描述问题重现的最短步骤。
（4）实际结果和预期结果
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
（5）错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
（6）要有bug的等级
定位好等级，到底是一个致命性bug，严重性bug，一般性bug还是一个建设性bug。

**例如邮箱注册：**
编号：regedit_001
标题:邮箱注册提交报500失败
环境：win10+IE11
步骤：
（1）进入163首页
（2）点击“注册免费邮箱”
（3）输入页面上的所有信息
（4）点击“已发送短信，立即注册”
实际结果：
页面报500错误
预期结果：
页面提示“发送成功”

bug的级别

**（1）致命性（1级bug）：**通常表现为系统无法运行，系统崩溃，主要功能模块无法使用。
**（2）严重性（2级bug）：**主要功能存在严重缺陷，但不影响系统的稳定性。
（3）一般性（3级bug）：界面、性能缺陷；边界条件下错误。
（4）建设性（4级bug）：比如界面颜色搭配不好，文字排列不整齐，界面的格式不规范。

bug的生命周期

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

无效的bug：Open —> Closed Open —> Rejected —> Closed

作为测试人员如何发现更多的bug呢？

（1）软件测试存在二八原则，即80%的故障集中于20%的模块，如果某部分的问题较多，加强测试广度和深度。
（2）开发人员也存在二八原则，80%的故障集中于20%的开发人员,如果某些开发人员的bug较多，加强他开发模块的测试广度和深度。
（3）多进行逆向思维和发散性思维
（4）不要局限于用例和需求文档
（5）尽早的介入项目。

与开发人员产生争执（处理人际关系）

（1）先检查自身，是否是bug描述的不清楚
（2）站在用户的角度考虑问题，让开发人员了解到bug对用户造成的困扰。
（3）bug的定级准确
（4）提高自身的技术和业务水平，不要光提出问题，最好也能提出解决方案
（5）即使开发人员不接受，也不要争吵。

什么是测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

---

怎样写测试用例？
(1)理解需求文档，整理为测试用例。
(2)假设具体场景来编写测试用例
(3)利用等价类划分，边界值，因果图，错误猜测法，场景分析法等编写测试用例。

软件/软件测试的生命周期

（1）软件的生命周期：需求分析-----计划-----设计-----编码-----测试-----运行维护
（2）软件测试的生命周期：需求分析----测试计划----测试设计----测试开发----测试执行----测试评估
需求分析： 主要就是阅读需求，理解需求，分析需求点，参与需求会议的评审，确认需求范围
制定测试计划： 进度安排，时间人力安排，软件类，工具类的资料，风险等。
测试设计： 测试用例的编写。
测试执行： 执行测试用例、缺陷管理
测试评估： 编写测试报告（测试结论、对缺陷分析）