标签：如何 状态 拆分 发布 根据 有助于 增删改 多次 后半程
IBM曾经指出，测试管理有助于DevOps通过利用数据促进持续集成和交付。本篇文章主要讲述普元DevOps6.0是怎样设计一个帮助用户获得他们优质产品的测试管理，普元DevOps6.0的测试管理如何做到帮助产品更快地交付。
目录：
1.测试管理对于产品的帮助
2.什么是测试管理
3.测试管理的设计
1.测试管理对于产品的帮助
老话说的好，工欲善其事，必先利其器。对于开发团队来说，有很多工作需要做好，测试管理不仅可以使产品实现这些效果，还可以使它们超越自我，达到最佳。IBM曾经指出，测试管理有助于产品通过利用数据促进交付。测试用例和测试数据可以轻松关联，并分析各种结果。这些见解对于帮助开发团队进步并不断满足用户需求至关重要。
通常来说，测试已经到了软件开发生命周期的最后阶段，在保证一切工作正常的情况下留给企业做重大改变的空间非常有限。Datical指出，传统的软件开发手段通常会在开发周期后半程才发现缺陷，这通常迫使组织付出很大的代价来解决这些问题，并最终减缓整个开发进程。测试管理将成为产品质量的推动者，并确保产品符合利益相关者和用户所设定的质量标准。
“QA实际上被认为是DevOps中非常关键的组件，甚至于DevOps强调质量保证是每个人的责任”，Datical说。但这并不意味着QA专业人员在DevOps环境中不再具有作用，而是意味着与组织中的其他所有人对质量和稳定性承担更多的责任，QA可以并且应该扮演更具战略意义的角色，并提供对质量保证功能的全面监督，以及建立更强大稳定的测试基础设施。
正如意料之中的，测试管理使开发团队和测试团队能够更好地协作以更快的交付和敏捷的支持，另一方面这些好处也从本质上导致了跨项目的质量的提高。
2.什么是测试管理
那是一个平平无奇的下午，我一如既往的搬运着代码，老大突然过来和我说了有这么个需求，我当时是没有相关概念的，老大看出我小小眼睛里的大大的疑惑，为了解决我的疑惑拉上了产品经理开了数次的讨论会，给我说明了各种使用场景，我终于是了解了要做的是什么了，原来是测试管理。
那为什么DevOps要做测试管理呢？
美国质量保证研究所对软件测试的研究结果表明:越早发现软件中存在的问题，开发成本就越低;在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍;软件质量越高，软件发布后的维护成本越低。
看到这里就不应该问为什么做了，而是应该反问了，这么猴赛雷的能力为什么不做呢？
但是头疼的事情来了， 怎么设计才能达到效果？
3.测试管理的设计
参考概念模型，我们可以 将需求拆分成3个部分：测试用例、测试计划、测试报告
1、测试用例
解析需求的过程和目的，明确要达到的效果，对操作过程和预期结果进行描述，这个过程将输出为测试用例。那么怎么统一管理测试用例呢？DevOps的用例库会对测试用例进行统一的管理。做到这里肯定还是不够的，我们需要再对测试用例进行更详细的分类，这里就使用了分组对相同类型或者是相同功能的测试用例进行分类，这里当然是不禁止套娃的，树形分组可以把测试用例分类成你想要的那样。
那么用例库是不是就只能进行测试用例的操作或者管理呢？或者说仅仅增删改查就能满足用户的需要了吗？当然是不够的，用户可以在用例库中对相关数据进行查看，测试用例将与不同测试计划中的该条用例执行结果关联，可对多次执行的结果进行分析和总结。为了追溯执行该条用例产生的缺陷，测试用例也与不同测试计划中的该条用例产生的缺陷进行了关联，可以随时关注到所关联的缺陷的状态。
另外有一个使用场景需要考虑到，用户如果要删除掉某个已有执行结果的测试用例，那这个操作是不能影响引入该用例的已完成和归档的测试计划，我们可以将该测试用例标记为已废弃状态。同样的，引入该用例的未执行和已执行中的测试计划中，该条用例也会被标记，可以让测试人员根据具体需要决定是否要将此用例移除。
2、测试计划
确定各测试阶段的计划和目标，明确要完成的测试活动，评估完成活动所需要的时间，进行活动安排和分配，这个过程将输出为测试计划。
什么叫各测试阶段的计划和目标？举个栗子，比如验证基本功能，目标就是确定产品基本功能可用。明确要完成的测试活动，接着上面抛来的栗子，要验证基本功能所要执行的测试用例就是要完成的活动。评估时间的目的是对测试计划执行的进度进行把控，可以帮助测试人员更好的利用和分配时间。活动安排和分配能对测试计划的执行进行更细化的管理。如果是测试用例较多、时间比较紧张的计划，不可能将一整个测试计划的执行都让一个测试伙伴去做，这时候就要根据测试伙伴们的时间分配任务了。
鲁迅曾说，“没有测试用例的测试计划不是一个好的测试计划”。
当创建测试计划时，用户选择需要的测试用例导入，为了方便管理和查看，导入测试用例时也会带入用例在用例库的分组信息，要注意的是在计划中修改用例的信息不应该对用例库中的该测试用例产生影响。一个好的测试计划不仅仅得有用例，用户还会关心这些用例在用例库里的比例，也就是用例库覆盖率。当然除了这个还必须要对测试计划的执行过程进行关注，执行成功了多少，失败了多少，还有多少关联的任务还未解决，这都是用户比较关注的问题，我们需要对这些数据进行统计。
测试计划开始执行时，会进入测试执行页，测试人员根据测试用例的步骤描述执行测试，测试结果与描述的预期结果进行比对，对比对的结果进行记录，如果测试该功能产生了bug，直接在测试执行页产生缺陷任务项，若存在相同的已存在的bug任务项，测试人员可更改相应的任务项的状态。
这里也需要对测试的完成状态进行把控，若计划没有执行完全，或者还有未执行的测试用例时，用户要变更此计划的状态，要对用户进行提醒，因为计划的状态“未执行->执行中->已完成->已归档”是不可逆的。测试执行时，项目管理员需要查看测试计划的产生的缺陷的情况，那我们就需要提供查看此测试计划关联的缺陷项，测试人员可以对已解决的缺陷项关联的测试用例进行验证执行，可根据执行结果判断缺陷是否已被解决，解决就关闭任务项，未解决就重新打开。
3、测试报告
根据测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录当前测试结果，记录、跟踪和管理产品缺陷，最终得到测试报告。
根据用户关心的数据，测试报告的设计应该包含测试执行报告、测试结果报告、关联缺陷报告。
测试执行报告应该从多个方面反映出测试计划的执行过程，要反映计划整体的进度，就需要从3个角度去看：从时间角度，计划已执行的天数和评估的时间进行对比；从结果的角度，要看计划中测试用例执行了多少，未通过的数量有多少；从关联缺陷的角度，是否还有未解决的缺陷。
测试结果报告以计划为单位展示测试用例执行结果数据，考虑到用户会有查看汇总数据的需求，设计时应该提供汇总多个计划中测试用例执行结果数据的。
测试小伙伴们比较关心的数据就是提交的缺陷改了没，还有多少缺陷需要验证的，缺陷报告会统计这些数据。测试小伙伴们在测试过程中提交关联缺陷，缺陷报告会以直观的柱状图展示自己提交的缺陷的状态，帮助测试小伙伴们了解自己相关的工作量。
就写到这里了，当然还有些不足的地方，比如说缺少了审批的环节、测试报告不够全面、各模块的关联性是不是就足够了？这些问题的解决会在之后的版本里推出，大家有什么想法可以在评论区讨论哦！
最后的最后，辟谣！
“那句话我没说过，是他瞎扯” ———— 鲁迅
精选提问：
问1：请问测试用例管理，除了Robot framework的自动化测试的用例，常用的手工功能测试和非功能测试案例是否也可以纳管？
答：可以纳入。
问2：测试主要在性能测试还是功能性测试，前后端的测试用例是否有关联性。
答：本次普元DevOps6.0测试管理关注点是对测试用例的管理和支持测试计划安排与执行跟踪。
标签：如何 状态 拆分 发布 根据 有助于 增删改 多次 后半程
原文地址：https://www.cnblogs.com/zgq123456/p/14771577.html
