摘要：如果数据从旧系统迁移到新系统是当前版本发布的主要目的，那么更要关注报表数据数据迁移缺陷如果一个旧系统要被新系统取代，旧系统里的数据要移到新系统。
对任何软件产品来说，软件上线永远是一件大事。完全确保所有功能生效以及发布高质量软件给用户非常重要。
不好的、不成熟的、不稳定的、难以使用的产品会引发重大经济损失，还会让用户对品牌本身失去信任。
我们通常听到当软件符合上线标准时，测试就应该结束了。我们也听到软件缺陷必须被修复以达到软件上线标准。
然而，这些都是伟大的冠冕堂皇的准则，太模糊了。
更确切地说：
· 多少比例的软件缺陷对软件上线来说是可接受的？
· 你如何决定哪些已知软件缺陷不影响软件上线？
· 哪种软件缺陷更紧急更严重？
你曾听到过这些问题吗？那么这篇文章将帮助你揭晓答案。
复杂的软件不是没有软件缺陷，相对于可运行的软件来说，关掉缺陷是一个鸡和蛋的故事。
修复的缺陷越多，修复缺陷时产生的新缺陷的可能性越大。那么，
· 你如何决定软件上线时可附带的缺陷程度以及缺陷类型？
· 你如何确定软件上线时的部署基准？
· UAT测试人员如何决定软件是否上线？
· 哪些参数应该用于评判软件质量？
· 如何回答-软件是否适用并会为利益相关者带来价值？
上线到生产环境对客户方和合同方来说都是一个大的里程碑，因为这关系着付款里程碑。双方对确保大型转型项目的成功都有着同等的责任。
我的经验表明客户想要高性价比并且提供了UAT上线标准。
· 功能
· 性能和负载
· 可用性
· 安全性
· 与外部系统的交互性
· 报表
· 数据迁移
我坚信每一个这些类型的软件缺陷都需要被进一步解释。而且，那是我们现在的确要做的事情：
功能缺陷
如果软件是根据客户提供的需求开发的，那么它必须满足需求。功能的任何偏离被录为功能缺陷。 根据严重性和优先级功能缺陷被分类。
如下是重要的考虑因素：
高严重性和高优先级的软件缺陷通常会影响软件的日常使用。这些类型的软件缺陷必须在软件上线前被修复。没有例外。
有时候功能缺陷由于不是原始需求的一部分被划分为需求变更。这些需求变更在软件上线后对业务运作是必须的，因此必须被实现。
软件缺陷的划分和功能缺陷的优先级划分是由UAT协调人员和用户以及需求分析人员共同完成的。通常，客户有一个关于多少比例的软件缺陷可以存在的上线标准
性能以及负载缺陷：
性能缺陷是软件上线的重要考虑因素，尤其是软件被外部用户使用。
如果用户量达到一定数目时，软件运行很慢。用户会因为加载耗时而避免使用软件。如果软件太慢会导致业务流失，用户会转而使用竞争对手的软件。
有时候，非客户面对的部分程序也会影响软件性能。
比如: 如果每天结束时要运行一个批处理任务，程序的响应时间因此而受到影响。那么批处理的性能也是一个考虑因素。
· 软件性能通常用屏幕响应时间来衡量，当特定数量的并发用户使用系统时性能对用户而言就必须考虑。
· 性能测试用工具来完成，比如LoadRunner，WebLoad，Neoload等
· 特定负载和未来预测负载的软件性能通常记录在合同里，在软件上线前必须要证明。
· 用户很少用到的部分程序页面延迟到系统上线后再评估。
· 软件性能也依赖于部署软件的硬件类型和网络条件。
· 性能测试在特定硬件里使用性能测试工具在UAT阶段完成，性能缺陷以类似于功能测试的方式来追溯。性能缺陷也会被划分优先级，达成一致以符合上线标准。
· 通常在UAT阶段的性能和负载测试在用户做完功能测试并且达到功能缺陷交付标准后完成
可用性缺陷:
软件开发应该易于终端用户使用，比如用不同的快捷键、快捷方式，最少的屏幕切换、换页。软件必须灵活并且直观。
如果在移到合适的屏幕之前有太多页面切换，用户通常会对使用这个软件失去信心。
· 软件构建前可用性准则被创建。软件必须遵循这些准则。
· 软件开发时也可能有工具限制，在软件被终端用户使用前必须克服这个问题。
· 用高可用性软件，一个终端用户可以输入常规软件5倍的数据。
· 软件的外观和感受必须是新鲜的，同时法律问题必须在软件上线前被列出来。
· 很多时候软件可用性顾问被任命来确保用户可以流畅地使用软件。
· 必须和软件程序一起交付的文档也必须尽可能合法使用且严格遵循可用性准则。
· UAT/外部测试人员录入的可用性缺陷像功能缺陷和性能缺陷一样也被划分了优先级，必须符合上线准则
安全性缺陷:
软件的安全性是一个热点问题，因为软件程序可能被黑客攻击，客户敏感数据可能被窃取。
因此，可信赖的软件不应该允许甚至一个非常专业的黑客以不合适的权限进入程序。
· 安全性测试是在UAT阶段以特定输入来确保软件不被攻击。
· 安全性测试由合法黑客来尝试攻击软件以检查软件是否脆弱。
· 所有安全性缺陷必须在系统上线前被修复。
· 安全性也意味着登录、不同权限的用户（内部和外部）使用程序的不同部分，以及创建和批准数据
与外部软件系统交互性缺陷:
通常，一个要在客户方部署的软件程序必须与任何已有软件交互。
比如:
打印系统，他们已经在使用中或者可能是一个外部系统比如账单程序或者资料荧屏系统。将要部署的软件程序应该与这些外部系统无缝交互。对这些系统的所有输入和输出应该同步工作。当前技术包含了移动应用程序和必须与之兼容的不同软件平台。
检查外部系统的交互性应该在系统测试阶段和UAT阶段被广泛执行。必须有一个满意的上线准则
报表缺陷:
来自软件程序的报表是表明程序内部数据统计的一种关键方式。
比如:所有账单相关数据必须符合借贷额度。
· 软件中所有数据必须协调。软件里的这种数据协调通过报表来展现，必须达到期望。
· 如果数据从旧系统迁移到新系统是当前版本发布的主要目的，那么更要关注报表数据
数据迁移缺陷:
如果一个旧系统要被新系统取代，旧系统里的数据要移到新系统。新系统应该如需求定义的一样支持迁移过来的数据。
所有旧数据可能在新系统里不可用；然而旧数据的截图会在新系统中可用。按约定，这个数据应该可用。
注意:上述列表并不详尽。根据程序类型，可能有更多的东西需要验证或者并不是上述所有都适用。因此，对软件的全面理解，业务目的，用户期望以及架构或硬件依赖对创建综合的上线准则是必须的。
软件上线标准示例:
这只是一个例子。具体情况因项目不同而不同。
· 优先级为1的软件缺陷要100%关掉（严重性为严重且优先级为1）
· 90%的优先级为2的软件缺陷（严重性为高且优先级为2）要被修复。对剩余10%的缺陷必须有变通方案。并且对关掉剩余10%的缺陷要有一个可行计划。
· 生产环境部署清单以及可用性检查清单已经准备好。
· 生产环境支持团队已成立并准备好解决问题。
· 70%的优先级为3的缺陷被解决并且有一个取代计划来解决剩余30%的低优先级缺陷。
值得注意的几点:
· 所有严重性以及优先级定义是在项目开始时客户方和合同方在业务会议上决定的。
· 在所有UAT缺陷被记录并且所有其他缺陷被解决后，UAT协调人员和业务发起人碰头对未解决的缺陷进行评估
总结
我们希望这篇文章对创建稳固的上线标准以防止软件在生产环境里受到潜在缺陷影响的一些重要思考已经给了你一些见解
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!
在我的QQ技术交流群里（技术交流和资源共享，广告勿扰）
可以自助拿走，群号：310357728群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦
如果对你有一点点帮助，各位的「点赞」就是小编创作的最大动力，我们下篇文章见！
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/119759.html
2019-2-18 貌似这篇文章帮了大家一些小忙最近tinymce出5.0版本了，下面的api还是4.x的,新版本可能会有些不适用了，最近业务繁忙，等哪天周末有时间的话我再做点更新 :) 前言 最近因业务需求在项目中嵌入了tinymce这个编辑器，用于满足平台给用户编辑各类新闻内容什么的业务需求，前后也花了不少时间体验和对比了市面上各类开源编辑器。 各大WYSIWYG编辑器的简单比较 UEdit...
2019-2-18 貌似这篇文章帮了大家一些小忙最近tinymce出5.0版本了，下面的api还是4.x的,新版本可能会有些不适用了，最近业务繁忙，等哪天周末有时间的话我再做点更新 :) 前言 最近因业务需求在项目中嵌入了tinymce这个编辑器，用于满足平台给用户编辑各类新闻内容什么的业务需求，前后也花了不少时间体验和对比了市面上各类开源编辑器。 各大WYSIWYG编辑器的简单比较 UEdit...
摘要：一介绍本文介绍一种多人参与开发时的分支管理模型，在团队项目中成功实践。开发新的功能某先从分支出分支，命名为。建议请勿在周五发布任何正式环境分支，以免出现问题六分支命名的建议分支以它类型名字命名。如修复连接数泄漏的分支，可命名为。 一、介绍 本文介绍一种多人参与开发时的 GIT 分支管理模型，在团队项目中成功实践。使用的是gitlab来做代码管理与权限控制。 二、服务器部署环境 一般来说...
摘要：造轮子的一些思考首先，我们的需求是用户能够方便的调整后台的各种表盘位置。内的所有组件必须不能重叠，还要能自动排序某些组件要可以设定静态的，也就是固定在那里，不被布局的任何变动而影响。为了快速获得这种心态的转变，你要做的就是造轮子。 先来一张图看看： showImg(https://segmentfault.com/img/remote/1460000013305417?w=600&h=...
摘要：造轮子的一些思考首先，我们的需求是用户能够方便的调整后台的各种表盘位置。内的所有组件必须不能重叠，还要能自动排序某些组件要可以设定静态的，也就是固定在那里，不被布局的任何变动而影响。为了快速获得这种心态的转变，你要做的就是造轮子。 先来一张图看看： showImg(https://segmentfault.com/img/remote/1460000013305417?w=600&h=...
阅读 1005·2021-10-15 09:39
阅读 838·2021-09-28 09:35
阅读 2821·2021-09-10 10:50
阅读 3339·2019-08-30 15:53
阅读 1757·2019-08-30 15:52
阅读 2429·2019-08-29 15:31
阅读 2640·2019-08-27 14:27
阅读 1851·2019-08-26 13:43
