测试工程师进阶之测试用例发散思维（二）
本帖最后由 testor_zl 于 2019-1-9 18:00 编辑前两篇博客主要分别讲了自身对于测试工作的心得分享、如何快速编写出覆盖率高得测试用例以及如何按照项目进度进行执行测试用例。如需回忆可直接点击下方链接查看我前两篇文章。
【分享工作心得】测试工程师有一种优良精神叫做分享
http://bbs.51testing.com/thread-1195173-1-1.html
【测试用例】测试工程师需要具备发散思维（一）
http://bbs.51testing.com/thread-1195175-1-1.html
接下来我会更多的从发散思维上对测试用例进行阐述：测试用例能做到什么样子？测试用例还是你想象中的那样简单？测试用例还只是停留在页面吗？不过在阐述发散思维之前，我想理清一下测试工程师的定位。
当然我不会随便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自动化测试等等。这在我后面会提到，如何将你做出来的自动化体现到测试用例当中。
总之，测试用例的发散思维依然是按照框架-细节-分层来做的，这在我第一篇测试用例已经提到。而上述我加上去的接口以及数据库用例无非就是将一个功能点扩散到底层。
: 【分享工作心得】测试工程师有一种优良精神叫做分享 http://bbs.51testing.com/thread-1195173-1-1.html
: 【测试用例】测试工程师需要具备发散思维（一） http://bbs.51testing.com/thread-1195175-1-1.html
实际项目中常见的两种情况
一，没那么多时间把测试用例的颗粒度写的足够细。
二，即使写的足够细，在bug提起阶段开发会以非用户常规操作或者bug影响等级低的原因而不去改修。
请问针对这两种情况，我们该如何去应对。
applepen 发表于 2019-1-10 08:42
实际项目中常见的两种情况
一，没那么多时间把测试用例的颗粒度写的足够细。
二，即使写的足够细，在bug ...
针对第一点，我觉得除了紧急需求，其他正常版本需求应该都有时间来写用例的，如果来不及，可以写一个列满测试点的测试方案，省去详细的测试步骤的书写，这是我个人的观点，可以交流；
至于第二点，我和你有相同的困惑，我觉得是需要和开发搞好关系，毕竟人都是有情绪的，得找好时机来说服开发，这个BUG不严重，但是用户就是辣么不可控啊，需要改掉BUG堵住客户的嘴，尽善尽美合作愉快嘛
页:
[1]
