软测培训1-测试理论.pptVIP

* 测试的目的是寻找错误,并且是尽最大可能找出最多的错误.在选取用例时,考虑那些易于发现程序错误的数据.测试的目的是为了发现尽可能多的缺陷。可是这个观念不容易被人接受。 正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是不真实的。 由于软件之中有缺陷，要靠测试把缺陷找出来。缺陷是软件“毛病”的统称，其范畴比“错误”更广。例如有些缺陷虽然不会导致软件发生错误，但可能使软件的性能严重下降。 Bug是缺陷的形象比喻，人们喜欢说Bug是因为可以把Bug当作“替罪羊”。软件的缺陷明明是人造成的，有了Bug这词后就可以把责任推给Bug——“都是Bug搞的鬼”。Bug真是太冤枉了。 为什么需要测试？因为软件中有Bug。 为什么软件中有Bug？ 以下是一些原因： （1）开发人员不太了解需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。 （2）软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。 （3）技术文档普遍比较糟糕，文档本身就有Bug，导致使用者产生更多的Bug。 （4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的Bug。 （5）任何人在编程时都可能犯错误，导致程序中有Bug。 （6）人们常处于进度的压力之下，急忙之下容易产生Bug，尤其是在期限临近之际。 （7）人们过于自信，喜欢说“没问题”，不真实的“没问题”将产生真正的问题。 * 测试的种类，常见的大体有20种 . * * “黑盒”、“白盒”都是比喻。“黑盒”表示看不见盒子里头的东西，意味着黑盒测试不关心软件内部设计和程序实现，只关心外部表现，即通过观察输入与输出即可知道测试的结论。任何人都可以依据软件需求来执行黑盒测试。 白盒测试关注的是被测对象的内部状况，需要跟踪源代码的运行。白盒测试者必须理解软件内部设计与程序实现，并且能够编写测试驱动程序，一般由开发人员兼任测试人员的角色。 * 有了黑盒测试为什么还要白盒测试？问题还可以反过来问：如果程序通过了白盒测试，为什么还需要黑盒测试？ 道理如下：通过了白盒测试只能说明程序符合设计要求，并不能说明最终的软件符合用户需求。如果系统设计偏离了用户需求，那么100％正确的程序也不是用户想要的。将错就错不等于正确，所以还需要黑盒测试。 可见黑盒测试与白盒测试都不能取代对方，只有两者结合才能弥补对方的不足。 单元测试 在系统设计阶段，整个系统最终被细分为许多模块，这里可以把模块理解为单元。每个单元的接口、数据结构与算法都已经设计完成。在实现阶段，程序员首先编写这些单元，然后把单元集成为子系统，再把子系统集成为最终的目标系统。在做集成之前，应当先执行单元测试，以保证单元本身正确无误。为了测试单元是否符合设计要求，必须跟踪到单元内部，检查所有的源代码。因此单元测试采用白盒测试方式。 由于单元通常不是可运行程序（如.exe文件），因此无法直接测试。测试者必须编写额外的可运行的测试驱动程序，通过测试驱动程序调用单元的接口，从而跟踪到单元的内部。单元测试的主要麻烦就在此处，并且由于测试驱动程序不是目标系统的组成部分，测试完了也就用不着了（至多被备份起来），让人有一种“不值得”的感觉。每当你有这种思绪时，请尽量想开点。人一生中会干不知多少“不值得”的事情，就别在乎单元测试中那一点浪费了！何况单元测试做好了，以后的工作就会轻松一些，好处还是蛮多的。 单元测试人员既要了解单元的详细设计，又要有本事为该单元编写测试驱动程序。这样的测试人员不好找，可以就地取材，让开发小组成员兼任测试人员的角色。通常做法是，开发人员编写完成某个单元后，先自我检查，然后请同伴进行代码审查，再请同伴进行单元测试，如果发现缺陷，原开发者应当及时修正程序。 这样边开发、边审查、边测试，可以高效率地发现并排除单元中的缺陷。如果单元通过了同伴的审查与测试，就可以升级成为基准（Baselined）文件，以后再对该单元修改时，必须遵循变更控制规则，避免修改过于频繁而失控。 一个系统的单元通常比较多，看起来单元测试的工作量比较大，挺烦人的。但由于每个单元比较小，而且相对独立，因此测试与改错的难度比较底。综合考虑，单元测试并不可怕。 集成测试 软件实现一般是渐增式的，从编写单元到完成整个系统，通常要经历数次集成（除非软件的规模很小）。于是每次单元集成都要进行相应的集成测试。 有人可能问：“如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？” 的确有可能！ 要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关