已有 116065 人访问
邓智群 ID.10000
阅读(5)
博客(177)
邓智群的博客
关于BUG流程相信大家都已经很熟悉了，并且用起来也得心应手，在此不再赘述。以下对BUG有一些小小的建议，主要针对我们日常工作中没有注意到的地方说的，建议虽小，但要重视噢。 　　对于研发经理： 　　当一个BUG被你审核通过，在派给开发人员时，你应该将BUG的状态改为“打开”。 　　审核BUG时你有最高权限，可以审核BUG的所有信息是否正确，所以最好重新审核一下我们提交的BUG严重程度，你有权修改哦。
472°/4684 人阅读/0 人点赞/4 条评论
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 　　用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试
548°/5476 人阅读/2 人点赞/1 条评论
前几天在测公司的外包项目（欧美）的时候，浏览器总是提示无法连接站点，于是下意识的用Ping来判断是否连通。刚开始以为是那边站点出了问题，但是其他人却能够正常访问，虽然公司内网有时不稳定，但也不至于长时间啊。由于需要亲自跑到机房重启“小锚”（路由的配置IP公司是保密的），次数多了也嫌麻烦（本人也不算很勤劳的那类人）。心想要是能有个工具来判断是否内网/外网问题，我也好偷个懒少走点冤枉路。哈哈，终于今天
400°/4009 人阅读/0 人点赞/0 条评论
有的软件没做性能测试，客户反馈了很多性能问题；有的软件没做性能测试，客户从没抱怨性能有问题；有的软件做了性能测试，客户依然反馈了很多性能问题；有的软件做了性能测试，客户从没抱怨性能有问题……这确实是个问题。其实我倒觉得问题不是要不要做的问题，而是怎么做，做多少的问题！请注意，没有任何一个软件不需要做性能测试，而是说需要程度到底有多高，这个需求程度决定了花多少精力去做，并且怎么做的问题。就算一个只有
616°/6069 人阅读/1 人点赞/10 条评论
缺陷报告是测试过程中最重要的输出之一，编写良好的缺陷报告也是提高软件质量的重要保障。清楚的缺陷报告对测试团队而言具有重要的意义： 　　● 可以减少被开发人员拒绝从而打回来的缺陷数量。 　　● 加快缺陷修复的速度。 　　● 增加测试人员测试能力的可信度。 　　● 加强开发人员和测试人员之间的团队合作。 　　● 更加高效地提高软件质量。 　　因此，测试人员在提交缺陷报告的时候，应该从不同的方面保证缺陷
453°/4517 人阅读/0 人点赞/2 条评论
测试人员一般使用两种形式的动态测试：自动化测试（通过编写代码来测试一个应用程序）和手工测试（使用程序的用户界面，手工输入数据进行测试）。 　　对自动化测试的评价可以说是毁誉参半。 　　说它不好是因为使用代码来进行测试，首先必须编写这些代码，这意味着测试人员也必须是一个开发人员。开发人员能否成为一个优秀的测试人员呢？很多人可以，也有很多人不行，这并没有什么定论。但是自动化的测试代码中也存在缺陷，这是
483°/4826 人阅读/0 人点赞/1 条评论
公司产品的安全检测，这次领导不知道咋安排的，居然派我一个测试人员过去。没有商务，没有网络工程师，更没有开发人员，如果人家问我数据流的过程，我该怎么回答哦？ 　　看来还是多看资料吧，我赶紧把公司需要检测的四个产品资料都弄到电脑里，一有时间就看，会的就不记录了，不会的，使用各种工具，把流程图画出来，然后发给公司的人员，让他们确认。 　　还好，检测提前完成，我躺在宾馆的床上，把出差近一个月来的事情仔细的
415°/4152 人阅读/0 人点赞/0 条评论
在测试执行过程中，经常会碰到一些不可重现或者很难重现的缺陷，特别是在进行系统的非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试、兼容性测试等。在非功能性测试过程中发现的缺陷往往是严重程度比较高的，例如：系统不稳定、系统在不可预测的时候重启等。假如软件产品交付给用户之后，在用户现场或者系统运行过程中出现由于这样的缺陷而导致的失效，那么将会大大影响用户对产品的信心。 　　虽然有的组织和项目可
610°/6019 人阅读/36 人点赞/9 条评论
在接口测试中，经常需要对系统进行分页查询测试。这次遇到了一个bug，就是有关于分页查询测试的。因为分页查询时，每次返回的都是第一页的数据，而我们的测试用例中没有考虑测试比较两页数据是否一致的校验点，因此出现了这个bug。随后，我从接口测试的角度仔细考虑了一下，同时吸取了一些功能测试的建议，感觉在进行分页查询测试时，需要校验的部分还真不少。虽然经常进行这方面的测试，但是还是很容易漏掉其中的某一方面。
614°/6112 人阅读/0 人点赞/3 条评论
也许是因为统计质量管理中发现了需求的问题占到整个软件缺陷50%-60%的原因，大家都习惯性的把焦点放在评审SRS这个重要的静态测试活动上面了。然而测试用例才是我们测试执行的最终依据——需求写的再好，测试用例没有写好，一切都是白搭！ 　　而这，恰恰是流程改进中必须浓墨重彩的一笔！下文同样取自一网友博文，并适当做了补充和修润（粗体部分）： 　　测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更
409°/4068 人阅读/0 人点赞/3 条评论