测试工程师进阶之测试用例发散思维（二）

前两篇博客主要分别讲了自身对于测试工作的心得分享、如何快速编写出覆盖率高得测试用例以及如何按照项目进度进行执行测试用例。如需回忆可直接点击下方链接查看我前两篇文章。

个人注册CSDN后第一篇分享关于测试工程师工作心得的文章
https://blog.csdn.net/weixin_43034017/article/details/86013289
测试工程师进阶之测试用例发散思维（一）
https://blog.csdn.net/weixin_43034017/article/details/86064734

接下来我会更多的从发散思维上对测试用例进行阐述：测试用例能做到什么样子？测试用例还是你想象中的那样简单？测试用例还只是停留在页面吗？不过在阐述发散思维之前，我想理清一下测试工程师的定位。

当然我不会随便Copy一下官方对于测试工程师的解释。我是按照我的体会去思考测试工程师它到底是个啥。

在目前的现状来看，对于开发而言，测试就是： 我写完了代码提测，测试提交bug，bug修完测试回归；对于产品而言，测试就是：我的需求和你讲明白，你按照我的需求规格进行测试，赶在需求交付日完成测试进行发版；对于项目经理而言，测试就是：管控好需求进度，交付需求，产品质量责任人。所以简而言之，就是产品给需求，开发收bug，项目经理要进度。

当然这只是目前的现状大多数是这个样，为什么这样？是因为敏捷开发。敏捷开发这词不懂得可自行百度。其实在我心目中，测试是一个很严谨的工作，你得把自己当做项目经理去管控好每一条线：测试首先就要参与需求评审，三方意见达成一致后便开始着手测试计划，提前写好测试用例形成文档给到开发提供参考，然后后台开发定义接口后形成接口文档给到测试，接口集成测试完成后反馈给开发，提交前端开发联调后进行客户端测试，发现bug即时反馈开发以及未达需求即时通知产品，规定bug优先级并且计划bug排期，回归测试，邮件申请，申请通过后通知运维发版，发版测试。当然现实很骨感，不同的企业文化，不同的项目开发形式，不同的发展目标，很影响测试的具体工作开展，但我相信在以后的健全管理下，测试的担子将会越来越重，责任范围越来越广。

前面提到的测试流程，所以你如果想做好测试，你需要考虑到开发、产品甚至项目经理怎么看待你这份测试用例，即便开发不看，但你得保持严谨的态度，写这份测试用例不仅仅是给别人看的，而是一份给自己的文档记录。所以写一篇测试用例能尽量用到专业词汇、接口相关、数据库相关、UI相关等，不仅别人对你刮目相看且产生信任，自己每次的思考也能全范畴展开，因为这时候你已经站在项目经理的角度去写测试用例。当然这只是一个夸张比喻，哪有项目经理去写测试用例，哈哈哈。

那么说了这么多，发散思维如何展开便跟你现有知识水平相关。下面我将举一个例子：
​​​​
很明显，这是在我写第一篇测试用例时用到的例子。相信你也能看出，上面的测试虽然包含UI、测试步骤，但仍然停留在页面上的测试。

如果你具有数据库方面的知识，你是否可以添加到你的用例？比如：
假设数据表user的字段password对应密码，mobile_phone对应手机号，渠道value值0代表微信，1代表QQ
数据表valid的字段valid_code对应验证码

测试点	测试描述
数据库user表	选择一条已有的数据，输入其中的mobile_phone，页面是否提示已注册
	输入一条未对应mobile_phone的手机号，点击验证码是否成功发送
	验证码是否保存在valid表，且手机显示的验证码与valid_code值一致
	输入与valid_code不一样的验证码，页面是否提示验证码错误
	在未接收到验证码之前输入valid_code，页面是否注册成功
	选择输入密码方式，输入手机号对应的password，是否登录成功
	选择输入密码方式，输入与手机号对应password不一样的值，是否登录成功
	选择微信登录，value字段对应的值是否为0
	选择QQ登录，value字段对应的值是否为1

你会发现还有一些可以扩展开来的与数据库相关的测试用例。

如果你具有接口方面的知识，你是否可以添加到你的用例？比如：
假设有一个user/sign的接口，参数有name，password，返回参数有valid_code，succeed，error_desc

测试点	测试描述
user/sign接口	当你随便输入一个手机号，name值是否与你的手机号一致
	输入一个数据库未有的手机号，点击获取短信验证码，succeed是否为1
	输入一个数据库未有的手机号，点击获取短信验证码，valid_code值是否与你手机接收的验证码一致
	输入数据库已有的手机号，点击获取验证码，succeed是否为0
	输入数据库已有的手机号，点击获取验证码，error_desc是否描述“该手机号已被注册”
	选择输入密码方式，输入手机号以及密码，password是否显示明文且一致
	选择输入密码方式，输入手机号以及密码，succeed是否为1
	选择输入密码方式，输入手机号以及错误密码，succeed是否为0且error_code是否描述“密码输入错误”

上述与接口相关的用例依然可以扩展开来。

如果你具有性能方面的知识，你是否可以添加到你的用例？比如：
假设并发数为100用户，1s内并发，average为平均相应时间，error为错误率

测试点	测试描述
登录性能测试	当100个用户同时请求登录时，average值是否小于1s
	当100个用户同时请求登录时，error值是否小于5%
	如果提高到200用户，average是否变化比较大以及error值提高
	如果提高到500用户，average是否变化比较大以及error值提高
	如果60s内并发100用户，average值是否小于200ms，error为0
	如果60s内并发200用户，average值是否小于200ms，error为0
	如果60s内并发500用户，average值是否小于200ms，error为0

上述与性能相关的用例依然可以扩展开来。

当然发散这些测试用例不是为了好玩，也不是做做样子，你也可以不需要花费额外的时间去做。但当你这么做的时候，你感觉你的思路不仅仅停留在产品功能以及UI上了。开发关注接口以及数据库，项目经理关注性能优化，而你的测试用例直接来说，可以应付所有项目组的刚需。

当然测试用例也可以包含接口自动化测试、UI自动化测试等等。这在我后面会提到，如何将你做出来的自动化体现到测试用例当中。

总之，测试用例的发散思维依然是按照框架-细节-分层来做的，这在我第一篇测试用例已经提到。而上述我加上去的接口以及数据库用例无非就是将一个功能点扩散到底层。

[1]: 个人注册CSDN后第一篇分享关于测试工程师工作心得的文章 https://blog.csdn.net/weixin_43034017/article/details/86013289
[2]: 测试工程师进阶之测试用例发散思维（一）
https://blog.csdn.net/weixin_43034017/article/details/86064734