测试概念概述

一、关于需求

1. 需求的定义：工作时一般分为【用户需求】和【软件需求】

   • 用户需求：
     • 甲方：甲方提出的要求，甲方是给钱的
     • 终端用户：终端用户使用产品时提出的反馈，但用户往往只会说增加XXX功能，具体增加在哪，需要什么样式等信息是没有说明的，需求比较简陋
   • 软件需求：也叫“功能需求”，是程序员拿到的“需求文档(prd)”，该需求文档会详细地描述开发人员必须要实现的软件功能（包括在哪里添加该功能，接口是什么样的……）

2. 为什么要有需求：需求相当于一个标准，开发人员根据这个标准去开发，测试人员根据这个标准去测试，彼此有序，可以提高工作效率

3. 测试人员对需求的处理：
   

4. 如何深入理解需求：阅读需求文档 + 询问他人

二、关于测试用例

1. 定义：测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素
   • 测试环境：编写、运行代码的环境
   • 操作步骤：写测试代码的一系列步骤
   • 测试数据：验证该功能时，编写的一系列用来验证功能的数据
   • 预期结果
2. 为什么【执行结果】不是测试用例的要素：测试用例是测试之前就写好的，但【执行结果】是要执行后才能知道，两者时机不一样，故而不是要素
3. 为什么要有测试用例：
   • 【1】提高测试效率：项目通常情况下，测试人员需要写测试用例来方便我们执行工作
   • 【2】建立自动化的基础：让工具去辅助测试人员进行工作
     测试人员在进行测试时，是自己的思路的，而“自动化”可以帮我们通过代码将这个思路实现
4. 评判测试用例好坏的标准：
   • 测试用例表达清楚，没有二义性
   • 可操作性强
   • 输入输出明确，且只有一个预期结果
   • 可维护性好
   • 对需求的覆盖率高

三、 关于 Bug

3.1 Bug的判断标准

1. Bug的判断标准：【当前程序没有匹配需求文档】或【程序没有实现用户想要的效果】

3.2 如何描述一个bug

1. 为什么不直接把bug面对面告诉开发人员，而是要描述：面对面告诉之后，开发可能忘记修复了，万一测试也忘了提醒，后续上线就会出现问题
   • 测试人员如果发现bug，需要往一个web系统里把bug描述后放进去，开发人员则负责从web系统里捞出bug并修复，如果web系统里面没有bug或bug已经都被修复了，此时项目就可以上线了
2. 一个合格的bug描述应包括的东西：
   • 发现问题的版本：一个软件的每个版本的代码都是不一样的，开发人员需要知道出现问题时的软件版本，这样才可以重现故障。版本的标识也有利于统计和分析每个版本的质量。
   • 问题出现的环境：环境分为硬件环境和软件环境，详细的环境描述有利于定位故障
     • 比如有一项功能可能在手机上无法实现，但在电脑上能实现
   • 错误重现的步骤：描述问题重现的最短步骤
   • 预期行为的描述：在测试用例里面也有，要让开发人员明白怎样才是正确的，最好以用户的角度来描述程序的行为，如果是依据需求提出的故障，最好写明需求的来源
   • 错误行为的描述：描述错误的行为，可以通过截图、录屏、log日志的方式来辅助描述
   • 其他：某些公司可能会有一些其他的要求，比如对故障和优先级的分类
   • 不要把多个bug放到一起：如果无法确认是同一段代码造成的故障，不要放在一起，放在一起后，开发人员可能会只改了一个bug而忘记另一个
3. bug的级别：不同公司可能叫法不一样，理解即可。崩溃和严重出现的概率较小，大多是【一般】+【次要】
   • Blocker(崩溃)：十分严重，程序直接无法跑起来了（系统崩溃、死机、死循环）。需要立即告诉相关人员终止当前版本测试
   • Critical(严重)：系统主要功能部分丧失，用户数据丢失，该问题在不影响其他功能测试的情况下可以继续版本测试
   • Major(一般)：功能没有完全实现，但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性
   • Minor(次要)：性能、界面有缺陷，大多是建议类问题，不影响操作功能的执行
4. 对不同级别的bug的处理方式：如果项目着急上线，【严重】/【崩溃】是一定要修复的，如果是【次要】/【一般】的bug且产品经理可以接受，可以将其放到下一个版本迭代的阶段去优化

3.3 bug的生命周期

四、开发模型和测试模型

4.1 什么是开发模型和测试模型

1. 什么是开发模型和测试模型：我们要以什么方式去展开我们的测试工作
2. 软件的生命周期：指从软件产品的设想到软件不再使用而结束的时间，大致可以分成6个阶段：需求分析、计划、设计、编码、测试、运行维护
   • 需求分析：分析需求的可行性，如果可行，产品经理会产出需求文档
   • 计划：项目什么时候开发，什么时候结束开发，由谁开发，测试确定开始和结束时间……
   • 设计：开发人员需要设计出“软件的架构”，设计人员则需要产出UI设计稿(将文字版的需求文档变成图片的UI设计稿)
   • 编码：编写代码
   • 测试：测试人员去测试代码
   • 运行维护：如果项目上线后有BUG，此时测试人员会协助开发人员定位并解决问题，最终将项目重新上线

4.2 开发模型

什么是开发模型：软件开发的流程

瀑布模型

• 瀑布模型优点：线性的，每个人要做什么事都很清楚

• 瀑布模型缺点：因为测试人员介入需求太晚了，万一项目出现问题，发现问题的时机会变晚

  （1）因为测试人员需要深入理解需求，即较早地介入项目，但这个流程下，测试人员介入得非常晚
  （2）如果介入得太晚，测试人员发现问题就需要回溯，让前面的负责人查代码，直到对应的负责人发现是哪块区域出问题，而一旦前面的出错了，后续的都需要更改，比较浪费时间

• 瀑布模型适用的项目：适用于较小的项目，几十分钟就可以完成，如改变一个按钮的颜色之类的需求。当项目比较大，就不适用了。

螺旋模型

4.3 测试模型

V模型

1. 图示：
   
2. 优点：
   • 线性执行，清晰明了
   • 将测试分成了好几种类型，且每种的关注点都不一样，可以确保软件最终的质量
3. 缺点：测试人员介入需求的时间较晚，这导致了发现问题的时机会比较晚。而每次出现问题，都需要回溯，一旦回溯，相当于前面的白干了。

W模型

1. 图示：
   

2. 因为W模型又像两个V，所以也叫 “双V模型”

3. 优点：测试人员更早地介入需求，能更早发现问题

4. 缺点：测试和开发活动是一种线性的前后关系，上一阶段完全结束，才可以正式开启下一阶段，无法支持敏捷开发模式，无法适应复杂的软件开发情况

五、增量 VS 迭代

六、敏捷

1. 什么是敏捷：是一种思想，由此思想诞生了很多个开发模式
2. 敏捷宣言：敏捷注重什么（不是说后者不重要，只是相比来说，前者敏捷更关注）
   • 个体与交互重于过程和工具：注重人与人面对面沟通，因为如果使用网络设备通信，对方可能没有第一时间回复消息，会有等待响应的时间
   • 可用的软件重于完备的文档：给用户交付的最终的软件比设计出的文档重要
     • 文档：测试用例、需求文档、技术文档……
   • 客户写作重于合同谈判：要和客户达成合作的关系，因为签订的合同不可能把所有的情况都涵盖进去，在出现意外时，要与客户协作，共同适应变化
   • 响应变化重于遵循计划：适应变化

七、scrum

7.1 什么是scrum

敏捷开发中比较流行的一种方式

7.2 scrum 角色

1. product owner：产品经理，简写为 “PO”
   • 主要负责整理需求，然后根据用户的情况，根据优先级排序以决定开发的顺序，确定好执行哪个需求后，制定发布计划（开发和提交的时间，注意，最终的时间由大家协商决定）
2. scrum master：项目经理，简写为“SM”
   • 负责召开各种会议，当研发团队的工作出现了问题了，需要进行协调，主要是为研发团队服务
3. team：研发团队
   • 由“后端开发”、“前端开发”、“测试”这些不同技能的成员组成，他们通过合作，一起完成项目需求

7.3 scrum 的工作流程

八、软件测试的生命周期

和软件的生命周期比较像，但由于是测试，所以相比于前者没有开发的部分

1. 需求分析：分析需求的合理性
2. 测试计划：计划项目开始和结束测试的时间以及由谁来测试
3. 测试设计、测试开发：设计测试用例，开发测试工具
4. 测试执行：执行测试用例，发现、提交、验收bug
5. 测试评估：测试人员产出一个测试报告
   • 测试报告：测试报告保障了项目的安全性
     • 内容：是个文档，大多是以邮件的方式通知下来，虽然每个公司的测试报告内容都不同，但一般都包括了【需求文档、项目名称、项目代码地址、开发人员、测试人员、项目计划(测试计划、开发计划)、测试方法、测试用例、各种状态的bug……】
     • 自己写的项目也可以写一个测试报告，在线文档形式即可

九、执行测试

1. 如何开始第一次测试

   • 确定测试范围
   • 了解已有的测试用例
   • 知道测试的时间
   • 开发人员、测试人员分别都有谁
   • 充分理解需求（可以靠阅读需求文档、技术文档，询问产品经理等人提高理解程度）

2. 执行测试的流程：打开待测试的系统后执行测试用例，当发现bug后，进行复现以确认bug，然后是记录、沟通、验证bug，最后提交测试报告

3. 如何测出更多的bug：

   • 软件测试有二八原则，如果某部分问题较多，要加强该部分测试的深度和广度
   • 开发人员也有二八原则，如果某些开发人员的bug较多，需要加强他开发模块测试的深度和广度
   • 多去看他人的测试用例，培养逆向思维和发散性思维
   • 不要局限于测试用例和需求文档，不要完全依据测试用例去执行，还要根据人的经验去思考
   • 尽早介入项目，这可以让测试人员更加深入理解项目，理解得越透彻，发现的问题也会越多

十、产生争执怎么办

测试一个项目，测试人员发现了一个bug，但是开发人员认为这不是bug

1. 先检查自己是否对bug描述清楚了
2. 站在用户角度上劝说开发修改bug
3. 对bug定级要有理有据：要站在用户的角度上考虑定位级别，往往用户的bug级别和我们的是有区别的
4. 不断提高自己的技术水平，不仅能提出问题，最好还能提出解决方法，以让开发更加信服
5. 不与开发人员争吵：
6. 发起会议：在会议上向其他项目相关人，表述出你的问题以及对应的解决方法，会议最后应得出【bug由谁来解决，是否要解决，什么时候解决】的结论