中小公司的软件测试过程现状
一个初创与小公司没有测试工程师，仅让产品经理做了验收测试，或是开发工程师自己测试。这个形态还是比较普遍。类似的还有中小型软件企业开发现状与项目管理现状
产品经理通常情况下能做的就是功能验收测试，而这种测试也是基于UI界面层，基本的功能测试。固然不会有对接口的测试，对功能上的边界测试，而这些测试实际上是非常重要的。还有一些逆向场景的测试，这些场景实际上也是大部分产品经理逆向思维的一个体现。大部分产品经理实际上只是考虑了正向的场景。这也是产品经理的一个逻辑思维的体现。关于测试思维我们回顾有如下：
正向思维是指软件可以正常运行状态下表现出来的特征如：某个功能点正确实现后是什么样？网站可以提供访问时如何展现？
说明：所以测试按照正常思维方式，检查验证系统功能是否实现，通常是以需求为准则来判断。
逆向思维是相对于正常思维，通常是检查正常思维相违背的地方，比如功能点未实现后如何？网站不能访问时页面是如何展现？核心服务不可用时，整个系统表现是什么？
全局思维则是从全方位360角度去分析软件系统，如：系统上线后可能会碰到的诸如多种风险情况，针对每种情况是如何测试？
局部思维则是相对于全局思维，通常是检查某个系统在局部情况如：手机信号测试时，可以隔离多种环境进行思考分析
极端思维更准确的应从两端极限分析思考，如：针对信号测试时，最小/大信号范围时，表现如何？网络环境变化类似。
比较思维则更注重的是选择某个标准物做参考，然后制定一些对比参数选项来评判，如：Google/Baidu搜索相同关键字时，返回的内容相关性，响应速度等
普通软件开发工程师来做测试工作时，当他不具备测试思维时，只是测试的正向流程，边界也不会考虑，更不会考虑性能与安全，所以这种测试必然有缺失，特别是系统中涉及支付业务时，有经过良好的完整的测试过程上线，必然会造成经济损失。过去我们真实的案例有支付退款业务导致的漏洞，是因为前期的测试不完整导致的。软件工程师为什么要懂测试， 软件工程师的核心竞争力
是否有测试岗位取决于公司对软件的质量是否重视。另一方面，软件可能不需要太高的质量，这种情况下，面对于研发来说也就没有什么挑战。研发自己来测试的场景，并且整个组织中没有测试岗位，这个时候连发并不能完全保证软件的质量，大部分研发并不具备自测的能力，连单元测试都写不好，这种情况下面整个软件的质量固然不会有太多提升。没有测试岗位，即没有软件测试过程，其也是印证：康威定律 (康威法则 , Conway's Law)
"设计系统的架构受制于产生这些设计的组织的沟通结构。Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
我们过去经常说要提供给客户高质量的软件，软件测试过程如果做不好，何谈质量？所以本质问题是不论是不是有人在做，有没有这个岗位，而是整个过程中有没有软件测试过程。有的时候，老板认为这是一种节约成本的方式，其本质是，因为这个老板他对测试的认知是浅薄的，还是停留在测试，只是点点而已，殊不知这样的安排在实际系统上线后造成的经济损失更不可预知，部分老板需要经历这样的过程才会吃一堑长一智。而这一类老板通常都是做销售的，对软件研发质量没有完整的认识。也可以说这类的软件团队是非专业的软件过程。个人追求的是在专业的团队里面做专业的事。
有一个情况是微小企业老板可能是知道软件测试的，但是为了节约成本不愿意设立测试这个岗位，这也是一个困境。但实际上的研发团队又不具备软件测试能力，如此陷入了这个漩涡。基本测试都有Web测试介绍一 UI测试， Web测试介绍2一 安全测试，构建移动应用测试(一)，自动化测试，微服务测试，性能测试工具，移动应用App测试与质量管理一
互联网的产品和项目缺少性能测试，上线后的后果就是出现资源的超发，在互联网应用的并发下面，由于程序自身没有做好并发的处理，导致资源的超发，最后导致较大的经济损失，最终都需要有人来承担与处理事故，同时也影响公司的声誉。这已经是前车之鉴了，但对于部分公司依然没有引起重视，后面再次出现了线上的事故时，最终让研发自己来承担这个费用，早知道如此，为什么不做好系统性能测试与负载测试呢? 团队里面必须有一个人懂性能测试与负载测试，并能够实际落地，帮助找出系统中潜在的漏洞，不论是架构师，主程，项目经理，测试组长。
我们可以参考如下，反思当前组织测试能力。
TMM 级别 | 目标 | TMM 水平的目标 |
1级：初始 | 软件应该成功运行 | 在这个级别，没有识别任何过程域 测试的目的是确保软件运行良好 这个级别缺乏资源、工具和训练有素的员工 软件交付前没有质量保证检查 |
2级：已定义 | 制定测试和调试目标和策略 | 此级别将测试与调试区分开来，它们被视为不同的活动 测试阶段在编码之后 测试的主要目标是显示软件符合规范 基本的测试方法和技术已经到位 |
3级：综合 | 将测试集成到软件生命周期中 | 测试融入整个生命周期 根据需求定义测试目标 测试机构存在 测试被认为是一项专业活动 |
4级：管理和测量 | 建立测试测量程序 | 测试是一个测量和量化的过程 所有开发阶段的审查都被视为测试 对于重用和回归测试，测试用例被收集并记录在测试数据库中 记录缺陷并给出严重程度 |
5级：优化 | 测试过程优化 | 测试是管理和定义的 可以监控测试的有效性和成本 测试可以微调并不断改进 实行质量控制和缺陷预防 实践过程重用 测试相关指标也有工具支持 工具为测试用例设计和缺陷收集提供支持 |
还有一类团队懂得建立小而美的团队，团队中每个研发懂得软件测试的基本理论与基础，可以自行完成单元测试，接口测试，性能测试，甚至于安全测试。实际上，这样的研发团队已经是开发测试工程师SDET组成的，这样子的团队过去只有像微软公司才会有过。一个普通的研发需要具备测试思维，需要长时间的训练。
https://wiki.owasp.org/images/d/dc/OWASP_Top_10_2017_%E4%B8%AD%E6%96%87%E7%89%88v1.3.pdf
今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
![MegadotnetMicroMsg_thumb1_thumb1_thu[2]](http://images.cnitblog.com/blog/15172/201503/211054051419485.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[2]")
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
