【测试用例】测试工程师需要具备发散思维（一）
前面的第一篇文章主要是讲自己干测试以来的工作心得，采取第一人称的形式让各位同学能够深有体会。但我相信，你能继续看到这篇文章是因为，你开始因为我的代入而对测试多多少少有了一些兴趣并且想了解一下。那么，从这篇文章开始，我将持续提供技能方面的知识以及我对于测试的思考方式。
从这篇主题的牵引下，我接下来会阐述测试用例的编写以及如何发散思维、更好的契合项目进度。
相信大家从很多论坛或者讨论群里听说过杯子的传说：
如何测试一个纸杯？
https://img-blog.csdnimg.cn/2019010811303112.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzAzNDAxNw==,size_16,color_FFFFFF,t_70data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==
你没听错，杯子的传说一直都被当做一个教材，不信你看：
功能性：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
对，你没看错，这就是测试纸杯。这就是以项目的角度去看待纸杯。你可能会问我，为什么我刚收到这道测试题的时候，脑袋一片空白，最熟悉的东西反而显得越复杂。我记得我曾经被平安集团面试测试岗的时候问了一个问题，如果给我一台ATM机，你该怎么去测试？我当时的情形就跟你们差不多，一脸懵逼，我特么是搞软件的！无从下手，思考两三分钟后才有了一些头绪，我从易用性，安全性，功能性，可靠性四个方面进行单点说明，最后说出来的用例我自己都感觉没有可读性，很乱。
为什么思绪乱？
你可能会说想得太多，但不知道从哪说起，说出来就忘记了一大半；你也可能会说，这些东西太熟悉了，习以为常的事物突然去放大思考显得不严谨；你也可能会说，我真特么啥也不知道。
怎么去处理思绪乱？
我前段时间，叫一个小姐姐写了一份要足够500个测试用例，是关于美团打车的APP。可能是为了满足虚荣感，最近喜欢跟素人交流怎么上手测试，所以说了很多理论，而这位小姐姐跟我以前一样，看了理论啥的就想睡觉，就像是高中的时候语文老师噼里啪啦的讲了一大堆，最后的输出结果就是后排一片倒。所以我让这个小姐姐开始实践，然后挑选了一个很复杂的APP美团打车让她试着写一写。
开始的思路是：先列出框架，说得高大上，其实就是主要功能点，如登录、打车、我的、发票等等。
小姐姐按照这个思路写了70多个用例，给我的第一感觉就是：哇，这是拿excel统计功能点！
所以我写了一份关于美团注册的测试点给她看
https://img-blog.csdnimg.cn/20190108115719702.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzAzNDAxNw==,size_16,color_FFFFFF,t_70data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==
这个注册功能的测试点覆盖率大概在80-90%左右。
然后我就提了一个要求，按照我这个思路去写其他功能点，写满500个测试用例。我觉得对于一个素人来说，500个测试用例是很有难度的，毕竟没有项目经验以及业务基础。令我欣慰的是，她竟然写到了530多个。
我拿到这个excel的时候，首先我看写了多少行，我之所以这样看是因为我觉得，写到了这么多说明覆盖率已经很高了。从框架到填入细节，你写得越多，说明你想得越全面，我不确定这些用例是否具有可执行性或者错误，但我确定的是，你的测试用例已经满足了我第一批需求。
所以，接下来，我又让这位小姐姐做一个任务，将500多个用例进行评定优先级，筛选并且综合目前所写的用例。我不清楚这个对于她有多大难度，但总得试一试，谁说做过项目的就一定比素人牛皮呢，我一直认为思维决定高度，而非技术。
我之所以会让她按照这三步走，主要是我的工作方式，或许称得上思维方式就是如此。先列出框架，再填充分支，最后择优方案。通俗的比喻就是，我去菜场首先会找到肉类，然后我看了看桌板上的猪牛羊鸡肉，我最终选择了我需要的猪肉。
那么你可能会问我，我没参加过什么具体的项目，以上所述和项目有关系吗？就像是说，我农村来的，你可别骗我。
项目没有你想得那么复杂，当然只是针对于测试用例来说。所以你可以得出，测试用例虽是最基本的技能，但也是最易上手项目并且最易掌握的。而项目就是遵循最优原则，避免重复性的用例以及提炼出你认为比较优先的用例。
那么问题又来了，如何提炼比较优先的用例，也就是说如何判定优先的用例？
我说一下我测试的方式，当我拿到一个功能测试，我会先参照UI设计原型，你也可以理解为前端的HTML和JS；然后我会参照需求文档，优先测试可单独测试的功能，比如查询，输入等，你也可以理解为后台的接口单元；再然后我会按照实际业务需求，来测试逻辑是否连贯，通俗点说，就是我在一个地方做了什么会影响到另一个地方吗，你也可以理解为后台的接口集成；最后我要看频繁或者恶意操作是否会造成系统故障，比如系统卡死，闪退等
所以，对于我来说，UI级测试用例是优先级较高的也是最易执行并且最易调整的，比如按钮的颜色、页面是否调用接口、输入框规格等；而接口级测试用例则要看具体情况：1.优先执行主要需求的测试用例2.优先执行查询类测试用例3.优先执行逻辑类的测试用例4.优先执行跳转类测试用例5.提示类用例可看情况选择6.优先执行文字说明书类用例7.违反常理类用例可看情况执行，等等。
看了你的第一篇点进来的，记得继续更新呀 看了你的第一篇点进来的，很有感触希望坚持更新
页:
[1]
