你与“优秀”只差一个好的测试用例

随着互联网行业的不断发展，软件测试人员已逐步成为互联网产品的守卫者。在日常工作中， 一个优秀的软件测试人员除了要会实操检测bug之外，更要清楚的了解产品的需求点，做好测试用例设计。 根据我以往的经验而谈，很多软件测试人员的测试用例设计方法比较陈旧，还需加强自己测试用例的设计能力。故我整理了这篇文章，与大家一起分享一下我的心德体会。 浅谈测试用例的意义 简单来说，测试用例设计是基于产品需求出发，为避免遗漏测试环点而准备的“listing”。现在很多公司都会要求测试人员设计测试用例，因为他们都意识到无论测试用例的设计是否全面，都必须有这个环节，它对产品的质量把控和效率都会起到促进的作用。

因此，我们需要做好软件测试用例设计。那么，好的测试用例有哪些共性呢？我们怎么做好测试用例呢？下面给大家谈谈我的浅见。 好的测试用例的共性 其实，这是一个见仁见智的问题。不同的测试人员有不同的测试设计风格，这里我们求同存异即可。好的测试用例设计的共性大致如下： （1）测试设计结构组织合理。 从测试用例的组织是开展测试的起点，良好的组织能够帮助我们快速定位到我们想关注的部分，这个部分的好坏关系到测试工作的持续性发展。 （2）测试用例设计覆盖全面且不冗余。 用精简的语言描述清楚一条测试用例，用较少的测试用例描述清楚需求测试点的覆盖。 （3）测试用例设计具有可执行、可判定、可再现的特点。 即在测试前提符合的前提下，按照测试步骤每一个测试用例都可以顺利执行，同时呈现相应的预期结果，而且测试用例在被多次执行的结果都应该是相同的。 （4）逐步细化测试功能。 在编写测试用例时，建议由提纲挈领到逐步细化，先写基本功能点，再逐步增加细节，切忌过早的陷入细节描述。同时测试设计粒度要适中，根据实际项目的测试效率和效果去平衡，太粗太细都不合适。 测试用例设计（以移动端测试设计为例） 01 面向问题的测试全面性组织方式 移动客户端平台的测试，在传统的软件测试基础上，本身又具有自身比较突出的诸多特点。比如客户端平台多样化，系统碎片化问题突出，灵活性极高，因此仅仅将测试停留在基本功能以及传统理念上的测试组织，来确保移动客户端的测试全面性是不够的。 传统的用例组织方式，如等价类划分，边界值分析，因果分析等，更多的是从面向如果精简测试用例，确保测试全面的前提下，尽量降低冗余而来的。 现在我们推荐一种是面向问题发现的测试的组织方式，即由bug出现的分布对应相应的测试内容，从而达到测试全面性的一种组织方式。 1）Basic – 基本功能测试 面向于被测应用的基本功能实现，在测试用例的组织上，主要可以通过功能分层，逐级细化；画出草图，然后文字化得方式书写。主要采用功能图分析方法，因果图分析方法。

基本功能测试可以称之为一般性的功能实现测试，这部分可以不完全去考虑实现的好坏(如读取文件的速度)，不考虑特殊的输入输出，不考虑特殊的中断，不考虑特殊的环境。我们组织用例时，考虑将基本功能测试点和其他特殊测试内容分离的原因在于， 按照经验，我们倾向于认为，基本功能在一般状况下，在实现并在一轮完整的测试之后通常即可保证该部分是完备的，之后的问题一般的都是出现在基本功能实现基础上的特殊状况中。 因此，如此组织用例，有利于我们后期，适当的裁剪测试用例，将更多的测试精力放在容易发生问题的部分，而基本功能基本上可以通过特殊状况的检验而覆盖到。 2）Boundary – 边界分析测试 在基本功能的基础上，开始考虑各种输入输出的影响。一般的，基本功能容易在边界附近出问题。主要采用等价类划分方法，边界值分析方法。 用例组织上，可以梳理已经产出的基本功能草图，确定哪些部分存在边界问题。 并构造测试用例，执行测试工作。 如： 3）Memory – 存储测试 主要测试涉及存储空间读写的部分。*大的问题还是内存泄漏(memory leak)。 在测试用例组织上， 主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题 。比如： • 旋转屏幕—响应G sensor，画面需要重新载入，重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。 • 连续加载页面 • 开多个窗口—比较典型的，如浏览器 • 应用多次的互相调用—应用之间的相互调用，调用传递之间，可能存在问题，另外要特别注意“重入”；所谓重入，是指一个应用A叫起了应用B，但是应用B又可以再次叫起应用A，如message编辑时插入图片可以叫起camera，拍摄之后，camera可以不直接返回message编辑器窗口，而是通过点击分享-message，重入message编辑器，由此产生循环的栈叠加，也容易发生内存问题。 • 多线程下载 4）Performance – 性能测试 响应速度，资源占用，流量消耗，CPU占用的测试需要比对benchmark，并依据和benchmark的比对来判断被测试应用的表现能力，另外一个参考是我们在立项阶段的对某些核心内容的预期，或者用户主观感受。 立项初期就选择合适的竞品，选择核心的用例。所谓核心用例主要是依据用户的一个使用习惯，调研反馈总结出那些核心数据是用户在意的。 比如：一款导航产品，位置平均误差会有一个用户体验可以接受的范围，对路径的优化结果会有一个主观感受等等。在测试执行时，切忌完全依赖于主观感受，对修复的预期缺乏清晰的目标。比如，我们认为一款产品的首页打开速度很慢，那多快才是我们所预期的，这个需要我们明确。 5）Stress – 压力测试 可以简单理解为在基本功能上的提升负载，速度，吞吐量等性能指标。一般的，移动客户端通过monkey之类的测试工具加以覆盖，以及录制回放工具之类的测试来实现压力检验。

6）Capability – 兼容性测试 兼容性测试是指测试软件在特定的硬件产台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能很好地运行的测试。简单的说，兼容性测试是指测试某 新开发的软件在某一特定环境下与各种软件的协调性，软件之间能否很好的运作。 移动客户端常见的兼容性测试测项 • 网络兼容性测试（不同运营商3G，4G， WIFI，弱网） • ROM类型兼容性（主流厂商如苹果，华为，小米，魅族，OPPO等） • 分辨率兼容性测试 （各种不同的分辨率） • 数据兼容性（不同版本间的数据兼容） • 其他可能会涉及移动客户端兼容性测试测项 • 蓝牙设备兼容性测试 （如果是一款使用蓝牙的应用） • 存储卡兼容性测试（比如文件管理器） • 第三方软件兼容冲突（比如输入法冲突） 7）Interrupt – 中断功能测试 当前的被测应用被另外的应用打断当前的功能执行状态。 在用例组织上，主要在考虑执行某项操作时的系统打断，比如： • 来电 • 短信 • 闹钟提醒，日历提醒，蓝牙提醒 • 插拔数据线，插拔耳机 • 待机，锁屏 • 低电量提醒 8）Interaction – 交互功能测试 应用以及应用之间的调用，以及不存在应用层面的调用，但是存在更低一层的资源抢夺以及公用。比如： • 页面占用 • 内存占用 • 音频资源占用 • 摄像资源占用 02 实践经验 综上述，我们通过全面测试的指导思想提出了多种测试设计方法，但是 每种测试方法其实都有一个*佳测试时间 ，如在版本测试阶段，我们应当要先做基本功能测试，边界分析测试和中断，交互功能测试，快速发现bug提单给开发去快速修复，保证主体功能可以尽快得到保证，而不是一开始就先纠结与性能，压力和兼容测试。 一方面这类测试往往所消耗的时间会很长，降低了发现bug的速度；另一方面，先做这部分测试后，再去发现主体功能的bug，那么在开发人员动了大量代码之后，还是要再执行一遍性能，压力和兼容测试的相关用例，不仅劳命伤财，效果还事倍功半。