你需要编写测试用例吗?

做自己的女王ヽ

简介
测试软件是一个真正的挑战,因为有很多类型的测试用例有很多不同的形状和大小。 事实是,没有“
一刀切”的方法对软件QA测试。 你必须花时间停下来评估在你桌子上的每一个项目。 在某些情况
下,您将希望创建一组全面的测试用例的详细计划,将记录你的每一步。 其他项目会让自己更随意,
探索性方法,敏捷测试用例是有帮助的。 绝大多数会在中间。

写测试用例是一个耗时的活动,
和方法不同综合测试计划更多的休闲和探索性的案例。
什么因素影响你的方法吗?
我们来看一看一些这些因素帮助你引导你的项目和团队的成功。

做一个测试用例

当你决定是否要创建一组软件测试脚本,有一些你不能忽视的影响因素。 编写软件测试用例的观点
日益强大,当你必须符合特定的业务规则。 项目可能会遵守法律要求,或甚至可能有合同义务提供你
测试的书面证据。 在这种情况下,你显然需要详细的测试用例。

大多数应用程序存在利弊时测试用例。 如果它是一个企业应用程序,您希望使用多年,然后一系列的
深思熟虑的敏捷测试用例将提供物有所值,因为他们会一次又一次的被重用。 他们甚至可能形成自
动化测试的基础。 如果它是一个局部的移动应用程序,需要上市快,不可能被更新,那么它可能不值
得花时间起草测试用例。

您还必须考虑如何灾难性的错误。 大多数软件,迎合医务人员不能出错。 其后果是太大了。 软件
测试脚本必须写详细的验收标准,以防止任何可能的人类疏忽时验证系统需求基础。 其他应用程
序可能不是关键任务,所以可以附带一些小错误。

在敏捷环境中测试

如果你的开发团队采用敏捷方法,动态特性设计和变化不断介绍吗? 如果没有明确的应用程序,你将
最终的开发,如果需求可能会改变,然后写很多敏捷测试用例将是毫无意义的,因为你将不得不重写
他们完全在几个构建。 你可能会选择一个清单方法并结合探索性测试和一个简单的兼容性需求
列表不需要阐明。 甚至可能仅仅为测试人员参考原始用户故事,通知设计或直接与客户交流,找
到他们的测试的基础。

了解你的听众

观众是另一个重要的考虑因素,它分解两方面测试团队和最终用户。 你的测试人员是如何熟练?
他们拥有什么背景知识,他们将被测试的软件有多复杂? 一个有经验的测试团队与相关背景知识
不需要指导。 新秀阵容,另一方面,将受益于一组测试用例。

软件在一个特定的利基或为一个特定的职业可能会适合的测试计划。 你可以预测最终用户如何
与相应产品和测试。 针对大众市场的软件应该受到更多的探索性测试。 直观和经验丰富的测
试人员对终端用户如何与软件交互,和他们可以发现重要的bug,如果他们找到他们的自由。

让您的测试团队

值得考虑可能会使人变得消极效应,严格,一步一步的测试用例对测试团队成员。 如果他们的日常
工作变得熟悉,冗长的介绍相同的旧的测试步骤,然后他们会厌倦。 未能使用他们的技能,鼓励他
们的思维过程,因为过于严格的测试用例通常会导致错误的下滑。 优秀的测试人员将很快暴露测
试用例中的任何缺陷如果你给他们机会分享想法。

所以,让你的测试团队定位测试作为一个创造性的挑战提供了机会来尝试不同的路径到达的共同
阐述了软件质量。 他们总是有限制的时间,人员,文档,在您的项目和其他资源,编写测试用例可以
是一个耗时的测试活动。 选择哪一种编写详细的测试用例将产生重大影响的有效性测试团队,我
希望本文中描述的因素将有助于使您的测试用例的决策更容易。

梦想家

谢谢分享~