广州新塘网站建设,房地产中介网站,手写logo设计,免费网站收录提交前言
最近干的最多的事情就是设计测试用例、评审测试用例了#xff0c;于是我不禁又想到了一个经典的问题#xff1a;如何设计出优秀的测试用例#xff1f;
可能有些童鞋看到这个问题会有些不以为然#xff0c;这有什么好想的#xff1f;干个测试谁还不会设计测试用例于是我不禁又想到了一个经典的问题如何设计出优秀的测试用例
可能有些童鞋看到这个问题会有些不以为然这有什么好想的干个测试谁还不会设计测试用例
但是以我个人经历以及一些接触来说这个测试基本功确实不是那么容易做好的。可能很多人都觉得这个太基础了往往就越容易忽略而喜欢趋之若鹜的追求各种开发语言、自动化测试、测试平台这种上层建筑。
在我看来业务测试是基础其他的各种技术栈都是用来提效的手段主次是分明的。另一方面来说只有深入透彻得理解业务才能更好的挖掘可以提效的点。
ok言归正传下面以我个人理解来浅谈如何设计测试用例欢迎交流。
如何设计测试用例
一、研究需求文档
通常来说正确的测试流程应该是需求评审-测试用例设计-测试方案设计-测试环境\数据准备-提测后执行用例进行测试查漏补缺所以仔细的研究需求文档是重中之重。
一般来说需求文档里会定义产品的功能点我们可以先通篇阅读对整个产品功能有个整体的印象然后再开始从多个角度去深入产品细节中去挖掘有价值的东西
产品显性功能点这个很简单就是产品里明确定义出来的内容。产品隐性功能点产品没明确定义但是会涉及到的功能点。疑问点需求定义不清楚的地方或者涉及到一些测试范围的确认等等。
在需求文档输出之后一般相关部门也会跟着输出其他辅助文档比如UE交互文档UI设计页面这些可以更好地帮助我们形象化产品更好的去设计测试用例。
二、知晓开发设计
需求确定后开发一般也会开始进行开发设计。通常会有一些架构设计、流程图、时序图、接口文档等内容输出千万不要忽略这些文档我觉得是非常有价值的。
记住就算是做黑盒测试也不要把被测系统真正的当做一个大黑盒。
必须对内部的架构有清楚的认识数据背后传输的链路、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等。
拿最近在忙的车控业务来说吧当你在手机APP上点击开车门后这个指令如何达到车端车端又是如何返回结果的。整个链路经过了哪些服务中间件等你都要清楚才行否则你就不能说是真正地熟悉这个业务。不是真正的熟悉业务那么又如何真正设计出一份优秀的测试用例呢
单单根据测试需求点设计的用例只能覆盖“表面”的一层往往会覆盖不到内部的处理流程、分支处理而没有覆盖到的部分就很可能出现缺陷遗漏。
另外我们可以去了解开发的实现思路有能力的童鞋或许可以直接去看开发代码。看不了的也可以通过跟开发沟通了解实现过程这些对我们都有很大的帮助。
有时候开发在给你讲述实现过程的时候甚至就能自觉地发现一些问题。
但是我们也不要完全根据开发的代码实现为依据去设计测试用例还是根据原始需求来设计。
三、用例设计方法
了解的足够多了开始要去设计测试用例了。我们是先写脑图记录出思路和问题点最后我们才会编写Excel版的测试用例。一般传统互联网可能也不要求写Excel了这个看不同公司规定。
然而不管你用什么形式你还是要通过运用一些方法来设计你的case这里提一下最常用的三种测试用例设计方法
等价类划分方法边界值错误推断法
当然了这里只列出了这三种我觉得是最常用的起码对于大多数的软件测试场景都是这样的。除非一些特定的领域还会用到因果图方法、判定表驱动分析法、正交实验设计方法等等这些就不表了。
方法在于你能真正的实际运用好才行记得在面试的时候问到候选人类似问题方法说的头头是道让举个具体的例子有的人就开始支支吾吾了这些都是基本功不扎实的表现。
四、多角度拓展
基本功能点都设计完了就要站着更多的角度去拓展下挖掘一些隐形需求了。比如
功能与其他模块产生交互集成测试是否充分性能涉及到的接口是否存在压力场景并发场景等安全数据传输/存储的加密、是否脱敏等兼容性不同设备、不同系统、不同屏幕是否显示完好覆盖市面主流机型易用性功能是否好友提示是否友好等
