软件测试过程的监控方法(3)

　　如果是比较大的软件开发项目，还会牵扯到：上线、割接、维护，一般会写在前期 的合同中，客户会按照上述阶段点阶段性付费，所以如果上述阶段点没有明确的成功、失败判定标准的话，对于公司尾款的收取是个挑战。

　　通过以上的详细询问，我相信，测试工作范围界定的是否有问题，测试工作是否规划的全面、细致，监控者应该比较清楚了，下面的任务就是将你的疑问记录下来，留待后面做证实。

　　测试实施期

　　在这个阶段，测试工作进行了一段时间，测试人员的工作应该已经步入正轨，按部就班的完成一些任务。这个阶段的特点是：开发人员和测试人员都按照日常的规范开始有条不紊的工作，有可能对一些问题已经习以为常，或者已经被同化。作为测试工作的监控者，应该在看似合理的工作中找出影响质量的问题，规避风险。

　　在这个阶段，应该关注以下问题。

　　l 缺陷管理流程是否规范?每个缺陷的提交和关闭是否都有复查?

　　缺陷管理是贯穿于整个软件开发过程、测试过程的关键环节，也是测试工作的根本，所以缺陷管理的流程是否规范，将是监控的重点。

　　首先，需要询问测试经理，软件开发过程中对缺陷的实际管理情况是如何的?不要让测试经理背诵公司的管理规范，而应该以一个实际缺陷为线索，追寻这个缺陷的产生直到关闭的过程是什么?期间是否有相关的记录，证明项目组的实施过程完全与描述相一致。标准的缺陷管理流程是怎样的，这里就不做叙述了，如果大家有兴趣可以查阅相关的资料。

　　在这个过程中，还需要注意一点：缺陷的提交和关闭是否都进行了复查。

　　缺陷提交和关闭的复查人可以是测试经理，或者测试经理指定的人选，一方面经过复查，可以减少缺陷的重复提交，提高缺陷报告的质量，另一方面在测试组中会有一个人对系统或一个大组件的质量情况有比较全面的了解，尤其在后期，这种了解会在很大程度上降低系统误发布的风险。还有一个好处是，在测试人员和开发人员交互的过程中，这个复查人员起到了桥梁的作用，可以有效的隔离开发与测试之间的多头沟通，在一定程度上提高了效率。这个角色可以是专职的，也可以是兼职的，关键看系统的大小。

　　l 配置管理工作是否规范?测试过程中涉及到的版本是否都可以完整的追溯?测试版本的发放频度是否符合测试的实际要求?

　　配置管理工作是整个软件开发过程的生命线，相比较而言，开发人员对此应该更为关心。对于测试人员来讲一方面要保证可以取到自己想要的文档版本，另一方面必须得到自己关心的程序的任意一个测试版本，以便可以在正确的版本上执行正确的测试用例。

　　在实际检查过程中可以在缺陷库中任意选择一个缺陷，查看这个缺陷是在那一个版本的程序中发现的，随即在配置库中调出该版本，看是否可以调出。随后，查阅该缺陷在那一个版本中修订正确了，随即也在配置库中调出该版本，看是否可查到。

　　在这个过程中，还需要注意开发部门提交给测试部门版本的频繁度，看是否过快或者过慢。过快或者过慢，没有一个时间上的判断。比如每2天提供一个新版本供测试人员进行测试，这个是过快还是过慢?判断的依据关键要看测试人员所处的状态，当版本提交的过快时，测试人员一直忙于对已修订好的缺陷进行反测，没有时间对新功能进行测试。当版本提交过慢的时候，测试人员的时间比较空闲。

　　在监控过程中，只需要询问测试人员的测试工作的紧张程度，一般就能够判断出版本提交的频度是否有问题了。

　　l 关键测试活动的关键测试资源是否如期到位?如没有到位是否进行了合理的规划来完成延误的测试工作?

　　在测试过程中，某些关键测试任务需要用到特殊的设备或者特殊人员的技能，称为关键资源。在测试实施过程中，要提前计划会用到那些关键资源，以免耽误项目进度。

　　作为测试的监控者，需要非常关心这些关键资源的使用情况，因为如果关键资源不能如期到位，势必要影响项目的整体进度。

　　如果由于某种原因，关键资源没有如期到位时，要注意测试人员是否对计划进行了修订，修订的结果是否可以弥补已经造成的损失，或者能最大程度的减少损失。

　　l 测试策略，测试计划，测试方案，测试用例是否都经过了正式评审?发现的问题是否都进行了更正?

　　作为测试的监控者，不可能在短时间内评估一份测试计划制定的是否合理有效，一份测试方案是否可以正确实施，并且也不必要这么做。

　　测试策略，测试计划，测试方案，测试用例等文档都是测试过程中的关键文档，也直接决定了测试工作的质量。监控者在评价这些文档的质量时，首先想到的一点就是我要充分的阅读这些文档，以我的经验和能力来判断这份文档的好坏。但是，作为一个项目组以外的人，很难能就所有的细节发表高质量的看法，其次，也不可能在短时间内完成所有文档的评价工作。所以这不是我们的解决方案。

　　在监控过程中，首先要相信项目组自身的能力，假定他们有能力完成这些工作，这样工作就简单了，也变得可以操作了。

　　首先，查阅这些文档，大致看看，有没有明显的问题。其次，应该检查这些文档的评审记录，看看相关的人员是否参加了该评审，都发现了什么问题，大家的意见和建议都有那些。最后，看看所有的发现的问题是否都得到了解决，文档是否按照解决的方法进行了修订。

　　在监控的过程中，默认参与评审的人员技术能力都符合要求，这样只需要关注评审的过程就可以控制质量了。但是，如果有证据证明，评审的人员或者组成不符合要求，作为监控者应该宣布该文档的评审无效，需重新进行评审，以解决问题。但是，使用这项权利的时候要小心，而且要充分论证，否则会扰乱项目组的正常次序。

　　l 测试的相关文档是否都按照项目目前的实际情况进行了更新，并严格遵照执行?

　　经常会听到一句话就是：计划赶不上变化，这个问题就是冲着这句话来的。我在讲课的过程中问过很多人这样一个问题：不做计划，直接做事情行不行?至今我还没有遇到一个说行的。但是，如果计划和行动不同步，这个和没有计划又有什么区别?

　　项目中有各种各样的理由告诉你，我没有同步计划是合理的，但是我们的要求一定是必须有计划，而且必须严格遵照执行，这才是降低系统风险的唯一合理方法。

原文转自：http://www.ltesting.net