关于软件测试

2017-03-02 tech test 10 mins 3662 字

最近在看关于软件测试方面的资料，整理了一些资料。文末列出了一些关于软件测试的观点，顺便推荐两个测试做的比较好的php项目。

何为软件测试

使用人工或自动的手段来运行或者测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试应当遵循的原则

测试显示缺陷的存在，但不能证明没有缺陷
穷尽测试是不可能的，应设定及时终止的条件
测试应尽早进行
缺陷具备群集特性
测试的杀虫剂悖论，不定期增删修改测试用例，从而发现软件缺陷
测试的二八原则，８０％的时间和资源用在２０％的重点模块上
测试活动依赖于测试背景，针对不同的测试背景，测试活动场景要求也是不一样的，比如对电信大并发量性能、金融的安全要求等.

软件测试的分类

按阶段划分

单元测试

单元测试是对软件中的基本组成单位进行的测试。目的是检验软件基本组成单位的正确性。单元测试可以倒推要求开发人员正视需求，对自己的程序更有信心。
集成测试

在单元测试的基础上，将所有软件单元按照概要设计规格说明的要求组装成模块、子系统或者系统的过程中各部分工作是否达到或实现相应技术指标以及要求的活动。偏于从技术角度进行测试实施方案
系统测试

将各子系统结合起来，包括功能测试、非功能测试。非功能测试就包括很多了，性能测试、稳定性测试、可用性测试、安全测试等。注重整个系统完整的功能和性能，偏于从业务角度测试系统。
- 功能测试：
  
  　功能测试是对产品的各功能进行验证，以检查是否满足需求的要求。其中又分为很多种：逻辑功能测试、界面测试、易用性测试、兼容性测试一般功能测试使用的工具有：
  
  商用
  - QTP
  - WinRunner
  - silktest
  - rational robot 开源
  - selenium
  - watir
  - sikuli
- 性能测试：
  
  　性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。软件的性能包括很多方面，主要有时间性能和空间性能两种。时间性能：主要是指软件的一个具体的响应时间。比如一个登录所需要的时间，一个交易所需要的时间等。当然，抛开具体的测试环境，来分析一次事务的响应时间是没有任何意义的。需要搭建一个具体且独立的测试环境。空间性能：主要指软件运行时所消耗的系统资源，比如硬件资源，CPU、内存，网络带宽消耗等。一般功能测试使用的工具有：
  - loadrunner
  - silkperformer
  - jmeter
  - webload
  - apache bench
  - loadui
- 安全测试：
  
  安全测试检查系统对非法入侵的防范能力。这一类的工具有：
  - appscan web应用漏洞扫描
  - webinspect web应用漏洞扫描
  - nessus 服务器主机类漏洞扫描
  - nmap 端口嗅探
  - metasploit 渗透测试
  - webscarab 代理劫持分析
  - fortify 白盒测试工具，源代码静态分析
  - w3af Web应用程序攻击和检查框架
- 兼容测试：
  
  　　兼容性测试主要是测试系统在不同的软硬件环境下是否能够正常的运行。
交付测试/验收测试
- 功能确认测试
- 安全可靠性测试
- 易用性测试
- 可扩充性测试
- 兼容性测试
- 资源占用率测试
- 用户文档资料验收

按照对象可见度

黑盒测试、白盒测试、灰盒测试

按照状态

静态测试、动态测试

按照测试执行方法

手工测试

手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。
自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。又可分为功能自动化测试与性能自动化测试。

冒烟测试、回归测试、随机测试

　　这三种测试在软件功能测试过程中，既不算具体明确的测试阶段也不算是具体的测试方法。

冒烟测试

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。引入到软件测试中，就是指测试小组在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新开发。这样做的好处是可以节省大量的时间成本和人力成本。
回归测试

是指修改了旧代码后，重新时行测试以确认修改后没有引入新的错误或导致其他代码产生错误。回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到通过为止。
随机测试

是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。随机测试可以发现一些隐蔽的错误，但是也有很多缺点，比如测试不系统，无法统计代码覆盖率和需求覆盖率，发现的问题难以重现。一般是放在测试的最后执行。其实随机测试更专业的升级版叫探索性测试
探索性测试

探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

一些观点

企业级Web项目中应该如何做单元测试、集成测试和功能测试？

Q: 使用Java做企业市场产品开发，应该如何做单元测试，集成测试和功能测试？是只测试后端服务吗？需不需要做界面的测试？之前和业界某著名咨询公司首席咨询师交流，他说应该多做基于场景的测试，并且尽量测试真实的代码，少打桩，这种说法有什么问题？

A: 并不是单元测试本身不好，而是由于单元测试本身花费的时间量太大，导致真正能够做好单元测试的越来越少。当前很多企业应用开发，根本没有逻辑层，或者说没有明确的领域服务，写出的单元测试用例直接在跑数据库的CRUD，这个基本没有太大的意义。

个人认为单元测试重点一定是要有明确的领域层或服务层，同时单元测试最好也是和CI持续集成配合，即单元测试无法做到100%完全测试用例覆盖，重点还是主体功能覆盖，更好的用于CI中的自动化冒烟测试。

集成测试，能够做好的同样很少，很多集成测试就是在做系统测试，原因在于很多就没有子系统的概念，没有组件化和模块化的概念，接口本身也没有提前定义和设计，谈不上模块的集成和组装。集成测试没做好不是方法的问题，首先还是模块化和接口设计没推进的问题。当有了真正的集成测试，你就会明白stub的使用往往是必须的了，特别是在由顶向下进行的集成的时候。

以上两点都难推进的情况下，那就好好把系统测试做好，你说的是对的，基于业务场景的系统功能测试是最重要的，至少能够交付到客户一个缺陷率低，满足业务需求的产品。

单元测试的好处

A：单元测试最直接的好处有两点：

让你写出更好的代码：职业高内聚、低耦合而且接口设计合理的代码才易于测试
让你在修改代码时更有信心

如何保持unit test代码的稳定

A: 代码是为了什么，当然是为了重复运行。如何保持unit test代码的稳定？主要靠好的API设计。API切实正确切割了需求，那么在重构的时候API就基本不用变化，unit test也不用重写。以后你重构的时候，只要你的unit test覆盖的够好，基本跑一遍就知道有没有改成傻逼。可以节省大量的时间。

所以那些专门写不需要维护的软件的人，讨厌测试，也是情有可原的。

两个PHP项目

BootstrapCMS

项目作者是PHP著名的 Laravel 框架的开发组成员。

octobercms

这个项目的测试文件比较完备，甚至改包括了使用selenium进行UI测试。