软件测试教程(华为培训专用)第6章讲解.ppt

记录回放类 这一类不需要太多的计划、编程和调试。优点在于简单方便。缺点在于稳定性差、兼容性差，所以脚本运行寿命很短。同时由于缺少结果的验证部分，所以很难找出Bug。可以考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归测试。 测试用例自动化类 这一类是指将需要反复测试或在多种配置下重复测试的用例自动化。基本实现过程为： 制定测试计划 设计测试用例 针对每一个测试用例评估自动化的可行性和经济性 将决定要自动化的测试用例做详细步骤分解 编写公用资源库（日志记录、异常处理等） 编写自动化程序 调试 运行 这类自动化测试最为灵活，能够发现较多的Bug，并且可以较好的与测试计划相协调。当前大中型软件企业主要使用这种类型的自动化测试。 6.13.1 文档性测试的概念 软件产品由可运行的程序、数据和文档组成。文档是软件的一个重要组成部分。在软件的整个生命周期中，会产生许多文档，在各个阶段中以文档作为前阶段工作成果的总结和后阶段工作的依据。 软件文档的分类如表6.11所示 用户文档 开发文档 管理文档 用户手册，操作手册，维护修改建议 软件需求说明书，数据库设计说明书，概要设计说明书，详细设计说明书，可行性研究报告 项目开发计划，测试计划，测试报告，开发进度月报。开发总结报告 文档性测试的概念 文档测试（Documentation Testing）主要针对系统提交给用户的文档进行验证，目标是验证软件文档是否正确记录系统的开发全过程的技术细节。通过文档测试可以改进系统的可用性、可靠性、可维护性和安装性。 文挡测试的内容 （1）用户文档测试内容 （2）开发文档测试内容 用户文档测试内容  在用户文档测试时，测试人员假定自己是用户，按照文档中的说明进行操作。在进行文档测试的时候，可以考虑以下几个方面： 把用户文档作为测试用例选择依据； 确切的按照文档所描述的方法使用系统； 测试每个提示和建议，检查每条陈述； 查找容易误导用户的内容； 用户文档测试内容 把缺陷并入缺陷跟踪库； 测试每个在线帮助超链接； 测试每条语句，不要想当然； 表现的像一个技术编辑而不是一个被动的评审者； 首先对整个文档进行一般的评审，然后进行一个详细的评审； 检查所有的错误信息； 用户文档测试内容 测试文档中提供的每个样例； 保证所有索引的入口有文档文本； 保证文档覆盖所有关键用户功能； 保证阅读类型不是太技术化； 寻找相对比较弱的区域，这些区域需要更多的解释。 开发文档测试内容 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰，准确地反映用户要求； 与所有其他系统成份的重要接口是否都已经描述； 被开发项目的数据流与数据结构是否足够、确定； 开发文档测试内容 所有图表是否清楚，在不补充说明时能否理解； 主要功能是否已包括在规定的软件范围之内，是否都己充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 开发文档测试内容 是否考虑过软件需求的其他方案； 是否考虑过将来可能会提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 有没有遗漏、重复或不一致的地方； 用户是否审查了初步的用户手册或原型； 项目开发计划中的估算是否受到了影响； 开发文档测试内容 接口：即分析软件各部分之间的联系，确认软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚低耦合的要求。模块作用范围是否在其控制范围之内； 风险：即确认该软件设计在现有的技术条件下和预算范围内是否能按时实现； 实用性：即确认该软件设计对于需求的解决方案是否实用； 开发文档测试内容 技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达； 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护； 质量：即确认该软件设计是否表现出良好的质量特征； 各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么； 开发文档测试内容 限制：评估对该软件的限制是否实现，是否与需求一致； 其他具体问题：对于文档、可测试性、设计过程等进行评估。 6.13.2 文档性测试方法 非代码的文档测试主要检查文档的正确性、完备性和可理解性。正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。完备性是指文档不可以虎头蛇尾，更不许漏掉关键内容。文档中很多内容对开发者可能是显然的，但对用户而言不见得都是显然的。 文档性测试方法 文档能否让大众用户看得懂，能否理解术语？缩写用户是否理解?内容和主题是否一致？很多程序员能编写出好程序，却写不出清晰的文档。与文档作者密切合作，对文档