软件测试理论整理

软件的测试方法/手段：
黑盒/白盒|静态/动态|手工/自动化
按照测试阶段划分：
→单元测试：基于代码逻辑实现的测试
→集成测试：基于模块、部件集成的测试
→系统测试：基于软件需求、功能实现的全量测试
→验收测试：基于用户的验收测试
测试模式：
→敏捷测试：敏捷宣言：个体与交互   重于  过程和工具
                      可用的软件   重于  完备的文档
                        客户协作   重于  合同谈判
                        相应变化   重于  遵循计划
            特点：无明显团队划分，无间隙合作，不遵循某种规则，一切结果导向
→ST:（scripted  testing）传统测试的脚本测试          特点 ：系统性强，易于管理
→ET:（exploratory  testing）探索测试，设计和执行并行  特点：自由灵活 强调测试人员的主动性  和st互补
→RBT:Risk-based  testing  基于风险评估的测试，基于质量风险、管理风险（人员技能等）




→MBT:基于模型的测试，这里的模型是指对需求功能点进行建模
分级SR建立良好的分支流程图，逐条覆盖防止漏测

若分支较多，遍历困难时尝试使用正交法等测试技术覆盖集中问题板块。



软件测试的类型：
→功能：根据产品的特性、操作描述和用户方案、测试一个产品的特性和可操作行为以确定它们满足设计需求
        针对的问题：功能错误或者遗漏、界面问题、性能错误、数据及访问错误，初始化及终止错误
→性能：压力、规格达标、软件能力的测试
→安全：OWASP top10业界十大安全漏洞（www.owasp.org） 
       1、注入攻击：sql或者脚本注入
       2、失效的身份认证： 失效的会话，认证信息外部可见，易于被劫持
       3、XSS：跨站脚本攻击
       4、不安全的对象引用：引用存在问题的模块或者发现问题尚未更改的部件 如：url中带id，修改后会获取其他用户的信息
       5、安全配置：开放了不必要的权限、端口等
       6、敏感信息泄露：泄露用户的敏感信息
       7、访问控制的确实：跳转用户没有权限访问的模块
       8、未被验证的重定向或转发


→可靠性：
→兼容性：平台、向下、互操作兼容等常用工具（browsershots、browsersandbox）
→易用性：用户体验  如：页面风格的一致性，三次鼠标点击是否达到用户的需求
→部署：基础数据、不同环境下部署文档可知道部署
→文档：
→本地化：针对语言、书写习惯、时区、日期货币格式、当地风俗、法律法规

Hello，Val最近在看有关测试的书，名字叫《软件测试的艺术》，这本书适合软件测试入门，书不是很厚，有概念也有例题，就是看着很多概念可能会搞混，看了网上的一些关于软件测试的题集，顺便再牛客网上刷了一些题才对测试有了一点点feel~，所以本篇博客就是一篇概念汇总博客，Val精制武林秘籍，有很多知识点在我以前写的博客中也有涉及的，还有相关例题，本篇主要是概念修炼。

1、什么是软件测试： 
为了发现错误而执行程序的过程。 
根据软件开发各阶段规格说明和程序内部精心设计一批测试用例（输入数据&预期结果），并利用这些测试用例运行程序，以发现错误的过程。

2、软件测试的目的： 
以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件的质量，从而避免软件发布后由于存在潜在的软件缺陷和错误造成的隐患带来的商业风险。

3、什么是需求文档测试？ 
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现。

4、什么是设计文档测试？ 
测试设计是否符合全部需求以及设计是否合理。

5、什么是alpha测试？ 
alpha测试由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。 
不能由开发或测试人员完成。 alpha测试发现的错误，可以在测试现场立即反馈给开发人员，由开发人员及时分析处理。 
目的是评价软件产品的功能、可使用性、性能和支持。尤其注重产品界面和特色 
alpha测试可以从软件产品编码结束之后开始，也可以在确认测试过程中产品达到一定稳定和可靠度之后再开始。 
有关的手册（草稿）等应该在alpha测试前准备好。

6、什么是beta测试？ 
beta测试时软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 
开发者通常不在测试现场，beta测试不能由开发或测试人员完成。 
beta测试是在开发者无法控制环境的情况下进行的软件现场应用。在beta测试中，由用户记下所有遇到的问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户报告后，作出修改，最后将软件产品交付给全体用户使用。 
beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。 
只有当alpha测试达到一定的可靠程度时，才能开始beta测试。 
由于beta测试主要目标是测试可支持性，所以beta测试应该尽可能由主持产品发行的人员来管理。

7、什么是驱动模块？ 
驱动模块在大多数场合称为“主程序”，接收测试数据，并把这些数据传递到被测试模块单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传输数据，为此写驱动。 
驱动模块主要完成： 
1、接受测试输入； 
2、对输入进行判断； 
3、将输入传给被测单元，驱动被测单元执行； 
4、接受被测单单元执行结果，对结果进行判断； 
5、将判断结果作为用例执行结果输出测试报告。

测试输入 –> 输入判断 –> 输入传给被测单元 –> 驱动被测单元执行 –> 接收执行结果，对结果判断 –> 判断结果作为测试用例执行结果输出测试报告

8、什么是桩模块？ 
比如对函数A做单元测试时，被测的单元下还包括了一个函数B，为更好定位错误，就要为B函数写桩，来模拟B函数的功能，保证其正确。

9、（1）什么是白盒测试 
白盒测试（逻辑驱动测试，结构测试），它知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结果测试程序，检验程序中的每条通路是否都有能按规定要求正确工作，而不顾它的功能，白盒测试主要方法：逻辑驱动、基路测试等，主要用于软件验证。 
对开发语言支持：白盒测试工具是对源代码进行的测试，测试主要内容包括语法分析、静态错误分析、动态检测等。 
目前测试工具主要支持的开发语言包括：标注C、C++、visual C++、Java、Visual J++等。

（2）白盒测试有哪几种方法？ 
白盒测试也称结构测试或逻辑驱动测试，它知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书正常进行，按照程序内部的结构测试程序，检验程序中每条通路是否有按预定要求工作正确，不顾它的功能。 
白盒测试主要方法：逻辑驱动、基路测试等，主要用于软件验证。 
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路经测试。

10、什么是静态测试？ 
通过运行程序测试软件称为动态测试，在动态测试中，通产使用白盒测试和黑盒测试从不同的角度设计测试用例，查找软件代码中的错误。 
通过评审文档、阅读代码等方式测试软件（静态测试） 
静态测试方法指不运行被测程序本身，仅通过分析或检查源程序的语法、结果、过程、接口等来检查程序的正确性。 
对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错 
静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。 
静态测试结果可用于进一步查错，并为测试用例选取提供指导。

11、什么是回归测试？ 
回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。 
如测试员对程序进行测试时发现了bug，返还程序员修改，程序员修改后发布新的软件包或新的补丁给测试人员，此时需要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

12、 
（1）软件缺陷的等级应如何划分？ 
软件缺陷的等级可以用严重性和优先级来描述； 
严重性：衡量缺陷对客户满意度影响的满意程度，分为： 
1、致命错误，可能导致本模块以及其他相关模块异常，死机等问题； 
2、严重错误，问题局限在本模块，导致模块功能失常或异常退出； 
3、一般错误，模块功能部分失效； 
4、建议模块，有问题提出人对测试模块的改进建议。

优先级：缺陷被修复的紧急程度； 
1、立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需要立即修复； 
2、高优先级（P2级）：缺陷严重，影响测试，需要优先考虑； 
3、正常排队（P3级）：缺陷需要正常排队等待修复； 
4、低优先级（P4级）：缺陷可以在有时间时被纠正

（2）针对缺陷采取怎样的管理措施？ 
1、要更好管理缺陷，必须引入缺陷管理工具，商用的或开源的都可以。 
2、根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。 
3、所有发现的缺陷（不管是测试发现的还是走读代码发现的），必须全部即时的提交到缺陷管理工具中，这是缺陷提交的管理。 
4、缺陷提交后，需要及时指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷尽快解决。 
缺陷解决后需要及时对缺陷的修复进行验证。这样目的2个：一是让缺陷尽快解决，二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。 
5、为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷类别、缺陷的龄期分布等信息。

13、如果能执行完美的黑盒测试，还需要进行白盒测试吗（白盒黑盒测试的区别） 
任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。 
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 
1、是否有不正确或遗漏的功能? 
2、在接口上，输入是否能正确的接受?能否输出正确的结果? 
3、是否有数据结构错误或外部信息(例如数据文件)访问错误? 
4、性能上是否能够满足要求? 
5、是否有初始化或终止性错误? 
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查： 
1、对程序模块的所有独立的执行路径至少测试一遍。 
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 
3、在循环的边界和运行的界限内执行循环体。 
4、测试内部数据结构的有效性，等等。 
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试，在未发现错误时，不能说明程序中没有错误。

14、软件测试分为哪几个阶段？简述各阶段应重点测试的点？各个阶段的含义？ 
单元测试、集成测试、系统测试、验收测试。 
每个阶段分为以下5个步骤：测试计划、测试设计、用例设计、执行结果、测试报告 
初级测试集中在每个模块上，保证源代码的正确性，该阶段称为单元测试，主要用白盒测试方法。 
接下来是模块集成和集成以便组成完整的软件包。 集成测试集中在证实和程序构成问题上。主要采用黑盒测试方法，辅之以白盒测试方法。 
软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。测试仅应用黑盒测试方法。

15、什么是单元测试？ 
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等。它是软件动态测试的最基本部分，也是最重要的部分之一，其目的是检验软件基本组成的正确性。

16、什么是集成测试？ 
集成测试是软件在系统集成过程中所进行的测试，主要目的是检查软件单位之间的接口是否正确。

17、系统测试 
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单任务，它被称为测试的“先知者问题”。

18、验收测试 
验收测试旨在向软件购买者展示该软件系统满足其用户要求，它的测试数据通常是系统测试的测试数据的子集。

19、回归测试 
回归测试是在软件维护阶段，对软件进行修改后进行的测试。其目的是检验对软件进行的修改是否正确。

20、设计用例的方法、依据有哪些？ 
白盒测试用例设计方法有：基本路径测试/边界值分分析/覆盖测试/循环测试/数据流测试/程序插桩测试/变异测试。这时候依据就是详细设计说明书及其代码结构。 
黑盒测试用例设计方法：基于用户需求的测试/功能图分析/等价类划分/边界值分析/错误推测法/因果图法/判定表驱动法/正交试验设计法。 依据：用户需求规格说明书，详细设计说明书。

21、单元测试、集成测试、系统测试的侧重点是什么？ 
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。 
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成子系统或系统，进行集成测试。 实践表明，一些模块虽然能够单独地工作，但并不保证连接起来也能正常工作。程序在某些局部反映不出来的问题在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。 
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及其他软件的兼容性。

22、描述使用bugzilla缺陷管理工具对软件缺陷（Bug）跟踪的管理的流程。 
（1）测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。 
（2）经验证无误后，修改状态为VERIFIED，待整改产品发布后，修改为CLOSED。 
（3）还有问题，REOPENED，状态重新变为NEW，并发邮件通知。 
（4）项目组长根据具体情况，重新reassigned分配给bug所属的开发者。 
（5）若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明） 
（6）开发者收到Email信息后，判断是否为自己修改的范围。 
（7）若不是，重新reassigned分配给项目组长或应该分配的开发者。 
（8）测试人员查询开发者已修改的bug，进行重新测试。

文档测试：http://blog.csdn.net/ValDC_Morning/article/details/77921657 
α、β、λ测试：http://blog.csdn.net/ValDC_Morning/article/details/77919049 
软件测试阶段：http://blog.csdn.net/ValDC_Morning/article/details/77924807 
测试例题：http://blog.csdn.net/ValDC_Morning/article/details/77884701


个人测试设计总结：做好一个测试设计个人觉得先对软件的需求进行分解，然后进行质量风险评估，然后由9大测试类型入手对测试设计进行全面覆盖。
在需求分解阶段针对各个测试类型进行最小测试点的分解覆盖：如笔芯的测试就分解笔头、笔管、和笔墨等