6年软件测试经验分享

lsekfe

工作多年，从毕业后就开始从事软件测试，不知不觉已经从事软件测试6年了，长期的测试工作让我对软件测试有了比较深入的了解。但是如今工作上仍然偶尔会犯错误，离一个优秀的测试工程师还有一段很长的距离，道路且长来日可期，脚步慢一点也无妨。下面总结一下我的工作心得。
　　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打开这个脚本，运行就可以了，当然了，有时候运行得不太顺利，就需要手动修改一下脚本，也可以添加一个“监听器-查看结果树”来判断运行的结果状况。
　　真正学习和实践自动化测试有两年了，收获了一些，下面总结一下我的一些自动化测试的想法。
　　1、　自动化测试的优点
　　①　降低回归成本
　　②　提高回归覆盖率
　　③　提高回归效率
　　④　提高回归的稳定性
　　2、　自动化测试的缺点
　　①　自动化更适用于回归和冒烟，难以发现BUG
　　②　不是所有系统、所有功能都适合做自动化测试
　　③　自动化的脚本编写和维护时间长
　　3、　什么项目适合做自动化测试
　　①　项目的需求稳定，变动不大
　　②　项目的周期长，可持续迭代
　　③　项目支持的平台多，如多浏览器兼容性测试、手机多系统版本测试等
　　④　通过手工测试无法实现的测试活动，如压力测试
　　4、　自动化测试分类
　　①　接口自动化测试
　　②　UI页面的自动化测试
　　最开始，我也是从接口自动化做起，因为当时工作的项目都是以数据查询、统计为主的，UI页面的自动化测试不知如何下手，后来就去网上看一下其他人是如何来做的，发现很多人都是说像这种统计数据的项目，基本上无法做UI自动化测试，后面就想着就算是统计数据的一个列表，也不用每一条，每一个字段都来检查，只要检查某一些字段就可以了，如此一来就简单多了，首先我会去获取页面上的一个列表的第一条的第一个字段，然后再去连接数据库，获取此字段的值，两个值对比一下是一样的，那就没有问题了。
　　自动化虽然不能完全代替手工，但是却省去了手工的反复，工作中可能一些项目不好操作，只要灵活运用，就没有做不了的自动化。要想做好自动化，必须要拥有编码能力，至少要熟悉自动化工具/框架的代码语言，最好有一定的编码能力，同时代码逻辑要清晰，否则不仅不能保证用例的逻辑性、业务性与健壮性等要素，也不能保证效率。
来源：51Testing软件测试网