【测试】测试基础

软件测试的概念

软件测试：软件测试就是你拿到一个软件，对它进行操作，看它的结果和需求说明书或者用户的期望是否一样。

软件测试的两个目的

1. 找bug；
2. 验证bug的正确性；

为什么要做软件测试？

• 可以举例来说明。

测开与研发的区别？

• 相同点：都要遵循代码的编写规范，测试人员也需要了解开发框架的设计，也要了解需求，参与需求的评审。
• 不同点

难易程度

• 开发广度小，专业度高；测试广度大，专业度低。

薪水

• 中小企业总体比研发低，自动化等专业测试领域和研发基本无差距，大厂研发测试基本无差别。

发展前景

• 自动化测试、安全测试等领域发展前景和研发基本一致。

繁忙程度

• 一般比研发轻松，但敏捷开发模式下差距不大，产品发布前压力比较大。

技能要求

• 测试要求更广泛，比如业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理解，编程能力等等。

测试与调试的区别

目的不同

• 测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题。

参与角色不同

• 测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行，调试由开发人员完成。

执行的阶段不同

• 测试贯穿整个软件开发生命周期，调试一般在开发阶段。

一个优秀的测试人员需要具备的素质

思维模式

• 逆向思维：开发盖房子，测试拆房子。不走寻常路。
• 案例：手机中有两条通话记录，进行删除。删除为0后，继续删除。
• 发散性思维：探求多项答案
• 案例：测试一台自动售票机。正向，逆向，边界，压力，性能，耗电量，断电，外观，没零钱.....

需求

分类

• 需求分为用户需求和软件需求。

概念

• 需求就是把用户想要实现的功能和期望转换为软件需求。

用户需求和软件需求的区别

• 用户需求比较粗略，很简单，有时候就一句话；
• 软件需求比较详细，软件需求可以指导研发人员进行设计与编码，指导测试人员进行测试用例的编写。

如何将用户需求转换为软件需求？

• 通过多次的沟通，最终把用户需求转换为软件需求。

缺陷

• 缺陷：对软件进行测试，测试出来结果和测试用例的预期结果不一致，这就是缺陷。

测试用例

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

五种开发模型

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点

• 强调开发的阶段性；
• 强调早期计划及需求调查；
• 强调产品测试。

缺点

• 依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
• 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
• 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会；
• 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险；
• 在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

瀑布模型：适合需求变更比较小的项目。

螺旋模型

螺旋模型是一个渐进式的模型，强调的是风险。 螺旋模型比较适合：规模庞大、复杂度高，风险大的项目。

优点

• 强调严格的全过程风险管理；
• 强调各开发阶段的质量；
• 提供机会检讨项目是否有价值继续下去。

缺点

• 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求，需要人员、资金和时间的投入。

增量、迭代

增量

增量：对于没有任何关联关系的功能模块，可以继续累加。

迭代

• 迭代：你想要增加一个功能，要考虑新增功能对前面功能的影响，有可能新增功能后，前面的功能不能用了，要考虑前后关联的关系。

增量和迭代的区别

• 例如画一幅人物画，增量是逐块建造的概念，我们可以先画人的头部，再画身体，再画手脚；
• 而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

增量和迭代的目的：降低项目的风险，它是把一个大型项目分成模块去做。

敏捷

敏捷价值观

• 强调沟通；
• 轻文档；
• 强调客户参与；
• 拥抱变化。

敏捷特点

• 迭代速度比较快（1-4周）。

敏捷开发模型的流程

1. 产品负责人整理user story（用户故事），放到产品的backlog。
2. 发布版本的迭代会议，讲解用户故事(即需求规格说明书)，确定本次迭代要做哪些内容；
3. 迭代计划会议，分配user story并评估完成时间点，我们要定下来这个任务要拆分给那个研发人员，研发人员需要评估你需要多久来完成它。
4. 每日例会：团队成员回答昨天做了什么今天计划做什么，有什么问题。
5. 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
6. 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

敏捷中的测试

• 挑战1：轻文档
• 挑战2：快速迭代

如何应对敏捷中的测试？

• 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主；
• 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试；
• 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因。

软件开发的生命周期

• 需求分析--计划--设计--编码--测试--运行维护。

软件测试的模型

软件测试V模型

 

在V模型中，需要测试人员介入的阶段有：

1. 用户需求：了解需求，编写测试计划。
2. 编码阶段：测试人员进行测试用例的编写。
3. 系统测试：

• 搭建测试环境；
• 数据准备；
• 执行测试；
• 缺陷管理；
• 编写测试报告。

验收测试是由用户进行的。

V模型的缺点

• 软件测试的V模型是串行的，v模型，测试人员介入的比较晚，缺陷发现的阶段比较晚，修改缺陷的代价比较大；
• 把系统测试放在了最后面，让人误以为测试不重要，把大部分时间留给了开发人员，导致最后出现问题时，修改缺陷的成本会变高。

V模型的优点 把测试线单独提出来，强调测试的重要性。