软件测试基础

目录

软件测试相关概念

测试

需求

测试用例

开发模型和测试模型

开发模型

测试模型

软件测试的生命周期

如何描述一个bug

产生争执怎么办（处理人际关系）

---

软件测试相关概念

测试

1.什么是软件测试？

软件测试就是验证软件产品特性是否满足用户的需求。

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

2.测试和开发之间的区别

（1）工作内容

开发：通过各种编程语言开发软件。

测试：写测试用例，执行测试，自动化测试，性能测试开发测试平台。

（2）技术区别

开发：开发要求精和深

测试：技术要求广

3.测试和调试之间的区别

（1）目的不同

调试：发现问题，解决

测试：发现问题

（2）人员不同

调试：开发调试

测试：测试+开发（部分的白盒测试开发人员完成，剩余的一些白盒测试由测试人员完成）

（3）阶段不同

调试：边写代码边调试（调试一般在开发阶段）

测试：贯穿整个软件生命周期，测试比调试介入早。

（4）手段不同

调试：debug

测试：黑盒测试方法，白盒测试方法

4.测试人员需要具备的素质

编码能力，较强的学习能力，文字表达能力（报告反馈、测试用例、测试报告），沟通能力。

需求

5.什么是需求

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

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成 的任务。该需求一般比较简略。

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求 软件需求是测试人员进行测试工作的基本依据。

测试用例

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

为什么要有测试用例？

1.提高测试效率

2.建立自动化的基础

软件测试(Bug)的概念

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

开发模型和测试模型

软件的生命周期
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

需求分析：分析需求的可行性，产品经理产出需求文档

计划：项目什么时候开发，什么时候结束开发，由谁开发，测试确定开始结束时间

设计：

开发人员：软件的架构

设计人员：设计师产出UI设计稿

编码：编写代码

测试：测试人员提交bug，发送测试报告

运行和维护：项目上线有bug,此时测试人员要协助开发人员定位问题，解决问题，最终让项目重新上线。

开发模型

软件开发的流程

瀑布模型（waterfall model）

优点：线性的，每个阶段要做什么事情非常明确。

缺点：测试人员介入需求太晚，发现项目问题的时机太晚。

适用于小项目。

螺旋模型（Spiral Model）

对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的 要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

优点：

强调严格的全过程风险管理。

强调各开发阶段的质量。

提供机会检讨项目是否有价值继续下去。

缺点：

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

增量、迭代

增量：ABCD（先开发A模块，在开发B模块，C模块，D模块）

迭代：ABCD各开发一部分（框架）-----再开发接口-----方法

敏捷

scrum

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。

scrum master 负责召开各种会议，协调项目，为研发团队服务。

team研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

测试模型

V模型

优点：线性执行，将测试分为不同类型

缺点：测试人员介入需求较晚，发现问题时机晚

w模型

优点：测试人员可以更早的介入需求

缺点：不能拥抱变化，不能使用于敏捷

特点：第一个V是开发流程，第二个V是测试流程

软件测试的生命周期

软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

需求阶段：测试人员了解需求、对需求进行分解，得出测试需求

计划阶段： 根据需求编写测试计划/测试方案

设计阶段 ：测试人员适当的了解设计，搭建测试用例框架，根据需求和设计编写一部分测试用例

编码阶段 ：测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。

测试阶段 ：测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中 记录、管理缺陷，测试完成后编写测试报告。

运行维护：测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

如何描述一个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

如何发现更多的bug？

1、加强测试广度 和深度

2、多进行逆向思维和发散性的思维

3、不要局限于用例和需求文档

4、尽早介入项目, 不要等到开发的差不多了再介入项目

产生争执怎么办（处理人际关系）

1、先检查自身，是否bug描述不清楚

2、站在用户角度考虑问题。应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修改Bug

3、BUG定级要有理有据

4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案

案例： 某网站经常隔几天访问时会出现500错误，但是之后就不会复现。

测试人员会提出问题：网站偶发性出现500错误。

开发人员回答：不常见，不影响使用，暂不修改

资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改连接池配置定期校验连接

开发人员处理：修改xml，增加校验配置项

5、开发人员不接受时，不要争吵

6、发起会议，表述问题和解决方案