测试

随着互联网行业的不断发展，软件测试人员已逐步成为互联网产品的守卫者。在日常工作中，一个优秀的软件测试人员除了要会实操检测bug之外，更要清楚的了解产品的需求点，做好测试用例设计。根据我以往的经验而谈，很多软件测试人员的测试用例设计方法比较陈旧用例分析图，还需加强自己测试用例的设计能力。故我整理了这篇文章，与大家一起分享一下我的心德体会。 浅谈测试用例的意义 简单来说，测试用例设计是基于产品需求出发，为避免遗漏测试环点而准备的“listing”。现在很多公司都会要求测试人员设计测试用例，因为他们都意识到无论测试用例的设计是否全面，都必须有这个环节，它对产品的质量把控和效率都会起到促进的作用。 因此，我们需要做好软件测试用例设计。那么，好的测试用例有哪些共性呢？我们怎么做好测试用例呢？下面给大家谈谈我的浅见。 好的测试用例的共性 其实，这是一个见仁见智的问题。不同的测试人员有不同的测试设计风格，这里我们求同存异即可。好的测试用例设计的共性大致如下： （1）测试设计结构组织合理。从测试用例的组织是开展测试的起点，良好的组织能够帮助我们快速定位到我们想关注的部分，这个部分的好坏关系到测试工作的持续性发展。 （2）测试用例设计覆盖全面且不冗余。用精简的语言描述清楚一条测试用例，用较少的测试用例描述清楚需求测试点的覆盖。 （3）测试用例设计具有可执行、可判定、可再现的特点。即在测试前提符合的前提下，按照测试步骤每一个测试用例都可以顺利执行，同时呈现相应的预期结果，而且测试用例在被多次执行的结果都应该是相同的。 （4）逐步细化测试功能。在编写测试用例时，建议由提纲挈领到逐步细化，先写基本功能点，再逐步增加细节，切忌过早的陷入细节描述。同时测试设计粒度要适中，根据实际项目的测试效率和效果去平衡，太粗太细都不合适。 测试用例设计（以移动端测试设计为例） 01 面向问题的测试全面性组织方式 移动客户端平台的测试，在传统的软件测试基础上，本身又具有自身比较突出的诸多特点。比如客户端平台多样化，系统碎片化问题突出，灵活性极高，因此仅仅将测试停留在基本功能以及传统理念上的测试组织，来确保移动客户端的测试全面性是不够的。 传统的用例组织方式，如等价类划分，边界值分析，因果分析等，更多的是从面向如果精简测试用例，确保测试全面的前提下，尽量降低冗余而来的。现在我们推荐一种是面向问题发现的测试的组织方式，即由bug出现的分布对应相应的测试内容，从而达到测试全面性的一种组织方式。 1）Basic – 基本功能测试 面向于被测应用的基本功能实现，在测试用例的组织上，主要可以通过功能分层，逐级细化；画出草图，然后文字化得方式书写。主要采用功能图分析方法，因果图分析方法。 基本功能测试可以称之为一般性的功能实现测试，这部分可以不完全去考虑实现的好坏(如读取文件的速度)，不考虑特殊的输入输出，不考虑特殊的中断，不考虑特殊的环境。我们组织用例时，考虑将基本功能测试点和其他特殊测试内容分离的原因在于，按照经验，我们倾向于认为，基本功能在一般状况下，在实现并在一轮完整的测试之后通常即可保证该部分是完备的，之后的问题一般的都是出现在基本功能实现基础上的特殊状况中。 因此，如此组织用例，有利于我们后期，适当的裁剪测试用例，将更多的测试精力放在容易发生问题的部分，而基本功能基本上可以通过特殊状况的检验而覆盖到。 2）Boundary – 边界分析测试 在基本功能的基础上，开始考虑各种输入输出的影响。一般的，基本功能容易在边界附近出问题。主要采用等价类划分方法，边界值分析方法。用例组织上，可以梳理已经产出的基本功能草图，确定哪些部分存在边界问题。并构造测试用例，执行测试工作。 如： · 边界类型数值大小 ，输入的数值的范围 · 字串长短，Null-max-max+1 · 内容有无 · 支持与否，（保留字符，特殊字符，计划外字符。 3）Memory – 存储测试 主要测试涉及存储空间读写的部分。最大的问题还是内存泄漏(memory leak)。 在测试用例组织上，主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题。比如： • 旋转屏幕—响应G sensor，画面需要重新载入，重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。 • 连续加载页面...

提示：点击上方”我们的开心”↑关注我们 文/黄翔 王冲 本文系统地介绍了图模型测试技术的相关背景、实施方案和应用效果，并基于图模型构建与校验、自动化脚本生成与执行、测试报告展示与评价等技术框架进行剖析，论证了图模型在开展业务场景建模、测试设计与执行、测试过程评估等方面的优势，有助于实现测试全生命周期的提质增效和测试成果的度量评价。 一| 研究背景 图模型源于业务流程图，是一种由点和边组成的用以描述系统的图形，一个图由顶点(Vertex)和它们之间的有向边(Edge)组成，可以通过使用不同的测试覆盖策略和算法最高程度地覆盖业务需求。 在图模型中，顶点代表了业务流程中的中间步骤，表示一次测试验证；有向边代表了系统之间的状态转移，表示一次测试动作。图模型测试（Graphic Model Testing）技术基于构建的图模型，制定行为和行为之间的关系以及行为和系统的关系（有限状态机），然后根据被测系统的状态、设置的限制条件和策略来生成测试用例。 二| 实施方案 01 图模型构建 在基于需求的建模过程中，图模型根据被测系统的状态、设置相应的限制条件和策略来生成测试用例。作为一种开源的图模型测试工具，GraphWalker支持命令行和窗口化的形式完成图模型的搭建工作，但需满足一定的语法规则。图1展现了运用GraphWalker Studio进行图模型构建的相关界面要素。 图1 GraphWalker Studio界面要素 02 图模型校验 在当前测试前移的背景下，测试团队经常需要对需求文档进行评审并给出建设性意见。常规的方法是基于业务逻辑对业务流程进行梳理，凭借经验判断业务流程是否合理。图模型测试赋予业务流程图技术属性，可以从图遍历的角度对模型连通性进行验证，判断是否存在死循环或是不合理的业务流程。 通过以命令行的形式调用GraphWalker组件并执行相应命令，可以在终端输出模型图是否正确的提示，进而对业务逻辑和图模型本身的语法规则进行正确性校验。 03 自动化脚本生成 对于校验成功的图模型，可以基于设定的遍历方法进行图模型上的随机游走用例分析图，并将结果保存在日志文件。实际上，图模型上的每一次遍历都对应一条流程级测试用例。通过打开图模型的运行日志，可以基于各激励事件生成自动化测试脚本。需要指出的是，图模型生成自动化脚本需要依赖命令行JSON处理工具jq。这是一种轻量级的JSON解析器，可以使用它来进行切片、过滤、映射和转换结构化数据，进而对GraphWalker生成的测试用例进行筛选。 图模型遍历之后生成的自动化测试脚本遵循图模型名称_渠道端命名的方式，例如ODP_web.py。该自动化测试脚本表示是针对构建的ODP图模型按照find_element_by_xpath(”)的方式生成基于web端的自动化测试脚本框架，对于Android或iOS端的自动化案例，一般基于find_element_by_id(”)的方式或find_element_by_ios_predicate(”)的元素定位模式生成脚本。 04 自动化案例执行 作为一种贯穿需求分析到系统测试的全流程测试方案，图模型测试支持将业务流程以自动化案例的形式进行执行，进而模拟测试过程中可能遇到的各种业务场景。然而，图模型遍历之后生成的测试脚本仅仅包含符合Python程序规范的各种事件激励接口以及装饰器函数，要想真正驱动自动化脚本的执行，还需按照Selenium规则对脚本进行完善。 脚本准备完毕之后用例分析图，图模型基于遍历日志进行测试。通过依次读取日志文件中e_开头的事件激励，调用自动化测试脚本中的相应函数开展测试执行。基于传递的参数，触发浏览器驱动依次执行相应的页面操作。 05 测试报告展示 图模型测试基于Pytest框架完成测试并基于Pytest-html插件生成测试报告。通过对测试失败的案例自动截图，可以基于html报告了解出现错误的测试步骤，方便进行代码调试和缺陷定位。 Pytest-html插件生成.png格式的测试截图并内嵌在html报告中，这对于以headless模式运行的UI自动化测试尤为有效。由于headless模式下界面的操作不能进行直观地展现，html报告中内嵌的测试截图便提供了最为便捷的缺陷跟踪方式。 三| 应用效果 图模型测试基于擎云平台开展接口自动化测试，通过复用擎云平台接口案例的执行方式，以事件驱动的形式触发流程级接口案例的执行。项目组通过构建图模型，并基于某项目开展了接口自动化的测试实践（图2）。 图2 某交易收费与明细查询图模型 图模型测试由于增加了事件的随机性，可以涵盖更多的异常事件场景，从而发现更多的隐藏缺陷。在测试执行过程中，通过将擎云平台的测试报告内嵌到Pytest-html报告，可以直观地对测试过程中遇到的问题进行分析。当测试执行通过率不是100%时（图3），图模型将案例执行情况以图片的形式进行记录。通过分析案例失败原因，发现为多次收费时出现账户余额不足，导致对公收费模型分支执行失败。 图3 接口自动化测试报告 作为企业级的自动化测试平台，擎云平台支持将接口测试案例以测试资产的形式积累到资产库中，通过手动拖动案例的方式实现测试案例执行顺序的调整。图模型测试整合了擎云平台的优势，将接口案例以事件驱动的形式集成到图模型的分支路径中，实现了测试案例的自动化重复执行和随机化路径探索。 四 |...