H模型

H模型的示意图仅仅演示了在整个生产周期中，某个（测试）层次上的一次测试“微循环”。图中的“其他流程”可以是任意的开发流程，例如设计流程和编码流程，也可以是其他非开发流程，甚至是测试流程自身。向上的三
角箭头表示，在某个时间点，由于“其他流程”的进展而（由于先后关系）引发或者（由于因果关系）触发了测试就绪点，这个时候，只要测试准备活动完成，测试执行活动就可以（或者说，需要）进行了。
概括而言，h模型揭示了
1、 软件测试不仅仅指测试的执行，还包括很多其他的活动；
2、 软件测试是一个独立的流程，贯穿产品的整个周期，与其他流程并发的进行；
3、 软件测试要尽早准备，尽早执行；
4、 软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的，也可能是反复的。

采用h测试模型的三个理由
1、有利于测试的分工，从而降低成本，提高效率。
首先，h模型强调软件测试准备和测试执行分离。准备阶段和执行阶段有不同的测试活动，例如，测试准备活动，包括测试需求分析、测试计划、测试分析、测试编码、测试验证等等，而测试执行活动，则包括测试运行、测试报
告、测试分析等等。准备阶段和执行阶段有不同的工作侧重点，不同的测试活动也需要不同的知识和技能。显而易见，测试的设计人员比执行人员有更高的能力要求，不同的岗位可以聘用不同的人员。如果一个测试设计人员同时
被指派去执行测试，那既是人力资源的浪费，也可能挫伤设计人员的创造性合积极性。所以，软件测试分工带来的第一个直接好处就是降低人力成本。第二个直接好处就是提高效率。分工带来的间接的长期的好处是，软件测试可
以成为一个有职业前景的职位，这有利于吸引人才以此作为自己的职业生涯，从而形成软件测试领域的人力积累和良性循环。
2、有利于认识到测试的复杂性，从而赢得重视和尊重。
H模型可以促使人们充分认识到软件测试的复杂性。这儿的复杂不是指技术上的复杂，而是指过程上的复杂。正如传统的软件开发被简化为编程一样，软件测试也常常被简化为运行一下被测的软件，观察是否有异常的运行结果
。软件测试也有不同的阶段，有不同的活动，而且这些阶段和活动要被组成一个系统才能有效的运作。没有组织的，非结构化的软件测试除了浪费时间和金钱外，几乎不可能有实质性的产出。认识到复杂性才可能得到足够的重视
和必要的尊重。重视主要来自于管理层，而尊重则主要来自于平行的其它流程的人员，例如编程人员。尽管测试流程是一个独立的流程，但它必须被置于整个软件生产的流程系统中，作为一个有机的组成部分，并与其它流程有效
的交互，才可能发挥作用。
3、有利于了解测试投入的去向，从而得到测试效益的公正评判。
第三个理由与一个长期存在的“测试怪圈”有关。测试经理总是抱怨测试上投入不够；测试人员要么被看作是“无所事事”，要么被看作“忙而无功”；而管理层则因为测试上的投入没有一个可视的结果而拒绝加大投入；更糟
糕的是，用户在投诉软件的质量问题，组织的声誉和利润都每况愈下。H模型并不能扭转这种糟糕的局面，但它有助于跟踪测试投入的流向，例如，在各个测试活动上的投入分别有多少，比例是否合理，哪些是用于测试准备的，
而如果由于其它流程的差错导致重做准备，那么浪费的投入有多少。在h模型中，测试是一个有组织的、结构化的独立流程，既保证了自身的有序和结构清晰，也保证了流程之间的“界面”清晰。这样，软件测试就不是一笔糊涂
帐，才可能得到公正的投入-产出的评判，软件测试才可能避免成为“出气筒”和“替罪羊”的“宿命”。