(测试管理复习.docVIP

应用软件的生命周期： 控制发布版本2）指定需求3）测试计划4）执行测试5)跟踪缺陷 质量保证组织面临的挑战： 1）由于缺乏信息、无效的沟通和缺乏一致的、可重复的流程而造成无效和冗余的测试。 2）配置一个坏的应用程序会导致风险增加 3）用户对无组织、无顺序的测试和慌忙的截止日期感到沮丧 4）花费大量的时间编写即将过期的报告 5）项目进展和状态的可见度不高导致错过最后的提交期限且提交的质量差 3.什么是QC?以及功能? (1)提供实时的可见性需求覆盖和相关的缺陷画清晰的业务分析 (2)让你的团队来管理发布过程和做出更明智的决定并释放实时的KPIS和报告 （3）帮助你管理衡量进展和有效性的质量活动 （4）允许你的QA团队，开发人员和业务分析师在一个全球平台的质量生命周期进行协助（5）让你的团队集中管理手动和自动化测试条件（6）QC功能:测试需求，测试用例，测试文档，缺陷 4.QC的过程 （1）设置测试需求（2）创建测试用例（3）执行测试用例和分析结果（4）报告和分析缺陷 5.QC的工作流 （1）进入缺陷（2）判断是否通过审查1)通过则复审缺陷或者添加缺陷—分配给项目经理-关闭2)没有通过则关闭（3）复审缺陷：1）分配给团队成员-确认是否已修复-关闭2）可接受的缺陷-在列表下修订—关闭 6.如何在项目中添加需求 （1）登录到QC创建的项目中进入Requirement模块， （2）单击工具菜单中的New Requirement 按钮，打开New Requirement对话框 在Name文本框中输入测试需求名称 7.怎样的测试需求为有效（测试需求的特征）？ （1）Unique:唯一性（2）Precise精确性（3）Bounded有界性（4）Testable可测试举例:25个用户在端到端实时系统中同时执行增删改查命令处理时响应时间在3秒之内 8.创建测试用例：手动创建测试用例（2）导入测试用例（3）保存测试用例到QC 将测试用例添加到测试树中：定义测试主题—测试用例—测试用例连接需求—测试用例步骤—自动化测试脚本—分析测试计划 测试用例连接需求： 1）在测试计划树中选择创建的测试用例 2)单击右侧窗口中的Reqs Coverage 选项卡 3）在需求覆盖页面中单击Select requerments 按钮 4)在需求树中搜索特定的测试需求 5）在需求树中选中想要连接的测试需求 6）单击 Add to Coverage 按钮 9.测试需求的覆盖：1）链接每一个在测试计划树中的测试需求，并且这些需求在测试需求树中，对于一个测试通过定义需求覆盖我们能够持续追踪在测试计划树和原始需求中的测试之间的关系。2）一个测试能够覆盖不止一个需求，一个需求能够被多个测试覆盖：测试用例和测试需求（多对多）：测试需求必须被测试，测试必须解决测试需求 10.一个有用的测试用例（特性）：1)目的性：purpose 2）操作步骤：navigation3）输入数据：sample date 4)验证：verification 11.执行测试用例的方法（步骤）：手动测试步骤：1)根据详细的测试步骤在程序上执行测试 2）比较预期结果和实际结果 3）依据实际结果是否匹配预期结果来分配测试用例的状态（通过/失败） 4）如果一个用例状态失败解释运行的实际结果如何 自动化测试和手动测试的区别：手工测试是传统的测试方法，由测试人员手工编写测试用例，缺点在于测试工作量大，重复多，回归测试难于实现。自动化测试：利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告，自动化测试节省大量的测试开销，并能够完成一些手工测试无法实现的测试。联系：1）自动化测试有其局限性不适合软件的新功能测试，特别适合回归测试可用保证对已测试过的部分进行测试的准确性和客观性 2）在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，也很难通过自动化测试来实现，多采用黑河测试的手工测试方法 3）单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试、等比较适合采用自动化测试 4）当界面需求变化比较频繁时，开发周期很短的软件，或做一次性软件开发项目时，自动化测试吃力不讨好，投入大而产出小13.缺陷的状态;图形及描述 1.什么是测试需求？ 测试需求主要解决“测什么”的问题 ，即指明被测对象中什么需要测试，通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求； 2.测试需求的特性（制定需求的条件） 1）制定的测试需求项必须是可核实的。 2）测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件； 3）测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容。 3.测试