熟悉阶段:软件测试流程


4.1软件测试环境搭建原则—环境测试必知必会

                              破剑式—软件测试流程

4.1.1搭建测试环境前:

(1)确定测试目的:

功能测试,稳定性测试,还是性能测试,测试目的不同,搭建测试环境时应注意的点也不同。

功能测试:不需要大量的数据,需要覆盖率高,测试数据要求尽量真实。

性能测试:可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置。

(2)测试的软件环境尽可能的模拟真实环境:

①尽可能的模拟用户使用环境,选用合适的操作系统和软件平台。

②了解符合测试软件运行的最低要求及用户使用的硬件配置。

③了解用户常用的软件,避免所有配置所有操作系统下都要进行测试,没有侧重点,浪费时间。

④产品化的测试则需要考虑兼容性的方案。

(3)营造独立的测试环境

①不同的项目、不同的公司会对测试环境的独立性有不同的要求。

②测试过程中尽量保证测试环境独立,不会受到其他测试人员以及项目研发人员的影响。

(4)构建可复用的测试环境

①通过备份或数据隔离的方式。

②重复运用一套测试环境进行多版本多时间段的测试。

4.1.2搭建测试环境过程分析:

(1)线下搭建

①找到独立测试服务器或虚拟机。

②进行测试环境的相关配置。

③测试项目导入

测试环境配置的例子:

①配置java环境(下载jdk并配置环境变量)。

②下载并安装中间件(tomcat、jetty或其它)。

③安装数据库并导入初始化脚本。

(2)Docker模式:

①构建属于自己的image。

②一键deploy(推出去)。

(3)依赖第三方平台

依赖第三方平台(如蚂蚁金融云)。

4.2测试环境的建设落地—将测试工作真实落地

4.2.1环境建设思路

(1)需要考虑的点:

①用途。

②使用成本。

③维护成本。

(2)基本架构:

①研发环境:用于研发自测、集成测试。

②测试环境:用于日常单系统或两两微服务之间测试,可同时集成自动化测试回归。

③联测环境:完备环境,用于大型联测。

④外联环境(如果有需求):稳定版本环境,用于外部商户等联调。

⑤灰度/沙箱环境:用于生产数据测试,仿真测试。

4.3测试过程—无过程,就不会测试

4.3.1简单的测试过程


测试过程


4.3.2测试过程划分


测试过程划分

①在逻辑上,测试活动是按顺序进行的。

②在实际测试过程中,这些活动是可以重叠或同时进行的。

4.4测试策划概念—良好的测试来自策划

4.4.1测试策划过程


策划过程


①进行测试需求的分析。

②确定需要测试的内容或质量特性。

③明确测试的充分性要求。

④提出测试的基本方法。

4.4.2测试策划过程中我们想要做的几件事:

①确定测试的资源和技术需求

②进行风险分析与评估。

③根据上述分析结果制定测试计划。

④根据测试计划开展相应的测试控制活动。

4.5需求测试——学会读懂需求很重要

4.5.1需求分析

定义:

         过往的软件生命周期中,需求分析阶段是没有测试人员参加的,但随着软件过程的优化,测试人员的加入对需求分析阶段有了更大的作用。

①测试工程师参与需求分析,对需求了解很深刻,减少与开发人员的交互,节省时间。

②早起确定测试用例的编写思路,为测试打好了基础。

③可以获取一些测试数据,为测试用例设计提供帮助。

④可以发现需求不合理的地方,降低测试成本。

4.5.2需求测试的作用

①测试需求的分析用来确定整个测试工作,明确测试对象以及测试工作的范围和作用,并作为测试覆盖的基础。

②被确定的测试需求项必须是可核实的,测试需求必须有一个可观察、可评测的结果。

③如果无法核实的需求就不是测试需求。

④测试需求分析还包括与客户的交流以澄清某些混淆。

⑤明确哪些需求更重要。

⑥确保风险承担者尽早地对项目达成共识。

⑦对将来的产品有个清晰地认识。

对于内部:

①测试需求是制定计划的基本依据。

②测试需求是设计测试用例的指导。

③确定了要测什么、测哪些方面才能有效设计用例。

4.5.3需求验证

(1)审查需求文档

①对需求文档及相关模型进行仔细检查。

②另外在需求开发期间所做的非正式评审也是有所裨益的。

(2)以需求为依据编写测试用例

①编写用户手册。

②在需求开发早期即可起草一份浅显易懂的用户手册,用以描述出所有对用户课件的功能并对它作为需求规格说明参考并辅助需求分析。

(3)确定合格的标准

①让用户描述什么样的产品才算满足他们的要求和审核他们的使用。

②将确认合格的测试建立在使用情景描述或使用实例的基础之上。

5.6余额宝需求测试实战


需求规格说明书检查列表

5.6.1需求测试实战

以支付宝上新增余额宝业务为例分析

原始需求:

       虽然支付宝在12年时被大众所接受,但是面临着一个很普遍的问题:支付宝账户余额内总是有一笔闲置资金,虽然不同账户资金数额有多有少,但总的来说,这笔躺在账户什么做不来的闲置资金数额还是比较庞大的,对于支付宝的发展而言非常不利。

      于是产生了这样一个需求,与基金公司合作推出了货币基金产品,同时用户购买货币基金后,可直接通过货币基金金额进行支付购买商品或服务。货币基金可以视同余额、集分宝一样作为支付工具进行消费。

分析的过程:

①审查需求文档

②需求分析过程中我们将流程分为:货币基金购买、提现、消费、资产管理、交易查询几部分。

③可以通过需求规格说明书检查列表进行检查。

需求规格说明书检查列表


4.7测试策略—不用担心测试做不好

4.7.1测试前的思考

①你知道要测试的系统是干什么的吗?

②你了解系统有些什么特点吗?

③系统有些什么功能?

④系统哪些需要测试?哪些不需要测试?

⑤系统对性能有什么要求?

⑥系统对安全性有什么要求?

.......

4.7.2测试的策略是什么

①测试策略是描述测试项目和测试任务之间的关系。

②它用来说明要测什么,如何测,如何协调测试资源和测试时间等。

③测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。

④如何之低昂好一个好的测试测略并且能防止遗漏呢?

⑤一个好的测试策略又包含哪些方面呢?

4.7.3测试策略要素

测试策略要素

测试安排、发布计划:

①罗列测试项目本身重要的里程碑。每个里程碑都需要有明确的结束时间。这个时间可以指导我们后续的测试。

②如果测试时间安排不足,我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试。

③保证可以最大限度的保证产品的质量。

测试范围(按优先级排列):

①分为In Scope和Out Of Scope。

②需要说明哪些模块是在测试范围中的,哪些是本阶段测试不考虑的。

③对于在测试范围中的模块,需要给出优先级。

④以遍相应测试时间不足的情况。

⑤对于不在测试范围中的模块,需要给出原因。

⑥为什么在本测试阶段不考虑测试。

测试资源:

①测试资源在测试策略中也是很重要的一环,它分为人力和工具两部分:

        人力资源主要说明参与测试的人员,当然可以包括很多的角色,如专业测试人员,客户,产品经理等。

      工具主要是指可能用到其他软件。

测试环境:

 ①测试环境主要包括推荐环境解决方案,操作系统要求,软硬件要求。

②对于推荐解决方案,需要陈述的是对测试项目对其他软件的依赖。

③比如测试项目对java有依赖,推荐版本可能就是1.7

测试方法:

①测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试。

②功能测试是必须的,非功能测试是可选的。

文档管理:

①对于一个完整的产品来说,文档也是很重要的一环。

②它一般包括安装、升级文档、用户指南等。

③文档不单单是一个文件。

④它需要经过完整的测试才能发布给客户。

⑤差的文档很可能会误导用户,从而使他们对测试项目失去信心。

风险管理:

      风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素。这些因素可能来自技术,资源或者其他方面。

4.8测试方案设计—方案何等重要

4.8.1测试策略、测试计划、测试方案的区别

测试策略:

        侧重需求分析,评估风险,定义测试范围。确定测试方法,制定测试启动、停止、完成标准和条件。

测试计划:

     制定项目测试过程中的测试重点。各个阶段的任务分配以及时间进度安排,并提出对各项任务的评估,风险分析,可以包括测试策略。

测试方案:

        侧重测试的方法,测试环境的规划。测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案。

                     测试策略VS测试计划VS测试方案

实际实施过程中,往往存在这样类似的方式:

①测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案。

②测试计划=测试策略+测试任务分配+时间进度安排。

测试方案列表


货币基金消费测试方案分析过程

1、需求分析:当前测试包含需求项(需求文档或wiki链接等)。

2、测试计划(里程碑)及负责人:整理当前项目个模块测试负责人、任务分配及测试时间安排。

3、测试范围、测试重点:哪些point需要测试,重点放在什么地方,优先级安排。

4、测试策略及工具:是否需要进行自动化、性能、安全测试?使用哪些工具?

5、测试用例设计方法:使用说明样的黑盒测试方法进行设计(等价类?边界值?因果图?等等)。

6、测试环境:测试环境是什么?需要哪些服务器、数据库?配置如何等。

7、联调测试:是否需要与第三方或其他部门联调?何时开展?联调包括哪些功能?例如基金公司。

8、测试限制:在测试环境中哪些内容无法测试?比如消费到账。

9、测试风险:在测试或设计过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量。

4.9测试评审—决定测试质量

4.9.1测试方案评审

①目前有开发需求说明书、设计评审会、代码复审会等各种会议,但是很多都是站在开发的角度,从需求和代码层面进行复审和风险规避。

②在测试缓解和测试阶段缺少以测试为主题的评审机制和沟通机制。

容易造成以下几个方面的问题:

①仅从文档、沟通获取信息,可能会造成信息不对称,认识片面,理解错误或不深入等问题。

②缺少同行交叉评审和开发评审机制,无法充分发挥集体智慧,个人的思维难以突破,可能出现测试遗漏的情况。

4.9.2评审目的

①呈现测试的工作。

②与开发达成共识。

③不同的思维方式碰撞出火花,借鉴被人的思考方式。

④培养不这样的行为模式:愿意为团队或其他人出谋划策。

⑤发挥团队写作,最大限度发挥个人的经验,特长,实现技能互补。

4.9.3评审重点

①采用的测试方法。

②等价类划分的依据。

③测试数据的选取和准备方法。

④流程测试的路径组合。

⑤数据对比选取的对象和数据检查点。

⑥是否需要模拟数据及模拟数据的方法。

⑦基于风险的测试取舍。

4.9.4测试过程划分


测试过程划分

你可能感兴趣的:(熟悉阶段:软件测试流程)