聊聊软件测试04



一、软件测试的定义

软件测试的定义有很多种，个人推荐定义为：“使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”，由于现在软件发展的十分迅速，软件的复杂度也越来越高，所以软件测试现在也变的原来越重要，软件测试贯穿于整个软件生命周期，软件测试并不局限于程序测试，它还包括对相关的需求、文档的测试，也包括一些多样化的回归测试、压力测试、性能测试等。

二、软件测试的思维

（1）“创造者”与“破坏者”

在思维和心里上，软件开发和测试最大的区别在于前者是“创造者”而后者是“破坏者”。

对于“创造者”而言，在心理上是不会对自己“创造”出来的产品进行破坏，就像每个人都会很爱惜自己的手工作品。而对于“破坏者”，心理上应该是属于乐于看到自己测试的系统“崩塌”的场面，就像拿着别人的手工作品摔砸扔来证明那个手工不行一样。

又如在实际应用中，开发人员会说：“这个功能我测过好几遍了，没有问题了”，但测试软件却还是能在这个功能里挑出很多的问题，原因在于，开发人员测试时，心理上的关注点放在了“证明这个功能点可行”上，往往会无意识的绕过一些可能会引起问题的操作；而测试人员的关注点放在了“使这个功能点不行”上，会尝试各种可能造成问题的操作。所以“破坏者”需要利用你所有可知的测试策略与方法，对软件进行不同程度的“破坏”，检查各种状况下，软件的处理方式与系统的能力。

（2）“第三方视角”&“好奇心”

以第三方的眼光看软件产品是测试人员与开发人员在进行测试时最大的区别。除了“第三方的视角”，测试人员在心理上还要时常保持“好奇心”，随着测试的深入，测试人员应不满足于现有的测试成果，“好奇心”会让我想知道每次点击操作背后系统正在做些什么，驱使我去找程序员问个究竟或者看他们的代码是怎么写的，看看能否进一步优化系统；“好奇心”会让我想弄清楚究竟多少用户同时操作，系统就会崩溃，能否应付系统上线后的正常使用；“好奇心”会驱使我在想用户如果来使用软件的时候会如何操作，会遇到什么样的问题，会不会觉得繁琐。有了“好奇心”，才能让系统在上线前就做了更加完备的测试。

（3）“兴趣”

“兴趣”也是关键，做过软件测试工作的人知道，软件测试有时候是一个很繁琐枯燥的工作。比如测试一个表单填写提交的功能，需要使用不同数据进行填写并提交，所以非常有可能出现的情况是，这一星期，每天8小时的工作就是坐在电脑前，不停的做着“填写表单并提交”这样的简单机械时劳动，这时，“兴趣”是能让我摆脱枯燥的方法。兴趣是最好的老师，如果对测试工作真正感兴趣的，就会不断地研究测试相关的理论知识、技能技巧、工具等。就如上面说的“提交表单”测试，你可以把它当成一种挑战，目标是搞垮它，这时，就可以尝试各种各样测试方法：尝试不同的填写数字、在填数字的地方写英文、在写英文的地方写中文、将必填处留空提交、在填写框中复制上一篇10W字的文章、上传附件处上传各式各样的格式文件、上传50MB以上的图片文件、使用QTP反复快速操作、使用QTP Object对象方法篡改页面控件属性提交、使用Loadrunner模拟大量用户同时提交、提交的时候拔掉网线、用Sniffer或HttpWatch抓包进行观察等等，有太多的方法可以尝试，再使出浑身解数后，发现不知不觉中，已对表单的各种场景进行了模拟测试，提交了大量表单，时间也觉得一个星期都不够了呢。用一个比喻来说的话，如James A. Whittaker的《How to Break Software》说的，“像小时候我们拿上一个小玩具，可能就是一个陀螺，甚至是一个拖把，我们也会玩上半天也不会感到厌烦。我们会变着花样来玩它，我们扮演各种角色，把它当成道具，玩得不亦乐乎。现在的测试工作是什么，测试的对象有时候就是个玩具，只不过有些看起来过于严肃而已。如果我们能把软件当成玩具来玩，那么我们可能不会那么快就认为测试已经可以停止了。因为还有那么多有趣的玩法还没尝试。如果实在是玩腻了，还大可以把玩具狠狠地甩在地上，用脚踩几下，看它有什么反应。这也是一种测试方法！

三、测试方法

测试方法有很多种，这里讲一些最基础的测试方法及操作。

如：登录框测试

（1）冒烟测试

我们测试的时候，最先需要使用正确的账号登录一遍，这叫“冒烟测试”，“冒烟测试”的作用是判断一个功能模块的最基本功能是否实现，如果“冒烟测试”能通过，则继续进行深入的测试，如果不过，则不继续进行测试。

冒烟测试是测试的第一步，当发现软件连最基本的功能都无法实现的时候，应立即终止测试，交于开发处理问题，而不是继续测试，放慢了整体研发速度。

（2）边界值&等价类

当“冒烟测试”过了，则可以进一步进行测试了。这里需要用到“边界值”和“等价类”的测试思想。何为“边界值”？边界值的概念是输入稍高于其边界值及稍低于其边界值的一种测试方法。往往会在边界值的地方发生错误或与需求文档要求的不符合。如例子中，假设限定用户名长度只能为6-12位，则我们需要分别对长度为5位、6位、7位、11位、12位、13位这6种长度进行测试，这就是“边界值”法。何为“等价类”？等价类是一种数学上的概念，在这里是将一个测试点划分为多种类的集合，如：还是长度只能为6-12位的问题，使用等价类的方法可以划分为三类：1是小于6位的情况，2是6-12位的情况，3是大于12位的情况。测试的时候，需要在这三类情况中各举出一套测试数据进行测试。这就是“等价类”。

（3）错误猜想

通过猜想，这也是一种测试方法，这也是用的最多的一种测试方法。当然，要依据的猜。往往经验丰富的测试人员能“猜”到更多有可能产生问题的情况，写出更加有效的测试用例。刚刚的登录例子，可以“猜”在能正常登陆的账号前或后加个空格，看看是否能正常登录；可以“猜”输入空的用户名和密码进行登录的情况；可以“猜”在登录框中粘贴进大于保存用户名变量类型的字符个数；可以“猜”在注册一些带有奇怪字符或是超出数据库范围的文字后能否正常登录；可以“猜”登录瞬间关掉页面检查Sever上Session是否释放等等，能猜的内容很多很多，随着经验的增长和对系统越发的熟悉，会“猜”到更多测试方案。

（4）场景法

这也是在平时用的比较多的方法，定义不同的场景，进行有规律的测试。主要用于检查流程等，可使用在有较多分支流程中进行测试。

（5）失败测试

纯粹为了破坏而设计和执行的测试用例称为失败测试。可考察系统超出需求范围时的行为。

四、测试用例

测试用例在测试过程中属于重中之重，能够规范化测试，记录所有可能出现的问题，随着对测试用例的扩充，能越来越达到完备的测试。

（1）预期结果

测试用例中必须要写的，最重要的一项是预期结果，在编写测试用例的过程中，发现这点很难有做的很好的。往往刚接触测试的人员会在预期结果一栏中写入诸如“登录正确”、“提交失败”等这样简单的预期结果。殊不知这样的写法和没写是差不多的，因为当另一个测试人员进行测试的时候，完全不知道“登录正确”时的表现形式，应写明页面上显示了些什么，那个角落会有什么样的显示，数据是否真正写到了数据库中而“提交失败”需写明失败提示到底是什么，是否有弹出框，是有错误图标等等的详细内容。

（2）测试数据

测试数据需要完整，如在某输入框中输入数据，需要写明需要输入的内容是什么，是“abcd”还是“123”，输入的账号也需要写明是什么账号，而不是写“输入正确的账号”，在别人测试过程中，是不知道什么才是正确的账号。如果这个账号不会变动（如管理员账号），则在测试数据中需写明“输入账号：admin，密码：123456”，如账号是常变动的（如用户账号），需在测试用例的前置条件中申明账号的可用性，如前置条件中写“系统存在账号为user123，密码为123456的用户”，这时在测试数据中就可以写“试用账号user123，密码为123456789进行登录”。

总之，写测试用例的时候，注意仔细与严谨。时常检查自己写的测试用例别人是否也能看懂。

五、BUG清单

提交BUG也是一门功课，既要简单易读，又要能说明问题。所以需要在BUG清单中写清楚复现的步骤，错误出现的频率，严重性和优先级，一个BUG清单讲述一个问题，不可将多个问题写于同一篇BUG清单中，BUG清单中需注意语气，不得带有情绪，如果BUG存在争议，需要提供证据进行证明，如需求说明说，可以咨询需求人员，如果什么都没有可以参考行业软件规范。

提三个BUG清单中可能存在的问题：

（1）客户方想只使用一个数值，来定义严重性和优先级。严重性和优先级是完全两个概念。

（2）一张清单上的3种不同类型的问题可以写在一个BUG清单上。

（3）将BUG的数量和测试人员的效益与开发员工的效益挂钩。会导致大量BUG冗余，严重影响项目进度。

六、自动化

自动化测试从字面上来理解，就是让电脑自动完成所需要的测试内容。如填写表单的测试，我可以预先将所要填写的内容写好，然后下班后，让电脑自动逐条进行填写，提交，记录测试的结果。看似很酷，但需要考虑的问题很多，最主要的是，需要有一定的编程基础，毕竟，脚本是要靠“写”的。主要表现有以下几点：

       只要开发出强大的自动化测试脚本，就能将测试人员解放出来。其实不是的，很多的测试都是靠手工进行测试，自动化只是辅助。比如页面的排版是否好看，第一次测试时遇到的各种各样的问题，因为开发做了较大的改变等等一些问题时，自动化的执行就会失败。
       对于需求会经常修改的系统如何进行自动化脚本的编写。对于这样需求会经常变动的系统，就不能开展自动化测试，还是老老实实的进行手工测试吧。
       在软件测试理论知识还不是很牢固的情况下，不要进行自动化。对软件测试和自动化测试的错误理解会导致后期自动化进行十分的困难且根本没办法维护脚本。
       在软件版本还没有稳定的情况下，不要进行自动化
       领导不支持的情况下，不要进行自动化
       系统中测试对象基本可以正常识别的情况下才进行自动化脚本的编写。
       自动化测试一般的情况下是用来证明软件能正常运行，而不是用在证明软件这么操作一定会出错上。

自动化测试最主要目的的是提高工作效率，正确的使用是，用1天开发一个脚本能用3个月的测试，而不是花3个月开发出一个很牛的脚本来测试1天。

七、测试分析

学会分析数据也是软件测试中必要的一项。优秀的软件测试人员能通过各种数字，得到当前系统的各种信息。在性能测试中，分析数据显得尤为重要，一个做金融保险类系统性能测试的前辈和我说过，做性能测试，用使用Loadrunner，编写脚本设计场景，学的话几个月就能搞定，但是分析执行脚本后的数据，可能需要2-3年的工作经验，才能看到你想看到的信息。

说些简单常用的，通过分析BUG数据，就发现很多有用的信息。如：当系统刚刚开发完成，交给测试人员进行测试的时候，BUG数量一定是呈上升趋势，如果上升趋势不明显，一定是还没有做更完善的测试，说明需要投入更多的测试，随着测试的进行，BUG数量会成下降趋势，经过开发的几次调整，测试的几轮复测，BUG数量走势会在经过几次小波动后，趋于稳定，通过这些数字，就可以清楚的了解测试的进度，测试何时需要加强，何时可以退出，何时可以自动化的介入，何时可以开始进行性能测试压力测试等。

同样的BUG单的数据，通过BUG单上模块进行分类进行分析，会发现80%BUG会出现在20%的模块中，这也是经典的“二八原则”，对于拥有80%错误的20%模块，测试人员需要进行更多的测试，很有可能有更多的错误藏在这20%的模块中。这样可以划分出测试的轻重，从而能更加好的计划出测试投入的时间。

八、文档编写

测试人员平时会遇到很多需要书写文档的地方，如：测试计划文档、测试总结报告、测试用例、自动化测试用例、自动化测试报告、性能测试报告等，也需要开不少的会议，进行较多的报告演讲。这些也是一个测试人员不可缺少的素质。

我总结的经验就是：写报告要有理有据，图文并茂，提出一个点，需要给出足够的证据与分析过程来进行描述，而不是只写一个结论，要保证除测试人员外，开发、需求、架构人员也能从报告中，获取到相应的信息。

九、总结

作为一名系统测试人员，还需要做到细心、耐心，多注意细节。平时也需要多做学习：系统的、网络的、软件的、硬件的、数据库的、语言的等等。总结也是必不可少的，把学到的、用到的知识，都记录下来，会对以后的工作带来非常多非常多的便利。