做一名既有宽度也有深度的测试！

一名好的测试人员，在工作中，不仅要做到有宽度更要有深度！

何为宽度？测试用例的覆盖面更广更全。

测试人员设计测试用例的时候可以分为这几种类型：

一：将prd的需求描述copy到测试用例。

二：细化prd，让每一个需求更饱满。

三：在二的基数上，根据实际系统业务，关联相关功能，加大覆盖范围

四：在三的基础上，加上经验的积累，丰富我们的测试用例，包括：多端兼容，中断测试，性能测试等等。

举个例子（非淘宝真实prd）：淘宝搜索框，增加默认关键词搜索，默认关键词取历史搜索记录，最多3条轮播显示，每条间隔1s。点击搜索支持默认关键词搜索。

这样的prd，如果让你设计测试点，你会包括哪些呢？

一句话需求，新增一个小功能，看似很小。第一种，4个测试点，貌似已经满足需求了，但当你详细列测试点，会发现其实要测试要注意的点，还是很多的。

何为深度？

1：深入了解需求背景

2：挖掘更深层次地业务逻辑

3：出现bug必揪

4：bug产生的原因必跟，尤其是线上

5：灵活使用工具等。

看到这里，你可能会问，为什么我要了解这么多，我只不过是一名测试，高质量的完成测试工作，就可以了呀。其实，我们的身份除了是测试，更多地是站在用户得角度来使用和体验软件功能。所以，角色不同，你要考虑的事情必然不一样。

举个例子：同上

1：深入了解需求背景。

为什么加这个需求？业务痛点是什么？加了之后有没有解决这个痛点？

背景：减少用户二次搜索。加了之后确实解决了这个问题

2：挖掘深层次地业务逻辑

如果用户常用拍照购物，这里的默认关键词怎么显示

3：bug必揪。

不能因为问题偶现，就放置不管，万一上线后，不少用户出现这个问题呢？它能出现必有原因，如果实在无法复现，可以和开发讨论，开发最清楚代码逻辑，也许你说了操作步骤和现象后，你们俩可以商讨尝试出bug的出现原因。

4：线上bug，原因必跟。

线上bug，问题必然很大，影响严重，但是事实已经出现，不要逃避推卸责任，我们应该要做的是复盘，复盘自己为什么没测试出这个问题，到底是漏测，还是场景特殊没考虑到，或者其他什么原因，把它当做一个警钟，在以后的工作中，加大宽度，提高质量，降低风险。

5：灵活使用工具。

在接口测试，修改测试数据或者抓包的时候会用到测试工具，接口一般都是快于页面，优先使用工具postman，jmeter等进行接口测试；测试数据可以借助navicat，dbeaver等数据库工具进行增删改查；比如到账功能，需24小时到账，那么你可以修改时间，快速测试到账金额是否正确，无需傻傻地等待24小时。出现bug，通过fiddler或charles进行抓包，快速定位问题等。如何抓包，请参考软件测试必备技能：抓包（一）