软件测试作业和习题的批注。

简介：
第一章 （判断） 1 程序测试旨在验证程序的有效性，并通过执行程序的过程来确认其功能。 2 软件测试的起点并非编码完成，而是贯穿于开发过程的始终。 3 软件缺陷的主要根源往往在于产品说明书的设计和编写。 4 软件测试是确保软件质量的关键手段，在软件开发生命周期中扮演着至关重要的角色。 5 烟雾测试（冒烟测试）的主要目标是验证软件的核心功能是否能够正常运行，为后续的正式测试奠定基础。 6 测试脚本是通过程序设计语言编写的可执行程序，用于自动化测试流程。 7 在紧迫的项目时间节点下，省略软件测试过程并非明智之举，应谨慎对待。 软件测试的误区： 误区一：如果发布后的软件存在质量问题，将全部归咎于软件测试人员是不公平的。 误区二：相比于编程，软件测试技术的要求可能相对较低，但仍需具备一定的专业知识和技能。 误区三：仅仅增加测试次数并不能保证发现所有问题，合理的测试策略更为重要。 误区四：将软件测试视为仅属于测试人员的工作，忽视开发人员的参与与协作是不全面的。 误区五：根据瀑布模型来看待软件测试，将其局限于开发后期是一个错误的认知。 软件测试的原则： 11 所有测试标准都应建立在对用户需求的深刻理解之上。 12 在时间和质量之间进行权衡时，必须优先保证质量。 13 在项目启动之初就明确产品的质量标准至关重要，以便后续根据实际情况进行评估和调整。 14 软件测试应从项目启动之初就开始实施，而非等到程序编写完成后再进行检查。 15 穷举式测试在实际应用中是不现实的；即使是相对简单的程序也可能存在大量的路径组合需要进行覆盖。 16 第三方参与的测试能够提供更客观、更全面的评估结果. 17 完善的软件测试计划是高效开展工作的前提保障. 18 测试用例的设计应基于目的性原则, 通过合理的策略提高效率, 最大化错误发现, 并提升程序的可靠性. 针对发现较多错误的程序段, 应采取更深入、细致的检测方法. 务必重视文档管理, 妥善保存所有相关的文档, 包括测试计划、用例以及报告等. 应当秉持“尽早、持续地进行”的理念作为指导原则. 需要注意修改错误可能引发更多问题的现象. 建议从小规模开始逐步扩大范围进行检测. 避免随意忽略或排除任何已设计的用例. 必须对每一个检测结果进行彻底核查. 关注并分析错误集中发生的现象, 这与程序员的代码水平和习惯息息相关. 第二章 （判断） 1 需求评审和设计评审属于静态分析方法的一种范畴. 最正式的评审形式通常采用会议形式展开. 需求评审过程中必须邀请用户或用户代表参与以确保准确性与有效性. 每次的需求会议评审都应该邀请相关人员包括 测试人员、业务人员以及业务主管等共同参与 . 在需求评审中需要明确具体的评审标准以保证一致性和可控性 . 需求评审的核心在于“以用户为中心”进行全面评估 . 系统架构评审主要关注系统的模块耦合度和内部关联性 . 第三章 （填空） 1 测试用例的概念: 指的是可以独立执行的一次或多个操作步骤和一个最小的可测单元的过程 。 2 测试用例的三种状态: 通过(Pass)、未通过(Fail)、未执行(Not Executed)。3 测试用例的分类: 包括正面输入法以及负面输入法 。4 由一系列独立的Test Case 以及与之对应的环境组合而成的集合称为 Test Suite 或者 Test Collection 。 关于自动化: 1 自动化测试不应取代手工验证, 而应作为辅助手段提升效率 。2 Jmeter 的自动比较技术使用 Assert 断言机制来进行验证 。3 使用 Jmeter 进行网站负载能力测压时 , 需要在 “线程组” 中添加相应的配置 。4 TestComplete 可以用来对网站的功能进行自动化检测 , 例如可以通过 TC 测试百度搜索 “四川理工学院” 的结果页面是否包含相关链接文本 。5脚本类型包括线性脚本、结构化脚本、关键字驱动脚本以及数据驱动脚本等 。