开发转测试2年了，因为有开发经验，头一年基本上是按照测试用例编写脚本，最近一年，开始涉及到测试用例的设计，脚本编写也还在继续。近段时间一直想对测试工作内容做一个总结。
一、
一开始接触的是服务器交换板的接口测试，由于业务知识缺乏，当时想法是：只要把设计好的测试用例用脚本的形式实现就可以了。之前做过开发，基础还可以，接触新语言上手也比较快，
所以这部分实现起来也没什么压力，只是在遇到业务相关的时候，会磕磕绊绊。到了后期，业务知识开始有了了解，对自动化的整体也熟悉了，发现原来自动化测试的脚本设计也是有整体考
虑的：1、在执行这个脚本前，需要初始化哪些东西，执行完之后，需不需要恢复测试环境等 2、测试环境一样的用例可以放在一个组里，这样就不需要每个用例都重新初始化（现在写脚本
的时候也有用这个方法，事实证明，这样执行发现的问题会更多）
二、
最近一年参与了用例设计和脚本实现，也借鉴了一些博文，现总结一下这段时间的一些想法：
A.最重要的一点：刚开始做测试，经常是给到一个版本就测，经常忘记去确认是不是最新版本，等到测出问题才发现不是新版本，低级错误，效率低下，实属不该；
B.什么时候适合做自动化：需求变动比较小的部分；现在很多ODM、OEM的产品，功能差异很小(可以借鉴配置文件的方式实现脚本选取)；
C.自动化测试用例怎么写：设计用例的时候，把能用自动化实现和不能用自动化实现的功能区分开；
D.开展自动化策略：当测试案例多到一定程度，测试周期内全部跑完,时间比较紧的时候，要根据修改的内容，适当选择部分相关的和优先级别高的用例执行；
E.实现脚本时，每个脚本都是独立的，如果实现过程需要对数据、环境进行修改，脚本结束时需要还原；
F.设计脚本的时候可以把一些有联系的参数、步骤放在一起，减少用例数，提高效率；
G.当发现一个bug时，不要第一时间找开发，先收集日志，找出触发bug的最小操作，明确要测试的点，排除干扰项，确定是否必现，最后再上报bug；
H.压力测试：当产品的功能测试已经经过多轮，且等级高的bug基本消除后，可以开始考虑产品的压力测试；
测试菜鸟的一点总结，有不对的地方还请拍砖。
网友评论