测试策略:模块化测试用例
目前，我的公司采用模块化测试用例方法，在业务工作流测试的背景下。在这种方法中，我们有很多组件级测试用例，它们本身并不是我们回归套件的一部分；然而，这些测试用例都用于更大的、工作流风格的、端到端、数据驱动的测试用例中。例如，如果Gmail是我们的应用程序，我们就会有一些东西(构建得更多，但希望您能理解我的观点)：
组件测试用例
-Login，参数化(用户名，密码)-本身不是回归水平测试
参数化的-Compose消息(收件人、主题、消息、抄送收件人)-本身不是回归级别测试
-Add附件，参数化(filepath/name) -本身不是回归级别测试
-View收件箱消息，参数化(来自收件人、主题、消息、附件)--本身不是回归级别测试
-Forward消息--它本身不是一个回归级别测试
-Reply -不是回归水平测试本身
-Logout -不是回归水平测试本身
回归测试用例
-Forward a message：--登录(“发件人”、“password1”)>撰写消息(“接收者”、“自动化”、“问题”、“”)>“发送”>登录>登录(“接收者”、“password1”)>查看收件箱消息(“发件人”、“自动化”、“问题”、“”)>转发消息>撰写消息(“转发人”)、“Fwd:自动化”、“问题”、“发送”>发送
-Send带有附件的消息：--登录(“发件人”、“password1”)>撰写消息(“接收者”、“自动化”、“问题与附件”、“”)>添加附件(“文件”)>发送>登录(“接收方”、“password1”)>查看收件箱消息(“发件人”、“自动化”、“问题”、“文件”)
这是我们面临的困境:很少有测试用例管理工具(QualityCenter，可能还有QTest)支持这种类型的测试。在数据驱动测试方面，我们已经研究过的许多其他中医工具都只支持组件级。(即可以用50组不同的数据登录50次，可以用不同的数据发送50条不同的消息)。我们开始怀疑我们是否是离群点，这就是我在…中的问题所在。
许多公司是遵循由组件级测试组成的工作流式测试，还是公司通常迭代地执行具有不同数据排列的非常小的测试用例，而将工作流测试留给探索性测试？
回答 1
Stack Exchange QA用户
发布于 2018-02-12 19:25:32
您并不是异常值--工作流风格的测试会发生，但重要的是要注意这一点:没有任何工具为工作流级测试提供良好的记录回放支持。记录回放工具和开箱即用的数据驱动是建立在假设所有的测试都是简单的。
这就是使用像Page这样的模型的地方，特别是使用了流畅风格的编码。
在回归测试中会有类似的内容(使用c#-ish语法，因为这是我最满意的地方)：
[Test]
ForwardAMessage()
{
MessageSentPage = LoginPage.Login(dataSource.Sender, dataSource.SenderPassword)
.ComposeMessage(dataSource.To, dataSource.Topic, DataSource.Body, "")
.SendMessage()
.Logout()
.Login(dataSource.Recipient, dataSource.RecipientPassword)
.ViewMessage(dataSource.SenderName, dataSource.Topic, dataSource.Body, "")
.ForwardMessage()
.ComposeMessage(dataSource.FwdRecipient, dataSource.FwdTopic, dataSource.FwdBody, "")
.SendMessage();
// assert that the targeted message has been forwarded using properties on the message sent page - in Gmail, probably the inbox
}
[Test]
SendMessageWithAttachment()
{
MessageWithAttachmentPage = LoginPage.Login(dataSource.Sender, dataSource.SenderPassword)
.ComposeMessage(dataSource.To, dataSource.Topic, DataSource.Body, "")
.AddAttachment(dataSource.FileName)
.SendMessage()
.Logout()
.Login(dataSource.Recipient, dataSource.RecipientPassword)
.ViewMessage(dataSource.SenderName, dataSource.Topic, DataSource.body, dataSource.FileName)
// Assert that the message properties match what you expected to see
}您的简单测试--您的组件测试--看起来更像这样：
[Test]
LoginToEmail()
{
InboxPage = LoginPage.Login(dataSource.Sender, dataSource.SenderPassword);
// Assert that the correct user is logged in
}您将定义不同的对象，这些对象包含用于执行所需操作的参数化例程:登录页面对象可能包含Login(string user, string password)方法，其中收件箱页面对象可能包含ViewMessage(string sender, string topic, string body, string attachmentname)等等。
然后，只需对数据进行结构化，就可以得到正确的测试:每个测试都定义一个数据源，并且有一个或多个要处理的行。
如果您想深入了解数据驱动，您可以更进一步，将所有内容封装到一个采用测试类型并通过case语句指向该类型的适当测试例程的驱动程序中--类似这样的情况：
[Test]
RunATest()
{
switch(dataSource.TestType)
{
case Forward: Runner.ForwardAMessage(dataSource.TestObject);
break;
// etc.
default: ;
}
}这种编码方式更复杂，可读性更低，但它允许您为任何受支持的操作(如case语句中定义的)添加测试，而无需添加更多代码。除非您使用的是一些非常复杂的东西，否则您可能不需要使用这个具有流畅样式的页面对象，这对您来说应该很好。
https://sqa.stackexchange.com/questions/32013
复制相似问题
腾讯云开发者
