初级软件测试相关知识

一、静态测试和动态测试

1、静态测试：静态测试并不会真正运行计算机源程序，只会进行特性分析，这是和动态方法以及人工测试不同的。因此静态方法常称为“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。

        静态分析常见的代码分析工具有：

        Ounec5.0，可扫描VB、C、C++、C#、Java，属于付费工具

        Coverity Prevent：扫描语言有：C、C++、Java、C#，付费工具

        Stake SmartRiskAnalyzer，扫描C、C++、JAVA，付费工具

        Rational Purify：C、C++、Java，付费工具

        Jtext：扫描语言Java，付费工具

        Flawfinder，扫描语言C、C++，付费

        Static Code Analyzer：扫描语言C、C++、C#、Java，付费工具

        PolySpace Client：扫描语言C、C++、Ada，付费

        RATS：扫描语言C、C++、python、perl、php，开源

        Fluid：扫描java，开源

 2、动态测试：

        动态测试主要特征是计算机必须真正运行被测试的程序，通过输入测试用例对其运行情况（输入/输出的对应关系）进行分析。日常测试属于动态测试。

二、黑盒、白盒测试

1、黑盒测试：

        黑盒测试基于产品（程序）的功能。在程序中把程序看作不能打开的黑盒子，不考虑程序内部的实现的情况下，对程序的功能进行测试。

2、白盒测试：

        白盒测试是基于代码的测试。白盒法全面了解了程序的内部结构，对软件的内部实现逻辑进行测试。

        一般来说，在进行单元测试时通常采用白盒测试，而在确认测试或系统测试中大都采用黑盒测试。

        常见的软件测试覆盖逻辑：

        a、语句覆盖：它要求被测程序的每一个执行语句在测试中尽可能都被检验过，这是最弱的逻辑覆盖准则

        b、分支覆盖或判断覆盖：要求程序中所有判定的分支尽可能得到检验。

        c、条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验。

        d、判断/条件覆盖：同时考虑条件的组合值及判定结果的检验。

        e、路径覆盖：只考虑对程序路径全面检验

        值得注意的是，无论哪种测试覆盖，即使其覆盖率达到百分之百，也不能保证把所有隐藏的程序缺陷都揭露出来。

三、软件测试过程：

        软件测试过程按照先后次序可以分为5步：单元测试，集成测试，确认测试和系统测试，最后进行验收测试。

        单元测试：是指对软件中最小可测试单元进行检查和验证。

        集成测试：在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。这里比较多的采用黑盒测试法来设计测试用例。

        确认测试：确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常使用黑盒测试方法。

        系统测试：是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。

        验收测试：检验软件产品质量的最后一道工序，又称为交付测试。这时相关的用户和独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

四、测试用例

        测试用例一般包括：用例编号、用例描述、优先级、用例类型、前置条件、操作步骤、预期结果、实际结果等。

五、测试设计技巧与规范

1、web类测试实践

        a、页面元素的用例设计：

        输入框：

        例1：可以填写任意字符，长度不超过20：

        <针对长度边界值设计>

        1.[空，报错]         2.[长度为1,正常]         3.[长度为20,正常]         4.[长度为21，报错]

        <正常类别>

        1.[数字,正常]        2.[符号,正常]        3.[符号.数字.字母,正常]        4.[汉字,正常]

        <安全性>

        [Xss攻击，正常]

        例2：小数点最多两位，长度不超过10的输入框

        <正常类别>

        1.[0，正常]        2.[1,正常]        3.[1.1,正常]        4.[0.11,正常]

        <异常类别>

        [包含非数字的字符，空，1.234，12345678901]

        

        下拉菜单：

        例1：选项为：空、A、B、C，默认为空不可写下拉框。

        ·<正常用例>

        [选择空，A，B，C，默认为空，不可写检查]

        多控件组合：

        例1：table表格，展示数据：名字和金额。

        <检查页面元素>

        [table格式和样式，其他页面样式]

        <页面数据检查>

        [名字为空，名字含汉字，名字为最大长度，金额为0，金额带两个小鼠，金额长度最长]

        例2：提交页面：一个输入框，一个下拉框，以及提交按钮

        <页面元素检查>

        [元素是否正常，元素的样式是否符合要求]

        <针对每个元素进行测试用例设计>

        可参考上面的案例

        <页面跳转>

        [符合要求填写内容后提交，不符合要求的内容提交]

        <外部异常>

        [后台报错，网络问题等]

六、移动APP测试

        树形移动APP测试：

        APP内部功能测试：

                1、单个页面测试用例：界面控件，与web测试类似

                2、界面之间的跳转逻辑

                3、启动、退出、更新

        APP硬件环境相关测试用例：

                1、访问权限、传感器

                2、不同机型

        APP软件环境相关：

                1、不同APP之间频繁切换

                2、不同的网络环境

        性能测试：

                1、耗电量

                2、网络流量

        

七、游戏类测试

        游戏开发需要通过各种调查、评估，确定开发游戏的范围或者项目，然后对市面上的此类游戏进行测试。测试人员需要去玩和开发相同类型的游戏。全面的测试报告包括：可玩性、功能方面、画面、性能、所需配置、社群体系等。

        游戏测试用例相较于软件测试复杂很多，游戏本身就是一个相对复杂的软件。

1、游戏基本功能的测试思路：

        

 2、游戏启动测试项：

        游戏图标：图标大小符合设计，图案与需求说明书一致

        界面显示：不同分辨率下显示全屏，启动成功后光标模型显示正确

        启动项检查：启动时间不超过需求中规定的时间，启动成功后游戏进程名没有错误

        按键操作：启动过程中通过功能键强制中断

3、游戏各个界面的测试：

        

4、更多游戏元素：

        游戏界面只是游戏内容的一小部分，实际上游戏内容远不止繁多的界面，通常还包含：角色人物、道具、音效、成绩、生命值、奖惩规则等元素。

        游戏元素测试项：

5、资源占用测试：

        一般，游戏相对于普通应用程序而言，因为需要处理动画、更加复杂的算法、逻辑、资源文件等。需要占用更高的CPU和内存空间。因此需要记录这两项数值情况，选择重要的初始值和峰值记录。

        资源占用测试项：

        

        测试场景：

        （1）CPU占用：线程越多，读写操作越频繁，则CPU占用数值就越高。

        （2）内存消耗：加载的界面和元素越多内存消耗就越大。需要对游戏的所有场景进行测试。

6、异常场景设计：

        异常场景测试是对测试用例覆盖率最有效的补充，往往最容易暴露问题的就是异常的操作或环境。用例设计需要考虑游戏与系统如何进行数据交互、游戏如何采用框架以及哪些数据需要跟其他软件进行传递。

        假如一款游戏运行在Linux系统上，与底层通过Pipe管道进行交互，问价成绩通过score.xml进行文件保存。此异常场景的测试项：