软件测试的变化之美

软件测试的变化之美

从汉字解字的角度，测字，从则，指原则和法则；从水，指变化法则，所以测需要遵循一定的规则方法，又需要一定的变化。试字，从言从式，就是指按照预定的想法，进行尝试。试音通似，判断其与真的相似度。测试的不确定性使得其中的变化无穷。我在测试执行过程也深深体会到通过长短，快慢，深浅，主次，先后的变化和平衡，测试变化之美油然而生。

⒈ 长短

（1）轮次长短的变化

测试执行过程中往往会有多个轮次。我推荐在一个版本中尽量安排一些长短不一的轮次交替。例如，每日构件，或2到3天长短的一小轮，或5到10天的一大轮。当我们刚拿到一个版本时，通常可能由于一些严重甚至block的缺陷而无法深入测试，此时一个周期较长的轮次就比较尴尬。而且，由于前期缺陷数目比较多，如果能及时将一些修复的缺陷放入当前被测试版本，也可以及时发现是否在已经修复的缺陷后还隐藏了其它问题，并敦促开发团队在前期及时修复缺陷。此时推荐采用短轮。而当版本新功能已经稳定后，通常我们希望对产品质量做一个全面的分析。这样目的的测试必须采用长一些的轮次，因为通常对一个系统的全面测试无法在短轮中做完，而且前面测试过的内容后面不会再回头去执行，所以如果这中间更换版本的话，除非修改的内容很有限，否则出现在上个版本中正常的功能在新版本反而不正常且没有被发现，将会是很大的风险。还有一点，我们通常在回归测试这样的轮次中安排测试覆盖率的分析，而如果源码发生改动，象EMMA这样的工具就不能支持将多个版本的覆盖率合并。

测试轮次长短变化的另一个好处是对测试人员而言的。根据我个人的体会，测试人员虽然是会不同程度地运用探索式测试来为测试执行注入一些变化，但从测试管理的角度，测试轮次长短的变化也是给测试人员一个全新感觉的有用方式。除了长时间的每日构件有点让人麻木以外，一般隔了几天后换上一个新版本，你还是能看到一个缺陷的新的小高峰的，这里有测试人员的心理因素在做怪。

（2） 路径长短的变化

无论是脚本测试还是探索式测试，测试人员都应该在测试路径的长短上转换自己的思路，在定位问题和获得信心方面寻求平衡。

一般而言，脚本测试中，功能测试，集成测试，系统测试对应的测试范围逐步增加，测试路径也逐步变长。

探索式测试中，即使你是一个最勤恳的测试人员，有时你也需要把自己想像成一个懒人，从最快捷的入口（包括最快捷的功能入口，热键，输入方式是键盘而非鼠标等），用最少的输入（能不输入就不输入，从不修改缺省值等），用最少的步骤（包括对于一个对象的最精简流程，也包括对于多个对象的批量操作）来执行一次业务操作。

⒉ 快慢（测试节奏快慢的变化）

虽然一般而言，测试都是在较大的时间压力下进行，因此大家都追求＂快＂。但我认为快和高效是不同的。高效也包括刻意地慢。对于一些数据字典中比较静态的测试，如字段类型，长度，取值来源和范围等等，或者对于界面标准，如行间距是几个像素，或者拼写是否正确，个人还没有找到能快起来的方法。即使对于功能测试，慢一点，才能看到虽然多次路过但不曾留意到的风景。

⒊ 深浅（测试内容深浅的变化）

我经常和我的同事说＂你需要知道当给你一天的时间测试时，你测什么，怎么测；同一个版本，给你十天的时间时，你又测什么，怎么测。＂测试内容深浅的变化取决于你的测试目的和约束条件，而两者的结合则包含在你的测试策略中。有时，我们结合BVT或者冒烟测试这种浅尝辄止的测试和全面回归这种深入、完整的测试。有时，我们先跑优先级高的测试了解功能是否能大致正常工作，然后再细致查看每个细小逻辑是否正确。

⒋ 主次（主次功能的区分和变化）

面向风险的测试要求测试人员必须清楚软件的核心功能是哪些，常用路径是哪些，可能输入是哪些，从而在测试资源的分配上做到主次分明。例如，对于重要性不同的模块安排同样的测试时间也许不合适。另一方面，虽然大部分时候我们习惯于一上来即测试主要功能，但偶尔也不妨对次要或辅助功能一些特殊关注，帮助我们找到这些地方的较深层次的问题。

⒌ 先后 (何种情况下先做某事？）

每个轮次中先验证修复的缺陷再测试还是相反呢？一般，我倾向于测试前期测试优先，而后期验证缺陷修复优先。为什么？因为前期我们希望尽可能快地暴露缺陷，后期希望做更多的信心建设。

如果有一个难以重现的缺陷，应该先花更多时间尝试重现它还是进行别的测试呢？我觉得这取决于这个缺陷的后果严重程度（当然，如果我们能对碰到它的概率有一些概念，这也是重要的考虑因素）。如果后果严重，那么应优先尝试重现它，因为这类问题必须处理，而当下如果不趁热打铁，后面由于环境，版本，测试人员记忆力衰退等各个因素的影响，能重现的概率更低。

测试之美，在于它的变化，在于变化背后的规律，在于你对规律的理解和运用。写此文不仅仅是为了分享我感到了什么，而是希望读完此文，＂你＂感到了什么！^_^