了解场景法稳定性测试场景关键点场景设计的关键词就是用户，产品或系统推向市场都是为了能够让用户满意，所以在设计稳定性场景时，要从用户使用角度思考设计相对于的测试场景；重点功能的测试保证，间接也是为了用户的满意度。场景示例Tips从用户使用及重点功能出发，考虑特定场景，以业务的角度去设计稳定性测试场景，有任何问题，反馈给我们吧~
症状起床后拿起手机，微博->论坛A->论坛B->知乎->人人，大概20分钟。工作中大概每隔半小时刷一下微博或论坛，点进去看两分钟再切回来。睡觉前拿起手机，微博->论坛A->论坛B->知乎->人人->草榴（-_-），大概30分钟。原因智能手机带来的极其便利的信息可访问性平板和智能手机使互联网的可访问性（accessibility）提升了至少两个数
引子多一点简单的选择，少一点复杂的填写，是提高用户体验的一种方式。下拉列表就是一种秉承着这种理念而生的控件。初来乍到，自我介绍下拉列表，也被称为下拉式列表、下拉框、下拉式选单、下拉菜单等，是一种被广泛的应用在计算机应用和互联网交互设计中的一种表现形式。常见的用法是，当用户点击一个选单时，选单会向下延伸出具有扩展选项的一个列表选单，从而用户可以从延伸的选单中选择最佳的选项。这样的控件有着许多的好处，
一、定义我的观点稳定性测试是在保证基本功能完整正确的前提下，软件或系统在一定时间或压力下，检验功能稳定运行的情况及性能劣化趋势，以减少系统或软件崩溃的发生。二、关注点我的观点稳定性测试直接的关注点，就是软件或系统功能特别是用户常用功能的稳定性；其次关注的是性能指标的变化情况；在测试过程中，我们需要特别考虑多线程进程及不同测试环境的问题。三、后续内容我的观点我们将依次从上图中的8个方面来介绍稳定性测
在测试过程中，不免会遇到开发人员因为一些原因不想修改个别bug的情况。那一般遇到这种问题时，我们该如何去推进开发修改bug呢？我们先来分析下到底会有哪些原因会导致开发不修改bug1、开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。2、工作流程方面的原因，例如开发有更高优
设计的方法这本书不管是UI、UX、PM、Planner桌上都该摆一本，不知道报告/企划书怎么写的时候拿来跑一下实验很好用。从中我认识到「狩野分析」，参考UX，设计的方法（项目初始）这篇文，当时预期狩野分析适合用在项目初始、分析这个功能要不要做。最近简单地跑了一遍，来写点笔记...步骤虽然多，但只要会加减乘除就行了。不加新功能就会死恐慌症很多人都晓得「少就是多」，也都知道越简单越容易被理解和操作，却
说到QA，通常指的是质量保证（QualityAssurance）工程师，但我更喜欢定义敏捷中的QA为质量分析师（QualityAnalyst），主要基于以下几个方面的原因：质量保证更偏向于工业说法，称参与软件测试的人员为质量分析师感觉更恰当；质量保证师更多的还是把测试当作软件质量的最后把关着、看门人，而敏捷中的QA更多的是建议提供者而非看门人，把QA称为质量分析师更能体现敏捷中团队对质量负责的原则
当项目成员越多，我越不推荐敏捷开发，原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前，就跳下去玩敏捷开发，那和比通灵还惨，通灵起码还有个目标物在前面，搞不清楚状况的人只能陪他跳世界迷雾开地图了。"敏捷开发-MBA智库百科"最下方有段「对敏捷开发的误解」。可顺便参考"敏捷软体开发-维基百科"。误解一：敏捷对人的要求很高说高不高啦
很多开发人员在开发软件时,会说他们的工作很难估得很准,因为spec常常更改,或者spec不明确,所以无法确保要做多久.哪测试呢?测试的工作就能估得很准吗?很多人会以为开发人员都已经写好了,测试人员只是把testcases跑完就好,哪有什么不确定的.是这样吗?让我们看下去....假设,我们要执行40个testcase.每个testcase需要执行2分钟.如果我们遇到bug,测试人员需要花6分钟来确认
前文所述两种风格的单元测试都在微服务中发挥着重要作用服务通常是一个由管道和协调代码包围富领域。域逻辑往往表现为复杂的计算和状态转换的集合。由于这些类型的逻辑是高度基于状态的存在，试图隔离这些单位的意义不大。这意味着尽可能，真正的域对象应该用于所有需要测试的单元。至于管道代码，则既难以将其与外部模块隔离，又难以根据状态变化进行测试。正因为如此，使用测试替代（testdoubles）更为有效的。这一级
热门文章