软件测试的“好、坏”之分

软件测试是用来鉴定软件的正确性、完整性、安全性和质量的过程。

如何看待软件测试，下面小编就一起了解了解吧…

软件的开始时间

软件的开始，那就就不得不说计算的诞生，世界上第一台通用计算机“ENIAC”于1946年在美国宾夕法尼亚大学诞生。它是一个庞然大物，用了18000个电子管，占地170平方米，重达30吨，耗电功率约150千瓦，每秒钟可进行5000次运算。就是这个一个看似不科学的机器，却是计算机的先锋。

之后到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。

到了1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。这是时候软件测试已有了行业标准(IEEE/ANSI )。

软件测试的多种方法

软件测试的方法，小编认为可以分为3类，自测、UI测试、检测

所谓的自测，即程序猿或与产品流程相关人员测试，主要测试的内容：

1、程序流程的合法性与流通性

2、程序的正确性、质量、合法、完成度（即产品上线之前评估）

3、程序的BUG

程序的UI测试，也叫“用户体验测试”，主要测试的内容：

1、产品的UI界面

2、产品与用户的交互（用户友好性、人性化、易操作性测试）

3、产品解决用户的需求理想程度

4、多用户需求，统一产品解决方案与预期解决方案

5、用户体验突发状况解决

检测即第三方软件测试，主要是做些人工做起来工作量大且不精准的工作，这时候检测就很实用，主要测试如下：

1、用户并发测试（压力测试）

2、大数据处理测试（效率测试）

3、程序结构、逻辑测试（白盒测试）

4、程序功能测试或者数据驱动测试（黑盒测试）

5、程序安装测试（环境测试）

以上测试内容根据不同产品采取大同小异的方式，当然每个产品或多或小都有自己的测试规律，这里小编只是举例说明，比如云平台、大数据服务等测试要求就会相当的严格，而一般的产品就好很多。

自动化测试

说完了需要人工参与部分人工参与的测试，那么接下来，小编说说不需要人工参与或少量人工参与的测试吧。

所谓自动化测试，大部分体现的测试还是手机端软件的测试，嵌入式、开发式软件那就是第三发测试了，程序只需要告诉软件，我一步接着一步的操作是什么，然后接下来就交给软件就好。

万物皆有阴阳两面，自动化测试有这么多优势，当然也有它的劣势。所以，至今仍然有很多公司自动化水平不高。我们分析一下这些劣势，主要有以下几方面：

　　1.对测试人员要求相对较高。

　　2.测试用例需要根据版本迭代进行更新，有一定维护成本。

　　3.测试结果不一定可靠，测试用例也分“好”、“坏”。

测试用例也分好坏

对于标题，你可能会有疑问，测试用例竟然也有好坏？的确，测试用例也有好坏之分，那么什么是坏用例？什么是好用例？那要先从测试用例的特征说起：

自动化测试或者测试用例的根本目的就是judge（判断）被测系统是否有问题，是以衡量被测产品的“标尺”存在的。所以，它具备一个重要的特征：在测试脚本和被测代码都保持不变的情况下，测试结果应该是稳定的、不变的。

根据这个原则，“坏用例”并不是指测试不通过的用例，更不是测试通过的用例，而是指那些在相同条件下，偶尔通过、偶尔不通过的测试用例。反之，“好用例”则是表现稳定的用例。

为什么说“坏用例”破坏性大？因为如果用例本身不具备稳定的结果输出，就无法准确的衡量被测产品是代码的问题还是用例本身的问题。如果每次测试结果都不能直接说明问题，需要进行反复分析，将直接导致大家对测试用例失去信心。也就是说，测试同学和开发同学会把测试用例的不通过，当成“Warning”而非“Error”,这样的最终效果就是自动化测试慢慢被抛弃。

测试用例的生命周期

有了“好用例”、“坏用例”的区分，测试用例就是“鲜活”的了。事实上，我们也可以规划处一个测试用例从生到死的生命周期。

IT小牛

一般情况下，我们可以以测试用例通过率或通过次数来为其划分“好/坏”。随着执行次数的增多，测试用例可以切换“好/坏”状态，当“坏用例”持续一段时间之后，我们可以把它标记为“垃圾用例”，并从自动化执行的序列中剔除。“坏用例”和“垃圾用例”可以被开发或者测试同学修复，然后进入“未知状态”。“未知状态”中的应用随着执行次数的增加，不断的在这个生命周期里循环往复。

如何消灭坏用例

1、通过“CI”（Continuous Integration持续集成）发现“坏用例”

“坏用例”指的是偶尔不通过、偶尔通过的用例。所以，你会发现在本地运行的时候很难发现“坏用例”，因为“坏用例”需要被执行很多次才能被检测出来。执行很多次的过程可以非常好地通过CI系统来帮助实现，所以，如果你还没有使用CI系统，也依然建议使用持续集成工具进行多次的执行用例，即便你的工程量很小。

2、防微杜渐

可能大家都听过“破窗理论”：当房子上的一扇窗户的玻璃被打破，如果不及时修复，将会有破坏者破坏更多的窗户。“坏用例”现象也是一样的，当出现一个“坏用例”时，如果不抓紧修复，整个测试用例集甚至自动化测试结果的可信度都将快速下滑。

3、避免执行环境差异

4、使用异步等待

5、解决并行执行的问题　

6、避免测试用例互相依赖　

7、避免测试脚本太长

8、提高测试用例代码水平　

等等，以上内容都是为了更好完善产品与修复产品BUG，当然一个软件或多或少都会有BUG了，都存在测试当中的漏洞，而我们测试的目的主要就是降低风险，提交产品的品质。

最后，小编想说，没有一款软件是十全十美的，我们只要达到用户所需，并不断的完善产品，那么就是一个合格的产品。