软件项目管理课程课件.ppt

易用性测试包括 标准与规范测试。测试用户界面要素符合有关现行标准与规范。 直观性测试。直观性测试主要考虑：用户界面是否洁净、唐突、拥挤，并且所需功能或者期待的响应应该明显，并在预期出现的地方？界面的组织与布局是否合理？是否允许用户从一个功能转到另一个功能？任何时刻都可以决定放弃、返回或者退出吗？菜单或者窗口是否深藏不漏？有冗余功能吗？是否感到操作太复杂？帮助系统有效吗？ 一致性测试。软件与其他软件的一致性是软件产品的一个关键属性。 灵活性测试。软件产品应该为用户提供便捷的使用条件。 舒适性测试。软件应该用起来舒适，处处考虑人的需求。 正确性测试。灵活性与舒适性有时是主观的，但正确性测试是客观的，如果面的按键标示是否与实际功能一致？有没有遗漏的功能？ 实用性测试。指具体特性是否实用。 残疾人功能测试。为残疾人考虑是软件人性化的考虑，也是相关法规的要求。 6.3.3 测试的原则 1、完全测试程序是不可能的 2、软件测试需要由专门测试人员完成的 3、从一开始就执行测试 对于软件的需求一旦确定，就应订出测试计划。如果系统采用分阶段交付的方式，可执行软件在第一阶段中期就存在了，此时测试就应立即开始。即使不采用分阶段交付，也应在单元编码完成时马上开始，并且随着系统的集成，逐渐展开。 6.3.3 测试的原则 4、打破对测试的过分依赖 测试本身并不能改善软件的质量。测试是考察软件质量的手段，而不是保证软件质量的方法。软件测试只有与纠正缺陷活动结合才能成保证软件质量的手段。更有效的手段是与过程管理、用户管理原型、技术评审等结合才能更有效。 5、为软件测试提供适当的资源 系统计划时就应考虑软件的测试费用——时间与人员。 6、注意“杀虫剂”现象 为此需要编写不同的测试用例，对程序进行测试，以找出更多的软件缺陷。 6.3.4 测试计划 软件测试计划的目标是找出软件缺陷，并尽可能早一些，保证得到修复。利用组织良好的测试计划、测试案例和测试报答交流和制定测试工作是达到目标的保证。 ANSI/IEEE 829/1983标准这样表述软件测试计划；规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人以及与计划相关的风险。 6.3.4 测试计划 测试计划应该在项目需求分析阶段就开始，好的测试计划所需要的一些内容必须从需求阶段产生，并在整个开发过程中进行跟踪。测试组应参与项目需求审查工作，以确保需求能够为测试提供一个合理的基础。 6.3.4 测试计划 测试计划应该包括： 建立每项测试活动的进度和职责 确定工具、设施和测试库的可用性。 建立用于计划和进行测试以及报告测试结果的规程和标准。 制定衡量测试成功与完成的准则。 测试计划确定后要进行测试计划的评审，Beizer给出了一个测试计划评审检查单，如表6.2所示（P162） 6.3.5 测试用例的开发 1、测试覆盖技术 解决测试覆盖问题的方法之一是把程序看作由节点组成的图形，并确保测试充分涵盖这些节点以及节点之间的路径。对于白盒测试，可以把程序的结构简化为一幅节点图，一般来说，分支指令定义节点，其余指令组成路径。设计出能够尽可能多地覆盖图形的方法。 6.3.5 测试用例的开发 2、单元测试中的路径选择 要在测试中覆盖所有的路径常常是不现实的。为解决这一难题，需要把覆盖的路径数压缩到一定限度内，例如程序中的循环体只执行一次。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 6.3.5 测试用例的开发 3、功能测试中的路径覆盖 在进行功能测试（黑盒测试）时，选择测试的一种技术是根据功能路径进行。程序功能被看作是构成贯穿整个程序的功能路径的一系列事务流。所有功能路径都应在需求中进行定义，并明确说明相关程序的目的。如果不对这些路径进行明确定义，就不能正确设计程序。 6.3.6 测试的执行与报告 单元测试还是由程序员自己完成。对于单元测试也应进行相应的评审与监督。 单元测试结束后，其他的测试工作就应移交给测试组来执行。 应把测试当作试验对待，进行精心记录，以便过程能够重复。试验要求注意和查清所有异常行为。对发现的每一点异常都要紧追不舍。同时要避免总是停留在对细枝末节问题纠缠不休，要善于通过现象发现软件缺陷的倾向性苗头与本质。 测试还要求精心定义和记录测试环境、规程和测试用例。 6.3.6 测试的执行与报告 每项测试结束时，要编制测试报告。报告应包括如下信息。 被测试的项目和程序的名称、ID号、测试目的和相关的测试计划。 涉及的项目和测试人员。 具体测试用例及其ID号、程序和数据，