认识达内从这里开始

随着互联网的不断发展，越来越多的软件开发企业都开始关注软件测试的效果，而今天我们就一起来了解一下，一个好的软件测试过程都有哪些特点。

1、开发的过程中测试用例扮演的角色

在开发过程中，测试用例扮演了很重要的角色。它给你很多好处：

测试用例验证需求。它将让你时刻警惕，你是否在正确的实现业务需求

让你尽早暴露缺陷。越早暴露问题，解决的成本就越低速度越快，而测试用例可以让你在开发过程中抓住这样的时机。

改善可维护性。写测试用例的前提是代码本身可测试，这意味着你先得想办法保证你的代码是可维护的。可测试的代码一般是解耦做的比较好，这中代码具备可读性，也具备更好的结构。

让你放心重构。完善的测试用例保障大的改动也不会导致引发回归测试。

帮助codereview。因为测试用例通常表达了开发者的意图，reviewer很容易就可以透过测试用例看出程序的深沉逻辑。

2、什么是好的测试用例

我们先来定义一下什么才是好的“测试用例”

通常，一个号的测试用例具备如下特点：

可被信任。这意味着一个测试用例如果跑不通，就一定表示程序出问题。如果测试用例是否通过跟代码逻辑正确性没有必然联系，那这个测试用例就不能被信任。

易读/易维护。你应该能很容易透过测试用例看出它在测试什么以及怎么测的，而不会被一些很隐晦的引用或者状态控制所干扰，这表明一个好的测试是直观且内聚的。

一个测试用例只验证一个case。这个涉及到单一原则。如果一个测试用例内assert很多的case，那么当它失败的时候，你就无法立刻知道到底哪里出问题了。

独立性。一个测试用例不应该影响其他的测试用例。一个典型的例子是很多测试用例共享一个全局变量，如果是这样，那么跑测试用例的顺序将影响测试的结果，此时你就得花更多的精力去搞清楚到底发生了什么。

3、测试过程实践

一个好的测试过程具备如下特点：

它应该是自动化的(比如CI)

当测试用例能在对的时机及时执行时，它才是有意义的。好是持续集成，在这个过程中，你的测试会在某个时机被经常执行，比如在每次提交的时候。不然，你很可能会忘记跑测试用例，也就形同虚设。

测试用例应该在开发的过程中写，而不是之后

TDD(先写测试，再写业务逻辑)是不错的，但是你不一定能在一开始就能看穿一个模块应该是什么样，类结构应该如何设计等等。所以，即使你不能在一开始就写测试用例，我觉得ok，其中的原则是我们要尽早而不是拖到后写测试用例。

之所以要坚持这个原则，是因为测试用例能帮助我们写出干净的代码，包括分离关注点，使用接口隐藏具体实现细节。如果延迟写测试用例，你将会陷入围绕不可测试的代码各种hack的境地，而且身不由己，无法自拔。

为缺陷以及业务单元增加测试用例

你大可不必为所有理论上可能逻辑分支写测试用例(关于这一点，下面会继续聊)。

重要的是，你的测试用例必须能很好的表达业务逻辑单元，以及在后续的需求增加以及变更，还有缺陷发生时，你的测试用例都应该有相应的体现。尤其要强调针对Bug写好相应的测试用例，这种积累很大程度上可以保证你的软件是正向发展的。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。