摘要：
1元=100分=10分*10分=0.1元*0.1元=0.01元=1分 阅读全文
摘要：
什么时候需要回归测试？当发现并修改缺陷后，或者在软件中添加新功能后，重新测试，用来检查被发现的缺陷是否被改正，并且所作的修改没有引发新的问题当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变，这些改变可能使原本工作正常的功能产生错误回归测试可以通过人工重新执行测试用例，也可以使用自动化的捕获回放工具来进行回归测试方式再测试全部用例：选择基线测试用例库中的全部测试用例组成回归测试包，测试成本最高基于风险选择测试：可以基于一定的风险标准来从基线测试用例库中选择回归测试包首先运行最重要的、关键的和可疑的测试，测试从主要特征到次要特征。回归测试方式基于操作剖面选择测试重新测试修改的部分 阅读全文
摘要：
系统测试根据软件需求规范的要求进行系统测试，确认系统满足需求的要求系统测试人员相当于用户代言人在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作 在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作。要对软件需求规范中的要求形成确认标准，并且在其形成之初进行评审，保证可测试性。对于一些不能由测试确认的需求，要在需求规范中说明，如果可能尽量明确其他的确认方式。系统测试主要内容所有功能需求得到满足所有性能需求得到满足其他需求（例如安全性、容错性、兼容性等）得到满足 阅读全文
摘要：
集成测试通过测试发现与模块接口有关的问题目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构应当避免一次性的集成（除非软件规模很小），而采用增量集成 自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给定层次的模块总是存在的，也不再有使用稳定桩的必要。集成测试的过程明确测试目标和完成准则，并确定关键部分。确定阶段和进度安排。测试和修正协调的策划。清理系统结构。确定集成测试方法的组合策略。描述 阅读全文
摘要：
单元测试完成对最小的软件设计单元—模块的验证工作目标是确保模块被正确地编码使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误通常情况下是面向白盒的对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误 因为一个软件模块本身不一定是一个单独的程序，所以必须为每个单元测试开发驱动器或/和稳定的桩(stub)。在大多数应用中，一个驱动只是一个接收测试数据，并把数据传送给要测试的模块，然后打印相关结果的“主程序”。子程序桩的功能是替代那些被本模块调用的模块。根据模块间关系的不同需要有不同的桩和驱动器，可以根据桩的类型开发一些通用结构的桩和驱动器，以减 阅读全文
摘要：
测试覆盖率 有多少需求、代码已经被测试了缺陷发现率 缺陷是何时被发现，并且有多少缺陷已经被发现。缺陷可以根据严重性来分类。需记录以下值： 缺陷数目 缺陷的严重性测试成功率 有多少测试已经通过了，并且有多少是运行正常的？需记录以下值： 已通过的测试用例的数目 可利用的测试用例的数目 阅读全文
摘要：
Bug的80-20原则在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug而系统测试又能找出其余Bug中的80%最后的5%的Bug可能只 有在用户的大范围、长时间使用后才会曝露出来因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。80/20原则1.80%的工程量用在20%的需求上2.80%的开发成本花费在20%的部件上3.80%的错误是由20%的部件引起的4.80%的延期或返工是由20%的变更造成的5.80%的系统资源是由20%的部件消耗的6.80%的进度是由20%的人完成的 阅读全文
摘要：
木桶原理：软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至 文化因素也会影响最终软件的质量测试是提高软件质量的必要条件，最直接、最快捷的手段，但决不是一种根本手段如果将提高软件质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。 阅读全文
摘要：
等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 利用因果图生成测试用例的基本步骤: (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件. 阅读全文
摘要：
错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. 阅读全文
