软件测试项目管理系之——测试类型划分及其项目实施

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

 我们在测试项目管理中,初期预研阶段,就要通过仔细分析和研究,确定以后工作中所要采用的测试类型。不同的测试项目,所选取的测试类型也必定不同。具体选用哪些,需视项目实际情况而定!

  简单来说,这些不同的测试类型,是按照不同的测试对象和测试范围划分的。

  我们以手机终端软件的测试项目为例,具体分类及包含关系如下图示:

  版本测试(Build Check/ Release Test)是开发完成代码设计和Code review、集成并发布后,测试人员拿到该测试版本,首先要做的一类测试。

  它的测试范围极窄,大概包括20~30条用例,都是最基本的功能用例,需保证1人在半小时内测完。

  对软件项目来说,根据子模块的大小、需求粒度等,每个子模块只选取3-5条基本用例。

  Build Check的目的是为了第一时间验证版本的正确性/稳定性,保证之后的测试中,各子模块不会出现严重的、阻塞基本功能的Block Issues。

  如果在版本测试中发现阻塞正常测试的严重问题,需第一时间提交给开发解决。测试工作暂时Block,转而关注问题的分析、解决与跟进。

  如版本测试顺利通过,才能开展后续的所有测试,所以它是测试工作的一个前提条件。

  目前很多持续集成工具如Hudson等均可加入实现了自动化测试执行的版本测试套件,当自动生成Daily Build后,马上开始后续的Unit Test、Coverage Test、Lint Test、Build Check等。

  在项目开始的需求开发阶段,敏捷开发模式下,我们执行的是迭代测试,包括功能测试和健全测试。

  因在开发阶段,PD/UI都不够稳定,开发也在频繁进行代码修订,这个时期不适合采用大规模的产品测试。

  而迭代测试是适合于敏捷开发模式下的一类测试,它可以紧跟开发/需求/UI的变更步伐,做一些小规模、针对性的测试工作。

  其中,功能测试( Function   Test )是测的最基本功能点和需求,也就是 UI 上的功能模块设计、业务流程设计、需求点设计实现等。它模拟是正常用户的正常行为,一般均为单任务,不牵扯交互、压力、异常操作等。而健全测试( Sanity   Test )是 系统测试的一个子集,它包含的是系统测试用例中的基本部分,相当于在系统测试之前所做的一次预测试。

健全测试达到标准,表示已达系统测试开始的准入条件之一,决定是否可进行全面的系统测试!

  一般健全测试用例数量占系统测试数的1/3左右,包括了所有K(Key)、M(Mandatory)型的测试用例,不包含O(Optional)型。

  系统测试是在产品测试阶段进行,它的覆盖范围极广,是对于软件产品的最重要测试内容之一。

  当前期敏捷开发阶段的需求测试(REQ Test)和基本功能测试、健全测试执行通过后,可认为产品质量已基本稳定,将前期测试结果作为准入条件,就可以开展后续的全面系统测试了。

  应注意的是:系统测试(System Test)是针对整个产品、整个软件系统所做的全面测试,而不是只针对单个功能、REQ或单一业务流程。

  它一般是在通过了Alpha release,迭代测试结束后,已经确保80%的功能集成且均REQ被分别测试,此时再开展系统测试,才有作用和意义。

  我们在系统测试中,定义了如上图示所列的各种测试类型。

  当然在不同的项目中,有时还需要定义一些Special Test Category如安全性测试、完整性测试、一致性测试、集成测试等。

  举例如手机上的客户端项目中,比较特殊的用例类型就是三层结构测试,因客户端设计原因,它是处于底层数据连接和上层App应用之间的夹层。

  所以可以设计基于“数据连接——客户端——上层应用”的三层结构测试,考核数据连接/设置/数据传输、上层App的启动、退出和异常场景等使用情况对于客户端的影响。

  交互测试(Interaction Test)是指的在同一测试机型上,被测模块(如手机客户端)与本机其它模块之间的交互测试,

  尤其是涉及接口调用和功能交叉的一些模块,类似客户端代码中调用的其它模块、客户端状态与数据连接设置的交叉、客户端计时与本地计时的功能交叉等。

  互操作测试(Inter-Operability Test)是指的被测产品与其它机型之间的交互,主要涉及信息、协议、信号解析的匹配与兼容性问题。

  例如不同机型对于短信的解析方式不同,可能导致互发后字符显示乱码,所以测信息时必须考虑互操作测试。

  但这主要针对不同解析方式和协议兼容性的,如果客户端有统一定义的业务/测试协议规范,不涉及这个问题,系统测试中就可以不考虑这个类型!

  性能测试(Performance Test)是针对产品/软件性能所做的度量测试,同时包括软件产品与竞品的性能对比测试。

  首先要在各种业务规范、测试规范、SW设计文档、需求规格文档等各规范文档及UI/PD设计中,采集了所有的性能指标。

  然后可使用本机自带工具、自己开发测试工具、自动化测试脚本、网上搜寻的工具等,对这些性能指标进行精准度量,得到性能指标的测试结果。

 压力测试(Stress Test)是指在各种压力情况和异常场景下,产品/软件功能使用的测试工作。

  如客户端的连续登录、下线100次,连续查询100次,各种异常下线,多用户同时登录,网络信号变弱等,尤其应关注各种异常场景下的功能使用状况。

  这部分测试,如果能用自动化测试工具完成的,可测试100次。

  一些涉及网络覆盖、信息接收、验证码输入等无法通过自动工具完成的,可手动执行20次。

  边界测试(Boundary Test)是指各种功能使用在极限情况下的测试,不仅是界面上的边界,也包括功能中的极大/极小边界、极多/极少值等。

  例如客户端的安装包,所能正常安装的最长路径长度(chars),最深存储文件夹层数(层),登陆用户名的最小字符数(个)等,都应当作为测试点。

  如果边界测试的用例数较少,可以直接并入系统测试用例中,不必单独列为一类,以免增加统计难度。

  兼容性测试(Compatibility test)是指产品或软件对于各种环境、设备、网络、解析规范等的适配能力测试。

  比如普通的软件产品,要测试基于各种OS(例Windows XP/ Win 2000/ Linux/ Mac OS/ Ubantu)、不同支持软件(例Outlook2003/ Outlook2007)的兼容能力。

  而手机客户端,主要通过四类测试来考核其兼容适配能力:终端适配测试、SIM卡兼容性测试、设备兼容性测试、网络兼容性测试。

  终端适配测试就是上图中所说的适配测试,因手机客户端是一个嵌入式系统,软硬件不可分割,故并入兼容性测试中。

  它测试的是不同分辨率、不同OS平台、不同硬件配置的机型对于客户端的适配兼容能力,我们在测试过程中,主要基于以下考虑:

  市场主流机型Top 20,主流分辨率,市场占据较多的OS前三位及其版本、主流设计商的芯片、对大字体设置的支持能力等等。

  SIM卡兼容性测试,是针对不同运营商、不同业务类型的SIM卡所做的兼容能力测试。

  如客户端是基于移动SIM卡开发的业务功能,则其中的短线接收,必须用移动卡才能正常接收,而在项目初期研发阶段,可能开发未考虑处理SIM卡兼容问题,就会导致使用联通/电信SIM卡会死在短线发送界面。此类测试解决的就是这些漏洞和问题!

  设备兼容性测试,这类测试需要借助一些专业的模拟网络环境和实验室,它可以模拟不同厂商的设备,保证客户端产品在所需的各种设备下都可以正常工作!

  网络兼容性测试,对于客户端来说,主要就是外场测试,包括企业内部外场区域和外部区域、移动区域等。

  它的测试目的是为了验证客户端在各种网络环境下的功能适配能力,执行的是全部功能+系统测试用例,在发现问题后还应做针对性测试。

  系统测试中,还包括内存泄漏测试( Memory-Leak   Test )、数据库测试( Database   Test )。

  内存测试主要针对应用软件的内存管理和释放机制,测试当大数据量传输、数据阻塞、频繁操作等异常情况下,内存使用和释放的正常性。

  一般使用自动化工具来进行此类测试,少量的内存测试用例可并入性能测试用例中。

  数据库测试是一类重要测试类型,主要测客户端与后台Server之间的数据传输、并发、准确同步等。

  一般手机客户端和后台的各类服务器等都有数据交互,应当针对这些Server进行专门的服务器测试,其中数据库测试和文件系统测试自然是重要组成部分!

  项目开发前期,即自 Kick   off Alpha   release 阶段,跟随软件的快速变化,我们所做的是迭代测试( REQ   Test Function   Test Sanity   Test )。此间每天采用 CIS 自动生成的 Daily   build ,在更新版本上进行迭代式测试。在 Scrum   Team 内随时与开发、产品进行沟通,快速反应解决问题。

  项目中期,自Alpha release ~ Beta release阶段,功能模块已基本集成,需要开始执行大规模的系统测试,并穿插周期性的功能测试。测试频度和范围视项目的测试周期、人力而定,但一般开始要先执行一轮全面系统测试(Full ST),以正确、完整地评估软件产品质量。

  之后再根据各模块成熟度和缺陷状况,决定如何对FT和ST进行针对性裁剪,选择新增模块、薄弱模块和重点模块的关键项用例来对软件产品做局部测试。

  此期间延长软件版本的迭代周期,每周更换2~3个测试版本,而不是每天更新版本。但需随时监察Release note和与开发及时沟通,知道有较大的功能性改动或重要的bug-fix时,就及时更换新版本进行测试!

  最后一个阶段——项目后期,也就是Beta release ~ Final/Product release之间的阶段,是产品发布测试期。此时已进入产品稳定和待发布期,在此期间,就不能像以前一样频繁更换测试版本了。一般产品质量较好时,我们采用每周更换一次新版本的更新频度。

  在这个阶段内,需要做的就是针对发布版本(Release candidate)的产品级测试,包括所有系统测试类型、验收测试、缺陷跟进及处理等。

  在产品发布之前1~2周,一定要最后做一次全面覆盖测试(Full Test),包含功能测试、系统测试的全部用例执行,以在最大程度上保证发布产品的总体质量!

  如上所述,当功能测试、系统测试、缺陷数量等均已达QA所订的质量目标后,在正式发布之前,当PD/UI已完全确定、稳定时,我们要做一轮验证测试。

  验证测试(Verification Test)是针对PD/UI/GUI的核查和验证,主要包括需求测试和UI验证。

  需求测试是核查所有需求点,看其所标示的功能是否已在软件发布版本上正确、完整实现。

  UI/GUI验证是核查软件产品的功能,是否与UI上标示的业务流程、界面显示完全一致,GUI中的每个Text/Graphic/Icon大小、颜色、色阶色深是否与定义一致。

  最后一类测试,就是稳定性测试,主测两个指标——MTBF和MTTF,均使用自动化测试工具实现。

  MTBF也就是平均无故障运行时间,应使用自动化Tool,在4台测试机上进行连续的、模拟用户行为的功能测试,取其均值作为考核指标。

  另外MTTF测试是在Android系统下直接运行adb命令,模拟在测试机上乱点乱划的行为,考察无故障运行时间。这是另一类稳定性测试!

  注意:为通过Alpha/Beta/Final release,我们有时会在里程碑截止日期(Milestone Deadline)到达之前,针对未达质量目标的功能测试/系统测试,再做一轮回归测试,以验证通过Release standard。

  而各阶段测试期间,我们也会针对局部的重点问题、严重缺陷和关键功能,做一些针对性测试,如焦点测试、集中测试、探索测试、自由测试等。其实从真正意义上来说,这些已经不属于测试类型的范畴,而是一些不同的测试方法!

  回归测试(Regression Test),是针对之前的一轮测试进行的再次测试验证,以达到QA定义的质量指标。FT/ST等都可以做回归,但以ST Regression较为重要。

  回归测试的范围主要包括以下三部分:上轮测试中的Fail case,需重新验证看是否已Pass;目前遗留的所有缺陷,进行修复验证;针对缺陷集中的薄弱模块、重点模块,进行引申测试。

  焦点测试(Focus Test)也就是专题测试。当测试过程中发现严重且普遍、涉及模块较多、影响较大的缺陷或问题时,应马上安排人手进行专门性测试。Test Leader围绕此问题设计专题测试用例,测试人员在执行过程中,也要自己进行思维发散和延伸,多做一些周边的操作测试,以在最大程度上发现可能的隐藏缺陷!

  集中测试(Test Workshop),亦称圆桌测试,也是在产品测试过程中经常采用的一种测试方式。顾名思义,它就是把一群用户级测试人员集中起来,在一个封闭会议室中,大家围着圆桌共同进行产品使用和测试。这些人可以是真正不了解产品的最终用户(End User),也可以是相互交换测试模块后的专职测试人员。测试的目的就是为了集中发现问题,尤其是那些因测试习惯性思维和行为盲区导致的潜在缺陷和风险点。

  探索测试(Exploratory Test),简称ET,其实是一种有导向、有目的的自由测试方法。它采用了一些科学统计和分析方法,针对性地对一些重要、关键测试点和模块、范围进行测试。主要由一名ET Leader做主导,负责定义Test point、安排测试内容/人力/时间、一对一开会讨论、总结编写ET Report等。

  自由测试(Free Test)就很简单了,大家都知道,就不多做赘述了。FreeTest可以随便找人来使用软件产品,寻找潜在的风险和隐藏的问题。也可以设定特定的目标用户群,从其中各抽出一部分人来集中进行自由测试。这样对样本点采集的全面性和可靠性更有意义,有时我们也会这样做!

  总之,测试类型千变万化,但万变不离其宗。我们在真正的测试项目管理中,一定要认真考虑、分析清楚当前处于哪个阶段、面临哪些重要问题、针对这些情况应采取何种测试类型来应对。

  天底下所有的技术、知识都是死的,运用存乎一心,只有它们变成了你身体的一部分,真正能够掌握、运用和创新改进的时候,你才能说“我真的会了!”

版权声明:本文出自 cmriqa 的51Testing软件测试博客:http://www.51testing.com/?489136

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。










====================================分割线================================


最新内容请见作者的GitHub页:http://qaseven.github.io/
目录
相关文章
|
17天前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
16天前
|
测试技术 UED
软件测试的艺术:探索性测试的力量
【10月更文挑战第6天】在软件开发的世界中,测试是确保产品质量的关键步骤。传统的测试方法往往遵循严格的脚本和预定义的路径进行,但探索性测试(ET)则提供了一种更为灵活、创造性的替代方案。通过模拟真实用户的行为和思考过程,ET能够揭示那些传统测试可能遗漏的问题。本文将深入探讨探索性测试的核心原则、实施策略以及它如何提高软件测试的效率和有效性。
|
17天前
|
测试技术
软件测试中的探索性测试(ET)实践
【10月更文挑战第5天】本文将深入探讨一种与传统脚本化测试不同的测试方法——探索性测试(Exploratory Testing,简称ET)。我们将通过一个实际案例来展示ET的有效性,并分享如何将ET融入日常的软件测试流程中。文章旨在为测试人员提供一种灵活、高效的测试策略,帮助他们更好地发现软件中的缺陷。
|
16天前
|
监控 数据可视化 测试技术
软件测试中的自动化测试实践指南
【10月更文挑战第7天】 在软件开发的生命周期中,测试是确保产品质量的重要环节。随着技术的进步和应用的复杂性增加,自动化测试逐渐成为提升测试效率和覆盖范围的关键手段。本文将深入探讨自动化测试的基本概念、实施步骤及其在不同应用场景中的最佳实践。通过对自动化测试框架的选择、脚本开发、执行及维护的详细解析,帮助读者更好地理解和应用自动化测试技术,从而优化测试流程,提高软件质量。
26 2
|
5天前
|
测试技术 开发者
探索软件测试中的自动化测试框架
在软件开发的世界中,质量是至关重要的。为了确保软件产品的质量,软件测试扮演着不可或缺的角色。本文将深入探讨自动化测试框架的概念、重要性以及如何有效地实施它们来提高软件测试的效率和效果。我们将从自动化测试的基本概念开始,逐步深入到不同类型的自动化测试工具和框架,最后探讨如何在实际项目中选择合适的自动化测试策略。
|
15天前
|
测试技术
软件测试的艺术:探索性测试的深度与广度
【10月更文挑战第7天】在软件开发的宇宙中,测试是一颗璀璨星辰,指引着质量的方向。本文将带你遨游于测试的海洋,深入探索性测试(Exploratory Testing)的奥秘,从其哲学本质到实践应用,揭示如何通过自由探索来发现软件中的隐藏缺陷。我们将一起思考如何在不断变化的软件环境中,利用探索性测试提高测试效率和效果,确保软件产品的质量。准备好,让我们启航吧!
|
18天前
|
测试技术 UED
软件测试中的探索性测试:一种创新的质量保证方法
在软件开发的生命周期中,测试阶段扮演着至关重要的角色。传统的软件测试方法,如自动化测试和回归测试,虽然在一定程度上保证了软件质量,但它们往往依赖于预定义的测试用例和脚本,可能无法覆盖所有用户场景和边缘情况。为了克服这些限制,探索性测试作为一种创新的质量保证方法应运而生。本文将深入探讨探索性测试的概念、优势以及如何有效地实施它,以帮助读者更好地理解和应用这种测试技术。
|
14天前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
25 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
|
2月前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
185 7
Jmeter实现WebSocket协议的接口测试方法
|
2月前
|
JSON 移动开发 监控
快速上手|HTTP 接口功能自动化测试
HTTP接口功能测试对于确保Web应用和H5应用的数据正确性至关重要。这类测试主要针对后台HTTP接口,通过构造不同参数输入值并获取JSON格式的输出结果来进行验证。HTTP协议基于TCP连接,包括请求与响应模式。请求由请求行、消息报头和请求正文组成,响应则包含状态行、消息报头及响应正文。常用的请求方法有GET、POST等,而响应状态码如2xx代表成功。测试过程使用Python语言和pycurl模块调用接口,并通过断言机制比对实际与预期结果,确保功能正确性。
187 3
快速上手|HTTP 接口功能自动化测试