全程软件测试第2版pdf-内存卡测试软件安卓版

链接: 提取码: t8mg

第四章 检查产品说明书

本章主要讲软件测试员通过高级审查技术查出软件的遗漏和丢失之处，低级测试技术用于保证所有细节都被定义。

1. 黑盒测试 白盒测试

黑盒只管输入和输出，不管内部结构

白盒可以访问代码，通过对代码的审查和检阅，修改测试程序，但有风险，因为要调整测试程序以适应代码操作，很容易形成偏见而无法进行客观测试。

2. 静态测试 动态测试

大白话来讲就是，检查审阅和实际使用的区别

3. 产品说明书有可能以文档的形式落地，也可能只是口口相传，不管是什么，都要捕捉到，然后进行黑盒静态测试。

4. 要设身处地为客户着想

5. 对产品说明书进行高级审查，看看有无丢失或者缺陷遗漏的大块头

6. 研究现有的标准和规范 区别在于程度不同，标注比规范更加确定，标准要严格遵守，规范是可选的，但应该遵守。

7. 审查和测试同类软件 产品经理在研究产品的时候，也会对竞品进行研究，测试员研究同类软件有助于制定测试条件和测试方法，还可能暴露没想到的潜在问题。

8. 产品说明书的低级测试 检查属性，检查用语

产品说明书果然是个大bug！！！

第五章，闭着眼睛测试软件

好嘞！精彩的来了！现在放下二郎腿，在计算机面前坐好，开始找bug！

---------------------------------------------------------------我是莫名其妙的分割线----------------------------------------------------------------------------

哎呀 从4月29号写到这里就中断了，现在看看发现下载链接上不了了，想上传但是系统提示上传电子书会侵权呢~

1. 关于黑盒测试：就是我们说的闭着眼睛测试软件啦~不看代码实现逻辑，测试工作就是进行输入，接受输出，检验结果。根据功能编写测试用例。

关于白盒测试：在接下来的6，7章会介绍

在有产品说明书的情况下的黑盒测试：按照步骤来，有说明书最起码比没有好是吧~

在无产品说明书的情况下的黑盒测试：还能怎么样，点点点，记录功能和特性，虽然很可能会有遗漏的功能，但是也总是能找出些bug的~

2. 软件测试有两个基本方法：通过测试和失败测试。

先进行通过测试，确认软件至少能做什么，保证基本功能的实现，而不会考验其能力。

再进行失败测试，纯粹为了破坏软件而设计和执行的测试案例叫失败测试或者迫使出错测试。也就是想方设法搞垮软件~

那么为什么要先进行通过测试呢？降低心理预期，底层经济基础打好了，再去追求上层建筑。才不会在正常使用软件时奇怪怎么会有那么多软件缺陷。客户要求的基本功能要先实现给他看，达到基本要求之后再去追求完美~

3. 等价分配：选择测试案例的方法是等价分配，有时称为等价划分。等价分配是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。

注意：在寻找等价区间时，想办法把软件的相似输入，输出，操作分成组，这些组就是等价区间。等价分配的前提是为了把可能的测试案例组合到仍然足以测试软件的控制范围。这种不完全测试当然会有风险，所以请尽量请有经验的测试员进行审查。

4. 等价分配的几个原则：边界条件，次边界条件，空值，无效数据

4.1 边界条件及边界条件类型全程软件测试第2版pdf，测试边界线

边界条件是指软件计划的操作界限所在的边缘条件。

如果要选择在等价分配中包含哪些数据，就根据边界来选择。

提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。

在软件的每一个部分不断地寻找边界是极为重要的，更多的边界被发现，就会找出更多的软件缺陷。

举个栗子：

如果文本输入域允许输入1~255，就尝试输入1至255作为合法区间。还可以输入254和2作为合法测试，输入0和256作为非法区间。

4.2 次边界条件

产品说明书或者测试过程中未说明，但在软件内部存在，用户几乎看不到的边界，称为次边界条件或者内部边界条件。例如2的乘方和ASCII表。

4.3 默认，空白，空值，零值和无

一定要考虑建立处理默认值。空白。空值，零值或者无输入等条件的等价区间。

4.4 非法，错误，不正确和垃圾数据

没有实际规则，天马行空地钻空子搞破坏吧~

5. 状态测试

注意：软件测试员必须测试程序的的状态及其转换。

第一步是建立软件的状态转换图

状态转换图应包括以下项目：

一、软件可能进入的每一种独立状态

二、从一种状态进入另一种状态所需的输入和条件

三、进入或退出某种状态时的设置条件和输出结果

通过等价分配，将大量的可能性减少到可以操作的测试案例集合，方法有以下五种：

一、每种状态至少访问一次

二、测试看起来最常见最普遍的状态转换

三、测试状态之间最不常用的分支

四、测试所有错误状态及其返回值

五、测试随机状态转换

6. 失败状态测试

包括竞争条件，重复，压迫和重负

6.1 竞争条件和时序混乱

竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以便找出哪些外部影响会中断该状态。考虑到要使用的数据如果没有准备好，或者在需要用到时，发生了变化，状态会怎样？数条弧线或者支线同时相连的情形如何？

6.2 重复、压迫和重负

重复测试是不断地执行同样的操作 最简单的是不停地启动关闭程序。进行这种反复测试的主要原因是看内存是否不足。

压迫测试是使软件在不够理想的条件下运行---内存小，磁盘空间小，CPU速度慢，调制解调器速率低等等。观察软件对外部资源的要求和依赖的程度。

重负测试时尽量提供条件任软件自由发挥，比如时间，对大多数软件，长期稳定的工作是很重要的。

注意：重复、压迫、重负测试应联合使用，同时进行。

7. 其他黑盒子测试技术

像无经验的用户或新用户那样做

在已经找到软件缺陷的地方再找找

凭借经验，直觉和预感

OK结束~em....本章连作者都说长~但是黑盒测试是软件测试的基础也是入门知识，运用本章所讲的技术是快速找出软件缺陷行之有效的方法。

第六章 检查代码

第五章说到六七章会详细讲讲白盒测试哈，没错它来了~

1. 静态白盒子测试：检查设计审查代码

静态白盒子测试：在不执行的条件下有条理地仔细审查软件设计，体系结构和代码，从而找出软件缺陷的过程，有时称为结构分析。

有点代码基础便可以进行，在规模不够大的小组中，一般是程序员进行测试。

好处：为该软件的黑盒测试员能够应用的测试案例提供思路。他们不必了解代码细节，但是根据审查备注，可以确定似乎有问题或者存在软件缺陷的特性范围。

另外，作者还是觉得应该重视静态白盒子测试，不觉得这是浪费时间的做法，作者觉得进行此项测试的首要原因是尽早发现软件缺陷，以便找出动态黑盒子测试难以揭示或者遇到的软件缺陷。

2. 正式审查

正式审查：正式审查就是进行静态白盒子测试的过程，含义广泛，从两个程序员之间的交谈，到代码的严格检查均属于此过程。

有四个基本要素：

一、确定问题

包括出错的项目和遗漏的项目。

二、遵守规则

审查要遵守一套固定的规则，有助于审查进展顺利。好处在于合作者了解自己的作用，目标是什么。eg：要审查的代码量；花费的时间；有哪些内容需要做备注等等。

三、准备

根据审查的类型，合作者需要了解自己的责任和义务，并积极参与审查。

四、编写报告

审查小组必须做出总结审查结果的书面报告，并尽快给开发人员使用。

按部就班地进行正式审查，就像一只捕虫网，能在早期抓住一些大的虫子。这样小组成员不会觉得是在浪费时间，当成员发现好处多多，此法便会日趋流行。

关于同事审查，公开陈述，检验

同事审查是初次的正式审查，还是按照上面四个步骤，但这个小团体只是在一起审查代码全程软件测试第2版pdf，寻找问题和失误，更多像讨论，不够正式，但是也是能发现些许问题。

公开陈述是同事审查的下一步，程序员解释自己的代码，其他人提问。

检验是最正式的审查类型，召开检验会议后，检验员可能再次碰头讨论他们发现的不足之处，并与会议主席共同准备一份书面报告，明确解决问题所必须的重做工作，然后程序员进行修改，由会议主席验证修改结果。根据修改的范围和规模以及软件的严格程度，可能还需要重新检验，以便找到其余的软件缺陷。

3. 编码标准和规范

作者认为，可以运行，甚至在测试中也表现稳定的软件，因为不符合某项规范而被认定为有问题，那真是amazing。风格问题不是软件缺陷。

有三个重要的原因要坚持标准或规范：

可靠性 事实证明，按照某种标准或者规范编写的代码比不这样做的代码 更加可靠，软件缺陷更少。

可读性/维护性 符合设备标准和规范的代码易于阅读，理解和维护。

移植性 代码经常需要在不同的硬件上运行，或者使用不同的编译器编译，如果代码符合设备标准，迁移到另外一个平台就会轻而易举，甚至完全没有障碍。

4. 通用代码审查清单

有编程经验的小伙伴看过来啦~

详细审查代码清单请服用~

一、检查是否有数据引用错误