测试经验

1、熟悉业务需求说明书

测试工程师的主要工作体现在测试报告和测试用例上，只有熟悉掌握项目的业务需求，才能设计出全面，覆盖率高，多异常流的测试用例，有一些细节甚至要比产品经理还要考虑细致。只要遇到任何不清楚的、有疑问的地方，就一定要找产品经理确认。

2、熟悉开发详细设计

很多测试工程师可能觉得开发的详细设计不需要了解，只要这个软件的功能做出来了就行了，具体是怎么做的，不需要关心，这种想法是不正确的。了解开发的详细设计后，你才知道这个业务的整个流程是怎么样的，你才知道开发有没有把所有的场景，异常流都考虑进来，是不是真的理解了这个业务需求。

3、把自己当用户来测试

把自己当成用户来测试这个软件，模拟用户可能会操作的所有行为，牢记软件的每个页面，每个功能。遇到问题提bug时，标题和内容要描述清楚，简洁，没有歧义，写上重现的步骤，最好附上问题的截图。每次测试完成后，一定要写测试报告，把自己遇到的问题或者认为不合理的地方归纳总结出来，逻辑要清晰，字数要简洁。

4、不断学习，了解软件的基础知识

如果不了解软件的基础知识，测试永远只会停留在表明上，只会在页面上点点点，不知道后端是如何运转的，前后端是如何联系的，甚至连开发在说什么都听不懂，开发的详细设计看了也只是按着他的来，不会带着质疑的精神来提疑问。最少要知道软件是由什么语言来写的，用的什么框架，用的什么数据库，只有懂得了基本的软件知识，和开发人员沟通起来才不会鸡同鸭讲。

5、保持工作的激情和兴趣

测试工作是一遍又一遍的重复性工作，一个用例可能执行了很多遍。每次项目升级，都要求回归测试一次，把原来上百条的用例再执行一次，需要耗费大量的时间和精力，过程是非常枯燥的，如果能保持激情和兴趣，每一次执行就当做是第一次执行那样有新鲜感，工作起来就会容易得多了。

工作的时候，总结了一下我的一些测试小技巧。

1、按F12，查看调试界面，分析bug归属于前端还是后端

在测试的时候，有时候会遇到一些问题，不知道是前端还是后端的问题，有时候提bug分派错了，会直接影响解决bug的进度，有时候测试一些列表数据时，发现查询列表数据不符合，就不好判断是前端问题还是后端问题，这个时候就可以按F12，进入调试界面，选择Network界面，这里的Headers可以看到前端请求地址和请求参数，Respons可以看到后端返回数据。

这里举一个例子来说明一下，前端展示有一个数据列表有一个查询条件是状态，状态分为：全部、成功、失败。

当查询成功状态时，前端列表展示的数据却是失败的。这个时候可能会想是不是前端展示错误了，首先按F12，查看调试界面，看后端返回的数据是不是成功状态的，结果一看，后端是返回了失败状态的数据，这个时候可能会想是不是后端错误了，别急，最后还要查看Headers里面的请求地址和参数，这个时候，发现请求参数错误，不是状态成功的参数，而是状态失败的参数，这样就可以确定是前端的问题了。

2、查看后端日志

在做测试时，一定要打开后端日志，当在前端页面操作时，突然弹出一个报错提示时，如何分析是前端还是后端错误时，可以从日志里面体现出来，如果后端日志没有报错，则考虑是前端的问题，如果后端有日志报错，则考虑是后端的问题，把日志截图出来贴到bug详情里面，可以方便开发查看问题，操作的时候，查看日志的SQL语句写得是否正常，是否符合操作的要求，都可以自己简单分析一下。

3、查看数据库

在做测试时，一定要检查数据库中，各个模块对应的哪些表，表字段是否符合要求，表设计是否合理，有没有索引，有没有唯一键，表与表之间如何联系，当表数据很多时，有没有做旧数据移表处理，这些都需要检查一遍。

4、照数据

在做测试时，有时候需要查询列表的很多页，需要很多数据，手动去添加的话，如果添加一条要花20秒，添加200条岂不是要1个小时，有时候测试数据导出功能，超过1万条数据时，走异步，添加1万条的话岂不是要几天，非常浪费时间和精力，这个时候，你可以自己去数据库中照数据，直接对需要使用的表格插入数据，写一个for循环就可以轻松搞定了。

5、录制脚本

在做测试时，每次项目升级时，都要来一遍回归测试，可以使用一些工具来辅助，达到事半功倍的效果，我就是使用的badboy，首先录制我要操作的一些动作，比如对列表的一些增加，删除，修改，录制完成后保存为jmeter格式，然后使用jmeter打开这个脚本，运行就可以了，当然了，有时候运行得不太顺利，就需要手动修改一下脚本，也可以添加一个“监听器-查看结果树”来判断运行的结果状况。