软件测试——易用性测试

软件测试——易用性测试

例子：微软的硬件设计

微软硬件部门所做的一项调查显示，办公中使用可靠而优质的鼠标和键盘，将有助于提高员工的工作效率和士气。

调查表明，每三个办公室员工中，既有2个人每天需使用电脑工作至少6小时，约25%的员工每天使用电脑工作8小时。

当员工在电脑屏幕前花费的时间越来越多时，鼠标与键盘的质量和舒适度就起到了关键的作用。

易用性测试是一种黑盒测试技术，主要包括召集可以代表目标用户的无偏见参与者，并要求他们执行特定的任务来测试你的假设。测试的界面可以是纸质界面，也可以是屏幕模型（mockup）或MVP。可以根据以下参数，揭示用户对你的app或网站是否满意

1操作流程

2导航和布局

3速度

4内容

用户通过封面来判断一本书...更确切的说，一个网站依赖其设计。比如布局,一致性，排版，色彩和样式之类的元素都会影响到用户对你的网站理解以及你的项目形象。这对主页最重要的，大部分新访问者都会浏览首页。所以请在那里提供这些核心要素：

1网站名称

2网站的有价值的主张（比如说，用户将从使用中得到什么好处）；

3与用户相关的主要部分导航。

链接应该是什么颜色？第一要义就是差异（对比）：链接要足够暗或亮度已和背景色相对照。其次，它要能从其他文本中凸显出来；图下链接红色
搜索框到27个字符能够满足90%的查询。
空白同样让内容更加清晰易懂。

一份研究发现段落之间和左右间距可以增进理解20%左右。

用户会发现更容易聚焦和处理使用大空白的内容。
当你的产品提供详细的信息，但是不要掉进用太多文字炮轰用户的陷阱。让这些信息更易于理解。

通过将文字分成小段并使用大量的子标题让页面可浏览，为你的产品添加大量的图片，并使用合适的语言：不要使用术语，你的用户可能不懂。
           功能性：适合性，准确性，互操作性，保密安全性，功能依从性。

           可靠性：成熟性，容错性，易恢复性，可靠依从性。

           易用性：易理解性，易学性，易操作性，吸引性，易用依从性。

质量

            效率：时间特性，资源利用，效率依从性。

            维护性：益分析性，易改变性，稳定性，易测试性，维护依从性

            移植性：适应性，易安装性，共存性，易替换性，可移植，依从性。
如何进行易用性测试?

A.制定测试计划

步骤1 -确定测试范围和原因。

范围：你在测试什么?比如范围是测试原型、导航、内容等。

目的：关注点和用户目标是什么?比如测试目是“用户可以导航到这个重要信息吗？”或“用户在当前位置会找到搜索框吗?”

步骤2 -创建测试脚本

时间表、持续时间和地点：你将在何时、何地进行测试?测试持续多久?

测试期和设备：描述测试期(包括长度)和设备要求，以便测试顺利进行。

角色：包括将参与易用性测试的工作人员列表，以及每个人将扮演的角色。

步骤3 -招募用户

参与者：指出你想要进行易用性测试的目标用户数量和画像。

如果你已经有了用户：识别那些积极参与你产品的人，并发送短消息/电子邮件。

如果你没有用户：想想你的目标受众聚集的地方，无论是面对面还是在线。从特别感兴趣的俱乐部、朋友的朋友、聚会、Reddit，在线论坛等找出来。

步骤4 -创建测试场景

描述将在测试期间使用的场景。场景包括用户故事（user story）和描述达到用户目标所需完成任务的上下文。场景不应该是通用的，应该能够测试你的假设。

步骤5 -确定测试的度量指标

效率： 完成任务用户的百分比

任务时间：参与者完成任务所花费的时间。

非关键错误：参与者可以从中恢复，并完成任务的错误(效率较低)。例如，打开错误的导航菜单项

关键错误：参与者无法从中恢复，并不得不放弃任务的错误。例如，无法找到“立即购买”按钮。

无错误率：没有任何错误完成任务参与者的百分比。

主观评价：这些评价是参与者自我报告的满意度、易用性、查找信息的易用性等评价，参与者用5到7分的李克特量表（Likert scale）来进行评价。

喜欢、不喜欢和建议：参与者提供他们最喜欢这个网站的地方，他们最不喜欢这个网站的地方，以及改善网站的建议。
易用性测试不仅针对应用程序，而且还包含用户手册等系列文档的测试。

应用程序的易用性测试包含：安装测试

                                               功能易用性测试

                                               界面测试

                                               辅助系统测试

用户界面测试

用于与软件程序交互的方式称为用户界面或ui

虽然ui各不相同，但是从技术上讲，它们与计算机进行同样的交互——提供输入和接受输出。

优秀ui构成：符合标准和规范

                     直观

                     一致

                     灵活

                     舒适

                     正确

                     实用

多年游戏测试经历之谈！ 全面且要有专长

作为一个在游戏行业摸爬滚打多年依然灰头土脸的游戏测试、谈谈自己的工作经历吧。

15年6月份毕业，由于游戏测试的门槛很低(和工资一样低)，所以来帝都后，很轻松拿到入职offer，7月份入职于第一家游戏公司，是某大型音乐舞蹈类游戏的研发公司，线上运营业绩很棒，现在还有不错的运营状况吧。

7月份入职后，初的一个月里只是让你熟悉测试工作会涉及到的文档啊、工具啊之类东西，以及如何提交bug、建议等。

之后leader安排一个老同事带我去跟游戏里的新功能，了解策划案，熟悉项目工作流程，熟悉测试用例的执行和编写。大概2-3个月的样子吧，跟别人一起做了2-3个功能的测试。leader看我表现不错，让我自己去测单独的小功能。

大概做了两个月，跟了2个小功能(活动啊之类的)和一个大点的功能之后，要立一个新项目，需要从这边抽调人手去那边，但这边的老同事都知道这项目是个坑(必死的那种，公司也是死马当活马医)，所以都不愿意去。但我一个新人不清楚啊，同意过去了。

在那边呆了半年多，从测试组成立到后组建完毕(加上测试组长总共仨人)用了不到两周时间，然后开始了蛋疼的炮灰之旅。初测试组总是被忽略，策划开会宣讲新功能总是不叫测试，项目经理(PM)呢也是程序出身，对于项目管理经验很少，所以测试组很蛋疼。之后我跟组长反应了公司的流程之后，他才主动找PM说以后开会需要叫上测试组。
之后开会有测试的一席之地，但策划的水平真心让人捉急，策划案简陋到不能再简单，不过基本上来说该有的还都算有了，勉强过关(要在之前的项目组这种策划案是不能通过策划内部的评审的!)之后是正常的测试工作流程：了解策划案，编写测试方案，评审测试方案，编写测试用例，用例执行，后续跟进提交的bug直至解决，以及针对现有功能提出建议之类的。

呆到16年的8月中旬，项目挂了，回到原来的测试组。虽然在那个项目没有太多出彩的地方，但回去之后，每周一次的例会上，我都能提出一些常见的工作中的问题，或者是分享一些功能的测试经验。当然这也是leader所期望搭建起来的一个交流平台，但每次例会都只有我一个人发言。当然这点leader也是看在眼里，对我大加赞赏(可是没提涨工资的事情!自己也没提，菜鸟应该都会犯这个错误吧!)

16年的年会结束后，也是18年的2月份吧，有了离职的想法，原因很简单：工资很低，干的活却是比我高一级的活。当然自己也没敢跟领导提涨工资的想法。只是跟领导谈过离职的想法，组内leader跟我谈了3次，测试总监跟我谈了2次，而且总监每次跟我谈都给我涨了薪资(用总监的原话：我一个月内给你涨了两次工资!啊!)，但涨后的工资依然不理想，而且职级也没升，所以果断在6月份离职了，也这样离开了自己认为是天堂的地方。

后面又尝试做过半年的游戏开发，依然是因为工资不高，而且在那边学到的东西太零碎，再加上不被重视，离职了。

之后辗转流离，参加过游戏开发的培训班，被坑过，18年的7月份又找了一份测试工作来做，当然也是有在游测行业希望有所作为，自己也对这行有兴趣吧。
一些建议和对行业的看法：

1.测试行业虽然在在国内开始受重视，但是现在小公司，游戏测试几乎是呼之则来挥之则去，所以做好这方面的心理准备，虽然薪资不会太低低，但是如果是开发转测试的话，会高不少。

2.游测比软测更枯燥无味，而且接触到的东西可能更少，游测更多是功能测试，性能、自动化、以及其他相关的测试短期内应该是很难接触到的;职位的可替代性更强，很多技术啊工具啊几乎用不到，完全看自己的项目是否需要，需要才能用到，不需要，可能你都不知道会有这样的东西存在。

3.必须系统学!做好这行，需要有广阔的知识面，但不用每一个知识点都特别深入，但好有自己专长的地方，比如你对于偶现bug的复现方法更实用，或者你能单独开发测试工具让大家使用，或者你对于游戏有不同的看法等等。

4.按照你说的，你的发展方向是测试转策划、测试管理等等，其实这也是很多游测人选择的职业规划，毕竟游测很枯燥工资低不被重视，而且组长啊等管理职位几乎很少有空缺，晋升空间小。

5.看个人能力。其实游测也有工资高的，有的十分勤奋(比如我第一家公司带我的师傅，经常加班到很晚，兢兢业业没的说)，有的嘴皮子好使(哄好领导表现好能顺利升职)，有的只会埋头苦干却不懂搞好人际关系(比如说初的我)。总之，你的付出肯定会有回报。

小马过河的故事谁都知道，所以，别纠结别犹豫，找到自己喜欢的，去努力去实践吧!

6.好去大公司，能接触到的流程更好，同事的工作能力也更强，当然也都是相对的，对以后的发展也会有好处。

了解更多关于软件测试的内容，欢迎加我创建的球球裙： 1017539290

软件故事线是什么意思

你好，
软件故事线（Software Storyline）是指在软件开发过程中，将软件需求、设计、实现、测试等环节串联起来，形成一个完整的故事情节。它从一个用户的需求出发，讲述软件的发展历程，并最终实现用户的期望。
软件故事线可以看作是一个软件项目的叙述或剧情，它可以包含多个故事点（Story Point），每个故事点可以代表一个独立的用户需求或任务。软件开发人员可以通过故事点来进行任务管理和进度跟踪，同时也能让产品经理和用户更好地理解软件开发的进展情况。
软件故事线通常由以下几个部分组成：
1. 需求故事：描述用户所需要的功能和需求，以用户的角度来描述。
2. 设计故事：根据需求故事所描述的需求，设计开发的解决方案和架构。
3. 实现故事：基于设计故事所提出的解决方案，实现功能的开发、编码和测试。
4. 测试故事：对实现故事所开发的功能进行测试，确保功能的正确性和可用性。
5. 集成故事：将各个实现故事集成在一起，进行整体测试并修复问题。
6. 持续改进故事：通过用户反馈、迭代和优化等方式，不断提升产品的质量和用户体验。
软件故事线在软件开发过程中起到了非常重要的作用。它帮助开发团队更好地理解用户需求，从用户的角度出发设计和开发功能；同时也帮助开发团队更好地管理任务和进度，提升开发效率和质量。

求软件测试计划的详细案例

测试计划
测试概述:
测试背景:
测试手段:
手工测试
测试范围:
功能测试 界面测试 接口测试 容错测试 安全测试 性能测试 稳定性测试 恢复测试 配置测试 安装测试 文档测试 可用性测试
测试环境:
软件环境
操作系统
被测软件 其他软件
硬件配置
PC 配置：CPU
内存 ：1G
外部设备
测试策略:
一．功能测试
1．菜单点击相应标题菜单，验证其功能是否能实现
2．工具栏 点击相应工具栏，验证其功能是否实现
3．按钮
4．快捷键
5.下拉框
6．单选按钮
7. 复选按钮
8.切换按钮
9.编辑按钮
10.触发键：
11．链接：
二 .界面测试 点击相应按钮是否满足UI设计
1登陆界面
2总界面
3 输入界面
4处理界面
5输出界面
6提示界面
三. 容测测试 是否满足数据库设计要求
主键容错
非空容错
四、接口测试 点击相应的菜单 按钮 工具栏按钮 弹出相应的接口界面，验证其功能是否能正确实现 模块之间的调用 是否满足概要设计的要求
1.内部接口
2.业务流程测试
3.外部接口
五、安全测试
1.应用级安全测试
2.系统级安全测试 点击相应菜单，验证其功能是否实现
六．性能侧试
七．负载测试
八.稳定性测试
九 .恢复测试
十.配置测试
十一. 安装测试
十二.文档测试
软件需求 概要设计 测试计划 测试用例 技术文档的 质量通过评审 来保障
在线帮助
安装手册
使用手册
七.测试进度安排
工作内容 开始时间 结束时间 责任人 提交的结果 备注
编写测试计划
设计发短信测试用例
设计资费测试用例
搭建测试环境
集成测试 执行发短信测试用例
执行资费测试用例
集成测试分析报告
系统测试 性能测试
恢复测试
配置测试
系统测试分析报告

软件渗透测试，有了解软件渗透测试的吗（安全测试方面）？可以介绍一些测试方法和测试流程吗？

安全测试、渗透测试、安全渗透测试。乍一看到这么多相似的概念，感觉晕晕的。今天主要沉淀一下自己对渗透测试的理解，同时希望对大家也有所帮助。
首先，安全测试是侧重于应用程序所面对对安全威胁而进行的有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。目的并不最终证明应用程序是安全的，而是用于验证存在哪些安全漏洞，来确保应用程序的安全。
渗透测试是以黑客的角度，由企业外部或在企业内部对目标网络环境作深入的安全探测，从外部或内部网络收集系统的相关信息，探查出逻辑性更强、更深层次的漏洞，预先找出企业脆弱的环节。渗透测试的目的不是为了确认功能，而是确认不再存在不安全的功能。渗透测试最简单直接的解释就是：完全站在攻击者角度对目标系统进行的安全性测试过程。
通过对安全测试和渗透测试概念和目的的理解，安全测试和渗透测试的关系是：安全测试包含部分渗透测试。
那如何来理解渗透呢？最开始看到这个词，我就想渗透什么呢？从哪开始渗透？渗透到哪去？我先介绍下渗透（Fuzz）是怎么来的。Fuzz这个名词来自于Professor Barton Miller。在1986年一个风雨交加的夜晚，他登陆一台自己的主机，不知道怎么回事，信号通过猫传到主机上，雷电一闪，把里面的高位变低位，低位至高 位了，结果到了主机以后改变了。Miller 由此想到了利用“crash、break、destroy”的方式来进行软件测试的技术——Fuzz。这个故事让我想到一个有点恐怖的场景，就是毒药从嘴里一直渗透到胃里、心里。最后中毒身亡。
接下来，解决前面的三个疑问。从哪里开始渗透呢？——软件及环境中可能发生变化的部分。从安全角度来看，环境、用户输入以及内部数据和逻辑是此类变化可能暴露出安全问题的主要位置。环境包括文件、应用程序、系统资源和应用程序使用的其他本地或网络资源。所有这些都可能成为渗透的入口点。渗透什么呢？——malformed数据。这个数据有可能是一个文件，有可能是一个数据包，有可能是测试表里面的一个项，有可能是临时文件里面的一个东西，总之是malformed这种非正常的数据。渗透到哪里呢？要考虑到应用程序本身执行的流程，考虑case放进去，能够放到多深，逻辑放到多深，就要非常了解应用程序内部结构。渗透测试是一个渐进并且逐步深入的过程。
渗透测试一定是黑盒的吗?很多技术人员对这个问题都存在这个错误的理解。渗透测试不只是要模拟外部黑客的入侵，同时，防止内部人员的有意识（无意识）攻击也是很有必要的。这时，安全测试人员可以被告之包括代码片段来内的有关于系统的一些信息。这时，它就满足灰盒甚至白盒测试。

软件测试有前途吗？

软件测试工作有前途。
软件测试就业前景挺好的，目前IT行业对于软件测试方面的人才需求是非常大的，软件产品的质量对于一个软件来说是攸关生死的，各企业越来越重视软件产品质量，而软件测试的工作就是让软件质量越来越好，还有就是软件测试的工资待遇是非常好的，和其它职业相比，月入上万要简单的多，随着时代的发展，软件也越来越普及，所以人才需求量和前景都是不错的。
软件测试是软件开发过程的重要组成部分，是用来确认一个程序的功能或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。最直观的目的肯定是通过对软件系统或程序的测试，发现其中的错误，也是目前和未来比较热门的一个行业。

软件测试中的测试依据到底是指什么？

关于软件测试的问题我们在前几期的文章中讨论过很多次了，尤其是对于需求文档的结构与组成方面的内容更多。今天，我们就一起来了解一下，软件测试中的测试依据到底是指什么。希望通过对本文的阅读，大家对软件测试有更多的了解。

软件测试基础理论中，我们提出了一个概念，叫做‘测试依据(testbasis)’。从字面意义上理解，测试依据就是就是我们测试可以依据它来进行测试分析，以及用例编写的文档或者信息;他被用来指导我们的测试，我们可以从中提炼出‘测什么’‘怎么测’这样测试根本性问题的答案。没有了测试依据，测试工作就将无从下手。

说到测试依据，我们直接会想到的就是需求文档了，根据项目特性的不同，他有可能呈现为不同的格式：比如需求规格说明书式，又比如原型图式等等。而根据需求文档内容分解和描述形式的区别，他又有可能呈现为用户故事型(UserStory)或者产品需求文档型(PRD)。

我们始终要明白一件重要的事情是，测试依据，其实指的并不仅仅只是需求文档。从本质上说，他应该包括所有可以指导我们测试的信息。下面我们就来一一探讨一下，都有哪些信息我们可以拿来用作测试依据，以及怎么来使用它们。

一个是开发部门的设计文档，包括我们在软件生命周期中提到的架构设计，详细设计阶段的产出。

开发部门在进行上述设计工作的时候，有可能会产出比需求阶段更丰富的文档，比如架构设计图，算法设计图，模块的详细设计说明书，接口定义文档，数据库设计说明书，界面设计线图等等等等。

实际工作中，你会发现，开发部门产出的设计文档往往会包含对产品更详尽，丰富的定义信息。基于这些文档提供的信息，我们就可以更进一步，深层次的确定我们测试所需要覆盖的范围和内容。

当然，理论上而言，这些设计文档只是开发部门为了实现需求而做出的分析性产出，他并不一定完全匹配初的产品需求甚至用户需求。我们使用这些设计文档的前提判断是：开发部门与需求部门有足够的沟通，他们的产品设计是符合需求的。北京电脑培训建议为了确认这一事实，我们测试人员可能需要来回往返于开发团队和需求团队(或用户)之间来寻求肯定的答复(一个典型的状况是，需求团队对于用户需求的解读并不够细致详尽，事实上他可能根本没有思考到相应深刻的程度，而对于开发通过主观判断给出的设计，他也许并提不出什么意见，只能表示认可)。

不懂编程也能学软件测试吗？

首先，是否需要编程技能与测试人员从事的测试工作种类有极大关系，相信很多人都听过微软曾经聘用一名家庭主妇来测试Windows操作系统的故事。实际上，霍营电脑培训发现软件测试分为：功能测试、需求测试、性能测试、兼容性测试、稳定性测试等，这些类型的测试基本不需要有编程基础。因为这些测试主要是从实现结果上去分析系统存在的问题，而不是过程。而对于分析代码的白盒测试，以及开发测试工具才要求测试人员有较强的编程能力。

其次，真正初、中级测试人员参与的都是第一类测试，也就是说与代码实现过程的关系不是很紧密，他们所关注的主要是需求和流程方面。对于高级测试人员，才会涉及到具体的代码，他们所关注的主要是测试工具的开发，以及对现有代码进行单元测试等工作。

再次，软件测试工程师的未来职业发展至少两条路线。一条是走技术加管理的路线，也就是说当你达到中级测试工程师的水平后，有了一定的行业背景及管理经验，就可以从事管理类的工作，比如担任测试经理的工作。这样工作的重点就集中到项目管理及人员分配上，所以就更加弱化对编程的要求。另一条是走纯技术路线，就是所谓的高级测试工程师，要求这类人有较强的编程能力，可以设计开发自动化测试工具。

懂编程就一定能做测试吗?答案是不一定的。从就业市场来看，许多开发人员没有对测试行业有个系统的了解，事实上，想要成为一名合格的软件测试人员，不仅需要理解和掌握测试理论、标准和规范，还需要根据不同企业的产品特点，熟练操作一种甚至多种测试工具。如果对测试行业没有系统的了解得话，是很难做好软件测试的。

【经验分享】软件测试用例管理

本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。

有人说：测试用例还不知道？不就是描述测试步骤吗？

这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。

专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。

虽然从格式上来说，基本就定型了：

关于这部分，网络上的教程只多不少，就不赘述了。

只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。

就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。

写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。

由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。

把这些结构化好的测试点文档化，就是我们所说的测试用例了。

所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。

测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。

但随着敏捷时代的兴起，有一种声音开始冲击这种认知。

早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。

如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”

对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel

但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。

事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。

如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：Testlink，或收费的独立平台: 如：TestRail

我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。

Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。

Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。

synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 Testlink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。

TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。

Testlink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。

TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。

综合考虑，虽然 Testlink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：

出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。

从官网介绍上可以看出，TM4J 还是比较现代化的：

首先我们看看利用 TM4J 如何来编写测试用例。

层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。

切换到 Test scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。

另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page

通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。

测试计划的创建本身操作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。

还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。

测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。

通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。

在新建完测试周期名称、描述以及详情之后。

进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。

这一步操作使得测试用例具备了项目属性。

最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。

通过查找来关联已经做好的测试计划。

创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。

对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行操作。统一平台的好处便是在此了。

虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。

TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。

我28了，想学点软件测试，请问看什么书好

测试入门
软件测试（第2版）
Software Testing (2e),Ron Patton
一本测试入门的好书，较全面地介绍了各种测试领域和方法，为测试新手提供了正确的观念和宽泛的基础。

软件测试工程师面试指导
蔡为东
面向初学者，介绍了软件测试行业、测试工程师素质要求、基本测试技术、求职策略、面试技巧、典型试题，对于测试新手或迈向测试行业的朋友有较高的参考价值。此书还收录了一些对读者来信的回复，内容涉及职业规划、大学生就业、测试学习、测试实践等，针对当前常见的困惑，做出了谨慎且深思熟虑的回答。附文《我在微软做软件测试外包》对于了解微软中国的流程与文化很有参考价值。

软件测试的艺术（第2版）
The Art of Software Testing (2e),Glenford J. Myers,Corey Sandler,Tom Badgett,Todd M. Thomas
一本“久经考验”的测试经典：1979年，第一版面试；25年后，第二版登场。平心而论，有些观点已经不能直接应用在测试实践中，但是仔细品味仍有所收获。毕竟，这是一本需要思考的书，而不是操作手册。
软件测试实战–测试Web MSN
蔡为东
以Web MSN为测试对象，形象生动地介绍了针对图形界面的黑盒测试技术，有很强的实践性。围绕一个实例，全面地的介绍各种测试方法，是此书区别于其他测试书籍的一大特色。附文《胶着》是作者一段开发经历的回顾与小结，有笑有泪，仅凭此文便值回书资。

通用测试技术
探索式软件测试（强烈推荐）
《探索式软件测试》涉及以下重要问题：为什么自动化测试无法消除所有缺陷，如何才能让这些缺陷无处遁形？哪些技术可帮助我不断发现和消除致命错误？如何更高效地进行手工测试，增加些许轻松和愉悦的感觉？对于每个项目，如何确定最高效的高级测试策略？在我无法进行全部测试时，哪些输入是必须测试的？哪些测试用例能提供最理想的特性覆盖率？在结合使用探索测试和传统脚本或场景测试时，如何才能获得理想效果？如何体现来自开发过程的反馈意见，代码更改吗？
计算机软件测试（第2版）
Testing Computer Software (2e),Cem Kaner,Jack Falk,Hung Quo Nguyen
一本值得反复参考的好书，”The bestselling software testing book of all time” 的美誉绝非浪得虚名。作者将多年的实践经验用平实的语言娓娓道来，内容涉及测试技术、测试管理、开发流程、思考方法、实践模式，可谓是一本测试典籍。部分内容看似有些过时，但是其思想和方法仍旧有很高的借鉴价值。
微软的软件测试之道
How We Test Software at Microsoft,Alan Page,Ken Johnston,Bj Rollison
微软的资深测试者审视微软当前的测试方法，并展望软件测试的未来发展。缺点是没有结合Windows或Office这样的著名且复杂的产品，详细讨论具体项目的具体技术。优点是提供了许多小故事，讲述了Windows、Office、Live等产品开发中的点滴。从经验传承、启发思路的角度，这些故事是全书的精华，具有很高的参考价值。
测试有道：微软测试技术心得
梁博,许珊,徐歆恺
内容由一系列技术点组成，每一个点都有精要的描述和作者的心得体会，力图以小搏大，以精粹胜广博。但是没有提供一个理论框架将这些点有机地联系起来，读起来有只见树木、不见深林之感，也缺少“授人以渔”的独到见解。最大优点是介绍了一批免费且实用的工具，可以放在案头备查。
软件测试基础:方法与度量
Software Testing Fundamentals: Methods and Metrics,Marnie L. Hutcheson
以风险分析为核心，讨论了测试计划、测试组织和测试设计。其中，关于“测试价值的可说明性”和“利用Office Suite来撰写、管理测试计划”的内容有启发性。适合有一定工作经验的测试人员参考。
软件测试（第2版）
Software Testing A Craftsmaj’s Approach (2e),Paul C. Jorgensen
将理论与工艺结合在一起的测试教科书。比较严谨地讨论了软件测试的基础理论，适合软件测试研究者研读。
面向对象的软件测试
A Practical Guide to Testing Object Oriented Software,John D. McGregor,David A. Sykes
介绍了面向对象软件测试的基本思路和方法。第7章“测试类的层次结构”比较有启发性，讨论了针对继承的测试设计和组织，相关内容在其他测试书籍中并不多见。
软件测试技术大全：测试基础、流行工具、项目实战
陈能技
该书由多位作者共同撰写，内容涉及测试理念、测试技术、测试开发、测试自动化、测试管理和常见的测试工具，不愧“测试大全”的书名。有些内容失之于粗糙，一些论述也不够严谨，缺乏参考文献更是此书的硬伤。瑕不掩瑜，此书理论和实践结合紧密，仍值得测试工作者学习和思考。
测试管理
笑傲测试–软件测试流程方法与实施
魏伟
以小说为体裁的测试管理书籍。通过令狐冲和风清扬的对话，从一个逐渐成长的新人的角度，介绍了测试管理的点点滴滴。全书轻松幽默，全无技术读本的枯燥乏味。附录所收录的文章“从新鲜人到新仙人”对于行业新人颇有帮助。
步步为赢–软件测试管理全程实践
蔡为东
以“管理就是负责人”为核心，介绍作者担当测试领导的切身经验：自我管理、自我成长、编写测试计划、编写测试用例、执行测试、沟通、测试计划/用例评审、测试总结、员工管理、测试思想等。也适合第一线的测试工作者阅读，所涉及内容皆和他们的日常工作密切相关。
专项测试技术
软件安全测试艺术
The Art of Software Security Testing: Identifying Software Security Flaws,Chris Wysopal,Lucas Nelson,Dino Dai Zovi,Elfriede Dustin
软件安全测试的入门书，用很短的篇幅涵盖了软件安全测试的多个领域，为测试人员提供了模型、方法和工具。对于Threat Modeling的介绍很精彩，为进一步的行动提供了良好的理论与实践基础。
Web安全测试
Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast,Paco Hope,Ben Walther
一本实践性很强的Web安全测试手册。从网络安全的角度，介绍了一批免费的网络通信分析、监控、修改、调试工具；以条目为组织，介绍了的测试方法或策略；以实践切入，穿插介绍理论知识，通过精心选材和组织，降低了Web安全测试的门槛。
实用软件测试指南
How to Break Software: A Practical Guide to Testing,James A. Whittaker
软件测试专家编写的实战指南，指导测试人员从攻击的角度展开软件测试。介绍了一些实用的测试工具，对于压力测试、极限测试有较强的参考价值。
软件测试新技术与实践
于秀山,于洪敏
介绍了组合测试技术在测试中的应用。适合组合测试研究者参考。
Web应用程序性能测试指南
Performance Testing Guidance for Web Applications,J. D. Meier,Carlos Farre,Prashant Bansode,Scott Barber,Dennis Rea
微软模式与实践(pattern & practices)团队的佳作，介绍了性能测试的正确观念、流程和实践。篇幅短小，内容深邃，值得在实践中反复参考和体会。
应用程序性能测试的艺术
The Art of Application Performance Testing: Help for Programmers and Quality Assurance,Ian Molyneaux
经验丰富的软件性能测试专家分享他的经验，内容包含性能测试的架构、模型、典型方法和结果分析。适合有一定经验的测试者参考。
测试自动化
.NET软件测试自动化之道
.NET Test Automation Recipes：A Problem-Solution Approach,James D. McCaffrey
该书讲解了在.NET平台上编写轻量级测试程序的实用技术。作者曾经在微软工作，该书与微软测试开发工程师的培训材料的契合度很高，实践性很强。对于Windows平台的测试工程师而言，此书的参考价值很高。
集成测试框架–用Fit进行敏捷软件测试
Fit for Developing Software: framework for Integrated Tests,Rick Mugridge,Ward Cunningham
Fit是一种编写系统测试的测试框架，作为一种业务交流工具，它深刻地反映出敏捷软件开发的若干特质。此书由Fit之父亲自编写，不但可以了解Fit的方方面面，还能从中体会大师的感悟与实践。
互联网单元测试及实践
陈卫俊,赵璨,周磊,陈洪
介绍了常见的单元测试框架，并结合具体项目讲解了单元测试的基本理论和技术。对于Web测试的新手，有较高的参考价值。

经验总结
软件测试经验与教训
Lessons Learned in Software Testing,Cem Kaner,James Bach,Bret Pettichord
值得反复研读的经典好书。Tom DeMacro的赞美——“这些经验中的任何一个，都抵得上这本书的价钱”，所言非虚。
完美软件–对软件测试的各种幻想
Perfect Software: And Other Illusions about Testing,Gerald M. Weinberg
该书没有介绍具体的软件测试技术，它讨论的是软件开发中的人、他们对测试的认知、软件测试的目的、实现目的的社会学和心理学上的探索。它试图建立正确的软件测试观念、协调的心理情绪和有效的思考方式。这些要素最终会决定在具体的项目中采用何种具体测试技术的组合。
赢在测试：中国软件测试先行者之道
蔡为东
介绍了一批测试先行者的个人经验的书。学习他人经验可以用较低的成本去扩大自己的体验，自然是他山之石可以攻玉，开卷有益。不过，个人经验非批判性地阅读与理解，不能有效，甚至有害，所以该书适合愿意学习且有能力学习的测试爱好者。不足是大部分被采访者都是管理者，没有真正的测试技术专家。
软件测试精要
董杰
作者分享他在测试领域的经验与思考，其热情和思辨跃然纸上。缺点是内容却有些散乱，即便是一章，其系统性也有些不足；对于测试工具背后的测试思想，挖掘得比较浅，没有上升到测试理论的高度。

（来源：学分高考 https://www.xuefen.net）文章共19903字