我们试图找出在测试计划中编写测试的最佳方法.具体而言,当编写一个旨在供包括QA人员在内的任何人使用的测试时,测试中的步骤是否应该非常具体或更广泛,从而使测试人员在如何完成任务方面有更多的余地.作为一个非常简单的示例,如果您正在测试在文字处理文档中打开文档,那么测试应该是:
使用鼠标,打开文件菜单
在文件菜单中选择"打开文件..."
在出现的打开文件对话框中,导航到x并双击名为y的文档
要么
打开文件打开对话框
打开文件y
现在我意识到一个答案可能是"它取决于你要测试的内容"但我试图在这里回答一个更广泛的问题:如果测试步骤过于具体,我们冒险a)制作测试过程辛苦,乏味,更重要的是b)我们冒险丢失一些东西,因为我们写下了太具体的实现目标的途径.或者,如果我们做得很广泛,我们是否过分依赖测试人员当时的想法,并失去对客户/客户更常见的路径的关键测试？
我的第一个问题是 - 为什么你的QA部门没有编写测试计划？通常,软件开发人员为QA提供软件应该如何工作的功能规范,然后QA基于此创建测试计划.
话虽如此,我建议对这些步骤非常具体,因为你要详细说明事情应该如何运作.然后,测试人员的工作就是确保您的具体步骤能够获得理想的结果,并且他们的工作也就是偏离计划并试图破解.
如果有多种方法可以实现目标,则需要描述每条路径.
京公网安备 11010802040832号 | 京ICP备19059560号-6 