软件测试基础–01

1. 软件测试基础

1.1. 什么是软件

Windows,Office,金山词霸,有道云，手机淘宝，手机微信…

1.2. 什么是软件测试

使用人工或者自动手段，来运行或者测试某个系统的过程。其目的在于检测它是否满足规定的需求或者弄清预期结果与实际结果之间的差别

 

1.3. 学习软件测试能做什么

 

 

 

1.5. 测试环境

测试环境=硬件+软件+ 络

 

硬件环境：pc机还是笔记本

 

软件环境：windows10  windows8  windows7

 

络:局域 还是互联

 

 

1.6. 测试用例

测试用例，英文是Test Case缩写为TC，指的是在测试执行之前设计的一套详细的测试方案，包括测试环境，测试步骤，测试数据和预期结果。

 

测试用例=输入+输出+测试环境

 

 

1.1.1. 为什么写测试用例

优点:

A) 便于团队交流

B) 便于重复测试

C) 便于跟踪统计

D) 便于用户自测

 

缺点:浪费时间，编写测试用例的时间有可能比测试时间还要长

 

1.1.2. 什么时间写测试用例

 

 

1.1.3. 测试用例模板

 

一般测试用例模板分为两种:word和excel

 

案例:

 

2.1. 黑盒测试和白盒测试

 黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果

白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。

 

2.4. 功能测试和性能测试

 1.1.7. 功能测试

 是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。

功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。

还有一些其他名词:恢复测试，确认测试，接口测试，数据库测试，安全测试，配置测试…. 

逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账 之后，才能进行登录,登录之后才能看我的购物车 

界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容…

 易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适

 安装测试:

 

 

1.1.13. 功能测试

能否装水，

除了装水， 能否装其他液体。比如可乐，酒精

能装多少ML的水

杯子是否有刻度表

杯子能否泡茶，跑咖啡

杯子是否能放冰箱，做冰块

杯子的材质是什么（玻璃，塑料,黄金做的）

1.1.14. 界面测试

外观好不好看。

什么颜色

杯子的形状是怎么样的。

杯子的重量是多少

杯子的图案是否合理

1.1.15. 性能测试

能否装100度的开水(泡茶)

能否装0度冰水

装满水，放几天后，是否会漏水

杯子内壁上的涂料是否容易脱落。

杯子上的颜色是否容易褪色或者脱落

风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏

1.1.16. 安全性测试

制作杯子的材料，是否有毒

放微波炉里转的时候，是否会熔化。

从桌子上掉到水泥地上是否会摔碎。

杯子是否容易长细菌

杯子内壁上的材料，是否会溶解到水中

装进不同液体，是否会有化学反应。

1.1.17. 易用性测试

杯子是否容易烫手

杯子是否好端，好拿

杯子的水是否容易喝到

杯子是否有防滑措施

是否能接受杯子的广告内容与图案

3. 软件生命周期模型

软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

3.1. 边做边改模型

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

瀑布模型中每项开发活动具有以下特点：

(l)从上一项开发活动接受其成果作为本次活动的输入。

(2)利用这一输入，实施本次活动应完成的工作内容。

(3)给出本次活动的工作成果，作为输出传给下一项开发活动。

(4)对本次活动的实施工作成果进行评审。

优点：当前一阶段完成后，只需要去关注后续阶段。

缺点： 需求在开始的不确定性，错误到最后才能发现。

3.3. 原型化模型

原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。

如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。

 

3.5. 螺旋模型

1.软件分多个版本开发，每个版本就是一次螺旋。

2.每个版本按照这样的顺序进行：

   1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）

   2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）

   3）实施软件开发；（图中右下象限）

   4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）

3.需求不是一次获取和实现的，通过多个螺旋来完善。

4.计划也不是一次成型的，每次螺旋都需要调整。

V模型的缺陷及解决思路

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

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

3.7. Ｗ模型

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

5.1. 软件的功能性

1.1.18. 适用性：

 所提供的功能是用户所需要的，

 用户所需要的功能软件系统是否已提供。

1.1.19. 准确性：

   软件系统提供给用户的功能是否满足用户对该功能的精

确度要求。

1.1.20. 互操作性：

   软件系统和一个或多个周边系统进行信息交互的能力。

例如

1.1.23. 防溢出攻击

例如：溢出攻击

正常输入：IE:http://www.baidu.com/

异常输入：IE:http://www.baidu.com/……（恶意代码）

1.1.24. 加密、解密：

在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全

1.1.25. 防病毒

5.2. 软件可靠性

1.1.26. 成熟性

    软件系统防止内部错误扩散而导致失效的能力。

    ▲子系统、模块、单元模块的设计人员应该仔细分析和自身有接口关系的子系统、模块、单元模块，识别出这些接口上可能会传递过来的错误，然后在自己子系统、模块、单元模块内部对这些可能的错误预先进行防范，规避这些错误传递到自身而引起自身的失效。

1.1.27. 容错性

    软件系统防止外部接口错误扩散而导致系统失效的能力。

▲设计人员应该充分分析外部接口可能产生的错误，然后在设计上对这些错误一一予以防范，防止这些外部传入的错误波及自身而失效。

1.1.28. 易恢复性

  系统失效后重新恢复原有功能、性能的能力

   ①原有能力恢复的程度

   ②原有能力恢复的速度

1.1.31. 易学性

    软件系统提供相关的辅助手段，帮助用户学习使用它

的能力。

例如：是否有用户手册，用户手册是否有中文版，是否有在

线帮助，界面上控件是否有回显功能等。

1.1.32. 易操作性

例如：

②GUI界面，菜单层次不要太深

③安装软件的过程

    错误：给用户大量的安装步骤，每步又有大量分支选项

（把用户当成本软件的专家）

 

   ▲测试时应该以非专业的角度来测试过程，往往需要α、

β测试。

1.1.33. 吸引性

   美观：GUI界面、手机外观等

   新颖：如夏新手机来电跳舞功能

5、易用性的依从性

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

5.4. 软件效率（性能测试）

1.1.34. 时间效率(2-5-10)

    系统在各业务场景下完成用户指定的业务请求所需的响应时间。

1.1.35. 资源效率

    系统在各业务场景下完成用户指定的业务请求所消耗的系统资源，如CPU占有率、内存占有率、通信带宽占有率、软件内部消息包资源占有率等。

1.1.36. 效率依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

 

5.5. 软件可维护性

 

1.1.37. 易分析性

    软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。（降低缺陷定位的成本）

1.1.38. 易改变性

    对软件缺陷的修复容易被实施（降低修复缺陷成本）

  ▲设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合，为未来可能的变化留有扩充余地。

 1.1.39. 稳定性

例如：代码中的有物理含义的数字，一定用宏代替。

1.1.40. 易测试性

（降低发现缺陷的成本）

①软件可控制：

    软件系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测试执行步骤的能力（通过打点、改变内部状态、值等手段）

②可观察：

    软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正确判断系统运行状态和测试执行结果的力。

 a、设计单独的测试模式

 b、提供单独的测试版本

    ▲测试部（一般指测试系统工程师）应该在需求分析阶段就提出可测试性需求，可测试性需求和软件产品其他需求一起纳入需求包被分析设计并实现。

5、维护性的依从性

    遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

5.6. 软件可移植性

1.1.41. 适应性

     软件系统无需做任何相应变动就能适应不同运行环境（操作系统平台、数据库平台、硬件平台等）的能力。

    ▲解决平台无关、可移植性问题的一个常用思路是构造出一个虚拟层，虚拟层将下层细节屏蔽，对上层提供统一口。

1.1.42. 易安装性

主流平台     全部测试用例

非主流平台  10%测试用例

1.1.43. 共存性

    软件系统和在公共环境与其共享资源的其他系统共存的能力。

    ▲测试不仅需要关注自身特性的实现，还要关注本软件是否影响了其他软件的正常功能。

 

5.7. 易替换性

      软件系统升级能力（在线升级、打补丁升级等）

可移植性的依从性

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。