测试用例是否应该包含业务逻辑？
测试用例是否应该包含业务逻辑？
提问于 2016-09-20 11:14:42
我和我的上司意见不一致。
背景：
基本上，对于我们的应用程序来说，这有时非常复杂，我们有：
- .doc文档中的App规范
- 重复规范的JIRA需求票，但是描述更详细，可能(或不)包含技术实现细节。
- 独立系统中的测试用例
测试用例格式很简单：
Step | Expected result
------------------------问题:我们的许多测试用例(1000+)在我们的测试用例中都有业务逻辑的复制、粘贴或解释。示例：
Step | Expected result
----------------------------------------------
1) Click button | The field should become disabled
2) Click something else | (because if A is true, then B affects C, and
3) Check some other field | because of that the field becomes disabled)我的理由是:这是不必要的重复(上面括号中的短语)，应该删掉(我确实删除了)，如果测试人员需要进一步了解他/她正在做什么- JIRA票证链接是一个点击(在测试用例本身或测试套件的头)。
Superior的推理:如果没有额外的解释，测试人员就不理解业务逻辑，只是盲目地执行单击操作，这是很糟糕的。在测试用例执行回归测试时，测试用例应该教育测试人员(特别是新的测试人员)。
我对此的回答是:我完全支持测试人员了解业务逻辑(否则测试人员几乎是无用的)，但是测试用例并不是保持业务逻辑的地方，它需要简洁和切题，否则测试人员将被迫阅读更多的文本，因此手动回归测试将变得更慢。
在这一点上，讨论到了一个死胡同。
回答 1
Stack Exchange QA用户
回答已采纳
发布于 2016-09-20 12:22:12
很短的版本-这取决于
更长版本的
这两种方法都有其优点。一些一般的启发式方法：
- 一个文档中的所有内容都是优先考虑的--如果您的公司认为测试人员在测试用例文档中拥有他们所需的所有信息是很重要的，那么他们将需要测试用例中的业务逻辑。
- DRY是一个优先事项--如果您的公司支持不要重复自己，那么他们会希望测试用例文档引用业务逻辑而不是重复它。
- 测试是/可能外包的-如果有外包测试的计划，可能希望在测试用例文档中包含所有逻辑，以限制必须从公司发送出去的内部文档的数量。
- 自动回归是计划的--如果有一个自动化回归测试的计划，那么测试用例文档中可能需要业务逻辑作为自动化团队的指南。
- 其他文档没有正确的细节--这比任何人都希望的更频繁，但这仍然是一个问题:测试用例的测试人员注意到，应用程序逻辑与文档不完全匹配。他们没有更新文档的权力，也不知道在下一轮回归测试之前是否会更新文档，所以他们更新测试文档，以便下次测试的人知道应该发生什么。这迟早会成为组织策略，并且在测试用例中期望业务逻辑。
- 没有人读说明书--再说一遍，不太理想，但我看到这种情况发生的次数比我想要数的还要多。如果没有人阅读规范，那么业务逻辑只在测试人员运行测试用例时才会被查看。
理想情况下，每件事都应该精确地记录一次，然后根据需要引用多次，但是生活并不理想，而且你的上级希望重复的原因可能有很多--也许有测试人员盲目执行测试用例的历史，这是缓解策略的一部分。
首先，我要研究一下您的上级希望/需要测试用例中的业务逻辑的所有原因，然后尝试与他合作，找到一种可能更好的方法来解决他想要解决的问题。
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://sqa.stackexchange.com/questions/22690
复制相关文章
相似问题
腾讯云开发者
