如何做论坛网站 知乎网站可以分为哪些类型

当前位置： 首页 > news >正文

如何做论坛网站 知乎,网站可以分为哪些类型,vi设计的简介,做网站 学什么对很多测试人员#xff08;尤其是对新手来说#xff09;在工作过程中最不愿遇到的一件事情就是#xff1a;在测试过 程中发现了一个问题#xff0c;觉得是 bug#xff0c;再试的时候又正常了。 碰到这样的事情#xff0c;职业素养和测试人员长期养成的死磕的习性会让她…对很多测试人员尤其是对新手来说在工作过程中最不愿遇到的一件事情就是在测试过 程中发现了一个问题觉得是 bug再试的时候又正常了。 碰到这样的事情职业素养和测试人员长期养成的死磕的习性会让她们觉得不能放过这个 bug但是重现这样的 bug 有时候需要花费大量的时间有的时候还有一些盲目性因为黑 盒测试的缘故很多内部状态是不可见的因此无法获取有效的信息来做跟踪效率较为 低下。 在实际工作中时间和进度摆在那里在经历了多次痛苦的失败尝试之后测试人员的处理 方法一般会有如下几种 1.向开发人员寻求帮助来重现 bug 2.当做一个 issue 报给开发人员。 可是这样的做法存在如下问题 1.开发人员责任心不够强不愿意花太多精力去求证这件事情常见的回复就是在我这儿 没事儿啊我也重现不了bug 关了吧。结果随后在生产系统上bug 又开始随机出现了。 2.就跟测试人员不擅长编码和调试一样开发人员并不擅长找出 bug。经过一番尝试以后 他们也找不出什么问题来常见的回复同第一条是一样的。bug 上线后又出现的宿命也是一 样的。 这时候真正的问题来了如何捕捉难以重现的 bug这件事儿对于测试人员来说就这么难 么 答案并不那么乐观重现“难以”重现的 bug 本来就是一件“难以”完成的事情。但“难以”并不 是不可能通过一系列的测试、分析方法我们是能够抽丝剥茧把绝大部分隐藏的很深的 bug 揪出来的当然有的时候你要考虑投入产出比但投入产出比不是本篇要考虑的本篇 只讲一些我积累的经验。 为什么不能重现 bug 最大的原因就是测试人员对被测物的了解还不够深入。 我曾经做过一段很长时间的收集和统计那些被称作过“难以重现”的 bug 最后都可以分为如 下几类 1.环境的变更造成了 bug 难以重现这里的环境包括了基础软硬件环境操作系统、网络、 存储、中间件、容器等等被测物自身发生了某些变更。环境的变更一般是由于多人共用 环境造成的也有少量情况下是系统内部或者时间触发的变更这类 bug 非常难重现。 2.没有找到真正引发 bug 的操作。这些操作往往是一些不怎么显而易见的操作测试人员在 不经意间完成而又忽略了这一操作以致难于重现 bug。 3.没有找到真正会引发 bug 的操作序列。很多 bug 的重现需要满足多个条件。在满足多个条 件的状态下你做了对应的操作bug 才会被触发。 4.Bug 必须使用特殊的数据才会出现测试人员没有意识到她使用的数据的特殊性。一种比 较难搞的情况是同一组输入在不同情况下不是不同的业务情况输入会被转化成不同 的数据。我曾经见到过这么个例子程序员用系统当前时间作为随机数的种子来生成 id但 是 id 设置的比较短一个存储的操作使用这个 id在一些情况下发生了冲突当时做功 能测试这种小概率事件耗费了测试人员大量时间也没有稳定重现还是在性能测试的阶段测 试了出来。 5.测试人员由于错误操作出现了误报这很常见。比如记得自己执行了 step3,其实没 有或者没有正确执行 step 却觉得正确执行了。 怎样对付这样的 bug 呢 我喜欢 James Bach 说的那句话测试就像 CSI。CSI 是 CriminalScene Investigation 的缩写 也是我非常喜欢的美国系列剧。 从我来看 CSI 的精髓在于仔细观察详细记录科学分析严密推理有序求证大胆 假设持续不懈团队协作和一点儿运气。找 bug 其实和 CSI 探员做犯罪现场调查没什么 太大区别。得知道你工作的重要性一点儿不亚于 CSI 探员。 仔细观察 第一件事情就是要观察观察你所做的一切操作和一切相关的系统反馈。在一开始观察的 重要性要远远大于思考通过观察你获得蛛丝马迹这些蛛丝马迹是你进行思考和假设的关 键输入。例如我在一次测试的过程中发现做某种操作的时候会相当慢极少数情况下还 报错过一两次当询问了开发人员后得知这个操作的后台实现步骤是先查看数据是否在缓 存中如果不在则从远端服务器请求数据。我抓住少数情况下会报错的这一现象仔细观 察它的出错信息后猜测报错并不是因为网络连接不稳定引起的而是由于远端服务接口实现 有问题引起的后来重新设计了测试用例果然找到了问题所在。如果不仔细观察出错信息 就会听信开发人员认为这是网络不稳定引发的正常 issue 而错过这个 bug。 详细记录 详细记录你的操作步骤及返回结果非常有助于回朔问题也有助于后续分析。准备一个 word 文档和截图工具有时候非常必要。另外在观察的时候你不仅要注意被测物的最终返回 还需要观察过程中的一些中间状态往往这些中间状态提供的信息才是解开问题的关键。这 些中间状态一般会被记录在 log 文件中因此知道你的被测物是如何记 log 的log 被记录 在哪里非常重要。log 给了你另外一个看系统的角度。log 是有级别的如果级别可以动态 调整在找比较难找的 bug 时可以将 log 记录的级别调至最低DEBUG 级让它们记录 更多内容。利用系统的错误转储文件比如 linux 的 core dump 文件windows 下也有相应 的记录转储文件的方式分析也是个不错的办法需要较高技术能力但一般建议测试人 员把这些转储文件交给更专业的开发人员来分析。 除了 Log如果能有监控信息也要查看他们。比如系统提供的监控平台监控日志应用 自己的监控平台、监控日志如果有的话采用一些外部技术手段截取一些中间状态信息 如使用 sniffer 抓取通讯包使用 Fiddler 截获 HTTP 报文内容给运行程序插桩来查看内存 堆栈线程函数被调用情况等情况如 Jprofilegpertool 等等。 科学分析 对于黑盒测试人员来说科学分析意味着你需要有一定的分析策略。我们需要采取一些形式 化的方法来完成我们的分析。基于我的统计缺陷难以重现有很大一部分原因是因为“没有 找到真正引发 bug 的操作序列“。测试人员不可能像开发人员那样去跟入到代码内部设置 断点调试程序他们主要的测试方式是直接来操纵被测物并从外部观察被测物状态的改变。 显而易见“状态转换图分析法”是测试人员对付“难以重现 bug”的最强有力武器之一。状态 转化图能够帮助测试人员很好的选择操作路径并且知道这么做有什么意义。“状态图转化 法”绝对是测试人员值得花时间学习和研究的一种方法你可以走的很深也可以研究得很 远可以从 MBT 的方向进行拓展限于篇幅这里就不展开了。在这里推荐《探索吧 深入理解探索式软件测试》这本书它的第八章对“状态转换”做了非常实用的描述。 上文分析的让 bug 难于重现的另一种原因是没有找到“真正引发 bug 的特殊数据”。 我的常用做法是这样的 1.画出系统交互图要真正弄清系统的边界这很重要并识别出每种交互会有什么样的 输入、输出数据和中间数据识别出这些数据的规约和格式这样你就不会对数据有遗漏。 2.考虑数据的等价类、边界值对这些输入进行组合分析数据之间是否有耦合关系如果 有耦合关系弄明白关系是什么设计违背这些关系的用例最后采用组合测试工具初步生 成测试集再人工选取最可能出问题的数据集直觉有时候非常管用。 严密推理 天马行空对测试人员很重要但是当你试图重现一个 bug 的时候这并不是一个非常好的方 法。抓住了蛛丝马迹你就要推理是为什么产生了这种蛛丝马迹。限于工作性质测试人员 更多的会从业务完整性、数据完整性、业务正确性、数据正确性等方面考虑问题。但是 如果测试人员对被测物的 IT 架构有比较深入了解的话推理的范围会扩大到技术实现层面 如多线程可能引发的问题网络引发的问题excepiton 处理不当引发的问题全局事务 设计不当引发的问题内存泄漏引发的问题数据库表设计不合规引发的问题等等等等这 些会让你的分析推理能力如虎添翼。当然如果限于条件测试人员不具备这类能力则应 该在适当的时候请求开发人员协助。 有序求证 这里只有一点需要注意。那就是在求证的过程中不要打散弹枪按照你的推理一步一步的 来一个个推理的来验证一次只引入一处修改。这样才能让你的捕虫网编制的足够细密。 大胆假设 有的时候看似八竿子打不着的东西竟然存在着千丝万缕的联系而你获取信息的过程总是 一个由少及多的过程一开始这些联系是无法被识别出来的。通过推理逐步验证你慢慢 的识别出了大部分内在联系。但有时候这种逐步推进的工作也会有局限性工作如果出现了 瓶颈你试遍了你所有的假设都没有重现 bug这时候就需要发挥一点儿想象力了天 马行空这时候从一定程度上又变得有用起来当然天马行空也不是无厘头还得靠我们所谓 的“灵光一闪”这号称是潜意识在帮助你。CSI 的剧情中不也总是出现这种柳暗花明的桥段 么 坚持不懈 话不多说有的时候你差的就是那么一点儿点儿耐心。 团队协作 很多情况下重现 bug 不是一个人能搞定的。我们需要测试环境 ready测试数据 ready各 种监控、分析工具 ready各种不同的视角开拓思路、加深对被测试物的认识。这是 team work独行侠有时候很管用但是终究有极限。这就是为什么 CSI 是一票人在做而不 是一两个人在做。 一点儿运气 说实在的有的时候重现 bug 就是靠运气你不得不承认这一点。事实上很多美好的事情发 生都得依靠运气比如中彩票。要记住的一点是运气是建立在你不懈努力的基础上的。如 果你一张彩票不买你肯定什么也中不了。但如果你坚持买上几年中个五块十块甚至二百 也不是梦。 Let it go 全试过了连运气都没有。你只能放手回到最上面我说的那两条了找开发来帮忙或者 给开发报 issue。btw即使不能重现 bug也应该给开发人员提供更多信息如 log、dump 文件、监控记录、屏幕截图等。做一个负责人的测试人员把烦恼真实的留给下家这很重 要 其实上面的大段论述是站在测试人员角度上来看的。我也写很多代码作为一个开发人员哈 哈我查错的方式一般是 1.先能稳定的复现错误。这一步最难 2.设桩打印出一些中间状态来分析看到那一块儿错了。 3.摘除不相干的代码慢慢迭代定位错误。 4.如果发现调用第三方依赖跟你想的不一样先读文档然后再测试第三方依赖。有问题再 想办法。 5.良好的程序设计和单元测试覆盖度才是不二法门会让你的调试变得简化的太多。。。用 过都说好 6.测试工作的确增强了我排错的能力。coding 的同学都尝试做几个月测试吧。会有相当大的 好处。