软件测试基础篇(2)

一)什么是需求？

甲方:简要描述要实现一个啥样的功能，要想什么？怎么来实现不关心不关系，就是简单的提出一个要求？比较简略，终端用户使用产品的时候必须要完成的功能；

软件需求:也叫做功能需求，功能需求是详细具体的描述开发人员必须要实现的软件的功能，大多数公司会将用户需求转化软件需求，进行技术可行性分析和市场可行性分析

有些要求不一定能实现，只要用户提出需求就要实现吗？所以需要对用户的需求进行需求分析，是否具备可行性:市场可行性(能实现但是没人买)+技术可行性(技术是都可以实现，技术实现是否有困难，投入的人力时间成本是否远远大于市场收益)

需求分析:有市场+技术实现也很简单，以及风险评估

软件需求是用户需求转化而来的，它是用户需求的细化，是用户需求的具体实现细节和规范
用户需求比较粗略，直接实现会有困难，因为没有细节，所以需要软件需求把用户需求细化和规范，把用户需求变成一个具体的可实现的过程文档

用户需求不能作为开发人员和测试人员的依据

1)每个人想法不一样

2)市场可行性和技术可行性分析，用户需求不合理；

3)细节实现太少，没法开发和测试

1)用户需求:很简单，只是一个简单的描述，没有具体的一个实现细节，比较简略

2)软件需求:用户需求的具体实现细节，开发人员根据软件需求来进行开发，测试人员根据软件需求来完成测试，作为一个参考依据，根据用户需求编写需求文档是产品经理的活，所以说产品经理是收集用户需求，最终将用户需求转化成软件需求，用户需求是无法直接作为开发和测试的依据的；

1)用户需求:

1.1)面向人群:市场业务的调研人员(广大用户群体)，业务人员，比如说银行系统，boss老板的想法，针对某一类型的人使用

1.2)只是一个简单的描述(很简单)，没有具体的实现细节

1.3)做一款社交软件，是不能直接交给开发人员来进行开发的，每一个人的想法是不一样的;

2)产品经理进行分析软件需求:分析用户需求进行验证，把用户需求转化成软件需求文档，整理分析出具体用户需求的功能的具体细节，聊天，群聊，发视频，转账，扫码，小程序，表情包；

3)开发人员进行根据软件开发文档编码

4)测试人员要根据用户需求，和软件需求文档里面的细节来写测试用例验证开发人员的实现的功能是否满足了这些需求；

为什么需求对软件测试人员如此的重要？需求是软件测试人员开展软件测试的依据

在进行涉及具体的测试用例的时候，首先要搞清楚每一个业务需求对应的多个软件功能需求点，然后进行分析出每一个软件功能需求点对应的多个测试需求点，然后再来根据每一个测试需求来分析具体的测试用例，业务需求，软件功能需求，测试需求点，测试用例

1)从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
2)对于识别出的每个测试需求点需要采用具体的设计测试用例的方法来进行测试用例的设计 

3) 测试人员是根据测试需求点来编写测试用例，连需求文档和参考文档都没有，是没有办法设计测试用例的

重要:那么如何深入理解被测试软件的需求呢？

5.1)只需要测试工程师在需求分析和设计阶段就开始进行介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机，测试应该贯穿于软件开发的整个生命周期，因为软件需求是测试人员编写测试用例的依据，整个软件开发的生命周期测试人员都应该参与；

5.2)只有真正的了解了业务原始需求之后，才可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到对端的比较高的测试用例；

根据具体实例来理解用户需求和软件需求

软件需求规格说明书:

一)用户需求:平台支持邮箱注册

二)软件需求:

2.1)注册账号

2.1.1)功能概述:用户可以通过填写邮箱信息在平台注册个人用户

2.1.2)用户角色:匿名用户

2.1.3)前置条件限制:无

2.1.4)输入(填写注册的人的个人的一部分信息):

姓名，电子邮箱，密码，确认密码，验证码，注册操作

2.2.4.1)各种输入最短长度和最长的长度，以及是否必填，长度以及类型做了限制

2.2.4.2)清晰地看出测试从哪方面来进行测试，这样就有了测试用例编写的依据，比如说长度，直接就可以看出开发什么点，测试什么点，如果你直接给一个用户需求，那么就不能清晰地看出开发什么和测试什么，有了软件需求，开发人员就知道开发什么，测试人员就知道测试什么；

2.2)基本事件流(注册流程)

2.2.1)用户选择注册:系统展示用户协议界面，并请求用户是否同意用户协议，等待用户是否同意点击

2.2.1.1)如果说用户不同意这个协议，那么系统直接禁止用户进行系统注册

2.2.1.2)如果说用户同意协议，那么用户进行注册信息的填写

 2.2.2)用户填写注册信息:注册个人，填写姓名，电子邮箱，密码

2.2.3)点击提交按钮，用户提交注册信息

 2.2.4)系统提示用户并向用户注册的电子邮箱中发送一封含有激活信息的电子邮件，系统并进行提示用户如果说您没有收到激活邮件，那么可以使用注册的邮箱和密码登录系统之后再次进行激活

2.2.5)用户可以直接进行激活操作，直接跳转到注册邮箱门户界面

2.2.6)用户可以直接通过收到的电子邮件中的信息激活账号，用户注册完成，流程结束

扩展事件流:和具体的注册流程没关系

用户注册并且激活成功之后，第一次登陆平台的时候，提示用户完善信息

异常事件流:

1)如果用户没有收到激活邮件，可以在登录界面录入电子邮件以及密码之后，再次发送激活邮件(因为网络原因，系统原因)；

2)用户每一次发送的激活邮件，仅仅在发送邮件的24H之内有效，超过24H之后，需要重新发送邮件，不能在原来的激活邮件里面完成注册；

针对用户短短的一句话，通过一句用户需求的总结出了这么多的软件需求，对于软件开发流程以及输入字段的一些限制，非常清晰明确，所以才可以作为软件开人员以及测试人员的工作的依据

整理软件需求编写需求文档是产品经理的工作，产品经理会整理收集用户需求转变成软件需求，测试人员要依据软件需求文档设计测试用例；

二)BUG是什么？

软件需求文档/软件需求说明书/规格说明书

1)当且仅当软件需求规格说明书存在正确并且要合理，软件程序功能和软件需求不相符，软件功能和软件规格说明书不相符合的地方就是软件错误

就算程序没有出现崩溃，那么也是BUG

2)软件需求也就是软件规格说明书不存在，如果用户需求存在且合理，软件功能和用户功能需求不符合，说明是软件错误，这是以终端用户为准，当程序的功能不符合终端用户的最终的合理预期的时候就叫做软件错误；

3)软件功能和软件规格说明书不相符合，也就是说如果规格说明书中没有提及到的功能，判断标准是用户需求，当我们的程序最终没有实现其最终用户合理预期的功能要求和使用要求的时候，就是软件错误:

3)什么是软件需求合理？什么是需求不合理？

老板或者使用我们系统的业务人员，用户，提出的一些功能看似很美好，如果实现了这个功能，那么使用这个软件就很方便了，但是在我们的目前的实现水平之下，完全没有办法实现，综合目前的技术水平和环境，都是不合理的需求;

软件规格说明书是产品经理写出来的，产品经理也有可能写错；

当且仅当软件规格说明书存在并且正确，程序和规格说明书直接的不匹配就叫做软件错误，当需求规格说明书没有提及到的功能，判断标准以最终用户为准，当程序最终没有实现用户合理的心理预期的时候，就是软件错误

测试时贯穿于软件的生命周期，那么什么是软件的生命周期？

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

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

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

1)需求分析:分析用户需求是否合理，从市场+技术层面进行分析

产品经理在进行收集用户需求的时候，要进行需求分析，分析需求是否合理

市场可行性分析和技术上分析，产品经理最终要把用户需求转化成软件需求文档

因为用户的需求是五花八门的，不能作为项目推进的一个依据，还有分析需求是否可行

2)计划:指定需求计划，产出计划文档

指定需求和项目周期制定执行计划

2.1)项目执行多久，消耗的时间，什么时候开发开始，什么时候开发结束，什么时候上线供用户使用；

2.2)从人力和物力去进行计划；

3)设计:产出设计文档

3.1)将需求细化成一个一个一个的任务，划分出多个软件功能

3.2)进行技术设计，设计哪些接口，采用哪些技术

4)编码:

开发人员按照需求文档(软件需求)以及产出设计文档进行编码

5)测试:

测试人员参考测试用例进行测试

6)项目上线以及线上维护产品

修护性维护:线上暴露问题进行维护，针对项目中的未发现的问题进行修复，漏测的测试用例

完善性修复:对功能进行完善和优化

预防性维护:居安思危，考虑可能出现的问题，线上如果出现问题了，线上请求突然增多，能不能进行自我完善呀，稳定性够不够好，影响用户使用，为了避免产品在线上出现了一些其他的问题，而进行的一些预防的手段；

设计:推动项目的执行