自动化测试杂谈

自动化与手工

 

测试工作无论从手工测试还是自动化测试都是软件质量保证的一个途径。网上有各种blog讲了他们两者的好处和缺点，这里我简单总结一下，以备以后面试中会问到。

 

自动化的产生：主要是用简单的脚本实现大量重复操作，做回归测试，模拟人的行为减轻测试人员的时间，进而减少成本。

 

自动化优点：

 

1.程序回归测试更加方便。回归测试的动作和用例是完全设计好的，回归的脚本自动执行可以缩短回归测试的时间，在版本迭代中是比较关键的一环。

 

2.一定程度上可以实现压力测试。这个要具体应用具体分析，一般重复操作模拟用户点击及下单操作等。

 

3.测试具有一致性和可重复性，增加软件信任度。流程化操作业务及功能点成为可能，解决大部分问题，自动化用例的设计可以完成更多手工完成不了的任务，为版本回归和验收测试提供依据。

 

自动化缺点：

 

1. 手工测试比自动化测试找到的Bug更多。

 

2. 对于软件需求变化比较大的情况下，不适合自动化测试，因为脚本的维护比较大。

 

3. 仅对移动端测试工具的选择上，没有一种相对成型的工具可以进行。

 

小公司开展测试工作

 

大公司自动化有专门的团队去做的”规范化、流程化”，他们有自己的测试团队去维护扩展，基本是成型的。我认为小公司的自动化测试应该走”敏捷”思路。Scream(敏捷测试)提倡以人为本，”人”的因素在软件开发及测试中具有相当重要的意义。敏捷测试强调”团队意识”、”互补意识”、”沟通第一”、”进度透明”等等，对于小的公司，没有所谓的严格规章制度，大家为了提高工作效率和员工积极性，可以在黑板上写下今天测试的bug(算是每日工作进度及质量)。”时间表”记录本周、本月的测试计划及进度等。同时可以开展每周例会编写表格记录本周测试工作。

 

对业务流要精通，精通软件需求业务，对功能的业务逻辑进行深入研究，对于每个功能点的输入结果、输出结果要比产品经理还要熟悉。对操作流要比较熟悉，所谓的操作流就是对于功能点采用正常、异常、不符合逻辑的变态测试，说白了就是不把应用搞死不罢休的思路，当然开发和用户绝对不会去这样做的，但是出于对于软件的稳定及安全方面考虑，还是要大概涉及一些的。

 

移动客户端是否需要自动化测试

 

1.软件需求变动不频繁

 

自动化脚本稳定性决定了测试维护成本，软件需求变动频繁、过大，测试人员就要花很多时间更新用例及测试脚本，还要修改调试自动化框架，所花费的成本低于利用其节省的测试成本，那么自动化测试便是失败的。

 

2.项目周期时间要足够长

 

需求确定、框架设计、测试脚本编写与调试需要一段时间来完成，项目周期短，耗时耗力去做这些毫无意义。

 

3.自动化测试脚本可重复使用

 

不用多说，一个自动化框架的构建不容易，如果可扩展性不好和重复利用很难，那么就是失败的，毫无意义的。

 

移动端开发周期短，需求变动频繁，迭代周期短，做自动化得不偿失。