自动化测试总结

1.需求来源和目标

需求是当系统趋于复杂后，我们希望简单的测试都由机器完成

目标为SSH连接后，自动测试命令行。由于是自己一个人弄，所以把目标定在合理范围内（需求定简单一点）

具体目标为：自动登录后，设置配置，然后获取配置，比较设置和获取是否一致

 

2. 过程

使用了pexpec和click库。pexpec用来执行ssh连接，click实现简单的命令行。

第一版的不足，测试的具体内容，都放到脚本里面，但是其它同事不会python（就是想偷懒）。所以开了评审会后，按同事的建议改为，将测试的具体内容放到csv文件里面。满足了项目90%的功能。节省大量人力。每次发版本都可以做全面测试。

 

3. 不足

click库只能执行1个命令，执行完后，退到shell。但实际有时候希望长期连在shell上。

找了大量的python库，看起来prompt_toolkit, Nubia有可能完成这个任务。

python提供了自动化框架Unittest。但是实际项目，最需要的是好看的测试结果，方便检查，测试case是否可以方便完成。如何把unittest和现在的测试项目结合起来，是今后的课题。

另外的问题是，只能测试ssh，其它的协议如何简单扩展。

 

4.具体项目总结1

    国外用户说挂脚本不停登录登出，过一段时间系统会重启。

    自己写了一个脚本测试，但是没有出现客户报的问题。

    后来我的美国主管写了一个，可以重现，但是需要挂机很长时间才重现，但是和我脚本用的不是一个API。

    没法，我只好把老板的脚本先学会。接着把系统的登录代码从头到尾看了一遍。最后问题为，当logout时，直接退出，不切断ssh链接，立刻就复现问题。

    实际解决时间，就1个下午。但是前期准备时间很长，unix API，系统代码登录登出的流程， 3个脚本，每一个都消耗了很长时间。

    问题1：还是太急躁，总想立刻就把解决问题，这个给自己带来不必要的压力。

    缓解压力的方法：可以把自己要做的事，列出来，写成邮件，告诉主管和客户，为什么要花这么长的时间解决。例如我要消化客户和主管的脚本，需要理解unix API和系统代码。解决问题就像吃饭一样，今天的饭就今天吃，不可能今天把明天的饭提前吃。这是客观规律，不管压力多大，也需要花时间。

    好的方面：提前把系统代码登录登出流程有画图了解, 找原因时，只是判断使用unix API的方法是否正确。

具体项目总结2

    如何解决偶现问题。

    测试中发现偶尔有登录失败，和负责这块的同事交流无果（因为同事要离职了）。先怀疑是测试脚本的问题，搁置了此问题，但该来的还是回来，终于在用户那爆发。具体的描述是，ssh和netconf时，一起使用相同用户登录会有冲突。

    总结：如何判断一个问题真的是问题。最后想来想去，只能从代码的流程来找问题，当问题不明显的时候，光从测试看不出端倪。

具体项目总结3

    测试的同事说有问题，我查了没问题，以为是测试操作有问题，就放过。结果测试又说有问题，我还是查的没问题，又放过了。但是测试还是说没解决，最后就坐在测试同事边上，一步一步看他的测试步骤，终于稳定重现问题。

    总结：测试员说很简单就重现，结果自己按自己想的很简单的步骤，没重现，因为这个case自己测过，也放松了警惕。

               实际测试步骤一点都不简单，但是自己被误导了 。

               当bug需要特定的步骤时，需要跟着测试员一起看，因为测试员有时描述不清具体的情况，导致我误判。