做搜狗手机网站优化,模板网站建设公司电话,变更icp备案网站信息查询,免费微分销系统作为开发人员#xff0c;我们应该遵守这样一句话#xff1a;“质量不是来自检查#xff0c;而是来自生产过程的改进。”——爱德华戴明
“测试即代码。” 太多的组织将任何未编码的东西视为一次性的。很明显#xff0c;测试是必不可少的#xff0c;但我们一次又一次地发现…作为开发人员我们应该遵守这样一句话“质量不是来自检查而是来自生产过程的改进。”——爱德华·戴明
“测试即代码。” 太多的组织将任何未编码的东西视为一次性的。很明显测试是必不可少的但我们一次又一次地发现团队将测试自动化和相关材料视为二等公民。测试是用户行为的文档与产品组织产生的需求密不可分并在虚拟层面与用于创建功能的代码相连。
如果它提供了价值就应该对它进行版本化、维护、照顾和尊重就好像它是产品本身的核心功能一样。这应该包括测试用例规范、设计和技术文档以及错误报告。
“时间扼杀信心。” 大多数人可能会认为在一个功能上花的时间越多就需要花越多的时间来完善、完善、测试和探索它。与直觉相反这适合“旧世界”风格的开发有一个测试环境、一个阶段环境以及围绕用户将如何与之交互的许多宏大假设。
这些法则试图将SDLC系统生命周期引入云计算世界微小的、渐进的变化在推广到整个世界之前先向有限的受众推广。“键盘在10分钟内完成生产”——这会带来更快的反馈、更少的逃脱和更高的信心。以下是编码新世界的10大法则。
1.人人皆测试 团队的每一位成员无论使用什么流程无论生产什么产品无论哪个行业——每个人——都对产品的质量负责。产品、工程、测试甚至周围的功能客户支持、销售、营销、业务开发、早期访问测试版客户、高管——每个人都在测试。
2.度量风险而非覆盖率 假设团队甚至可以就“完美”的工作定义达成一致那么仅仅追求完美就会导致注意力从最重要的事情上转移关键缺陷转移到生产中对业务的风险。 在你开始担心所有功能的全面覆盖之前先痴迷于对你的业务最关键的六个用户流。
3.测试的是“金钱”想要什么 每个业务、每个部门和每个团队都部署了一组核心功能这些功能对收入的影响比其他功能更大。或者每个团队都必须维护一组影响较小但仍然必要的功能。在考虑其他因素之前将测试工作重点放在影响收入的部件上。对于电子商务将结账流程优先于用户配置文件。对于财务优先考虑安全和资金处理工作流程而不是信息页面。
4.广度比深度更重要 浅层测试产品的所有区域比深层测试产品的某些区域更重要。业务逻辑的深度、多元组合旨在找到最模糊的边缘案例这可能会在其他高优先级领域遗漏更明显的缺陷。
一旦达到了广度那对某个特定功能的深度是多少请参考法则2。
5.唯一完美的信号是用户的信号 在你的用户与你的软件交互之前你所做的一切都是理论性的。
测试就是模型。它们是基于从过去用户行为中获得的信息的用户行为的近似值。我们从测试中得到的信号可能因环境、测试本身的逻辑缺陷、无意识的偏见甚至之前模型中的错误数据而存在缺陷
了解用户使用软件时会发生什么的唯一方法是观察用户使用软件后会发生什么。生产分析的用户旅程应与测试覆盖率相关联以评估测试策略的有效性。
此外考虑到用户体验中包含的元素甚至不会被视为bug也可能不会反映在分析中。当构建变为绿色时并不意味着就是工作的结束。
6.代码在可测试并经过测试之前是不完整的 可测试性是对代码的各个部分进行检测的行为。如果不允许对这些信号进行轮询和解释很难判断正确的行为。这导致了不成比例的额外工作这增加了发布周期的时间并将焦点从客户体验上转移开。时间将会扼杀信心。
7.每项测试都应导致明确的行动 如果不知道当测试失败时该怎么办无论是从测试的角度还是从产品的角度那么测试就没有提供价值。
这通常是由于测试步骤太多或者产品没有提供足够的失败信息包括没有充分的可测试性参照法则2。
8. 始终测试高层级 软件测试有“层”从高到低生产、UAT、功能、集成和单元。 高层测试对于强制不同团队开发的不同组件之间的交互至关重要但边缘案例的细节可能会向下移动到较低层。这些较低层测试具有较少的依赖性避免了昂贵的管道配置/编排并且运行速度比较高层测试更快。
例如UI测试应该仅用于确定用户界面是否能够呈现API的输出。如果通过同一个UI重复测试业务逻辑则应该将这些测试中的大部分“向下”移动到API层。
9.从不链接测试 所有测试都应在不考虑任何其他测试状态的情况下执行。测试数据的管理应确保每个测试都生活在自己的独立场景中并且不能被另一个测试更改。
测试应该是原子化的、自主的。
10. 首选最紧密的反馈回路 所有测试都是反馈回路。他们从特定的角度贯穿产品并向特定的人或团队提供反馈。最严密的反馈回路是尽可能多地切断以测试所讨论的特定操作的回路。测试一个比必要的更宽的循环会引入一些变量这些变量可能会混淆你从测试中得到的信号。
这十条法则并不完整测试领域还有很多限定守则而且使用这些法则时的上下文环境也很重要。也许某次测试会打破一两条法则那也无妨不必把它们奉为金科玉律重要的是寻求持续改进而非特定一次的完美。
