4．多任务测试

　　多任务测试也是软件测试过程中必须考虑到的一个方面，比如说我们在报告打印的过程中，突然来电。这时根据规格要求，传真机不但要能正常接听来电，打印动作也不被来电影响，类似于这类的测试很多，而这类问题的测试也是一些bug多发情况。

　　在多任务测试时，很容易出现一些死机、某些功能无法正常实现等情形。我们在进行多任务测试时不但要把握这些功能能否正常实现还要看有没有其他一些问题出现。比如，在打印报告的时候来电，在CALL ID打开的状态看来电显示是否正确，在通话结束的时候挂机，看LCD的显示是否又恢复到打印状态时的显示等。

　　在进行多任务测试时，我们还要结合一些中断测试等来进行测试，以防止出现一些异常情况。

　　5．临界测试

　　我们知道，日本是一个地震多发的国家，每年都会有一些或大或小的地震去骚扰一下，为此，日本人曾吃了不少苦。为什么日本会有那么多的地震？原因很简单，从地理上而言它处于亚欧版块和太平洋版块的临界位置，不稳定！所以也就容易出现一些不必要的问题。

　　以上只是形象的说明一下临界位置是一个比较敏感地带，表现的不稳定性，容易出问题。我们软件也是如此。因此，对软件进行临界测试时是一个非常重要的方面！

　　我们在对M4进行临界测试时，表现最为重要的还是内存方面，往往内存在达到其存储容量的临界点时会有很多问题发生，如数据丢失等。

　　临界测试还有如对电话存储极限时的测试：当来电历史里的记录条数处于最大状态或者电话薄中登录的号码数目最大时，我们对其进行一些合法的、非法的、正常的以及非正常的操作来检验软件是否出现一些以外情况等。

　　事实上，进行临界测试时还要更多结合一些中断测试，比如之前在传真刚发送完成显示“TRANSMITTING OK”时，我们按<stop>来进行 “蓄意”破坏，结果会出现重起情况，这就不应该了。

　　三、其他问题

　　1．概率性问题

　　应该说概率性问题是对任何一个测试者都感到头疼的问题，尤其是那些概率性偏低的问题，很难重现。为此，我们在佳能软件测试时就饱受这方面的折磨。

　　一个最为难忘的例子就是对A3进行“CLEAR ALL”操作时出现“MEMORY ERR”问题，这个问题的概率很低，出现的情况很随机，毫无规律性而言，为测这个问题几个人前后做了不下3000次的操作。好在问题最后得以解决——原来是硬件FLASH出现的问题。

　　概率性问题是一个让人头疼的问题，但恰恰是这种问题的存在影响了我们产品的性能，试想，软件正在工作的过程中突然出现了死机或者重起的现象将会让用户有着怎样的感受！对于一个小的产平还好，如果大到航空航天、金融系统，如果在运行中出现了这样的问题，将会是怎样一个后果呢？灾难！

　　在此，主要是想说明我们在测试时，必须把一些概率性的问题重视起来，对于一些比较严重的概率性的问题，我们的原则应该是已经出现，就要查出，最终解决！在这方面，佳能做的就十分不错，非常值得我们学习！

　　2．测试流程

　　对于测试流程，大家基本上都是大同小异，在此就不再介绍了。我们所要注意的一点就是在测试流程的执行上一定要严格，尤其是最后发行软件版本前的确认测试，一定要将每一个可能出现问题的地方都要测试到位。

　　3．测试文档

　　如何编写一个好的测试文档（precheck list）对于测试而言是很重要的一个环节，测试文档是一个测试者测试思路、方法的重要反映。一个好的测试文档所罗列的测试用例首先要全面，要能涉及到软件的各个功能部分，不能有所遗漏。如果测试出现空白，将是一件十分可怕的事情。

　　有资料反映，微软在写windows操作系统的测试文档时就写下了10万个测试用例。在测试文档的编写方面，一定要做到全面、详尽，而且最好是经验丰富的测试人员来编写。

　　4．测试管理

　　测试管理应该说是一门很值得研究的学问，它涉及到测试执行、bug的发现提出、分析评估、分配解决、确认解决情况等很多方面，时间关系，在此不能，也很难一下子把它说的那么到位。下面仅提一下bug管理工具。

　　应该说现在的bug管理工具不是太多，而一个好的bug管理工具对软件设计而言又非常重要，一个好的软件管理工具能够帮帮助人们有效的管理软件中出现的问题，提高工作效率。在测试管理管理上，canon使用的是lotus管理工具，这个管理工具相对而言比较好一些，值得我们在今后的工作中借鉴使用。

　　四、小结

　　一个好的测试者决不限于对一些基本功能的测试验证上，不仅是为了证明某些功能可以实现，更主要的是为了证明某些功能不能实现而进行的一些“破坏性”测试，这样的测试也是为了保证相应功能能够正常稳定的实现。基于这个指导思想我们在佳能传真机的测试时进行了大量的中断测试、掉电测试、临界测试以及其他一些异常操作测试。当然，不管如何测试，软件中的bug都无法全部发现解决，我们所做的就是按照软件测试中的good-enough原则，尽可能多的测试出用户在使用中可能碰到的bug，确保软件质量。

　　从宏观而言，软件测试现在还处于婴幼儿阶段，还很不成熟，在国际上也没有一个统一的测试标准，我们要做的就是不断地学习、积累、探索。