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

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

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

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

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

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

白盒测试工具

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

黑盒测试工具

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

自动化测试工具

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

性能测试工具

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

是否遇到看了几天的需求文档没有理清楚需求从哪里开始，到哪里结束，需求边界在哪里。

是否曾花了很多时间编写出的用例，到项目中却无法开展测试。

是否刚做完测试，又有新版本过来，来不及看需求，来不及写用例，项目经理就来问测试结果。

每天忙的像个陀螺，节奏越快越没底，对新项目(需求)渐渐有了恐惧，完全不知道从哪里开始。

以上这些，是我的测试路程，我不聪明，也不愿意什么事都请教别人(怪我咯)，分配到自己身上的事情再难也会抗，跳过很多坑，背过很多锅。

有人曾说我只有测试经验没有行业经验，我认同。

因为我单看需求文档，只认识文字，组合在一起就是想象不出到底表达了几个意思。

为什么读不懂需求，我一开始认为是没有听产品经理讲解，于是在后来的项目中，产品经理讲解需求时我特意跑去参加，发现听到都清晰，但就是无法将它们转成我能理解的需求(判断标准是能不能写出测试用例)

我没有行业知识去判断产品经理写的这个需求是不是正确的，然而我又无法自动认为已看到的就是正确的。

而测试的步，就是判断需求的正确性，我总纠结我看到需求存在的合理性，因我怕这个需求是错的，而我在这个错的需求上做的越多，就错的更多。

我对我听到/看到的需求无法做出它是不是正确需求的判断，我一直思考的是需求本身的正确性，因为无法确定，所以我一直无法写出用例。

在工作中，不管是否理解需求，测试都是要做的，为了减少需求理解不对带来的Bug，在多次尝试后，我找到了自己的笨方法。

为看到的需求设想使用场景，比如：在一个订购的场景中必须要有的元素

用户、产品、价格、产品付费类型(一次、、包时段)，其他属性优惠/减免，去和需求对应，去和产品经理做确认。

这种方式尝试的次数越多，构思场景的速度越来越快，常常还没到测试执行阶段就能发现问题，我想这也是一种测试方式。

到正式拿到可测项目时，心里对需求已有底。

那么如何地进行功能测试呢?

1)找到项目的主流程场景和常用场景。

2)拿以上场景中的字段属性和需求去做对比，对有出入进行修正。

3)边测试边完善场景，写简要的测试用例和步骤(补充异常case)

4)走完轮测试，回顾所有场景。

因都是自己大脑思考，回忆一遍很快，也因都在脑海，只要负责过的项目，有什么功能、功能在什么地方，有什么字段属性都是一清二楚的，再也不用翻看厚厚的需求文档。

5)场景测试完成后，对所有功能做个扫测。

确保所有功能无明显异常(页面报错、功能不可用)

如查看功能，点进去看一眼即可(因知道所有属性，也知道属性显示成什么样是对的，一般一眼就能判断出)

6)保持一个习惯，看研发提交日志和代码。

这是一个提升测试正确率的大杀器，可以少走很多弯路，减少大部分工作量。

前提：要有阅读代码的能力。

此方式在代码框架设计的合理情况下都是可靠的，倘若框架设计的烂，如两个毫不相干的模块却共用一个方法、属性，那就死的不能再死啦，因为你根本就是想象不到的，也无法预防的。

每次测试前我都会仔细阅读研发的提交日志和代码变更，会根据这些去判断哪些需要重点测试，哪些只要看是否有影响即可。

如果发现代码变更和需求变更无法对应上时会立马找研发当场确认，为什么改动这块代码。

这个时候往往发现有个更大的坑在，如果不看代码变更，那么只有做全部的回归测试才能发现问题啦。

以上6点，就是达内软件测试培训小编进行测试的秘诀，分享给大家，望对大家有所帮助，也期望和大家讨论，得到更有效的测试路径。