测试团队已逐渐介入公司各项产品的测试，并根据团队的开发模式、产品方向不断调整测试策略、方法。团队创建至今颇有感概，特趁渊哥约稿之际，与大家分享一下我的从业经历（软件测试、软件项目经理）及公司现状下，测试团队的定位及存在意义，简文存在一些个人的意见，欢迎大家积极讨论、修正。
首先，简单聊下软件测试的历史：软件测试起初是软件开发人员在完成代码后自发的一个代码检查的过程，直至1975年《测试数据选择的原理》后，软件测试才被正式确定为一种研究方向。
软件测试从最初的经典定义：测试是为发现错误而执行的一个程序或者系统的过程。发展到现下流行的定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。
我们可以从中发现，软件测试的理论随着软件项目的规模、复杂度不断增强，而不断完善的。软件测试目前已经不再是我们10-20年前所熟知的找缺陷的过程（由于国内软件测试的环境部，大部分理论研究均来自于国外，所以相关理论的应用、推广也比较滞后），软件测试已经成长为一项与软件开发类似，同样具有生命周期的持续过程性任务。在软件测试的每个生命周期，测试工程师的职责、工作任务和产出均有明确说明，每个阶段也有对应的评审过程以保证各项产出的准确性、有效性。从软件测试的最新定义看来，软件测试目前可做为整个软件项目中的一个子项目进行实施。
再来聊下与软件测试相关的，大家比较熟悉的几个名词：
缺陷（BUG），这是大家对软件测试产出最直观的认识，也是绝大部分国内公司考察软件测试工程师KPI中最直观的指标之一。大部分人对缺陷的认知还是比较狭隘的（包括笔者从业前2年），可能在大家看来只有功能无法使用、软件崩溃、数据无法读写、软件逻辑冗乱这些与应用相关的异常才称之为缺陷。
在阐述个人观点前，我们首先来辩证地认识缺陷的常规描述：缺陷即瑕疵、缺点、欠缺、不完美，从缺陷的定义看来缺陷是一个相对定义，他需要一个比照标准以判断是否与标准匹配。然后我们回到软件测试中的缺陷认知，类似的软件测试的缺陷也需要一个参照标准，凡是与标准不一致的功能、描述、输入、输出、UI、配色、布局、入口、出口、数据格式、数据精确度、数据流向、数据一致性等都可称之为缺陷。
软件测试的意义，这个命题有点类似于罗素悖论：从公司层面而言，各位领导期望在最短的时间，使用最少的人力完成项目的各类测试（功能、性能、UI、安全、兼容、安装/卸载、易用、压力、负载、文档）提交各类文档，并保证软件不存在缺陷；从测试团队而言，工程师希望公司投入更多的人力、时间对软件进行充分测试、尽可能发现更多潜在缺陷（事实上，缺陷永远无法消除。比如：尽管微软的开发，测试从业人员比例小于1比2，但是每年仍不停的发布补丁以修复各类缺陷），在进行多次充分测试后再进行结论文档书写。通常测试团队会在项目周期内，根据项目资料尽早进行测试准确，对客户关注部分进行详细测试，其余部分与需求规格说明匹配情况即结束了项目的测试。这类处理方式看似非常中庸，实为项目管理制下满足客户、领导要求最大化的无奈之举。
回到公司的测试团队及研发的各兄弟团队上来。在我初入公司时，公司有建制的团队为：开发、项目管理、运维、部门管理。公司测试团队空缺的情况下，部分测试任务被分配到开发团队和运维团队的日常工作中。这样做的弊端如下：
对于开发人员而言，检查自己的作品是一件虐心的活动。在这种心理下，开发人员很难较多地发现自己的作品存在的缺陷；
测试方法、测试理论的缺失，导致开发人员和运维人员很难定义什么样的现象属于有效缺陷，测试的效率较低；
测试在局部展开，很难形成有效的测试报告，并将测试成果运用于其他项目；
测试、缺陷修复的随意性，导致版本发布较为随意，版本管理比较困难；
因此开发、运维团队在很长一段时间内都在频繁处理如下问题：
修复客户使用过程中发现的缺陷；
修复缺陷更改过程中引入的新缺陷；
频繁发布、维护一些不够稳定的软件；
频繁重复同类型活动带来的抱怨、吐槽等负面行为；
版权声明：本文出自 大妮 的51Testing软件测试博客：http://www.51testing.com/?3793
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
