软件测试基础概念篇

阶段	概念解释
需求分析	分析用户提出的需求是否合理(市场分析，技术分析，可行性分析等)
计划	确认需求需要执行多久，对需求进行详细计划
设计	将需求细化为一个个任务
编码	开发人员按照需求进行编码
测试	测试人员参考测试用例执行各种测试
运行维护	项目上线之后对产品进行线上的维护（修复性维护：对项目中未发现的问题进行修复；完善性维护：对功能进行完善；预防性维护：为了避免产品在线上出现一些问题所进行的预防手段）

三、开发模型介绍

1、瀑布模型

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

特点：线性的开发流程

缺点：测试被后置（风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会；必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户），瀑布模型最大的缺陷在于可以运行的产品很迟才可以被看到。

适用场景：需求固定的小项目

2、螺旋模型

螺旋模型引入全流程的风险分析，每次分析完成之后都会生成一个新的原型

优点：强调严格的全过程风险管理

缺点：时间拉长、耗费人力资金

适用场景：规模庞大、复杂度高、风险大的项目

3、增量模型和迭代模型

增量模型：假如用户有A,B,C三个需求，开发完A就可以直接供给用户使用，开发完B就可以直接供给用户使用......

迭代模型：先开发一个简单的基础版本(包含功能A,B,C)，但是功能实现的比较简单，后续会在基础版本上不断进行迭代优化

4、敏捷模型

敏捷宣言：

特点：轻流程，轻文档，重目标，重产出

敏捷开发有很多种方式，其中scrum是比较流行的一种。

三个角色和五个会议：

产品经理：收集用户需求，编写需求文档，对产品负责的人

项目经理：负责召开各种会议，协调项目，为研发团队服务

研发团队：开发人员，测试人员，ui设计人员等等

发布计划会议，迭代计划会议，每日例会，演示会议，回顾会议

scrum的基本流程：

●产品负责人负责整理用户需求，形成左侧的product backlog。

●发布计划会议: product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

●迭代计划会议︰项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。

●每日例会:每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

●演示会议:迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

●回顾会议:项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

四、bug的相关描述

1、软件测试的生命周期

阶段	解释
需求分析	站在用户的角度：查看需求是否符合用户的行为习惯；站在开发人员的角度：思考希求是否可以实现以及实现的难度大小
测试计划	制定测试计划(不仅仅只有测试人员...)
测试设计、测试开发	设计测试用例，比如经验丰富的白盒测试人员进行单元测试
测试执行	参考测试用例执行测试
测试评估	测试人员记录测试过程数据，做好缺陷管理并进行测试评估

2、如何描述一个bug

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

部分	解释
发现bug的版本	开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
发现bug的环境	环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是 app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
发现bug的步骤	描述问题重现的最短步骤。
预期的结果	要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
实际的结果	描述错误的现象。crash等可以上传log，UI问题可以有截图。
其他	bug类型以及bug等级等等
注意事项	在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

3、bug的级别

注意：每个企业的定义可能不同，这里提供一个参考

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

4、bug的生命周期

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。无效的bug：open->closed open-rejected-closed

五、软件测试模型

1、软件测试v模型

●明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系 ●V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求 ●局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

2、软件测试W模型

●W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 ●W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的 ●W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。 ●局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。