软件测试期末复习重点

1、软件测试的定义以及软件测试的目的/意义。

（1）定义：
软件测试就是一个过程或一系列过程，用来确定计算机代码完成了其应该完成的功能，不执行其不该有的操作。
或：软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体。
（2）目的/意义：
1）（1）要以最少的人力、物力和时间找出软件中的各种错误与缺陷，通过修正各种错误与缺陷提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的经济风险。
2）测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与评价，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。
3）通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。
4）同时通过对软件结果的分析整理，为风险评估提供信息，还可以修正软件开发规则，并为软件可靠性分析提供依据。

2、解释软件测试的心理学和软件测试的经济学。

（1）软件测试心理学：
测试是为了发现错误而执行程序的过程。定义暗示了：软件测试是一个破坏性过程，甚至是一个“施虐”的过程。成功的测试：发现了某个新错误的测试；不成功的测试：指未能适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”。一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。最终，通过软件测试建立某种程度的信心：软件做了其应该做的，未做其不应该做的。
（2）软件测试经济学：
软件测试中需要考虑经济问题，错误发现得越早，改正错误的成本就会越小。
穷举输入测试要强于穷举路径测试，但是两者都不是有效的方法，因为这两种方法都不可行，可以将白盒测试和黑盒测试结合起来进行测试。

3、简述软件测试的基本原则。

（1）测试用例中一个必需部分是对预期输出或结果的定义。
（2）程序员应当避免测试自己编写的程序。
（3）编写软件的组织不应当测试自己编写的软件。
（4）应当彻底检查每个测试的执行结果。
（5）测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
（6）检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
（7）应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
（8）设计测试工作时不应默许假定不会发现错误。
（9）程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
（10）软件测试是一项极富创造性、极具智力挑战性的工作。

4、集成测试策略类型和阐述增量测试策略的类型和各自优缺点。

（1）瞬时集成测试和增量集成测试。
（2）增量集成测试分为自顶向下集成，自底向上集成和混合式集成。
1）自顶向下集成：

优点：
对高层行为进行早期确认：
至多只需一个驱动程序；
每步可以只加一个模块；
支持深度优先和宽度优先。

缺点：
对低层行为确认比较晚；
对缺少的元素需要编写树桩程序；
测试案例的输入和输出可能很难明确表示。

2）自底向上集成：

优点：（自顶向下缺点的对立面）
对底层行为早期进行确认；
不需要写程序桩；
对一些子树而言比较容易明确表示输入，比较容易解释对其他的输出。

缺点：
推迟对高层行为的确认；
需要驱动程序；
当组合子树的时候，一大堆元素要进行集成。
3）混合式集成：
优点：
具有自顶向下和自底向上两种集成策略的优点之外，运用了一定的技巧，能够减少桩模块和驱动模块的开发。
缺点：
中间层不能尽早得到充分的测试。

5、建一个除法类（Divide），并编写相应的测试用例 Junit test case。

6、常见白盒测试方法和黑盒方法。

（1）白盒测试方法：
语句覆盖；
判定覆盖/分支覆盖；
条件覆盖；
判定-条件覆盖;
条件组合覆盖;
路径覆盖;
基本路径覆盖。
（2）黑盒测试方法：
等价类划分法；
边界值分析法；
判定表法；
因果图法/因果分析法；
正交试验法；
功能图法。

7、简述软件测试的过程。

（1）拟定软件测试计划；
（2）编制软件测试大纲；
（3）设计和生成测试用例；
（4）实施测试；
（5）分析 测试结果。

8、请用因果分析法分析下列说明。

（1）原因与结果：

（2）因果图：

（3）判定表：

（4）生成测试用例：

PS：利用因果分析法生成测试用例的过程：
（1）分析程序规格说明书，识别哪些是原因，哪些是结果。原因往往是输入条件或是输入条件的等价类，而结果常常为输出条件。
（2）分析程序规格说明书，按其语义，采用因果图连接各个原因与其相应的结果。用四种关系符号来描述因果图中原因与结果之间的关系。
（3）标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。对于这些特定的情况，在因果图中使用讲述的五种约束符号（E、I、O、R、M）来标明原因间、结果间的约束条件。
（4）把因果图转换成一个因果图列表进而生成判定表(或判定树)来描述哪种输入组合所引起的哪个执行动作的决策规则。
（5）把判定表的规则转换成测试用例。选择测试数据以便使判定表里的每个规则都被测试。

因果分析法知识补充：
在因果图中通常用Ci表示原因， Ei表示结果。

8、画出下列图片中的状态图。

（1）列出被测系统的输入事件

（2）对空闲状态（程序刚启动时的状态）加所有可能的输入，判断产生哪些新状态。

（3）第三步：对第二步产生的每个新状态分别加所有可能的输入。

（4）对第三步产生的每个新状态分别加所有可能的输入。

（5）对第四步产生的每个新状态分别加所有可能的输入。
此程序有如下9个状态：
空闲
遗漏国家和人民币
国家已选择
人民币已输入
遗漏人民币信息
遗漏国家信息
完成两种输入
显示等价金额
退出

9、采用基本路径法导出测试用例。

PS：基本路径测试用例覆盖法步骤
① 依据代码绘制流图 ；
② 确定流图的圈复杂度；
③ 确定线性独立路径的基本路径集合（基本路径，又称独立路径；基本路径，是指在程序入口和出口之间的任一路径，其间不存在两条长度大于2的相同的子路径；集合不一定唯一）（圈复杂度=基本路径）（启发式算法：“每一条基本路径覆盖至少一条未被其他路径覆盖到的边。” ）；
④ 设计测试用例覆盖每条基本路径（由基本路径集导出的测试用例，保证每行代码语句至少被执行一次）。

计算圈复杂度的方法：

10、根据程序流程图，应用条件组合覆盖方法导出测试用例，并运行测试用例集，分析测试结果。

11、使用参数化运行器（Parameterized.class）对税收类 tax 进行测试，建立测试类 testTax。
源程序：

public class Tax {
	public double countTax(double salary){
		double temp = salary - 2000;
		double tax=-1;
		if(temp <= 0){ tax = 0;}
		if(temp > 0){
			if(temp > 500){
				tax += 500 * 0.05;
			}else{
				tax += temp * 0.05;}
		}
		if(temp - 500 > 0){
			if(temp > 2000){
				tax += 1500 * 0.10;
			}else{
				tax += (temp-500) * 0.10;}
		}
        return tax;}
}

//参数化运行器
@RunWith(Parameterized.class)
public class PrarametersTax {
	private Tax tax; 	private float finput;	private float expectedTax;
	@Parameters
	public static List<Object[]> data(){
		Object[][] object = {{0f,0f},{2000f,0f},{2500f,25.0f}, {4100.0f,190.0f},{120000.0f,37725.0f}};
		return Arrays.asList(object);}
	@Before
	public void init(){
		tax = new Tax();
	}
	public PrarametersTax(float input, float expectedTax){
		this.finput = input;
		this.expectedTax = expectedTax;	
	}
	@Test
	public void testTax(){
		assertEquals(this.expectedTax, tax.countTax(this.finput),0.0);
	}
}

PS：
参数化测试（Parameters）：当一个测试类使用参数化运行器运行时，需要在类的声明处加上@RunWith(Parameterized.class)注解，表示该类将不使用JUnit内建的运行器运行，而使用参数化运行器运行；在参数化运行类中提供参数的方法上要使用@Parameters注解来修饰，同时在测试类的构造方法中为各个参数赋值(构造方法是由JUnit调用的)，最后编写测试类，它会根据参数的组数来运行对应的测试次数。

12、利用等价划分法分析电话号码。

（1） 电话号码等价类划分表；

（2）根据等价类划分表，设计测试用例覆盖有效等价类；

（3）根据无效等价类划分表，设计测试用例覆盖无效等价类；

13、WEB应用测试的种类。

内容测试（数据库测试）
用户界面测试（易用性测试和兼容性测试）
组件级测试
导航测试
配置测试
安全测试
性能测试（负载测试和压力测试）

PS：负载测试
吞吐量P值：P=NTD（N——并发的用户数；T——单位时间每个用户的在线事务数；D——每个事务被服务器处理的数据负载量）

14、人工测试的种类。

利用错误列表进行代码检查；
小组代码走查；
桌面检查；
同行评审；
可用性测试（黑盒测试）

15、单元测试大量地使用白盒测试技术（辅助使用黑盒测试技术），集成测试使用最多的是黑盒测试用例设计技术（辅助使用白盒测试技术）。
16、软件工件的一部分改动会影响其他相关部分的现象叫做波漪效应，而迭代的分析而且去除改变的副作用的过程就叫做波漪效应分析。
17、集成测试被定义为在单元测试与系统测试之间级别的测试，集成测试解决接口连接问题。
18、软件测试的方法按技术分类主要为：白盒测试和黑盒测试（还有一个灰盒测试）；按照执行状态分类为静态测试和动态测试。
19、一个成功的测试是指发现了至今尚未发现的错误的测试。
20、测试用例应当由测试输入数据和与之对应的预期输出结果两部分组成。（输入与预输出）
21、测试是要发现语义的或逻辑的错误，而不是要发现语法的或符号的错误。
22、功能图法就是为了解决动态说明问题的一种测试用例的设计方法 ；功能图由状态迁移图和逻辑功能模型构成。从功能逻辑模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合；从状态迁移图导出整体测试用例，以覆盖系统（程序）控制的逻辑路径。
23、错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。
24、两种支持黑盒测试的插桩技术，测试预言与随机数生成器。
25、代码检查小组：通常4人，第一个小组成员是：协调员。
26、黑盒测试是以数据驱动的测试；白盒测试是以逻辑驱动测试。
27、有资料表明**，60％以上的软件错误并不是程序错误，而是软件需求和软件设计错误**。
28、系统测试的目的是为了证明软件产品与其初始目标不一致的过程。
29、功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
30、模块测试（单元测试）的目的是发现程序模块与其接口规格说明之间的不一致的过程。
31、验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。
32、系统测试包括：能力测试，容量测试，强度测试，易用性测试，安全性测试，性能测试，存储测试，配置测试，兼容性/配置/转换测试，安装测试，可靠性测试，可恢复性测试，适用性测试，文档测试，过程测试。
33、关于JUnit单元测试：

JUnit常用的注释类：Test、Ignore、Before、After和Assert。
@Test表示的是一个测试用例，可选参数timeout用来指定限时测试，可选参数expected用来测试一个预期的异常。
@Ignore忽略某个测试。
@Before在测试之前进行数据的初始化处理。
@After在测试之后做收尾工作

TestResult 负责收集TestCase所执行的结果，将测试结果转发到TestListener处理
TestListener包含4个方法：addError(), addFailure(), startTest()和endTest()。
JUnit 报告测试没有成功，区分为失败（failures）和错误（errors）。失败是你的代码中的 Assert 方法失败引起的；而错误则是代码异常引起。

在JUnit中，测试方法需要满足如下原则:
（1）public的
（2）void的
（3）无方法参数的
（4）方法名称最好以test开头

套件运行器，如果想要同时运行多个测试，需要使用两个注解：@RunWith(Suite.class)和@Suite.SuiteClasses()，通过这两个注解分别指定使用Suite运行器来运行测试，以及指定了运行那些测试类，其中@SuiteClasses中可以继续指定Suite，这样JUnit会再去寻找里面的测试类，一直找到能够执行的Test Case并执行之。

34、白盒测试中覆盖准则最强的是路径覆盖。

因为我学习的软件测试书是《软件测试的艺术》第三版，可能我写的软件测试期末复习重点不适用于所有的兄弟们，可以取其精华去其糟粕。

这是我觉得写得不错一个软件测试期末重点，感兴趣的可以看一波：
软件测试期末复习要点整理

标签：复习,路径,tax,测试用例,期末,测试,软件,软件测试
来源： https://blog.csdn.net/qq_44111805/article/details/117507968