深圳达内软件有限公司是亿元级外资IT培训集团达内旗下深圳分公司，达内是获得国际风险投资的IT培训机构。达内已经发展成为集培训、咨询、开发、人才服务于一体的高新技术集团公司，公司下设达内IT培训、达内软件人才服务中心、达内软件研发中心。

课程直切企业需求，培养全栈式测试人才

囊括企业级软件/大型网站/游戏开发/移动APP开发等多种软件测试需求

1.黑盒测试2.QTP3.接口测试4.LoadRunner5.JMeter6.Selenium7.手机测试8.游戏测试

学习测试工具，助你具备核心竞争力

打造符合企业用人需求的测试工程师

白盒测试工具

对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。

黑盒测试工具

利用脚本的录制/回放，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。

自动化测试工具

可以覆盖绝大多数的软件开发技术，简单，并具备测试用例可重用的特点。

性能测试工具

通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。

我们写测试用例的目的是为了能够整理思路，把要测试的地方列出来，做为知识的积淀，用例可以交给其他测试人员执行，或者是跟需求提出者进行讨论，对用例进行补充和修改。

理论上用例写的越多，越容易发现bug。但是，本文我们将讨论如何写出发现不了bug的测试用例。

不看需求

要想写出测不出bug的用例，较关键的一点就是不看需求或者随便看看需求。

需求文档是个磨人的小妖精，要么是写的看不懂，要么写的太简单。这玩意很多时候我们是看不懂的，看不懂的话，嗯，那么就脑补咯，用例写的又快又好，执行的时候肯定发现不了bug。

只看需求

我们的测试用例只涵盖需求中描述的部分，其他需求里面没有提到的部分坚决不写。测不出问题不是用例的错，都是需求的锅。

只写正常的逻辑

永远只关注业务的正常流程和逻辑，把测试用例写成用户说明书，这样看起来内容会很多很详尽，但是根据这个用例，不管你怎么测你都测不出来问题，厉害吧。

拷贝粘贴

一般大家都用excel写用例，这时候相似的用例是可以使用拷贝粘贴的方式去搞的，改几个字就是个新用例了，很聪明不是?这样的用例交到执行人员手里，因为长得差不多，执行的时候很容易被忽视造成场景漏侧，遗漏了就自然发现不到bug了，不是么?

只可意会

把每一条用例都写得只可意会不可言传。这样的用例自己写过3天之后都会忘了写得时候到底是怎么想的，通过这种用例去找bug，只能靠运气。

没有断言

只描述方法和步骤，不写断言，或者把断言写的很暧昧，有一种朦胧美，让人觉得看起来很有道理，但是执行的时候一脸懵逼，比如

·应该登录成功

·应该保存成功

·应该跳转到正确的页面

·应该有错误提示

只要掌握了上面的方法，勤加练习，相信大家很快就能练成撰写测不出bug测试用例的绝技。目前江湖上此等绝技风行一时，人人争相敬仰之。

较后以上我说的都是反话！请注意！