软件测试价值论

第第页软件测试价值论软件测试价值论

发表于：2023-06-21来源：未知：娃娃点击数：标签：软件测试

软件测试的价值来源于公司的价值，公司的价值来源于商业上的成功。对于生成纯软件的公司来说软件产品就是商品，而用户就是市场，在非垄断行业中，用户的选择是自由的，增加用户黏度和吸引用户是公司策略的重心，而软件测试就是其中的有力支撑之一。

最近在坛子里发现很多新人询问软件（测试）的价值在哪里?。又见公司迅猛扩张，招收了很多测试工程师，部分测试（工程师）也再询问此类问题。经过一番思考，再结合我多年的工作和学习情况，在此做一抛砖引玉之文。

（软件测试）的价值来源于公司的价值，公司的价值来源于商业上的成功。对于生成纯软件的公司来说软件产品就是商品，而用户就是市场，在非垄断行业中，用户的选择是自由的，增加用户黏度和吸引用户是公司策略的重心，而（软件测试）就是其中的有力支撑之一。

如何进行软件测试才能体现出软件测试的价值呢?

首先从软件的生命周期开始，软件生命周期为计划，需求，设计，编码，测试，维护六个环节。从这里看出测试似乎在编码之后才开始进行，然而等到编码完成之后，都已经木已成舟，这个时候不管怎么改都已经无济于事了。为此在这里我们要把测试从这里抽出来，与其他五个部分并行，越早发现（缺陷）越有利于节约成本提升效益。那么现在把软件测试的生命周期定义为：（需求），架构，设计，单元测试，功能测试，集成测试，性能测试七个部分。每个部分目的不同，体现的价值也不同，综合起来就能够完成支撑公司商业成功的目的。

在需求阶段，（测试人员）需要去分析产品人员提供的需求文档，因为有效的需求是功能的抽象，我们要从需求文档中挖掘出有效的需求，剔除模糊不清，模棱两可的需求。再把有效的需求进行功能化，这里可以通过以往的经验来分析，也可以参考以往的版本，如果是全新的产品，则可以借鉴类似的产品，或其他平台上有类似功能的产品，详细到功能也可以参考别的产品类似的功能，对这些功能加以比较和分析，取长补短，整合创新。以此可以给产品人员和（开发）设计人员提供更好的建议和意见，以期增加产品的吸引力。比如一个登录的功能，很多软件都有，大不了就是输入用户名密码，验证码，仅此而已。其实我们可以结合环境加以创新，比如手机终端软件，就可以提供语音输入登录，用户读出自己设定的数字组合即可认为输入密码成功。在音频技术相对成熟的情况下，实现起来并不是很困难。

在我们分析出需求的功能点之后，我们可以根据业务逻辑确定目前所存在的功能点哪些是属于必须要有的功能点，这些功能点一个也不能少，从而给开发设计人员一个提醒，在设计的时候首先就要考虑这些功能点。其次可以确定那些功能点在当前的同类产品中属于创新的，可以作为产品的亮点存在的，这些功能点没有的话，将会导致产品变得大众化而毫无吸引力，那么开发设计人员在设计过程中将会投入较多的精力来设计和实现这些功能点。也可以分析出那些功能点可有可无，在项目时间和资源紧张的情况下，可以先不做或者放弃的，这样可以节约资源和时间，争取提前发布，抢占市场。这些就是需求测试中需要去完成的，也是测试价值的体现之一。

架构设计阶段，这个阶段属于承上启下的重要阶段，不仅是产品成败的关键，也是公司技术实力的体现，这里测试人员要从全局着眼，架构的好坏直接影响到软件的稳定性，扩展性，可维护性以及（性能）负载能力等。而测试人员重点考虑的就是（性能）负载能力，我们要分析出系统的性能瓶颈可能在架构的那些环节出现，通过以往的经验及和设计人员的沟通，来加以分析和考虑。软件性能问题的产生来源于资源的有限，在硬件形式表现为cpu处理速度，内存大小及读写速度，硬盘大小，硬盘I/O速度，网络带宽，网络节点分布等，而软件形式为是否多线程并发，是否有死锁，数据库访问速度，频发程序的算法，内存管理（安全）等。而软件架构则会涉及到网络，cpu使用，硬盘，内存，（数据库），频发程序，任务并发等多个方面，在这些方面入手考虑架构的性能指标，为软件架构设计提供初步的性能风险评估，避免后期来调整架构，这样可以有效的减少重复工作的时间，大大缩短项目开发周期，并且也为软件后期的维护，扩展，测试降低成本。这是测试价值的体现之二。

设计阶段，这个阶段主要是软件接口和功能的设计，包括概要设计和详细设计。在这个阶段里，测试人员需要重点关注接口和功能的可测性，同时也是设计测试用例的时候，我们需要弄清楚当前的接口设计是否可测，这是非常关键的事情，一旦接口定下来，后期将会直接影响到测试的实施和有效性。这里我举一个简单的例子：某款软件，主要给用户提供天气信息的显示，接口很简单，就是从指定的内容提供商处获取天气资源并发送到终端，由终端显示给用户。主要定制了三个接口，从内容提供商处获取资源，将资源传送给终端，计费。然而问题就出现在计费这里，计费是采取包月，而服务器不会给终端下发（服务器）时间，因为没有这个接口，终端时间是不可靠的，而在设计的时候是从（服务器）下发的天气资源包中获取时间的，当然这个时间也是准确可靠的。计费测试的（用例）主要的有：新用户可以免费使用七天，然后再次使用将提示用户开始计费。包月用户在包月期之内不会收到提示，且功能正常使用;包月失效后的用户会收到计费提示，如果不缴费，则停止资源下发。现在问题来了，计费的标准时间无法控制。因为开发人员并未给测试留输入接口，那么这里不测试是不可能，因为这属于重点功能，为此只能让开发人员编译三个版本，测试完毕之后再将时间接口改回去，由于代码的改动，必须要做一次全功能（回归），为此开发修改代码，测试，再修改代码，再回归测试，平白无辜增加了两天时间。如果在设计的时候提出来在这里需要留测试接口，那么这里两天时间我们就可以省下来了。这是测试价值的体现之三。

（单元测试）阶段，这个阶段主要依赖于开发人员自己完成，但是（测试用例）需要由测试人员来提供，现在国际流行的敏捷开发，其主要考核点之一就是单元测试的覆盖度，单元测试覆盖度越高，越节约测试时间，像谷歌这样的单位，开发人员和测试人员比例为10：1，全仰仗于此。这里测试人员就是提供测试用例及评估单元测试的有效性和覆盖度，保证大部分缺陷被扼杀在摇篮里。单元测试做的好的话，可以避免掉很多低级缺陷，从而大大的降低测试成本和时间，并且软件的可靠性也会大大的提升。而自动化测试也基本在单元测试阶段建立，为后期的回归测试节约了大量的人力。这就是测试价值的体现之四。

（功能测