集成测试方法与最佳实践

Posted 2021-05-01 自动化测试研究与应用

摘要:

自动化测试研究与应用专题组对软件测试方法论进行了研究与整理，总结了目前通用软件测试案例设计方法论，包括测试大纲设计方法、测试用例组织方法与测试用例设计方法等，希望本文可以帮助从事开发测试的同仁开拓测试的思路，带来一定的启发~

第一部分：测试大纲通用设计方法

一、收集、分析测试需求与编写测试大纲

  对测试需求进行功能分解，确定各个功能点测试优先级，把重要的关键的功能标识出来作为重点测试对象。

（一）测试点覆盖

测试点要覆盖系统的界面、单个功能、功能组合（或者说业务流程）、系统接口、后台批量、系统兼容性、系统安全性、系统稳定性、系统并发性、用户体验、安装等方面。

（二）测试大纲的范围

主要应以当前要投产的功能集合为测试范围，不在投产范围内的功能应不纳入当前测试范围，由于代码变更受影响的功能除外。每个测试点的描述清晰易懂，避免晦涩、绕口的语句，避免重复性的描述。

（三）测试大纲要素

至少应包括系统名称、模块名称、功能点名称、功能点描述、功能点业务规则描述、功能点编号、对应的测试用例数或测试场景数、测试优先级等。

（四）编写测试大纲方法

由上而下、由总体到局部、由粗到细层层分解、直至无法分解为止，这种原理就是剥洋葱原理。分解完成后再由下到上、由点到线到面，归纳整理出各类测试场景或测试流程.

1、需求-功能矩阵法：用表格矩阵的形式将需求和需求有关联的功能点罗列出来，进一步细化需求，具体化需求。

2、思维导图法：以思维导图为基准，辅以收集的零散需求文档和系统原型逐步细化出测试点。

测试大纲应通过业务方、开发方和测试方三方评审，获得一致认可，才能作为下一步设计测试用例的直接依据。

思维导图大纲示例

第二部分、 测试用例通用设计方法论 

测试用例是最小单元的可以操作的测试指令。它是根据测试大纲的每一个测试点和测试场景来设计的，一般要求每个测试点都要有正反测试用例，其比例至少达到1:2。

（一）测试用例结构

建立用例集，由各用例子集构成，如公共用例集、研发自测用例集、冒烟测试用例集、功能用例集（基本功能用例、场景穿越用例、接口用例）、移除用例集等，用例集可以使用例结构更清晰，用例的利用率最大化，尽可能的在整个项目生命周期为测试服务。

1、公共用例集

一般含两种类型，第一类为系统中频繁测试的功能点，如UI测试中的页面显示、布局、必填项、特殊字符限制等;第二类为系统中多个模块间相同的功能点，如翻页、导出、上传、下载等功能，这类用例重复性高，项目间也可以复用。

2、研发自测用例集

以研发执行为目标的用例集，可有效在提测前预防低级BUG频出问题，用例可在功能用例中抽取一部分粗刻度用例组成研发自测用例集，建议测试人员配合与指导研发执行，养成良好的协作氛围。

3、冒烟用例集

也叫基础用例集，主要针对各主要功能、流程的最基本用例，不过多考虑异常，通常由功能用例集提取。测试目的强调对程序的主要功能进行验证，而不会对具体功能进行更深入的测试。

 

（二）测试用例设计方法

测试用例的设计是一个循环迭代的过程，整个测试设计和执行一共可分为三轮。

下面对每一轮做个简要介绍。

第一轮：快速测试RST(Rapid Software Testing)

RST能够帮助QA在短时间内发现一些特定类型的缺陷，这些错误可以是需求设计上的业务逻辑错误，也可以是平时测试中经常遇到的缺陷。

方法名	所针对风险	测试手段
用户界面	软件界面易用性差，会让使用者疑惑	测试人员漫游用户界面，发现是否有任何令人疑惑、不快、烦躁的界面设计，发现是否有可改进之处。
错误处理	软件的错误处理代码容易出错	测试人员尝试着触发软件的错误消息，然后反复执行导致错误消息的操作，以检查错误处理代码是否产生了资源泄露等问题。
快乐路径	软件在典型用户情景中失败	测试人员测试产品最简单、最直观、最典型的情景，完成一项或多项用户任务。在此过程中，检查其表现是否符合用户和产品团队对它的期望，而不会让用户感到疑惑、恼怒、挫折等负面情绪。
挖墙脚	软件不能正确处理一些异常情况	测试人员启动一项软件操作，然后破坏该操作所依赖的资源，例如删除它要访问的文件、关闭它将访问的网络服务、启动另一个程序去锁住它要修改的数据库表格等。软件应该妥善地处理这些异常，合理地报告所遭遇的问题，不导致严重的故障。
狗刨	当某些操作被反复执行时，软件可能出错	测试人员将一组操作重复多次，用并发的流程、嵌套的结构去考验软件。例如，文本编辑软件支持嵌套文本框，于是测试人员就不断在文本框加入新文本框，以增加嵌套层次。当文本框嵌套层次达到上限时，操作这组文本框有可能发现隐藏的缺陷。
功能交互	不同的功能可能由不同的程序员编写，它们的逻辑可能不一致	测试人员发现相互调用或共享数据的一组功能，然后用夸张的数据或操作来压迫它们，以暴露交互中存在的问题。

第二轮：基于HTSM的测试设计

使用HTSM（HeuristicTest Strategy Model启发式测试策略模型）中的Test Techniques创建测试，目的是覆盖到最基本的测试点。例如：

1）域测试 Domain Testing

描述：专注于测试软件所处理的数据

2）压力测试 Stress Testing

描述：用极限行为和数据压迫软件

3）流测试 Flow Testing

描述：测试软件的操作顺序

4）情景测试 Scenario Testing

描述：用有说服力的场景来测试软件

5）声明测试 Claims Testing

描述：测试所有产品资料 Challenge everyclaim

6）用户测试 User Testing

描述：从用户角度测试 Involve the users

（这里有一个坑，就是你很容易自以为你就是真实的用户，而你并不是。）

第三轮：基于探索式测试之漫游测试的测试设计

探索式测试可以帮我们发现在规范说明书中可能漏掉的用户场景。探索式测试之漫游测试是在特定主题指导下对产品进行探索的一组测试方法，这里列出一些最常见的方法。

1）功能测试 Function Testing

 卖点漫游：测试人员发现并测试软件的亮点功能，重点测试该功能。

  配角漫游：测试人员重点测试软件的非主要功能。例如，对话框上有一条指向帮助文档的链接，很少有用户会注意到它。

2）流测试 Flow Testing

 测试人员发现并测试触发某一功能的所有途径，或完成某项任务的所有方式。该方法有助于完整地考虑并测试一个功能或情景。

3）情景测试 Scenario Testing

 测试人员用一些不合“正常”逻辑的情景来测试软件。例如，测试在线交易网站，提交订单并支付后，又取消订单并要求退款。

4）风险测试 Risk Testing

测试人员在测试软件时，以找茬的心态去挑战软件。他提出各种问题去质疑软件，例如：“如果我这么做，会如何？如果我偏不这么做，又如何？如果我不想这么做，有什么替代方案？”该漫游有助于发现程序员设计的不足和软件逻辑的漏洞。

QA在这一轮测试设计中，更多的异常测试用例会被挖掘。测试设计也基本完成了。