1 / 16

小组软件过程 —— 集成和系统测试

小组软件过程 —— 集成和系统测试. 欧阳柳波 湖南大学软件学院. 测试原则. 测试的目的是为了评估产品，而不是修正产品，尽管你的确应该修正测试中发现的缺陷。 一个产品的质量是在它被开发时决定的，当你测试一个质量差的产品时，测试之后你得到的仍是质量差的产品。. 测试原则. 靠基于测试的质量策略让小系统相当可靠地工作要用大量的时间。

lala
Download Presentation

小组软件过程 —— 集成和系统测试

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 小组软件过程——集成和系统测试 欧阳柳波 湖南大学软件学院

  2. 测试原则 • 测试的目的是为了评估产品，而不是修正产品，尽管你的确应该修正测试中发现的缺陷。 • 一个产品的质量是在它被开发时决定的，当你测试一个质量差的产品时，测试之后你得到的仍是质量差的产品。

  3. 测试原则 • 靠基于测试的质量策略让小系统相当可靠地工作要用大量的时间。 • 如Magellan空间飞行器的控制软件仅有22KLOC，然而在系统测试中发现了186个缺陷，其中42个很严重，且只有1个严重缺陷在第一年发现，虽经过2.5年的测试，产品仍有严重缺陷，尽管能完成任务，但还是出现了一些与软件相关的紧急事件。 • Galileo飞行器的软件测试用了6年，最后10个严重缺陷是在经过了288周的测试之后才被发现。

  4. TSPi测试策略 • 使用经过单元测试的部件来创建系统。 • 通过集成测试，来判定单元部件是否都存在，以及它们是否能共同工作。 • 通过系统测试来确认产品是否满足系统需求。 • 确认质量差的模块，并将它们交给质量经理处理 • 确认那些除去缺陷仍令人头痛的质量差的部件，并交给质量经理进行返工或替换。

  5. 建立和集成策略 • 集成测试检查所有的部件是否存在，以及它们的调用和交互是否起作用。 • Big-Gang策略： 将所有的部件放在一起来观察它们是否能工作，它需要最少的测试开发，但很少成功，尤其对质量差的系统。 • 每次一个策略： 逐次添加一些部件，这样得到问题相对较少的简单系统，因而更有效，但要求更多的测试开发工作。

  6. 建立和集成策略 • 聚类策略： 以类的方式添加部件，选定某种特定类型的相关部件然后测试它们，如关于文件的处理、打印模块等。 • 平面系统策略： 首先集成所有最高层次部分，然后并行的一层层向下钻研，可以一次测试所有部分，或者一次加入一个部件，其好处是能在早期发现系统级问题，建立系统梗概。

  7. 系统测试策略 • 系统是否展示了其要求具备的功能 • 系统是否达到了它的质量目标 • 在正常情况下系统是否能适当地工作 • 在非正常情况下系统是否能够适当地工作 • 可选择的系统测试策略： （1）以不同的方式来强调测试目标，如连续测试每一个目标。可以先测试每一个预期的功能，重点检查操作，评价可用性等

  8. 系统测试策略 （2）关注选出来的功能区，在进行下个功能区之前，确认这个功能区的每个方面。它没有强调整体系统行为。 （3）结合上两种策略，对正常、非正常和重点条件下的低层次功能进行测试，然后进入高一点的层次，再测试其结合后的协同工作功能，再重复上述过程，直至覆盖整个系统。此策略对于质量差的系统较适用，因为许多系统功能最初是完全不起作用的，但对于大系统，其不利之处是要花费长时间循序渐进地测试所有的重要功能。

  9. 系统测试策略 （4）首先对最高层次进行功能测试，然后逐步向下，一次次进行正常和重点测试，依据系统的大小和系统的主要目标，进行不同功能的综合测试。此方法能最快地包含系统问题，对于高质量的系统有效。

  10. 测试计划 • 完整的测试计划描述了你计划运行什么测试，以什么顺序运行它们，以及每个测试所需的材料。 • 一个完整的计划应该能够展示各个需求怎样被测试以及测试脚本是怎样覆盖测试需求区域的，应该知道那些区域已被详细测试过，那些还没有被详细测试过。 • 应对每个预期的测试命名，定义其应该产生的效果，以及运行的时间，估计缺陷数，修复时间及总共的测试时间。

  11. 测试计划 • 结束测试计划时，应递交的材料： （1）所有要执行的测试步聚清单 （2）每个测试所需要的支持材料 （3）测试产生的结果 （4）估计每个测试的无缺陷运行时间，发现的缺陷数，以及总时间 （5）在测试计划中要求开发的每个条款所需的工作估计

  12. 跟踪和度量测试 • 测试日志 （1）测试运行的日期 （2）进行这个测试的人的姓名 （3）测试的运行名称或编号 （4）被测试的产品和配置 （5）每个测试开始运行的时间 （6）每个测试结束运行的时间 （7）发现缺陷的数量，使用LOGD引用和编号 （8）测试结果 （9）被测试系统的配置 （10）任何使用了的特殊工具和设施 （11）操作员的干涉是否需要，需要多少

  13. 跟踪和度量测试 • 有缺陷倾向的模块 IBM的经验数据表明，在测试时你发现的缺陷越多，那么你没发现的缺陷也越多。从而可通过测试数据评估有缺陷倾向部分的系统风险。对这类模块，应立即停止测试，并进行检查。 • 模块缺陷数据 通过SUMDR和SUMQ表格来记录模块缺陷数据

  14. 跟踪和度量测试 • 追踪缺陷数据 为追踪和分析有缺陷倾向的模块，你需要每个测试的有关每个缺陷的数据，并使用这些数据来改进测试过程。 （1）缺陷逃过了哪个过程的步骤 （2）你能怎样改变这些步骤以免缺陷不再发生 （3）你能怎样改进开发过程来预防将来发生这些缺陷 （4）在系统的那里可能存在未发现的类似缺陷 （5）现在你怎样发现这些缺陷并修改它们

  15. 测试文档 • 文档是每个软件产品的必需部分，在许多方面，文档比代码更重要。没有文档的程序是无用的。 • 测试开发和写文档的比例根据开发过程变动。 • 文档设计很重要，一个精心设计的用户手册应关注读者的需求，而不是围绕产品的结构来设计。 • 文档化的每一步是制作详细的提纲，从一个高层提纲入手，然后逐步细化。 • 书写风格应使用短句和易懂的词，具有易读性。 • 文档复核：结构、内容、术语、准确性等。

  16. TSPi测试脚本 • 开始条件：SRS、SDS、通过单元测试的部件 • 测试开发：开发集成和系统测试程序和环境 • 建立：建立产品并检查其完整性 • 集成：测试产品、集成产品形成系统 • 系统测试：在正常和重点条件下测试产品、测试产品的升级、安装和恢复 • 回归测试：运行上一个开发周期的系统，以确保产品仍保持以前的功能 • 文档化：编写用户文档 • 结束标准：产品版本、测试记录、缺陷分析、用户文档、SUMP、SUMQ

More Related