前语

最近干的最多的事情就是规划测验用例、评定测验用例了，于是我不禁又想到了一个经典的问题：怎么规划出优秀的测验用例？

或许有些童鞋看到这个问题会有些不以为然，这有什么好想的？干个测验谁还不会规划测验用例？

可是以我个人经历，以及一些接触来说，这个测验基本功的确不是那么简单做好的。或许很多人都觉得这个太根底了，往往就越简单疏忽，而喜欢趋之若鹜的寻求各种开发语言、自动化测验、测验渠道这种上层建筑。

在我看来，业务测验是根底，其他的各种技术栈都是用来提效的手法，主次是分明的。另一方面来说，只有深化透彻得理解业务，才干更好的发掘能够提效的点。

ok，言归正传，下面以我个人理解来浅谈怎么规划测验用例，欢迎交流。

怎么规划测验用例

一、研讨需求文档

一般来说，正确的测验流程应该是：需求评定->测验用例规划->测验方案规划->测验环境\数据准备->提测后执行用例进行测验&查漏补缺，所以细心的研讨需求文档是重中之重。

一般来说需求文档里会界说产品的功用点，咱们能够先通篇阅读对整个产品功用有个整体的形象，然后再开端从多个视点去深化产品细节中去，发掘有价值的东西：

  • 产品显性功用点：这个很简单，就是产品里明确界说出来的内容。
  • 产品隐性功用点：产品没明确界说，可是会涉及到的功用点。
  • 疑问点：需求界说不清楚的当地，或许涉及到一些测验范围的承认等等。

在需求文档输出之后，一般相关部分也会跟着输出其他辅助文档，比方：UE交互文档，UI规划页面，这些能够更好地协助咱们形象化产品，更好的去规划测验用例。

二、知晓开发规划

需求确认后，开发一般也会开端进行开发规划。一般会有一些架构规划、流程图、时序图、接口文档等内容输出，千万不要疏忽这些文档，我觉得对错常有价值的。

记住：就算是做黑盒测验，也不要把被测体系真实的当做一个大黑盒。

有必要对内部的架构有清楚的知道，数据背后传输的链路、数据库的读写别离、消息中间件 Kafka 的配置、缓存体系的层级散布、第三方体系的集成等。

拿最近在忙的车控业务来说吧，当你在手机APP上点击开车门后，这个指令怎么到达车端，车端又是怎么返回成果的。整个链路经过了哪些服务，中间件等你都要清楚才行，不然你就不能说是真实地了解这个业务。不是真实的了解业务，那么又怎么真实规划出一份优秀的测验用例呢？

单单根据测验需求点规划的用例，只能掩盖“外表”的一层，往往会掩盖不到内部的处理流程、分支处理，而没有掩盖到的部分就很或许呈现缺点遗失。

另外，咱们能够去了解开发的完成思路，有才能的童鞋或许能够直接去看开发代码。看不了的也能够通过跟开发沟通了解完成进程，这些对咱们都有很大的协助。

有时候开发在给你讲述完成进程的时候，乃至就能自觉地发现一些问题。

可是，咱们也不要完全根据开发的代码完成为根据去规划测验用例，还是根据原始需求来规划。

三、用例规划办法

了解的足够多了，开端要去规划测验用例了。咱们是先写脑图，记载出思路和问题点，最后咱们才会编写Excel版的测验用例。一般传统互联网或许也不要求写Excel了，这个看不同公司规定。

然而不管你用什么形式，你还是要通过运用一些办法来规划你的case，这里提一下最常用的三种测验用例规划办法：

  • 等价类划分办法
  • 鸿沟值
  • 过错推断法

当然了这里只列出了这三种，我觉得是最常用的，起码关于大多数的软件测验场景都是这样的。除非一些特定的范畴，还会用到因果图办法、断定表驱动分析法、正交实验规划办法等等，这些就不表了。

办法在于你能真实的实际运用好才行，记得在面试的时候问到候选人类似问题，办法说的头头是道，让举个详细的比如有的人就开端支支吾吾了，这些都是基本功不厚实的表现。

四、多视点拓宽

基本功用点都规划完了，就要站着更多的视点去拓宽下，发掘一些隐形需求了。比方：

  • 功用：与其他模块产生交互，集成测验是否充沛
  • 性能：涉及到的接口是否存在压力场景，并发场景等
  • 安全：数据传输/存储的加密、是否脱敏等
  • 兼容性：不同设备、不同体系、不同屏幕是否显现完好，掩盖市道主流机型
  • 易用性：功用是否老友，提示是否友爱等