软件测试基础总结

软件测试已经在软件的生命周期占重要位置了  可见软件测试越来越重要 而有些项目没有软件测试岗位则会造成不可估量的后果 例如咱们所知的狮子王 火星登陆等等事件

那么以下有一个问题总结一下

        如果你碰到不能复现的bug你改怎么办？

       将bug的操作步骤进行记录，然后进行在不同的测试环境中多次的调试，如果还是不能复现bug将根据bug的登记进行上报测试组长，根据需求文档对bug进行评级，看是否需要修改，

如果不能修改的则记录在测试报告中防止后期出现同一bug进行解释说明。

什么东西要完后都会有个流程 软件测试也有自己的流程

软件测试流程

软件缺陷从哪来？第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常更改，或者开发小组没有很好的沟通，造成对说明书理解的不一致。第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品规格说明书一样的问题，第三个原因才是编写代码和其它原因；前两个原因至少占了 80%以上。如图1-1所示

通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：

1. 需求解释有错误；
2. 用户需求定义错误；
3. 需求记录错误；
4. 设计说明有误；
5. 编码说明有误；
6. 程序代码有误；
7. 数据输入有误；
8. 测试错误；
9. 问题修改不正确；
10. 不正确的结果是由于其他的缺陷而产生。

软件测试定乂

狭义：测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。

广义：为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。延伸后的软件测试，被认为是一种软件测试的广义概念。

软件测试的定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

1. 软件工程的目的

成本：项目的开销，人工成本，工具成本，设备成本，错误成本（BUG）

进度：时间，计划

质量：软件对顾客需求的满意程度，一个低质量的软件，即使生产成本很低，进度控制良好，顾客也难以接受。

1. Ｖ模型

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能与非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主；

2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要看模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等；

3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第一个测试阶段，是对开发出来的单独模块进行测试，以确保每一个功能模块的功能正常，可以构建桩模块和驱动模块来回调用，方法也是以白盒为主。

4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等一些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。

V模型的缺陷及解决思路

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

1. Ｗ模型

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

敏捷开发和测试

敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。

模型优势：

工作任务划分清晰，工作效率较高

与开发和产品沟通紧密，团队协作性强

测试介入到整个项目的所有会议中，对整体版本信息情况把控全面

迅速占有市场，添加新的功能，吸引更多用户使用，提升用户体验度

模型的缺陷：

模块提交较快，测试时较有压迫感

项目规划要合理，不然测试时会出现复测的现象，加大工作量