软件自动化测试应该 自动化测试工具
软件自动化测试应该
事情(通常所说的建设性或积极的测试)的任何事情(通常所说的破坏性或消极的 测试)
·测试应用程序是健壮的(例如，能够处理假的数据而不崩溃)；如果可能，特殊的积极测试结果和消极测试结果应该被确认为特殊测试脚 本的预期输出。
Fuchs是一个宁愿写自动化测试用例而不愿记录它们的人，他提供了一种创建自动化测试用例的三步方法，下面给出了具体的实施方案[2]。
第一步：设计测试用例。Fuc}ls说每一个测试用例都应该包含l～10个密切相关的场景。具有10个以上场景的测试用例应该分成多个测试用例。每个场景都应该与一个惟一的预期结果相关联。
第二步：手工运行测试。Fudu指出在回归测试中自动化测试是发现错误的最好方法，而在第一回合中用手工测试比较好。第一组测试用例在发现新错误方面应该是最有成效的，而回归测试应该发现较多的与软件的改进有关的错误。但是回归测试确实发现了原来没发现的错误。我们曾亲眼看到回归测试识别出了从一开始就存在于软件系统中的错误(举例来说，有一个错误在系统中存在了20多年，直到回归测试发现了它)。
第三步：自动化测试用例。在每个测试场景中，测试脚本应该包含以下几个部分：
·进行设置
·进行测试
·验证结果
·记录结果
·处理意外情况
·决定停止还是继续测试用倒
·进行请理工作
测试脚本必须运行的设置工作包括定义测试所用的共同变量、常数以及过程；也包括启动Aur和创建所需要的日录和数据文件。
测试工作需要模拟用户是如何使用AWr的。这里比较重要的一点是测试场景必须按照它们被编写的顺序执行，因为这个顺序代表着用户怎么样来进行工作。在识别典型的用作业务目的的场景时应该从功能需求文档开始。比较好的方法是看一个人怎样实际使用这个系统，然而在大多数情况下这是不可能的，因为系统没经过测试。
验证结果涉及到检查每个用户操作中的控制参数的初始状态和终止状态。同时也意味着为那些预期的和非预期的变化检查数据库。验证业务规则以及业务规则相互作用有关的应用程序功能性的惟一方法是确认那些变化是针对相关的数据值出现的。
记录结果就是指为每个测试用例的通过或失败的状态做一个记录。这样．在测试完成后，你可以回顾测试结果，可以把不同测试执行情况的测试记录相比较。
处理意外情况包括跟踪意外事件并对它们进行恢复。可能发生的意外事件包括意外按键、意外窗口、本来应该出现却没有出现的窗口和系统级的中断。
在每个测试场景结束时需要决定是停止还是继续。作出怎样的决定取决于刚刚执行的测试场景是处于通过状态还是失败状态。在一些情况下，即使前面的测试场景失败了，后面的仍然能够执行，但在另外一些情况下，如果前面的测试场景失败了，那么后面就会输出无效的测试结果。
进行清理工作包括关闭AuT、删除任何不再需要的目录和数据文件以及运行其他所有附属的清理工作。这通常是指将测试用例返回到出发点。
测试脚本应该置人测试套件中，并且测试套件从Shdl脚本中执行[2]。微软v如u出1bt在线文档显示了如何设计功能区域测试套件、回归测试套件、基准测试套件、压力测试套件以及验收测试套件。我们则添加了三类测试——单元测试套件、集成／冒烟测试套件和系统测试套件。
文章来源于领测软件测试网 https://www.ltesting.net/