我的问题可能听起来有点愚蠢。
我的团队必须测试一个由 3 个不同的User Roles 使用的 Web 应用程序。因此，我们首先根据用户故事编写测试用例。我的问题是我不想为每个用户角色创建 3 个不同的测试用例。我认为在编写测试用例并稍后对其进行测试时，这需要大量时间，因为：
Total Test Cases Number = User Stories x Test Cases Per User Story x User Roles Number.
此外，如果将来某个时间会创建新的用户角色，我不想创建新的测试用例，因为它们只是重复的，有一些小的差异。
有没有更好的方法来处理这种情况？
提前致谢。
【问题讨论】：
标签： testing testcase user-roles microsoft-test-manager
Single Responsibility Principle?
单独编写和测试用户对用户故事的访问权限，除非您确实根据您的角色获得了完全不同的故事，在这种情况下，它是一个独特的规范并需要进行自己的测试。
【讨论】：
不确定在编码方面（取决于情况以及代码是如何实现的），但我可以从测试的角度回答（到目前为止 2 年，在迁移到敏捷的传统瀑布系统中超过一半)。
我测试的 Web 应用程序类似，我们有三种用户类型（全局）和三种用户角色（与“项目”相关联，即网站桶，网站作为图像桶，如果好奇，请查找 EyeQ ）。因此，9 个可能的组合，其中 8 个可以创建一个站点。当前的回归程序文档有 100 多个测试用例，其中 20 个左右是编辑/创建/删除站点。总体总计：500 多个测试用例大部分是手动运行的（正在努力使它们自动化，但需要时间，因为我们已经通过 UI 重新启动）。
无论如何，由于 UI 的全面更改，我不得不重写我们的一些手动程序，并试图避免在我之前犯过的作者所犯的错误，例如您所描述的错误（过度重复，也就是重复使用相同的测试 3 次）略有不同）。
我没有坚持他们编写案例的策略，而是使用循环（编码中也适用相同的术语）——也就是说，每次通过使用一个角色类型组合的测试用例。与其为每个角色/类型编写相同的测试用例 3 次以上并分别执行每个测试用例，不如使用该过程一次，但在最后添加几个步骤。
示例测试用例： 用户可以创建一个站点（8/9 的类型角色组合可以在我的应用程序中执行此操作）
我进来之前他们做了什么： 测试用例 1- 未绑定到项目的系统管理员可以创建站点（10 个步骤）； 测试用例 2- 具有项目角色的系统管理员可以创建站点（相同的 10 个步骤）； 测试用例 3- 未绑定到项目的帐户管理员可以创建站点（与第一个案例相同的 10 个步骤）； 测试用例 4- 具有 proj 角色的帐户管理员可以创建站点（同上）； 测试用例 5...等等
我做什么： 测试用例 1：使用组合 1 以用户身份执行 10 步， 步骤 11- 以该组合注销，使用组合 2 以用户身份登录并重复 1-10， 第 12 步 - 从第 11 步以用户身份注销，并以组合 3 的用户身份重新登录并重复 1-10， ...
区别： 执行了 3+ 个测试用例或 30+ 个步骤（在这种情况下，大约 100 个） 对比 1 个测试用例：20 步以下
尽管如此，这取决于您的问题类型。 如果它确实是重复的（与示例一样）尝试尽可能循环。
优点是，当你建立一个自动测试框架时，测试用例中的一个简单的 for 循环，带有一个数组对象或结构体作为输入。 缺点是，它不会是模块化的（如果出现问题，需要额外的 30 秒才能找到问题原因，但这是我的观点）。
【讨论】：
无需混淆。您只需要制作 Matrix 以获得访问权限 Vs。用户角色。 例如：- Raw：用户模块（用户的权利） 列：用户角色
只需在 Excel 工作表中标记哪个用户具有什么类型的权限或访问权限。 你也可以下载一些工具来生成这种排列组合。
您可以从这里下载。
https://testcasegenerator.codeplex.com/
它是精确测量排列组合的好工具。
【讨论】：
我们已经为一个大型企业应用程序测试了这些基于角色的测试用例，该应用程序使用思维导图在 15-20 多个网页上拥有近 38 个角色和 100 个可编辑或不可编辑的字段。
由于每个角色都有很多工作流状态，因此需要进行彻底的测试。
添加一个涵盖功能和权限的通用测试用例，并在测试说明中提及，以按照设计的思维导图为每个角色执行测试用例。将思维导图附加到测试用例。
我们将测试用例转换成思维导图： Sample MindMap
思维导图有助于将大量数据整合为图形形式，便于理解测试用例并加快执行速度。
【讨论】：