由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的这需要判断技能、常识、感觉和经验如果有正当理由，也可采用正式的方法对于该项目的用途而言，哪种功能最重要?哪种功能对用户最明显?哪种功能对安全影响最大?哪种功能对用户最有用?对客户来说，该应用软件的哪个部分最重要?在开发过程中，该应用软件的哪个部分可以最先测试?哪一部分代码最复杂，容易导致出现错误?哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?哪一部分程序与过去项目中引起问题的部分相类似/有关?哪一部分程序与过去项目中需要大量维护的部分相类似/有关?需求和设计的那些部分不清楚或不容易读?开发人员认为在应用软件中哪些部分是高风险的?哪些问题能造成最差的发行?哪些问题最能引起用户抱怨?哪些测试可以容易地覆盖多种功能?哪些测试在覆盖高风险部分的测试时使用时间最少?3.软件测试是有风险的行为 如果决定不去测试所有的情况，那么我们就面临了很大的风险，比如在计算器例子中假设１０２４＋１０２４会出现致命的错误，那么你会怎么办？所以说这也变相说明了为什么有些错误我们怎样测试都发现不了，一但到了客户那里马上为客户所发现 软件测试人员需要学会的一个主要本领就是如何把无边无际的可能性控制到一个可以接受的范围内，这就需要根据风险制定出相应的计划了 我们可以通过对资源的调节，对测试程度和范围进行有效控制一边是完全测试，另一边是从不测试，这都是测试的两个极端表现至于往哪边移动就看你的现有资源投入了，原则是尽量使用有限资源得到最大的回报我们可以通过对测试用例复用、测试数据选取来确定对测试的充分性，但是不管怎样测试总有错误会遗留给用户，经过长时间反复的使用才让它真正暴露出来这就是测试只能保证尽可能多地发现错误，不能保证发现所有的错误4.并非所有的错误都能修复 在软件测试中最令人沮丧的是，即使你全力以赴也不能保证所有你发现的软件错误都能被正确的关闭，这并不意味着软件测试人员未达到目的，要知道现在我们所使用的任何软件系统中都存在着大大小小的软件缺陷没有足够的时间在任何一个项目中，通常是所包含的软件功能复杂，而代码的编写人员和测试人员较少并且，在项目进度中没有为修改和再次测试留出足够的项目时间不算真正的软件错误总会有人说：这不算真正的软件缺陷，而是一项真正的软件功能在某些场合和环境下，错误的理解、测试本身的错误和不完整的软件说明书会把软件缺陷当作附加功能来对待修复的风险太大非常遗憾的是这样的情况经常出现，软件本身是脆弱的、难以理清的也可以这样说软件就是一团乱麻，所以修复它需要冒很大的风险，也许修复了一个软件错误导致出现了其它更多的软件错误如果项目进度紧张，修改软件错误要冒更大的风险，所以跳过这些以避免出现更多的麻烦也是一种安全之道不值得修复不常出现的软件错误和在一些不太常用的功能中包含的软件错误可以放过，虽然这看上去有点“违反原则”不值得修复并不意味着不修复，只不过这些错误将在螺旋模型的下一次过程中被一一修复5.反向思维逻辑. 测试最重要的一件事就是要考虑到所有的出错可能性同时，还要做一些不是按常规做的、非常奇怪的事说起来可能不太好听，测试的过程就像黑客(Hacker)的攻击过程那样可以这么说，像黑客这样的人是最好的软件安全测试员他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞来保证软件的性能如果找不到这种漏洞，那就说明该软件质量己经很好了 除了漏洞之外，测试还应该考虑性能(Performance)问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况我们可以在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)我们在做IE 的时候，就是让它72小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的缘故 另外，测试还要考虑软件的兼容性(Compatibility)一般来说，一个软件是由许多小软件构成的，如果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误这种错误需要通过测试来发现和解决许多人认为写代码的人一定能找出错误来其实开发人员在写代码的时候，如果有错误，他可以意识到了，可是写出来的错误，他不一定能想得到我自己也编过程序，在编程序的时候很自信，觉得不会有错，可事实上，即使是我编的小程序也有错误，但要自己找出来，却要费很大劲6.由小到大的测试范围 小规模代表着测试的粒度，或者表现为某种程度的单元测试多块的单元测试构成了测试的基底（如果是面向对象的测试则单元测试被替换为“类测试”，集成测试被替换为“交互测试”），测试进度曲线依据这个基底向更高一级的测试过程过渡7.避免检查自己的代码程序员从来都不会承认自己写的程序有错误程序员测试自己的编码是一件很糟糕的事但是让他们测试别人的编码却成了最好的测试人员程序员的测试思路有明显的局限性多数程序员没有经过严格正规的职业训练程序员无良好的BUG跟踪和回归测试习惯8.追溯至用户需求“产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的，如果需求得到了准确的验证，则可以消除80%的返工问题，节省总项目投入费用的45%”总项目费用的45%这是多么客观的一个数字，还有什么理由来阻止我们不在需求阶段就介入严格的测试工作呢？需求评审报告设计评审报告
（图片来源网络，侵删）
0 评论