在实施之前编写测试用例？

#1 楼

好吧，首先-恭喜，哥们，很高兴知道您为客户/公司工作，并了解在早期阶段参与质量检查绝对是值得的！

我将在下面从我自己的角度讲几点管理QA团队（最多10个FTE）的经验，涉及相当大的项目测试，要求页面数约为1000页或更多，业务逻辑非常复杂，以至于QA团队新手的典型项目调查大约需要2-3周。

许多客户确实认为，在任何情况下，对任何类型的测试文档进行投资都是在浪费精力：实际上，在这段时间内我们不进行测试并且不显示任何错误，所以有什么好处？ ？下定决心之前，请考虑以下事项！ （：


在项目的早期阶段创建测试用例（或简单的任何类型的测试文档），例如原型设计，需求优化，早期DEV就有一个很大的优势：与此同时，我们测试需求！有时，错误的发生率甚至有时会比应用程序本身还要高，但是在早期阶段，其错误修复需要花费BA /分析人员几个小时的时间，而不是稍后进行数百小时的DEV工作。在首次构建之前两个月就参与了测试用例的创建，阳光能够揭示500多个不同严重程度的问题：从错误的警告消息到业务流程中的矛盾，所有这些都由3位分析师团队轻松处理-比较40个以上DEV团队处于实施和实际应用测试的活跃阶段。
同时，我必须承认，许多早期测试用例已从最终套件中消失了。实际上，在第一个版本之前创建的约2.5k个整体测试用例中，正在运行的套件中仅包含约1.5k。真的值得吗？好吧，除了上述与要求测试有关的要点外，到第一次测试时，质量检查团队本身就已经足够熟悉该功能，因此，从一开始就对同一测试的测试工作仅比以后增加了20-25％ 。考虑到系统的复杂性和不可更改的项目发布日期（在我们的案例中，这完全是不可更改的！）实际上是不可能的，因为对于任何规模的项目调查团队来说，同样需要2-3周的时间。因此，在我们的案例中，这是产品调查中最重要的部分。
关于测试用例的格式和细节：确保在需求提炼阶段创建详细测试用例的东西根本不是最佳选择。在所描述的情况下，我们最终采用以下方法：首先是简短的文档，其中仅对测试方向进行了高级描述。 “ For the document submission form: personal info details integrity, attachments availability for download and printed form version are tested using this and that sets of test data”。这样的文档（我们称之为“ Test Design”（我们的项目经理只是喜欢（：）））随后传递给了分析师，分析师随后针对所描述的方案进行了删除，更正和调整了优先级。仅在此阶段之后（大约占10-15％与创建详细的测试用例相比，这种改进的测试方法被转换为详细的测试用例。毫无疑问，当逻辑复杂且项目庞大时，这样做是值得的。对我来说，它看起来与“ My current suggestion is to map the use case and data/control flow of the requirement being tested.”几乎相同最初的问题！）
在此阶段，请不要忽略测试环境的准备工作或至少进行计划：这将有助于避免以后出现意外情况，并节省发行周的宝贵时间甚至数小时（对于我而言，那是真正了解“ hour lost at project start is that very same hour you so terribly miss at release date”的项目）。

上面的内容也许比OP中的预期要宽一些，但是我希望某些想法对其他人会有所帮助。可以肯定的是，在QA参与的早期阶段，实际方法取决于项目/团队/复杂性/发布日历等。因此，“ test cases before the application”方法对于规模小/逻辑简单的项目值得怀疑，但是对于大型项目，这些QA工作将明智地计划，就能获得可观的整体利润。

#2 楼

您绝对认为在早期阶段最好花时间来理解问题。

映射需求的用例和数据/控制流是建立这种理解的一种好方法，在这样做的同时，您还正在测试这些需求，因为您会发现想要解决的问题问，需要澄清的差距和不明确之处。

我建议您也退出需求文档，花些时间了解被测系统旨在提供什么价值。仅查看需求列表可能很难发现这一点-您可能需要跟进业务分析师或业务的其他代表，以了解需求背后的动机。 （您可能会发现企业实际上并不清楚他们想要什么价值，或者不同的利益相关者对此有不同的看法和矛盾的看法。在这里要保持外交意识，并牢记您的公司文化。在某些公司中，您非常感谢您发现这种问题，而在其他情况下则不是。）

不了解系统应提供的价值，但是，您没有任何设计测试的方法，因此他们最有可能揭示该价值的风险。那就是您的测试目的，不是吗？不仅是毫无疑问地确认每个要求，而且没有其他内容了吗？

我希望在早期阶段做的其他事情是获得对该技术的了解，特别是如果它对我来说是新的。我要去的深度取决于项目-有些要求我建立起相当好的技术理解才能识别风险，而有些则不需要。我在执行此操作时不仅在寻找风险，而且还经常尝试了解哪些工具可能对我探索系统有用。有时我会提前编写一些工具。我还考虑了哪些测试数据可能有用，我可能需要哪些测试环境等等。

所有这些东西比花时间记录您还不太了解的东西更有价值。

#3 楼

在几乎要问相同的问题时分享我的想法。

我发现以关键字驱动的测试框架可以帮助QA在准备好测试应用程序之前启动。尽管实际上，您的质量检查团队可能还有其他东西（产品/版本已经投入生产），而当前relese的实现尚未准备好进行测试。

我们面临的问题是规格/设计持续进行次要更新，当首次构建结束时，测试用例可能会过时。使用关键字驱动的框架，您只需更改/调整关键字的库，然后您的测试用例就可以再次恢复正常。这可能需要一些实践来以不需要触摸测试用例的方式来创建关键字，但是应该缩短在对被测应用程序进行“较小更改”后使测试用例再次工作所需的时间。

一个简单的示例，在甚至没有看到登录页面之前就对登录页面进行测试。

带有关键字驱动框架的测试用例：

    log in to site with ${valid credential}
    veryfiy login was successful
    log out 
    page should not contain $(element)

您可能还会有其他50个具有无效/空/双咬凭据的类似测试用例。

因此，您的登录页面可能会得到完整的改进，您需要做的就是更改关键字的下划线代码，然后所有的tescase都应重新开始工作。

您可以辩称，定义良好的测试子例程将执行相同的操作，但是我发现关键字驱动的框架使其更容易自然地完成。

#4 楼

首要任务是：


读取并优化需求
准备测试用例
将测试用例映射到需求
创建测试数据
创建测试环境
实际上尝试深入了解完整的应用程序
上一个sprint剩下的任务。

在实施之前访问Testers任务以详细了解每个建议，并查看是否有帮助或不。