测试——可能是应用程序开发中最被低估的部分

我为什么要付钱让你测试你自己的工作？

这是我多年来在与客户讨论测试预算时经常听到的一个问题。 对于外行来说，这听起来像是一个公平的问题。 但是，任何参与软件开发的人都知道测试的复杂性和耗时性。 事实上，测试是任何软件开发项目中最重要的部分之一。

大型电子商务平台是一个极其复杂的东西，包含数百万行代码、数千兆字节的数据和许多集成点。 有很多相互关联的运动部件； 链条中的环节太多，很容易出错。 该应用程序将通过众多桌面和移动设备上的众多浏览器以数百万种不同的方式使用。 该开发项目将持续至少 6 个月，并有许多不同的人参与其中。 可以测试的领域和场景的数量几乎是无限的。 任何东西都能奏效真是个奇迹！

测试可以分为多个不同的区域，但每个测试区域都需要考虑。 每个项目都有点不同； 有些客户喜欢自己承担大部分测试，有些喜欢外包，而有些则希望他们的开发人员全部完成。 测试也不是一个固定的实体； 你可以做很多测试，也可以做一点。 你测试的越多，你就越能降低项目的风险，但花费的时间越多，成本也越高。

单元测试

单元测试是测试小“单元”代码以确保它们按预期运行的测试。 例如，提交表单时，应将输入的详细信息保存到数据库表中。 这是一个独立的测试，专门且仅确保单元按预期运行。 使用真正的测试驱动开发方法，开发人员将在实际创建任何代码之前先编写测试，以便只有在测试通过时才能认为代码已完成。 在实践中，单元测试仅用于应用程序的一些关键领域，以确保核心功能按预期工作。 虽然单元测试可以减少发生功能问题的可能性，但它也可以增加开发时间。

冒烟测试

您可能会听到您的开发机构经常谈论烟雾测试。 冒烟测试是测试用例的一个实用子集，涵盖了整个应用程序中的关键用户旅程和功能。 至少，您的开发人员应该在将任何东西交给您进行 UAT 之前进行冒烟测试。

界面测试

用户界面 (UI) 测试可能是一件非常复杂且耗时的事情。 用于访问网站的移动设备、平板电脑和桌面设备、操作系统和浏览器种类繁多，这意味着手动全面测试每个组合几乎是不可能的。 由于需要涵盖大量不同的变体，UI 测试是自动化测试的完美候选者。 自动化测试工具能够通过您的网站跟踪脚本之旅，并测试是否达到了预期的结果。 他们还可以记录每一次旅程，以便每一次都可以回放。 虽然这种方法并不完美，但它可以显着减少网站可能面临的主要 UI 问题的数量。

一些 3rd 方测试服务（例如 Bug Finders）提供众包服务，来自世界各地的数百名自由职业测试人员用于测试网站，并在发现问题时获得报酬。 这种方法是一种在数百种设备/平台/浏览器组合中测试应用程序的相对经济有效的方法。 一个测试周期导致提出大约 200 个问题是正常的。 挑战通常在于对问题进行分类和优先排序，以便您将资源集中在处理最重要的问题上。 每个网站都会不断积压一些不太可能解决的低级问题。

回归测试

回归测试是持续开发中极其重要的一部分。 它旨在测试对应用程序某个部分的任何更改是否会导致另一部分出现问题。 例如，更改用于验证联系我们表单的 JavaScript 函数可能会影响结帐中使用的表单。 由于任何电子商务平台的复杂性，回归问题并不少见，因此制定可靠的回归测试计划对于确保您的用户体验不会受到这些问题的不利影响至关重要。

UAT

用户验收测试 (UAT) 是任何开发项目的关键部分，它涉及客户在平台上线之前对平台进行完整的端到端测试。 UAT 是我认为最常被低估的过程。 当时间紧迫时，它也是项目中最先遭受损失的部分。 但是，这可能会导致更高的失败率。 对于任何新的网站建设，我们建议至少计划 2 个月的 UAT。 您的电子商务网站只是您的任何商务业务的一部分，涉及搜索、结账、订单管理、支付、发货、客户服务、财务和链的所有其他部分的端到端流程都需要测试。

UAT 经常与 SIT（系统集成测试）混淆或合并，您将在其中专门测试多个系统之间的集成。 SIT 是端到端测试的一部分，可确保链的所有部分都能正常工作。

好的 UAT 涉及创建测试用例和测试计划。 这些通常采用一组脚本的形式（脚本是一组要运行的任务），手动测试人员将运行这些脚本并根据结果通过或失败测试。 端到端 UAT 测试计划包含 500 多个测试用例并不罕见。

UAT中的A是它如此重要的原因之一。 在 UAT 流程结束时，您通常会被视为已接受该申请，因此您必须对其进行彻底测试以确保它完全按照您预期的方式工作。 这并不意味着未发现的错误将不在保修范围内，但如果有功能无法按您预期的方式工作，则需要在 UAT 中进行处理。 它如此重要的另一个原因是它是在问题上线之前发现问题的最后机会。 任何错误和问题都可能对用户体验产生负面影响。

UAT 需要代表客户付出很多努力，而这往往被低估了。 一些客户在 UAT 期间使用外部测试机构来支持他们，这可以显着降低客户没有人力有效执行 UAT 的项目的风险。

安全测试

有时我很惊讶一些零售商没有足够认真地对待安全测试。 零售商不知道他们上次在其网络平台上进行渗透测试是什么时候并不罕见。 这些通常是尚未受到网络攻击（或还不知道自己受到攻击）的人。 在当前网络犯罪的频率和复杂程度持续增长的环境下，尤其是在欧洲即将出现 GDPR 的情况下，安全测试变得越来越重要。 所有电子商务网络平台都应至少每年一次由专业的第三方进行渗透测试，但最好每年两次。 还建议您定期使用 Nessus 等专业软件扫描您的应用程序是否存在漏洞。 在 Envoy，我们倾向于每周扫描客户的 Web 平台，以确保快速发现应用程序漏洞。 至少您应该在每次发布到生产之前执行应用程序安全扫描。 当您引入新的应用程序漏洞时，等待 6 个月直到下一次渗透测试是没有好处的。

性能测试

性能测试通常用于确定您的网站可以处理多少流量、页面请求、并发用户和订单量。 这是一个比你想象的更难的过程，因为要准确地测试，你需要模仿真实的用户行为，而且你会知道，真实的用户会做很多不同的事情。 您能做的最好的事情就是模仿您的关键用户旅程，例如搜索、添加到购物车和结帐。 理想情况下，您希望在生产环境而不是暂存环境上执行负载测试，因为它会给您一个更真实的画面，但这也可能在测试期间的某个时刻使您的平台脱机。

大多数零售商倾向于每年进行一次负载测试，通常在黑色星期五或圣诞节等交易高峰期之前进行。 这可能导致的问题是，自上次年度测试以来，可能已经对应用程序进行了大量更改，其中一些更改可能对性能产生了增量影响。 如果年度负载测试显示与前一年相比性能下降，则很难确定过去一年中哪些变化或哪些变化导致了性能下降。 这也可能没有给您足够的时间在高峰交易开始之前解决性能问题。

为了解决这个问题，建议在每个新代码发布之前进行性能基准测试。 这些不需要在生产环境中执行，只要每个测试都在相同的环境中执行，因为目的是确定性能相对于上一个版本是增加还是减少。 这种方法使开发团队能够了解性能的任何增加或减少来自何处。 当然，这需要时间，因此会增加开发时间和成本

虽然上面的列表并不详尽，但您可以看到软件开发中的测试范围可能非常庞大和复杂。 每种类型的测试都需要时间和精力，您不应该只是假设所有测试都是按标准完成的，不收取额外费用。 非常注重测试的公司会将任何项目时间的 40% 分配给测试，这可能是一个非常惊人的数量。 良好的测试可以降低项目的风险，并且从长远来看可以收回成本，因为它将为您的客户带来更少的错误、更好的性能和更好的整体体验。