软件测试基本理论.ppt

目录 1. 测试的常识与道理 2. 测试的分类与比较 3. 测试人员的组织 4. 测试策略 5. 测试规范 6. 软件产品的主要测试内容 7. 黑盒测试的主要方法 1. 测试的常识与道理 1.1 测试的目的是什么 测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。 推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。 目前还有一种理论,认为测试的目的应该是保证发布到用户手中的软件是可用的,适用的.强调用户的观点可以有效地防止测试人员吹毛求疵地搞测试,发现了一堆问题,而用户真正关心的问题却漏了. 1. 测试的常识与道理 1.2 一些常识和经验之谈 测试能提高软件的质量，但是提高质量不能依赖测试。 设计的缺陷导致测试时BUG无法收敛,到用户手中仍然问题多多.因此,设计的好坏是质量的关键,测试在评审设计文档时,要站在测试的角度去评审其可测试性,是否会在测试时出现各种问题. 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。 测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。 所谓有效测试应该是:用户关心的问题都能测试出来. 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。 2. 测试的分类与比较 2.1 测试方式 白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档 黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档 2.2 测试阶段 单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，主要测试各个模块之间的接口. 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。 2. 测试的分类与比较 2.3 开发与测试的 V 型关系 如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。 2. 测试的分类与比较 2.4 测试内容 接口与路径测试。 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试… 3. 测试人员的组织 3.1 了解开发人员的测试心理 测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。 开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误. 开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。 结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。 3. 测试人员的组织 3.2 避免开发人员与测试人员产生矛盾 开发人员的注意事项： 不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。 不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。 测试人员的注意事项： 发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。 在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。 请留意另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。 4. 测试策略 4.1 理念： 企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。 用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。 4.2 如何合理地减少测试工作量 减少冗余的测试 白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的